Материализация признаков в оперативное хранилище

Your features sit in batch storage, but predictions need them in milliseconds. Materializing copies the latest values into a fast online store. ⚡

The offline store is great for history but scanning Parquet at request time would be far too slow for live serving.

The online store is a key-value database, often Redis, that returns the newest feature for an entity almost instantly.

The online store keeps just the most recent value per entity, not the full timeline. It is optimized for now, not for the past.

The feast materialize command moves feature values from the offline store into the online store for a time range.

Use materialize-incremental to load only what is new since the last run, so you do not reprocess everything each time.

Schedule materialization on a cron so the online store stays fresh. Stale features quietly hurt prediction quality.

At prediction time call get_online_features with the entity rows you care about, and Feast returns ready-to-use values.

Call to_dict on the result to get a plain Python dictionary you can feed straight into your model.

If a feature is older than its ttl, Feast returns null online. That is your signal to materialize more often.

So the flow is: write features, materialize to the online store, then read them fast per request. That last hop is what makes real-time serving work. 🚀

Which command loads features into the online store?

You materialized features into a fast online store, kept them fresh with incremental loads, and read them at serve time with get_online_features. Next, you'll get the timing exactly right.