Batch, stream, and training-serving parity
Parity starts with one temporal meaning, then proves every execution path implements it.
Fraud labels arrive late and online features disagree with training data.
This chapter moves from specify the logical function to monitor live divergence. We will make the idea concrete in a small code example before placing it back inside a production system with a declared latency, cost, and operator-capacity budget.
Sample entities, recompute their features offline as of the logged cutoff, and alert on value or freshness mismatch.
Verify the behavior illustrated in parity_fixture.py, then measure decision utility, slice reliability, and system latency.
Joining only on customer ID attaches the present balance to every historical row. An unsafe release must degrade to a named baseline or the last known-good version.
Build the idea one layer at a time.
A feature definition is not correct merely because its batch query and streaming job share a name. They must produce the same value at the same logical cutoff.
Batch systems can revisit complete history; streams see events incrementally and must manage state, late arrivals, and watermarks. These different mechanics often drift around window boundaries, deduplication, or timezone handling.
Define semantics once—entity key, event eligibility, window endpoints, and availability—and test both implementations against shared event fixtures. Online freshness then becomes a monitored service-level property rather than a substitute for semantic parity.
- transform state
- watermarks
- label maturity
Follow the reasoning before touching the code.
- 01
Specify the logical function
Write the feature as a function of events and cutoff, including whether each window endpoint is open or closed.
- 02
Exercise both engines
Replay the same ordered and out-of-order fixtures through batch materialization and streaming state.
- 03
Monitor live divergence
Sample entities, recompute their features offline as of the logged cutoff, and alert on value or freshness mismatch.
from datetime import datetime, timedelta, timezone
def purchases_7d(events, customer_id, cutoff):
start = cutoff - timedelta(days=7)
return sum(
event["amount"] for event in events
if event["customer_id"] == customer_id
and start < event["event_time"] <= cutoff
)
utc = timezone.utc
cutoff = datetime(2026, 8, 29, 12, tzinfo=utc)
events = [
{"customer_id": "c1", "amount": 10, "event_time": cutoff - timedelta(days=8)},
{"customer_id": "c1", "amount": 25, "event_time": cutoff - timedelta(days=2)},
]
offline_value = purchases_7d(events, "c1", cutoff)
online_value = purchases_7d(list(events), "c1", cutoff)
assert offline_value == online_value == 25Use one cutoff definition to verify offline and online values.
What to notice
- The eight-day-old purchase is outside the open lower boundary, while the recent purchase contributes 25.
- A shared fixture states expected semantics; real batch and stream adapters can now be tested against the same oracle.
YOUR TURN Pause and predict before revealing the answer.
Add an event exactly seven days before cutoff. Should it count in this definition?
Need a hint?
Read the two comparison operators in the window predicate.
Check your reasoning
No. The lower boundary is open because the predicate is start < event_time; changing that decision requires a versioned feature definition.
Lessons 1, 2, 3 in this course.
Connect the chapter to the course’s quantitative spine.
Parity starts with one temporal meaning, then proves every execution path implements it. The feature availability invariant below is the shared course-level lens that helps quantify the surrounding system. Name each symbol, check its units or shape, and use only values that were available at the production cutoff.
Feature availability invariant
| Symbol | Meaning / shape / unit |
|---|---|
t_available | time the value became knowable |
t_decision | prediction cutoff |
f_i | feature i |
Open derivation and numerical substitution
Start from the production quantity being optimized, substitute the observed values with their declared units, then isolate the model-controlled term. Preserve shape annotations at each step so broadcasting or aggregation cannot silently change the result.
- Write the named inputs: t_available, t_decision, f_i.
- Substitute one small, hand-checkable batch before vectorizing.
- Calculate an independent reference value and compare within a declared tolerance.
# equation → code contract
inputs = validate_shapes_and_units(batch)
value = compute_c03(inputs)
assert is_finite(value)Change one assumption and make the tradeoff visible.
Use the worked chapter as your prediction, then change one input in the lab and explain why the output moves. The lab runs predefined TypeScript and never executes learner code, so the focus stays on the concept rather than setup.
Point-in-time freshness lab
Delay feature arrival and see which historical rows remain eligible.
Assumption: Five events have fixed prediction cutoffs separated by six hours.
Open nonvisual data table
| Item | Computed state | Interpretation |
|---|---|---|
| row 1 | cutoff +0h | not yet knowable |
| row 2 | cutoff +6h | eligible |
| row 3 | cutoff +12h | eligible |
| row 4 | cutoff +18h | eligible |
| row 5 | cutoff +24h | eligible |
Trace the complete operating path.
Carry the chapter’s central idea into the system: Parity starts with one temporal meaning, then proves every execution path implements it. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.
- 01
Turn “Specify the logical function” into a written invariant and a failing test.
- 02
Promote parity_fixture.py from illustration to a versioned implementation with representative fixtures.
- 03
Use “Monitor live divergence” as the release checkpoint: Sample entities, recompute their features offline as of the logged cutoff, and alert on value or freshness mismatch.
- 04
Serve or materialize behind explicit a declared latency, cost, and operator-capacity budget.
- 05
Join telemetry to mature outcomes and retain a rollback path.
Observability
Join service health, input quality, prediction distributions, slice behavior, and mature outcomes by exact version.
Cost
Measure storage, preprocessing, compute, queueing, and human review under a representative arrival pattern.
Failure modes
Joining only on customer ID attaches the present balance to every historical row. Add a detector, owner, mitigation, and stop condition for this class of failure.
Alternatives
Compare a rule, a simpler statistical baseline, and a different system boundary before adding model complexity.
Explain the contract, not just the vocabulary.
Point-in-time feature system
Design a versioned training set and online lookup from transaction, account, and outcome events.
- Contracts and lineage
- Temporal join specification
- Late-event/backfill policy
- Offline-online parity report
Read primary material with a purpose.
Return to the opening failure.
Version contracts, temporal joins, transform state, snapshots, backfills, and continuous offline/online parity checks.
For this lesson, the release evidence is the worked code example, a hand-checked formal result, deterministic simulation output, a ≥80% checkpoint, the production rubric, and a named fallback. The course resolves when the system can produce data contracts, point-in-time features, backfills, quality gates, and lineage.