Feature Group

Every feature within a group originates from the same source system—whether a streaming event bus, a data warehouse table, or a real-time API. This co-location ensures that data lineage is traceable to a single point of origin. The group defines the connection parameters, schema mapping, and extraction logic once, applying it uniformly to all member features. This eliminates redundant pipeline definitions and enforces a consistent data contract between producers and consumers.

A Feature Group enforces a single materialization schedule for all its contained features. Whether the group is configured for streaming ingestion (sub-second updates via Change Data Capture) or batch computation (hourly/daily aggregations), every feature in the group shares the same feature freshness guarantee. This temporal consistency is critical for point-in-time correctness during training dataset generation, as it prevents joins between features that were updated at wildly different intervals.

All features in a group are keyed by the same primary entity (e.g., user_id, product_sku, session_id). This entity acts as the join key that stitches the group's features together into a coherent feature vector at serving time. The group explicitly declares its entity binding in the feature registry, allowing downstream consumers to understand which business objects the features describe without inspecting the underlying data.

The Feature Group serves as the atomic unit for versioning and metadata management in the feature registry. When the schema of a source table changes or a new transformation is introduced, a new version of the entire group is registered. This allows model training pipelines to pin to a specific group version, ensuring reproducibility. The group's metadata includes ownership, documentation, retention policies, and feature lineage that propagates to all member features.

A single Feature Group maps to a corresponding feature table in both the offline and online stores. In the offline store (e.g., Snowflake, BigQuery), it persists as a time-series table for large-scale training. In the online store (e.g., Redis, DynamoDB), it materializes as a low-latency key-value structure for real-time serving. This dual-store mapping is managed transparently by the feature store platform, abstracting the storage complexity from the data scientist.

Feature Groups are the primary unit of feature reuse. When published to the feature registry, a group becomes discoverable by other teams who can consume its features via a feature view without re-implementing the ingestion logic. This prevents duplicate pipelines and ensures that critical business metrics—such as customer_lifetime_value or product_affinity_score—are defined authoritatively once and consumed consistently across all models in the organization.

A logical abstraction that defines how raw data from one or more Feature Groups is transformed and joined to create a model-ready dataset. A Feature View specifies the exact entities, timestamps, and transformation logic required, acting as the bridge between feature engineering and model consumption. It ensures that the same logic is applied consistently during both training and inference.

The centralized metadata catalog that tracks every Feature Group, its schema, versions, lineage, and ownership. The registry promotes Feature Reuse by allowing data scientists to discover existing features instead of re-engineering them. It maintains strict Data Contracts to ensure that downstream consumers can trust the structure and semantics of the features they depend on.

The process of pre-computing feature values from a Feature Group's source data and persisting them into the Online Store or Offline Store. For real-time inference, materialization moves data from slow batch storage to a low-latency key-value store. The cadence of materialization directly determines a feature's Feature Freshness and its suitability for latency-sensitive use cases.

A critical data engineering guarantee when joining multiple Feature Groups for training. It ensures that feature values are reconstructed exactly as they existed at a specific historical timestamp, preventing data leakage from the future. A feature store must handle time-travel queries to accurately join a label at time t with features that were valid before time t.

The low-latency retrieval path that fetches pre-computed feature vectors from the Online Store at prediction time. The Serving API (typically gRPC or REST) looks up the latest materialized values for a given entity across multiple Feature Groups and assembles them into a single Feature Vector. A Feature Cache may sit in front to reduce database load for frequently accessed entities.

Automated guardrails that run before a Feature Group's data is written to the store or used in training. Validation checks include:

• Schema adherence: data types and nullability constraints
• Statistical properties: min, max, mean within expected ranges
• Feature Drift detection: comparing production distributions against a training baseline These checks prevent bad data from silently degrading model performance.