SageMaker Feature Store: online and offline

Lesson 4 of 5 in Ingesting and Storing Training Data.

Here is the failure a feature store exists to prevent. The training pipeline computes avg_spend_30d in SQL over the warehouse; the inference service recomputes it in Python from a cache. The two definitions drift by one rounding rule — and the model quietly scores production traffic on numbers it never saw in training. That is training/serving skew, and the exam names it.

SageMaker Feature Store fixes it by making features compute-once, read-twice. Features live in feature groups (a record identifier plus an event time, then the feature columns), written through one ingestion path and read through two doors: the online store serves single-record GetRecord lookups at request latency for inference, and the offline store keeps the full append-only history in S3 for building training sets.

Ingestion mechanics worth knowing: a synchronous PutRecord writes a feature row to the online store immediately and a copy lands in the offline store (S3) shortly after; batch pipelines — a Data Wrangler export job or the Feature Store Spark connector — can also fill the offline store directly. The offline store registers its tables in the Glue Data Catalog, so Athena builds training sets straight from it, including point-in-time queries that use each record's event time to reconstruct exactly what was knowable at prediction time — the honest way to avoid leaking future values into training (module 3 returns to this).

Key terms: SageMaker Feature Store, Online store (Feature Store), Offline store (Feature Store), Training/serving skew

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.