Features & Feature Stores

A model sees the world only through its features. The previous chapter showed what happens when features are computed carelessly. A feature store is the system that makes them consistent: it computes each feature once, stores it, and serves the same value to training and to production.

Picture a restaurant group with ten kitchens. If every chef prepares their own stock, the flavor varies, work is duplicated, and nobody knows which batch went into which dish. A shared pantry fixes it. Each ingredient is prepared once, labeled, and dated. A chef who wants to reproduce last month's dish can ask for the pantry as it stood on that day. A feature store is that pantry, and "as it stood on that day" is the idea of point-in-time correctness.

• -Entity attributes: slow-changing facts, like a user's country or an item's category.
• -Behavioral aggregates: summaries over a window, like orders in the last 30 days or average session length.
• -Context at request time: values known only when the request arrives, like device, time of day, and current location.
• -Embeddings: vectors learned from data, such as a user's taste vector.
• -Cross features: combinations, like a user's country with the item's category.

They differ in how fresh they must be. A country changes rarely, so a daily batch job is enough. A count of the last five minutes of clicks changes constantly, so it needs a streaming job or a computation at request time. Freshness costs money, so match each feature to the staleness the model can tolerate.

• -The offline store holds the full history of every feature, usually in a warehouse or data lake. Training reads from it, in bulk.
• -The online store holds only the latest value for each entity, in a key-value database built for lookups in a few milliseconds. The model server reads from it on every request.
• -The same jobs write to both, so a feature has one definition. Eugene Yan's survey of industry systems notes that using one feature store for both training and serving limits skew.

When you build a training set, each example has a date, the day its label was decided. For each example you need the value of every feature as it was known on that date. A naive join grabs the latest value in the table, which includes everything that happened after the label. That is leakage.

The code keeps a history of one customer's "orders in the last 30 days" value, with the day each value took effect. Three training examples, with their label dates, are joined two ways. Press Run, and look at the "leaked" column.

The naive join gives every example the value 8, the latest one. For the example on day 12, the true value that day was 4, and for day 25 it was 5, so those two training rows were handed information from days 35 and later. Only the example on day 40 is correct, and by luck. A feature store with point-in-time retrieval does the as-of lookup for you across millions of examples.

• -Worth it when many models share features, when online and offline values must match exactly, or when real-time features need a reliable, low-latency lookup.
• -Not needed for one model, a small team, and features computed from a single table. A well-tested shared library and logged serving features can give most of the benefit.
• -Real costs: another platform to run, a schema to keep, and backfills when a feature definition changes.