Comparison
Streaming joinvsTemporal join
Streaming join
you need the click matched to the impression, and one of them is always five minutes behind the other.
Joining two unbounded inputs, which requires holding one side's records in state long enough for the other side to show up. That retention window is the join's cost and its correctness bound at the same time: too short and you miss real matches, too long and state grows without limit. Unlike a batch join, an unmatched row is not necessarily a data error — it may simply be early.
Full entry →Temporal join
you priced the order using the exchange rate as it was at the moment of the order, not the rate as it is now.
Joining a stream of events to the version of a reference table that was current at each event's own event time. It is what stops a re-run producing different numbers, because the enrichment stops depending on when you ran it. Building it requires the reference data to be versioned rather than overwritten, which is the practical reason slowly changing dimensions and streaming enrichment turn out to be the same problem.
Full entry →