Lakehouse, batch, streaming, and event time
Reliable batch and streaming systems agree on event identity and semantics while staying honest about when information became knowable.
A late feature silently corrupts every downstream prediction.
This chapter moves from separate the clocks to prove replay equivalence. 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.
Replay a bounded event range through batch and stream logic and compare keyed outputs, including duplicates and out-of-order arrivals.
Verify the behavior illustrated in daily_volume.sql, then measure decision utility, slice reliability, and system latency.
A backfill uses corrected future knowledge and silently inflates offline AUC. An unsafe release must degrade to a named baseline or the last known-good version.
Build the idea one layer at a time.
Batch and streaming are two ways of observing the same business history. The difficult part is not choosing a fashionable engine; it is preserving event meaning when records arrive late, are replayed, or are corrected.
Event time says when something happened in the domain. Processing time says when the platform handled it, and availability time says when a prediction system could actually know it. Watermarks express how long a stream waits for late events before considering a window substantially complete. They are latency-versus-completeness policies, not guarantees that no later data exists.
A lakehouse provides immutable or versioned columnar history for replay, backfill, and training. Streaming maintains low-latency views. To make them agree, use stable event identities, idempotent writes, explicit correction rules, and the same semantic transformation definitions across both paths.
- Flink/Spark
- Parquet/lakehouse
- watermarks
- feature stores
Follow the reasoning before touching the code.
- 01
Separate the clocks
Carry event_at, available_at, and processed_at so historical truth, knowable truth, and platform delay cannot be confused.
- 02
Choose lateness behavior
For each aggregate, state the watermark, correction window, and whether late records update, retract, quarantine, or wait for a batch repair.
- 03
Prove replay equivalence
Replay a bounded event range through batch and stream logic and compare keyed outputs, including duplicates and out-of-order arrivals.
WITH latest AS (
SELECT *, ROW_NUMBER() OVER (
PARTITION BY event_id ORDER BY available_at DESC
) AS revision
FROM transaction_events
WHERE event_at < TIMESTAMP '2026-08-29 00:00:00'
)
SELECT DATE_TRUNC('day', event_at) AS event_day,
SUM(amount_cents) AS volume_cents
FROM latest
WHERE revision = 1
GROUP BY event_day;Deduplicate events before an event-time aggregate
What to notice
- The business day is derived from event_at, while available_at selects the newest known revision of the same event.
- A replay cutoff is explicit, so rerunning against a later mutable table cannot silently claim to reproduce the earlier view.
YOUR TURN Pause and predict before revealing the answer.
A Monday event first arrives on Wednesday. Should it change Monday’s aggregate, Tuesday’s historical training row, both, or neither?
Need a hint?
Distinguish corrected business history from what was knowable at Tuesday’s prediction cutoff.
Check your reasoning
It can correct Monday’s eventual aggregate, but it must not enter a Tuesday training row that reconstructs Tuesday’s knowledge. The two views answer different temporal questions.
Lessons 1 in this course.
Connect the chapter to the course’s quantitative spine.
Reliable batch and streaming systems agree on event identity and semantics while staying honest about when information became knowable. The point-in-time feature lookup 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.
Point-in-time feature lookup
| Symbol | Meaning / shape / unit |
|---|---|
j | entity |
t_p | historical prediction time |
e | eligible event |
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: j, t_p, e.
- 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_c17(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: Reliable batch and streaming systems agree on event identity and semantics while staying honest about when information became knowable. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.
- 01
Turn “Separate the clocks” into a written invariant and a failing test.
- 02
Promote daily_volume.sql from illustration to a versioned implementation with representative fixtures.
- 03
Use “Prove replay equivalence” as the release checkpoint: Replay a bounded event range through batch and stream logic and compare keyed outputs, including duplicates and out-of-order arrivals.
- 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
A backfill uses corrected future knowledge and silently inflates offline AUC. 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.
Local mini ML platform
Specify idempotent events, a point-in-time join, shared feature definition, quality gates, lineage, and model registration.
- Data contract
- Late-event semantics
- Feature parity design
- Lineage/registry record
Read primary material with a purpose.
Return to the opening failure.
Make temporal correctness, ownership, lineage, reproducibility, and escape hatches the platform defaults.
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 a traced batch/stream platform with orchestration, registry, lineage, and ownership.