Feature Table

Every row in a feature table is uniquely identified by an entity ID (e.g., user_id, product_sku) and a timestamp. This composite key ensures that feature values are correctly joined to the right business object at the right point in time. Without this structure, models would ingest misaligned data, leading to incorrect predictions.

Feature tables maintain a full history of values through time-series rows. Each update to a feature inserts a new row with a new timestamp rather than overwriting the old value. This enables point-in-time correct training dataset generation, where you can reconstruct the exact feature state as it existed historically, preventing data leakage from the future.

Feature tables enforce a strict schema defining column names, data types, and constraints. This contract is typically registered in the Feature Registry and validated on every write. Common types include:

• Numerical: FLOAT, INT64 for counts and ratios
• Categorical: STRING or BYTES for one-hot encoding
• Embedding: ARRAY<FLOAT> for dense vector representations

The same logical feature table is materialized differently depending on the store:

• Offline Store: Columnar formats like Parquet optimized for high-throughput batch scans during training
• Online Store: Row-oriented key-value stores like Redis or DynamoDB optimized for single-entity, low-latency lookups at inference time This dual physical layout is a core architectural pattern of feature stores.

A feature table belongs to a Feature Group, which bundles related features sharing the same source, entity, and update cadence. For example, a user_demographics group might contain age, income_bracket, and location_city columns. This grouping simplifies management, backfilling, and monitoring of features that logically belong together.

Each feature table carries metadata defining its maximum staleness—the acceptable age of a value before it is considered unreliable. A real-time feature like items_in_cart might require sub-second freshness, while a batch feature like lifetime_purchase_total can tolerate a 24-hour lag. This metadata drives monitoring alerts and materialization schedules.

The centralized platform that manages the full lifecycle of a Feature Table. It bridges the gap between data engineering and model serving by ensuring that the same transformation logic is used for both offline training and online inference, eliminating training-serving skew.

The low-latency database where a Feature Table is materialized for real-time serving. It is optimized for point lookups at millisecond speeds, typically using key-value stores like Redis or DynamoDB, to supply feature vectors during a prediction request.

The high-throughput storage layer where a Feature Table persists historical data for large-scale model training. It leverages distributed query engines like Spark or Snowflake to generate point-in-time correct training datasets from time-series feature values.

A logical abstraction that defines how a Feature Table is derived from source data. It specifies the transformation, join logic, and entity mapping, allowing data scientists to select a consistent set of features for a model without managing physical storage.

The critical guarantee that when a Feature Table is queried for a historical timestamp, it returns values exactly as they existed at that moment. This prevents data leakage by ensuring the model does not train on future information.

The low-latency retrieval process that reads pre-computed rows from a Feature Table in the online store and delivers them as a feature vector to a model endpoint. This is typically invoked via gRPC or REST at the start of an inference request.