Advanced

Online/Offline Feature Serving

Understand the dual-store architecture of feature stores: offline stores for training data, online stores for real-time serving, and materialization strategies.

Offline Store

The offline store holds historical feature values for generating training datasets. It supports point-in-time queries to prevent data leakage.

Python - Offline Store Configuration (Feast)
# feature_store.yaml - Offline store options

# Option 1: File-based (development)
offline_store:
  type: file

# Option 2: BigQuery
offline_store:
  type: bigquery
  project: my-gcp-project
  dataset: feast_features

# Option 3: Redshift
offline_store:
  type: redshift
  cluster_id: my-cluster
  region: us-east-1
  database: features

# Option 4: Snowflake
offline_store:
  type: snowflake.offline
  account: my-account
  database: ML_FEATURES
  schema: FEAST

Online Store

The online store serves the latest feature values with low latency (single-digit milliseconds) for real-time inference.

Python - Online Store Options
# feature_store.yaml - Online store options

# Option 1: SQLite (development)
online_store:
  type: sqlite
  path: data/online_store.db

# Option 2: Redis (production, low latency)
online_store:
  type: redis
  connection_string: "redis-cluster:6379,password=secret"

# Option 3: DynamoDB (AWS, auto-scaling)
online_store:
  type: dynamodb
  region: us-east-1

# Option 4: Bigtable (GCP, high throughput)
online_store:
  type: bigtable
  project: my-gcp-project
  instance: feast-online

Materialization Strategies

Materialization is the process of computing features and populating the online store.

🕑

Scheduled Batch

Run materialization on a cron schedule (hourly, daily). Simplest approach. Features may be stale between runs.

⚡

Streaming

Continuously materialize from event streams (Kafka). Near real-time freshness. More infrastructure complexity.

🔄

On-Demand

Compute features at request time from raw data. Always fresh, but adds latency to serving. Use for simple transforms.

Python - Materialization Scheduling
from feast import FeatureStore
from datetime import datetime, timedelta

store = FeatureStore(repo_path="feature_repo/")

# Full materialization (backfill)
store.materialize(
    start_date=datetime(2026, 1, 1),
    end_date=datetime(2026, 3, 15)
)

# Incremental materialization (only new data)
store.materialize_incremental(end_date=datetime.now())

# In production, run this via Airflow/cron:
# feast materialize-incremental $(date -u +"%Y-%m-%dT%H:%M:%S")

Online Store Performance

Online StoreP50 LatencyP99 LatencyCost Model
Redis<1ms2-5msMemory-based (higher cost)
DynamoDB3-5ms10-20msRead/write capacity units
Bigtable3-5ms10-15msNode-based pricing
SQLite1-5ms10-50msFree (dev only)
✅
TTL management: Set appropriate TTLs (time-to-live) on your online store entries. Features for active users might have a 24-hour TTL, while features for all users might have a 7-day TTL. This controls online store size and cost.
💡
Point-in-time joins: The offline store performs point-in-time joins to prevent data leakage. For each entity-timestamp pair, it retrieves the feature values as they existed at that timestamp - not the latest values. This is critical for correct model training.

Ready to Go Deeper?

Live instructor-led courses from our partners. Affiliate disclosure.

🧠

AI & ML Courses - 30% Off

Live instructor-led AI, machine learning, data science, and cloud courses for working professionals. Use code Limited30 at checkout.

Edureka
📊

DataCamp - AI & Data Science

Hands-on Python, machine learning, and AI courses with interactive exercises and real projects.

DataCamp
🎓

edX - Top AI Courses

University-level AI courses from MIT, Harvard, Stanford. Earn certificates that employers recognize.

edX