Joins — regular, interval, temporal (point-in-time) & lookup

5 h
requires FLK-03

From your world. SCD2 point-in-time (as-of) joins: enrich a fact with the dimension version that was effective at the event's business time

Practice quiz with instant feedback. For a scored run that counts toward your local progress, use uv run de quiz FLK-05.

1An order placed on 2026-01-08 must be converted to USD. The business requires the FX rate that was in effect on 2026-01-08, even when the pipeline reprocesses the order weeks later. Which join is correct? AA lookup join to a JDBC fx_rates table BA temporal join: fx FOR SYSTEM_TIME AS OF o.order_ts CA regular join on currency only DAn interval join within 1 hour of the order

5You build an as-of enrichment by hand with a KeyedCoProcessFunction. Why do you register an event-time timer at the timestamp of the fact before you emit? ATo rate-limit the output BTo wait until the watermark passes the time of the fact, so that every dimension version effective at or before that moment has arrived CBecause timers are required for any ProcessFunction DTo convert processing time to event time

6A lookup join (for example JDBC) enriches orders with the address of the customer. You replay the pipeline to reprocess last quarter. What goes wrong? ANothing; lookup joins are always correct BEach order gets the address as it is NOW, not the address that was effective at the date of the order CThe join produces duplicates DThe watermark stalls

7Which statements about the as-of (point-in-time) rule are correct? (choose all) (select all that apply) APick the dimension version with the greatest effective_from that is <= the event time of the fact BA version with effective_from strictly greater than the fact time must not be chosen CIf no version is effective at or before the fact time, a LEFT temporal join yields NULLs for the dimension columns DYou should always pick the newest version regardless of the fact's time

8Unbounded keyed state in a regular or temporal join can be a problem over months of data. Why, and what control limits it? AIt cannot be limited. You must restart the job BA state TTL (time-to-live) evicts entries that nobody accessed within a configured duration CIncreasing parallelism removes state DCheckpoints delete state