Tutorial: Route hot and cold Feast features to memory and flash
For the complete documentation index see: llms.txt
All documentation pages available in markdown.
Objectives
By the end of this tutorial, you will be able to:
- Validate the
namespace_overridesstructure locally and identify the namespace changes required for production tiering. - Identify the storage benefit, read tradeoff, and local-demo boundary of namespace routing.
- Define hot-only and full
FeatureServiceobjects, then compare the feature views each service requests.
Introduction
Imagine an online store whose recommendation model ranks products for a user on every page view. The ranking reads a few fast-changing signals, such as how many items the user viewed and how much they spent in the last hour. That same user also has slower-moving profile values, such as lifetime value and a category affinity score, that only a nightly email campaign job and an internal analytics dashboard read. Everything lives in the same online store, so the profile values occupy memory even though nothing on the ranking path reads them.
Aerospike storage tiers differ in read speed and in cost per byte: memory serves reads faster, and flash holds far more data for the same money. If your online feature set is large but only a small part of it needs the fastest reads, routing the rarely read feature views to flash reduces memory use without adding separate infrastructure.
Feast routes feature views to Aerospike namespaces through namespace_overrides in feature_store.yaml. Aerospike hybrid memory architecture and device paths are set in aerospike.conf. Feast only needs the namespace name.
Why route feature views by storage need: Tiering means routing different feature views to different storage namespaces based on how often they are read and how much latency they can tolerate. Hot feature views can use an in-memory namespace when they require lower read latency than flash storage. Cold feature views use flash storage instead of memory.
| Tier | Example | Aerospike namespace |
|---|---|---|
| Hot | scoring_velocity: item views and spend in the last hour, read on every ranking request | Memory namespace (for example feast_ram) |
| Cold | user_profile_wide: lifetime value and affinity score, read by the nightly campaign job and the analytics dashboard | Flash namespace (for example feast_ssd) |
The tradeoff is that every requested feature view still adds a read call, and flash-backed calls can take longer than memory-backed ones. A hot-only FeatureService keeps cold views off the latency-sensitive ranking path.
The local demo uses one Docker namespace. See Benefits and boundaries for what it verifies and what production tiering requires.
The same shared-record behavior from Tutorial: Serve real-time Feast features with Aerospike applies to feature views that resolve to the same namespace and set.
Key terms
| Term | Meaning |
|---|---|
| Tiering | Routing different feature views to different Aerospike namespaces based on how often they are read and how much latency they can tolerate. |
namespace_overrides | Feast configuration field in feature_store.yaml that maps feature view names to Aerospike namespaces. |
feast apply | Command that reads your project’s Python definitions and registers the entities, feature views, and feature services in the Feast registry. |
Hot FeatureService | Groups only latency-critical feature views on one tier. |
Full FeatureService | Groups hot and cold views when a background or lower-priority consumer, such as a campaign job or a dashboard, needs both tiers. |
| Cross-namespace read | A request whose feature views resolve to more than one Aerospike namespace. Feast still issues one read per feature view. |
When to use this pattern
Use this pattern when you:
- See memory-store bills growing faster than traffic.
- Have many features per entity but only a small subset on the real-time ranking path.
- Need a governed YAML route from one Feast project to memory and flash namespaces.
Skip tiering when your entire online working set is small and every feature needs the same low latency. A single namespace requires less operational work.
What you do
- Validate a local
feature_store.yamlstructure with a default namespace andnamespace_overrides. - Define
scoring_velocity(hot) anduser_profile_wide(cold) feature views plus hot-only and fullFeatureServiceobjects. - Materialize both views and compare the feature views requested by each service.
To implement physical tiering, configure separate memory and flash namespaces in aerospike.conf, then replace the two test values before feast apply.
On the next page, you install Feast and Aerospike locally.