MODELCATALOG

Data & preparation

Data & preparation

Feature Store

Centralizes reusable model features and can support both offline training and low-latency online retrieval.

Inputs

engineered feature rows + record id + event time

Outputs

offline historical features and optional latest online features

Core explanation

Feature Store is not mandatory for every model; I use it when feature reuse, consistency and online lookup justify the additional platform layer.

01

Mental model

What this means before worrying about syntax.

Use it when governed feature definitions need reuse across training and inference, especially when online retrieval matters.

  • Feature Group is the logical collection; record identifier + event time define records.
  • Online Store is for latest low-latency feature lookup; Offline Store retains historical feature values for training/batch.
  • The value is reuse, governance and training-serving consistency—not simply storing a table.
Lifecycle position
source data -> feature engineering -> Feature Store -> offline training / online inference
02

Implementation anatomy

The sequence you would actually build or configure.

  1. 1

    Define feature schema, record identifier and event time.

  2. 2

    Ingest via streaming/PutRecord or batch processing.

  3. 3

    Use offline history for training datasets.

  4. 4

    Use online lookup only for latency-sensitive serving features.

Objects / terms worth remembering
Feature GroupOffline StoreOnline Storerecord identifier
03

Concrete example

A real model-development or production flow.

1

card_id as record identifier

↓
2

tx_count_5m, amount_sum_1h, merchant_risk_score as features

↓
3

Offline history trains fraud model

↓
4

Online latest values enrich a live authorization

04

Implementation lab

Concrete code, data manipulation and configuration for this lifecycle step.

01

Create feature rows with record id + event time

python 
from datetime import datetime, timezone

features = {
    "card_id": "CARD-10439",
    "event_time": datetime.now(timezone.utc).isoformat(),
    "tx_count_5m": 4,
    "amount_sum_1h": 825.20,
    "avg_amount_30d": 76.42,
    "merchant_risk_score": 0.81,
}
02

Online lookup using Feature Store runtime

python

The Online Store lookup is by record identifier. Your application still has to parse and order the features for the model.

import boto3

fs_runtime = boto3.client("sagemaker-feature_store-runtime")

resp = fs_runtime.get_record(
    FeatureGroupName="card-behavior-features",
    RecordIdentifierValueAsString="CARD-10439",
)

feature_map = {
    f["FeatureName"]: f["ValueAsString"]
    for f in resp["Record"]
}

print(feature_map)
03

Point-in-time training idea

sql

This is the core of training-serving correctness: historical training rows must not receive future feature values.

# PSEUDOCODE / SQL SHAPE
# For each transaction at time T, select the latest feature record
# whose event_time <= T. Never use a feature value created after T.

SELECT t.transaction_id,
       t.card_id,
       t.event_time,
       f.tx_count_5m,
       f.avg_amount_30d
FROM transactions t
LEFT JOIN feature_history f
  ON t.card_id = f.card_id
 AND f.event_time <= t.event_time
QUALIFY ROW_NUMBER() OVER (
    PARTITION BY t.transaction_id
    ORDER BY f.event_time DESC
) = 1

Design decisions that matter

  • Which features truly need online storage.
  • Freshness SLA and update frequency.
  • Point-in-time correctness strategy.

Common failure modes

  • Online Store is not the historical training database.
  • Using future feature values during training creates leakage.
  • Feature Store does not automatically inject features into an endpoint request.

Production readiness check

Items to close before treating this step as production-ready.

✓ record identifier✓ event time✓ freshness✓ point-in-time correctness✓ online/offline consistency✓ access control