Practice: Feature stores and feature pipelines: offline/online consistency
Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.
Main tool: Feast · Feast is open source and runs entirely on a laptop with file-based offline and online stores, so you can practise the registry, point-in-time joins, materialization and online retrieval end to end without any cloud account. · Alternatives: Tecton is a managed feature platform that also runs the transformation pipelines for you; SageMaker Feature Store is a cloud-hosted offline and online store tied to one cloud account; Hopsworks is a full platform with its own storage and UI; a hand-rolled pairing of a warehouse such as BigQuery or Snowflake with Redis or DynamoDB gives the storage but leaves the registry and point-in-time joins to you.
Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1
Setup (one time)
1. Check that your laptop meets the quickstart prerequisites, in particular a supported Python version and a clean virtual environment.
Feast is a Python package with many dependencies, so an isolated environment keeps the later steps reproducible.
Explained in: Quickstart | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: An activated virtual environment reports a Python version the quickstart accepts.
2. Install Feast with the package installer into that virtual environment.
The same package provides the command line tool, the Python SDK and the local file-based stores used in every later step.
Explained in: Quickstart | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: The feast version command prints a version number.
3. Create a new feature repository with the feast init command and open the generated folder in your editor.
The generated repository holds sample driver data, example definitions and the store configuration file that the whole path builds on.
Explained in: Quickstart | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: The new folder contains a feature store configuration file, an example definitions file and a sample data file.
Steps
1. Run the sample workflow script that ships with the generated repository from start to finish.
One run shows the whole loop of register, historical retrieval, materialization and online retrieval before you take it apart piece by piece.
Explained in: Quickstart | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: The script finishes without errors and prints both a training dataframe and online feature values.
2. Write your own entity and feature view over the sample driver data in a new definitions file, with an explicit schema, a time to live and a timestamp field.
Entities and feature views are the core objects: they define a feature once so that training and serving read the same definition.
Explained in: Feature view | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: Your definitions file imports cleanly in Python and declares one entity and one feature view with named fields.
3. Create a feature service that groups the features one model version needs from your feature view.
A feature service is the named contract between a model and the store, and using the same one for training and serving is the main guard against skew.
Explained in: Feature retrieval | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: Your definitions file declares a feature service that lists your feature view or a selection of its features.
4. Run feast apply in the repository, then locate the registry file and the online store database it created and match each to its entry in the configuration file.
This makes the architecture concrete: the registry holds definitions, the offline store is the timestamped source data and the online store holds the latest value per entity.
Explained in: Quickstart | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: The apply output lists your entity, feature view and feature service, and you can point to the registry file, the source data file and the online store file on disk.
5. Run a historical retrieval with an entity dataframe that lists the same driver at two different event timestamps, one of them older than the time to live allows.
A point-in-time join returns for each row only the feature value known at that row's timestamp, which is what stops future data leaking into training.
Explained in: Point-in-time joins | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: The two rows for the same driver show different feature values, and the row outside the time to live window comes back with missing values.
6. Create a training set by querying your feature service, save it to a file, and compare it with one built from the equivalent list of feature references.
Persisting the training set and comparing both retrieval styles proves the feature service returns exactly the features you think the model was trained on.
Explained in: Feature retrieval | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: Both saved dataframes have the same columns and the same values for every entity row.
7. Run an incremental materialization to load the latest feature values from the offline store into the online store.
Materialization is the feature pipeline step that keeps the online store in step with the offline history, so its schedule sets how fresh served features are.
Explained in: Quickstart | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: The command reports the materialized time range for your feature view and exits without errors.
8. Query the online store through your feature service for one driver and compare the values with that driver's most recent row in the offline data.
Reading online and offline values through the same feature service and checking that they agree is the simplest manual test of offline and online consistency.
Explained in: Quickstart | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: The online values for the driver equal the values in the latest offline row for the same features.
9. Configure logging on your feature service, start the local feature server and send it a few online feature requests.
Serving through the feature server with logging on records the exact values handed to the model, which is the raw material for detecting training-serving skew.
Explained in: Feature Quality Monitoring | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: The feature server answers your requests and logged feature rows appear in the configured logging destination.
10. Compute metrics over the serving logs and compare them with the batch baseline metrics for the same features.
Comparing the distribution of served values with the distribution of the offline data turns skew from a suspicion into a number you can alert on.
Explained in: Feature Quality Monitoring | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: You can show log metrics and batch metrics side by side for at least one feature and say whether they diverge.
11. Write a CI workflow for the feature repository that previews definition changes on a pull request and runs feast apply on merge.
Treating definitions as reviewed code and applying them only from CI keeps the registry reproducible and stops ad hoc changes from a laptop.
Explained in: Running Feast in production (e.g. on Kubernetes) | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: A committed workflow file runs the plan step on a test pull request and shows the expected registry diff in its log.
12. Configure a database-backed registry using a local Postgres container in place of the registry file, then rerun apply, materialization and an online query against it.
A shared SQL registry is what production deployments use so that many clients and servers see the same definitions, and a local container is the closest laptop substitute for a managed database.
Explained in: Running Feast in production (e.g. on Kubernetes) | Feast: the Open Source Feature Store (docs.feast.dev), checked 2026-10-11
Done when: The registry tables exist in the Postgres container and the online query still returns the same values as before.
Back to Feature stores and feature pipelines: offline/online consistency