Feature View

A Feature View encapsulates the exact transformation logic applied to source data, ensuring reproducibility. It defines a point-in-time correct join between entities and their features.

• Captures SQL queries, Python transformations, or Spark jobs as code
• Ensures the same logic is used for both offline training and online inference
• Prevents the common training-serving skew caused by inconsistent implementations

Feature Views are bound to a specific Entity, such as a user_id or product_sku, which acts as the primary join key. This organizes features around business objects.

• A single Feature View can combine multiple Feature Groups sharing the same entity
• Enables the assembly of a complete Feature Vector for a prediction request
• Simplifies discovery by allowing teams to search for all features related to a specific entity

A defining characteristic is the ability to reconstruct feature values as they existed historically. The Feature View orchestrates temporal joins to prevent data leakage.

• Uses event timestamps to ensure only features available before a label's timestamp are joined
• Critical for training datasets where using future data would artificially inflate accuracy
• Enables accurate backfilling of historical feature values for new model development

Feature Views bridge the gap between batch and real-time systems by defining how features are served in both contexts from a single definition.

• Offline Serving: Generates large-scale training datasets from the Offline Store using distributed queries
• Online Serving: Provides low-latency feature vectors via the Online Store for real-time predictions
• The same Feature View definition guarantees feature parity between training and production

Feature Views are versioned, immutable assets registered in the Feature Registry. This promotes Feature Reuse across teams and models.

• Each change to transformation logic creates a new version, enabling safe rollbacks
• Teams can discover and consume existing Feature Views instead of re-engineering features
• Tracks Feature Lineage from raw source to consumption, simplifying auditing and debugging

Beyond static pre-computation, Feature Views can incorporate dynamic data that cannot be pre-materialized.

• On-Demand Features: Compute values at request time using client-supplied context, such as real-time geolocation
• Streaming Features: Ingest from Change Data Capture feeds or event streams for sub-second Feature Freshness
• Allows the same logical view to blend Batch Features, Streaming Features, and request-time context seamlessly

A low-latency database component designed to serve pre-computed feature vectors to models during real-time prediction requests. It prioritizes speed over storage capacity.

• Typical latency targets: < 10 milliseconds at the 99th percentile
• Common implementations include Redis, DynamoDB, and Bigtable
• Stores only the most recent feature values for active entities
• Populated by the materialization process from batch or streaming sources

A high-throughput, scalable storage component that persists historical feature data for large-scale model training and batch inference. It is optimized for analytical queries over massive time-series datasets.

• Built on data warehouses like Snowflake or data lakes on S3/ADLS
• Enables point-in-time correct training dataset generation
• Supports time travel queries to reconstruct historical feature states
• Stores years of feature history for retraining and backtesting

A centralized metadata catalog that tracks feature definitions, schemas, lineage, and versions. It promotes discovery and reuse across data science and engineering teams.

• Records the transformation logic defined in each Feature View
• Tracks feature ownership, documentation, and freshness SLAs
• Enables feature reuse to prevent duplicate engineering efforts
• Integrates with CI/CD pipelines for feature validation and deployment

A data engineering guarantee that feature values used for model training are reconstructed exactly as they existed at a specific historical timestamp. This prevents data leakage from future information.

• Critical for time-sensitive features like 'purchases in last 7 days'
• Requires joining feature tables using timestamp-accurate AS-OF logic
• Without it, models learn from data that would not have been available at prediction time
• Feature stores automate this through time travel query capabilities

The low-latency process of retrieving pre-computed or on-demand feature vectors from a feature store and delivering them to a model endpoint during an online prediction request.

• Uses high-performance Serving APIs via gRPC or REST
• Combines features from multiple Feature Groups into a single vector
• May leverage a Feature Cache to reduce database load
• Must meet strict latency budgets, often under 5 milliseconds