Tutorial: Serve real-time Feast features with Aerospike

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:

Register two Feast feature views on one entity and materialize both into Aerospike with feast apply and feast materialize-incremental.
Inspect the shared Aerospike record layout and identify its storage benefit, shared TTL, and per-feature-view read behavior.
Observe a targeted Map CDT update when you materialize one feature view on a shared record.

Introduction

Imagine a logistics app that scores delivery drivers before assigning them rides. The scoring model needs two sets of values: the driver’s recent delivery stats from one data source, and a live demand adjustment from another. Different teams own those sources and update them on different schedules. At assignment time, the app needs both values together and fast.

Feast is an open-source feature store for machine learning. The Aerospike online store for Feast stores an entity’s feature views together on one Aerospike record.

This tutorial explains the Aerospike record layout Feast uses for collocated feature views and how Map CDT partial upserts protect data when teams update views independently. For the broader feature-store workflow with Spark and model serving, start with Part 1: Feature Engineering or the end-to-end Feature Store tutorial.

Why feature views share a record: When every feature view for one entity shares a single online record, that pattern is collocated feature serving. The Aerospike online store uses it to reduce record-key and primary index (PI) overhead as feature views are added.

One record per entity means fewer record keys and primary index entries as you add feature views. The tradeoff is that feature views on different schedules share one write target and one record-level time to live (TTL). A write that replaced the entire features map could replace another feature view’s values. Map CDT partial upserts update only the targeted feature view’s map entries inside the shared record.

For reads, TTL, and FeatureView.ttl, see Benefits and boundaries.

In this tutorial, you register two feature views on the same driver entity, materialize both into Aerospike, inspect the shared record layout, and observe a targeted update to one feature view.

Key terms

Term	Meaning
Entity	The object a feature describes, identified by a join key (for example, `driver_id`).
Feature view	A named group of related features for one entity, backed by a data source.
Offline store	The historical store (data warehouse, object storage, or local files) where raw feature values are held for training and backfill.
Online store	The low-latency store Feast reads from at inference time. It holds only the latest value per entity. Aerospike is one implementation.
`feast apply`	Command that reads your project’s Python definitions and registers the entities, feature views, and feature services in the Feast registry.
Materialization	The step that copies the latest feature values from the offline store into the online store.
`get_online_features`	The Feast SDK call that reads feature values for one or more entities from the online store.

When to use this pattern

Use this tutorial when you:

Serve features from more than one feature view for the same entity at inference time.
Need to understand how Aerospike stores collocated feature views before working with namespace overrides or push sources.
Want to see how Map CDT partial upserts work when feature views share a record and update on different schedules.

For related patterns on the same online store:

Tutorial: Route hot and cold Feast features to memory and flash when memory cost dominates and you need to separate hot and cold storage tiers.
Tutorial: Stream fraud velocity features with Feast when scoring depends on fresh writes from a streaming pipeline instead of batch materialization.

What you do

Register a driver entity with two feature views, driver_stats and pricing, and materialize both into Aerospike.
Read features from both feature views in one get_online_features call, then inspect the shared Aerospike record directly.
Materialize a new batch of driver_stats data only and observe that only the driver_stats map entries change on each record.

On the next page, you install Feast, the Aerospike Python client, and the Aerospike online store extra.