A benefits-eligibility scoring service needs low-latency access to the newest risk features at inference time, and it also needs historical feature snapshots for periodically retraining the model. Which SageMaker Feature Store design fits both needs?
Select an answer to reveal the explanation.
Short Explanation
Think of the online store like a cashier's till — fast, holds just today's numbers, built for instant lookups — while the offline store is the ledger in the back office holding the full history for later analysis. Inference needs that till: quick, current values for a single request. Retraining needs the ledger: a complete historical record to learn patterns from, which is exactly the split SageMaker Feature Store is built to offer.
Full Explanation
SageMaker Feature Store maintains two stores from the same feature group: the online store, backed by low-latency storage tuned for single-record reads at inference time, and the offline store, which lands time-stamped feature history in S3 for batch access during training or retraining. Using the online store for both jobs ignores that it's optimized for point lookups, not the large-scale historical reads a training job performs. Using the offline store for both jobs ignores that it's an S3-backed batch store with higher read latency than a live scoring endpoint can tolerate. Swapping the two — online for retraining, offline for inference — inverts the actual latency and volume profile each store was built for: retraining benefits from breadth of history, not millisecond response times, and a live endpoint can't wait on S3-backed batch reads. Scope note: both stores stay consistent because they're populated from the same feature group definition, so feature parity between training and serving isn't a separate integration problem to solve. Operational check: confirm feature values returned by an online GetRecord call for a given entity ID match the corresponding row in the offline store's latest snapshot before trusting the pipeline end to end.