Feature Store Data Models
Feature store data models are the schema concepts that describe machine-learning inputs: entities being described, feature views grouping related features, feature values at a time, timestamps defining validity, and online keys used to fetch values during inference. They make offline training data and online serving data refer to the same facts.
The problem is that machine-learning features are not just columns in a table. They describe something, are computed at a particular time, and are later reused in a different runtime path. If those relationships are implicit, training data can accidentally include future information, serving code can fetch the wrong row, and two models can use features with the same name but different meanings.
A feature store model usually starts with an entity, such as a user, account, product, device, merchant, or transaction. A feature view is a named group of features for one or more entities, often sharing the same source data or transformation. A feature value is one computed value for one entity at one valid time. Timestamps let the store choose the latest value that existed before a label or prediction event.
The key mechanism is the point-in-time lookup. When building a training set, the feature store joins labels or prediction events to feature values using entity keys and event timestamps, selecting only values that were already valid. For online inference, the application supplies an online key, usually derived from the entity key, and the serving store returns the current materialised values for that key.
The trade-off is modelling discipline. Teams must decide which timestamp means event time, ingestion time, and computation time, and they must keep entity keys stable across pipelines and applications. This adds schema work and operational constraints. It is commonly misunderstood as merely feature naming; the harder part is preserving time semantics and key semantics across offline and online systems.
Engineers meet these models when defining feature views, backfilling historical training data, debugging training-serving skew, or wiring prediction services to an online store. The honest answer to many design questions is "it depends": feature view boundaries depend on ownership and refresh logic, entities depend on the prediction subject, and online keys depend on what the production request can actually provide.
Common questions
- What is the difference between an entity and an online key?
- An entity is the conceptual thing the features describe, such as a user or device. An online key is the concrete identifier used by a production service to retrieve feature values, such as a user identifier in a request. They often correspond, but the entity is the modelled subject while the online key is the serving lookup handle.
- Why are timestamps part of the data model?
- Features change over time, so a value is only correct relative to when it was known or valid. Timestamps allow point-in-time joins for historical training data and prevent future information leaking into examples. Engineers must distinguish event time, ingestion time, and computation time because each answers a different question.
- Is a feature view just a table?
- Not quite. A feature view may be backed by a table or transformation, but its meaning includes the entities it is keyed by, the features it exposes, and the timestamp semantics that define validity. Treating it as only a table misses the contract needed for safe reuse and online serving.