Streaming Features

A centralized platform that manages the engineering, storage, and serving of machine learning features for both training and real-time inference. It ensures consistency between online and offline environments, acting as the single source of truth for all feature data. A feature store typically includes a feature registry for metadata management, an offline store for historical data, and an online store for low-latency serving.

• Eliminates training-serving skew
• Enables feature reuse across teams
• Provides point-in-time correct historical snapshots

A low-latency database component of a feature store designed to serve pre-computed feature vectors to machine learning models during real-time prediction requests. It is optimized for high-throughput reads at sub-millisecond latencies, often using in-memory caches like Redis or DynamoDB. The online store is populated by the materialization process, which pushes the latest feature values from the offline or streaming layer.

• Must support point lookups by entity ID
• Requires high availability for production inference
• Often paired with a feature cache for hot data

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. This is typically done via a Serving API using gRPC or REST protocols. The serving layer must handle entity lookups, join features from multiple feature groups, and assemble the final feature vector within strict latency budgets.

• Combines streaming and batch features at request time
• Must handle missing or stale feature values gracefully
• Critical path for model inference latency

A metric defining the maximum acceptable age of a feature value in the online store, ensuring models do not act on stale data. For streaming features, freshness is measured from the time an event occurs to the time the updated feature value is available for inference. Tight freshness SLAs (e.g., < 1 second) require stream processing engines like Apache Flink or Kafka Streams.

• Directly impacts model accuracy for time-sensitive use cases
• Monitored via data observability dashboards
• Trade-off between freshness and infrastructure cost

A pattern for detecting and ingesting row-level changes in operational databases in real-time to update feature values in the online store with minimal latency. CDC tools like Debezium tail database transaction logs and stream insert, update, and delete events to Apache Kafka. This enables feature stores to react to source data changes without batch ETL delays.

• Eliminates polling overhead on source systems
• Provides an ordered, replayable event stream
• Essential for maintaining feature freshness from transactional data

The process of pre-computing feature values from source data and persisting them into an online or offline store to accelerate retrieval during training or inference. For streaming features, materialization happens continuously as events arrive, updating the online store in near real-time. This contrasts with batch materialization, which runs on a schedule.

• Transforms raw events into model-ready feature vectors
• Can involve aggregations like rolling window sums
• Managed by the feature store's orchestration layer