Feast

Feast guarantees point-in-time correctness when generating training datasets. It reconstructs feature views exactly as they existed at a specific historical timestamp, preventing data leakage from future information. This is achieved by joining time-stamped feature rows to entity event timestamps, ensuring that a model trained on historical data sees only the features that would have been available at prediction time.

Feast abstracts the storage layer, allowing teams to pair a high-throughput offline store (e.g., BigQuery, Redshift, Snowflake) for batch training with a low-latency online store (e.g., Redis, DynamoDB, Datastore) for real-time serving. This decoupling ensures that training pipelines do not impact production inference performance and vice versa.

A centralized feature registry catalogs all feature definitions, schemas, and metadata. This promotes feature reuse across teams by allowing data scientists to discover and consume existing features via the Feast SDK rather than re-engineering them from scratch. The registry tracks lineage and versions, serving as a single source of truth.

Feast supports both batch features computed on static datasets and streaming features ingested from real-time event sources like Kafka. This hybrid ingestion model allows models to combine long-term user trends with immediate behavioral signals, such as session clicks, within a single feature vector.

Feast provides a high-performance serving API (gRPC and REST) designed for online inference. It retrieves pre-computed feature vectors from the online store in single-digit milliseconds. The SDK supports native integration with Python, Java, and Go, allowing model serving infrastructure to request features with minimal overhead.

For context that cannot be pre-computed, Feast supports on-demand features. These are computed at request time using user-provided transformation logic applied to raw data passed in the serving request. This is critical for handling real-time context like a user's current cart contents or geolocation that must be transformed just before prediction.

The low-latency database component where Feast persists pre-computed feature vectors for real-time serving. During a prediction request, the model retrieves the latest values for a specific entity with millisecond latency. Feast supports pluggable backends like Redis and Google Cloud Datastore, allowing architects to choose the infrastructure that meets their specific SLAs.

A critical data engineering guarantee preventing training-serving skew. When constructing a training dataset, Feast joins feature values to an entity's event timestamp, ensuring only data that existed before that moment is used. This prevents data leakage where future information accidentally informs the past, a common pitfall in naive timestamp joins.

The centralized metadata catalog that tracks every feature's definition, schema, and lineage. It acts as a single source of truth, enabling teams to discover and reuse existing features via the Feast SDK. This promotes feature reuse and prevents duplicate engineering efforts across different model teams within an organization.

The process of pre-computing feature values from the offline store (e.g., Snowflake, BigQuery) and pushing them into the online store. Feast schedules this as a periodic batch job, ensuring the online store contains fresh aggregations. This decouples heavy historical computation from the lightweight, low-latency read path required for inference.

A logical abstraction representing a specific transformation on source data. A Feature View defines how Feast should select, join, and aggregate raw data to produce a consistent set of features. It is the primary object a data scientist defines to tell Feast: 'This is the data I need for my model, and here is how to build it.'

A pattern for computing feature values at request time using data passed directly in the prediction payload. This is essential for context that cannot be pre-computed, such as the current contents of a user's shopping cart or a real-time geolocation coordinate. Feast executes these transformations via a Python UDF within the serving path.