Data Systems

Feature Stores

A feature store is a shared registry that computes, stores, and serves the engineered inputs a model consumes during training and inference.

What a feature store solves

Machine-learning models rarely consume raw records. They consume features: aggregations, encodings, ratios, and lookups derived from raw data. Without a shared system, each team recomputes these transformations in ad-hoc scripts, and the definition of a feature drifts between the training pipeline and the production service. A feature store is the piece of infrastructure that gives a feature a single canonical definition, a place to live, and two matched paths for delivery.

Training-serving skew

Kronos motion — pid vs model

The central failure a feature store prevents is training-serving skew: the model learns on one computation of a feature and is scored on a subtly different one. A classic example is an average that is computed over a 30-day window in the batch training job but over a calendar month in the online service. The distributions no longer match, and accuracy degrades in ways that are hard to trace. A feature store forces both paths to reference the same transformation logic.

Core components

A registry of feature definitions with owners, types, and freshness expectations
An offline store (columnar, high-throughput) for building training sets
An online store (low-latency key-value) for inference lookups
A transformation layer that materializes features from source data
Point-in-time-correct join logic to assemble label-aligned training rows

Point-in-time correctness

When you build a training set you must join each label to the feature values as they were known at that instant, never later. Joining to the current value leaks future information and inflates offline metrics. Feature stores implement point-in-time joins (also called as-of joins) so a label from a given timestamp only sees features that existed at or before it.

When you need one

A single model maintained by one team may not justify the overhead. Feature stores earn their place when many models reuse the same features, when the same feature must be served online and offline, or when regulatory review demands a documented lineage from raw data to model input. In a research-heavy setting such as fusion diagnostics, a feature store lets a shared library of derived plasma and sensor quantities be reused across many downstream analyses without each analysis re-deriving them differently.