DATA ARCHITECTUREML

ML Feature & Feature-Store Modeling

How data engineers design data that lasts — pick a topic on the left and its full breakdown loads here: the mental model, ERDs and worked schemas, trade-offs, edge cases, and the decisions that separate a durable model from a fragile one.

⏱ 18 min readTopics chapter readerLevel · Specialized & Applied
01 · Orientation

What You'll Master Here

A feature is a value about an entity AS OF a point in time. Modeling features is mostly about getting that timestamp right.

⏱ 4 min · Topic 1 of 7

Machine learning models do not consume raw tables, they consume features: numeric or categorical signals about an entity. Modeling them well is a distinct discipline with one dominant concern — time. Get it wrong and the model looks brilliant in testing and fails in production. No ML background is assumed; feature bugs are data-modeling bugs about time, not algorithm bugs.

The four questions below are the whole chapter, in the order they have to be answered. Step through them: each one names the failure you get by skipping it, and jumps to the topic that fixes it.

Core mental model

A feature is a value about an entity AS OF a point in time. Modeling features is mostly about getting that timestamp right.

Why it matters

Most ML production failures are feature problems: leakage that inflates offline accuracy, or skew that makes serving differ from training. Both are data-modeling mistakes.

feature
A signal about an entity used by a model (e.g. sessions_7d for a player).
point-in-time correctness
Using each feature's value as it was at the label's timestamp, never later.
data leakage
Letting future information into training, inflating offline accuracy unrealistically.
feature store
A system serving consistent features to both training (offline) and serving (online).
Four questions, in order, for one featureLarkspur Games predicts whether an Ember Isles player will stop playing. The feature is sessions_7d. Answer these four in order and the rest of the chapter is bookkeeping; skip any one and it has a name.
As of when was this value true?P-101 had 3 sessions on 1 March and 0 today. A label dated 1 March must read 3. Every stored value carries the instant it was true.
Skip this question and you getLeakage. The offline score is inflated by activity that had not happened yet, and nothing in the code looks wrong.
Common mistake

Treating feature engineering as modelling work rather than data modelling. The four questions below never get asked, and every one of them fails silently — no exception, no failed test, just a number that was never true.

Better habit

Write the feature definition down before writing the query.

Ask "as of when?" before "which columns?".

Compare the offline metric against the live one before believing either.

The big idea

Feature modeling is temporal modeling for ML. The hard part is always "as of when?", and the answer must be the label's time, not now.

Remember this

Features are entity values as of a point in time; point-in-time correctness and training-serving consistency prevent the most common ML failures.