Feature stores
Sharing and serving the same features between training and production, from the training-serving skew that silently degrades models to a full Feast setup on a card-fraud scoring use case.
Course Duration: 5h
What You'll Learn
- Diagnose training-serving skew from evidence, not from intuition
- Describe the anatomy of a feature store: registry, entities, feature views, offline and online stores
- Choose between offline and online serving for a given feature and a given consumer
- Define and version features so evolving them does not break existing models
- Write a point-in-time correct join that no longer leaks the future into training
- Materialize features at the right frequency and measure freshness at the endpoint
- Operate a Feast repo end to end:
apply,get_historical_features,materialize,get_online_features - Share features across teams without turning duplication into a governance problem
- Monitor feature quality upstream of the model, before drift reaches predictions
- Decide, on a real use case, when a feature store actually pays for itself and when it does not
Prerequisites
- Feature engineering (course 06): why the raw column is rarely the useful one
- MLOps (course 20): reproducibility, tracking, drift monitoring, deployment
- Python, pandas and a first exposure to Parquet and Redis
Course Modules
- Training-serving skew and its consequences
- Anatomy of a feature store
- Offline and online store
- Defining and versioning features
- Point-in-time correct joins
- Materialization and freshness
- Feast in practice
- Features shared across teams
- Monitoring feature quality
- Project: a feature store for a scoring use case
The thread running through the course
A single business use case runs through every module: card-payment fraud scoring. The features are the ones any anti-fraud team keeps recomputing — number of transactions over the last 1 h, 24 h and 7 days, average amount, distance from the previous purchase, share of night-time transactions. Each of those must be identical between the day the model was trained and the millisecond the payment terminal asks for a decision. We first show the skew that appears when they are not, then we fix it: an offline store on Parquet, an online store on Redis, definitions versioned in a Feast repo, point-in-time joins on transaction timestamps, materialization every fifteen minutes, alerts on freshness.
Around the fraud team, a marketing team will also want the same "average transaction amount over 30 days" feature. That shared use case makes the case for a feature store concrete: it exists to be shared, not just to be stored somewhere central.
Assessment and certificate
The course ends with a 40-question exam covering every module. It is judgment that is assessed — reading a leak in a naive join, spotting a stale feature, choosing between two materialization frequencies — not the recitation of Feast commands. On success, a certificate of completion is issued immediately; its number is verifiable on the platform.
Free courses, by contrast, end with a 5-question quiz and a preview of the certificate, without certification.