Process functions — timers, keyed state & broadcast rules

5 h
requires FLK-06

From your world. a dynamic business rule applied to a session of events, where the rule can change over time and must be applied as of each event

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

1Which primitives does a KeyedProcessFunction give you? A windowed aggregation hides these primitives. AOnly keyed state BKeyed state, timers (event-time or processing-time callbacks), and access to the current watermark COnly broadcast state DSQL changelog semantics

2How do you implement a session timeout (end the session after a gap of inactivity) with a process function? ACall Thread.sleep for the gap duration BOn each event, register an event-time timer at event_time + gap and delete any earlier timer. onTimer fires when the watermark passes that time and no newer event exists CUse a processing-time timer so it fires on wall clock DEmit immediately on every event

4Events and a broadcast rule stream are independent inputs. Why can the evaluation of each event against 'whatever rule is in state now' be non-deterministic? ABecause broadcast state is not fault-tolerant BBecause there is no ordering guarantee between the broadcast and keyed inputs. A rule may or may not have arrived when Flink processes an event CBecause timers are random DBecause keyed state is cleared between events

5The business says 'a transaction is judged by the fraud policy in force on its date'. How do you implement this with a broadcast rule stream? AAlways use the newest rule BVersion each rule by an effective time. Buffer events. On an event-time timer, apply the rule with the greatest effective_from <= the event time CApply the first rule ever seen DUse a processing-time timer

6A session has timed out and onTimer fires. What should the function typically do? ARegister another timer immediately and never emit BEmit the session result (for example, its summary or flags) and clear the keyed state for that session CDelete all other keys' state DThrow an exception

7Why do you prefer event-time timers to processing-time timers for business logic such as session timeouts and rule application? (choose all) (select all that apply) AThey are deterministic across replays (the clock of the data drives them) BYou can reconcile the result against a batch oracle over the same events CThey fire on the wall clock, which is reproducible DThey handle out-of-order events through watermarks

8In a KeyedBroadcastProcessFunction, processElement has a ReadOnlyContext for the broadcast state. processBroadcastElement has a read-write Context. Why? AA bug in the API BOnly the broadcast side changes the (replicated) rules. Processing of keyed elements may read the rules but not write them. So the broadcast state stays identical in every parallel instance CTo make keyed state read-only DTo disable timers on the keyed side