Topic 3 of 7

Offline Online Feature Separation

Learn Offline Online Feature Separation for free with explanations, exercises, and a quick test (for MLOps Engineer).

Published: January 4, 2026 | Updated: January 4, 2026

Why this matters

Point-in-time join (SQL-ish):

SELECT r.request_id, r.driver_id, r.zone_id, r.request_time,
       z.avg_speed_15m, z.pickup_demand_30m, d.driver_util_1h
FROM requests r
LEFT JOIN zone_features z
  ON r.zone_id = z.zone_id AND z.event_time <= r.request_time
QUALIFY ROW_NUMBER() OVER (PARTITION BY r.request_id ORDER BY z.event_time DESC) = 1
LEFT JOIN driver_features d
  ON r.driver_id = d.driver_id AND d.event_time <= r.request_time
QUALIFY ROW_NUMBER() OVER (PARTITION BY r.request_id ORDER BY d.event_time DESC) = 1;

I defined entities, windows, freshness, TTL.
I wrote an offline storage and cadence plan.
I described online updates and fallback.
I wrote a point-in-time join.

Common mistakes and self-check

Training-serving skew: transforms differ between offline and online. Self-check: compare 1000 sampled entities; value diffs within tolerance?
Data leakage: using future data in training join. Self-check: verify all joins enforce event_time ≤ label_time.
Wrong join keys: missing entity or dimension. Self-check: uniqueness checks on keys and null-rate alerts.
TTL too long or short: stale features or high churn. Self-check: monitor freshness vs model AUC/latency.
Non-idempotent writes: duplicate features after retries. Self-check: use upserts keyed by entity + event_time + version.
Type mismatches: float vs int, enum drift. Self-check: schema registry and validation on write.

Mini challenge

Pick one of your current model features. Write a 5-line feature contract with: name, entities, dtype, freshness SLA, TTL, and backfill window. Then list the parity metric you will monitor and its acceptable threshold.

Who this is for

MLOps and ML platform engineers building training and serving pipelines.
Data scientists who need reliable, consistent features in prod.

Prerequisites

Comfort with SQL for aggregations and joins.
Basic streaming/batch concepts.
Understanding of keys, time columns, and windowing.

Learning path

Understand feature contracts and entities.
Master point-in-time joins and backfills.
Implement online materialization with TTL and freshness SLOs.
Add parity testing, monitoring, and recovery playbooks.

Practical projects

Project A: Build a small offline store with 30 days of user events; compute 7d/1d features and produce a point-in-time training table.
Project B: Create an online materializer that maintains rolling counts and exposes reads by user_id with TTL and staleness flags.
Project C: Implement a parity test job that samples entities daily and reports drift metrics with thresholds and alerts.

Next steps

Add recovery: backfill a missed day and verify idempotency.
Tune TTLs based on observed volatility and serving costs.
Expand parity checks to include distribution comparisons (KS test or percentiles).

Ready to check your understanding? Take the quick test below. Your progress is saved when logged in.

Practice Exercises

1 exercises to complete

Instructions

Create a concise design doc for ETA features that covers:

5–8 features with entities, windows, freshness, TTL, and defaults.
Offline computation plan (cadence, event_time, partitions).
Online update strategy (streaming/incremental) and fallback.
Point-in-time join for training (SQL or pseudocode).

Expected Output

A 1–2 page design with feature contracts, offline/online plans, and a point-in-time join snippet.