Skip to main content

Feature Stores and Feast

A feature store coordinates definitions, historical retrieval, materialization, and online lookup. It is not automatically necessary, and it does not remove the need to define event time, availability time, entities, freshness, and ownership. Study Sprint uses two numeric fields and one category, so shared preprocessing in its inert model is the smaller solution.

Prerequisites​

Complete DVC Data Pipelines and Offline–Online Feature Consistency.

Learning goals​

  • distinguish offline historical retrieval from online latest-value lookup.
  • require point-in-time joins that respect when features became available.
  • decide whether a feature store solves a real reuse or latency constraint.

Worked example​

Feast 0.67.0 is the stable PyPI release checked for this lesson. Its maintained concepts include entities, file or database sources, feature views, a registry, historical retrieval, materialization, and online retrieval. A minimal definition has this shape:

from datetime import timedelta
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, String

student = Entity(name="student", join_keys=["student_id"])
activity = FileSource(
    path="data/student_activity.parquet",
    timestamp_field="event_timestamp",
)
student_activity = FeatureView(
    name="student_activity",
    entities=[student],
    ttl=timedelta(days=30),
    schema=[
        Field(name="prior_score", dtype=Float32),
        Field(name="practice_minutes", dtype=Float32),
        Field(name="learning_track", dtype=String),
    ],
    source=activity,
)

The entity dataframe passed to FeatureStore.get_historical_features(...) needs an event timestamp for each training row. Retrieval must choose values available at that time, not the newest value now. After feast apply and bounded materialization, get_online_features(...) looks up the current entity values; parity tests still need to compare definitions, types, defaults, and freshness between both paths.

This is a manual boundary: Feast is not installed or executed in CI. Its dependency surface and local registry/store files are disproportionate for the three committed Study Sprint features. Try the example in an isolated environment pinned to feast==0.67.0, with a local file offline store and SQLite online store, only after supplying timestamped local data.

A plain file, database view, or shared preprocessing library is sufficient when one model owns a small batch dataset and online lookup is unnecessary. A feature store earns its cost when many models reuse governed definitions, point-in-time training sets are hard to reproduce, or strict online latency and freshness require managed materialization.

Common mistakes​

  • Joining training rows to the latest feature value and leaking the future.
  • Using event time when the value was not actually available until later.
  • Assuming offline and online stores have identical freshness or null behavior.
  • Materializing personal or sensitive attributes without purpose and retention controls.
  • Adopting a feature store before naming producers, consumers, and on-call owners.

Practice​

Draw timestamps for an assessment at 10:00, a source event at 09:55, and ingestion at 10:05. Decide whether the feature is valid for a 10:00 prediction and for a training job run the next day.

Next steps​

Continue with CI for Machine Learning to make lifecycle contracts block unsafe changes before merge.

Primary sources​

Checked 2026-10-15: Feast feature views, Feast point-in-time joins, Feast Python API, Feast local provider, and PyPI Feast 0.67.0.