1. Which windowing strategy places a single element into multiple overlapping windows?
Not quite — fixed windows are non-overlapping, so each element lands in exactly one bucket.
Correct: sliding windows are defined by a size plus a smaller period, so consecutive windows overlap and one element falls into several. Source: Beam Programming Guide, Windowing functions.
Not quite — sessions are gap-driven per key, not built to overlap.
Not quite — the global window is a single window covering all data.
2. You need a per-minute count where every event belongs to exactly one bucket. Which window?
Correct: fixed windows are uniform and non-overlapping, so each element lands in exactly one window. Source: Beam Programming Guide, Fixed time windows.
Not quite — sliding windows overlap, so an element would be counted multiple times.
Not quite — sessions vary in length by activity, not a clean per-minute bucket.
Not quite — the global window wouldn't bucket per minute at all.
3. What best describes a watermark in Beam?
Not quite — a watermark is a heuristic, not a guarantee; late data can still arrive.
Correct: a watermark is a guess — the system believes it will not see an element with an earlier timestamp. Source: Beam Basics, Watermark.
Not quite — a watermark tracks event time, not processing or wall-clock time.
Not quite — it is an event-time estimate, not the newest element's processing-time stamp.
4. An event arrives with a timestamp that belongs to a window whose end time is already behind the current watermark. How is the event classified?
Not quite — the watermark has already passed the window end, so it isn't on-time.
Correct: once the watermark moves past the end of a window, any further element with a timestamp in that window is late data. Source: Beam Basics, Watermark and late data.
Not quite — it arrived after the watermark passed, the opposite of early.
Not quite — whether it survives depends on allowed lateness, not an ingestion-time drop.
5. Which window type is data-driven and closes after a configurable gap of inactivity?
Not quite — fixed windows are time-driven with predetermined bounds.
Not quite — sliding windows are time-driven and overlapping, not gap-based.
Correct: sessions group per-key bursts and close once the inactivity gap exceeds the configured threshold. Source: Beam Programming Guide, Session windows.
Not quite — the global window never subdivides by activity.
6. Watermarks are measured against which clock?
Correct: watermarks track progress through event time — the timestamp on the element itself. Source: Beam Programming Guide, Watermarks and late data.
Not quite — processing time is a different clock; watermarks are about event time.
Not quite — trigger intervals control firing, not watermark advancement.
Not quite — uptime is unrelated to watermark advancement.
7. What does Beam's default trigger do?
Not quite — per-element firing needs an explicit trigger like AfterCount.
Correct: the default trigger emits a single on-time pane when the watermark crosses the end of the window. Source: Beam Programming Guide, Triggers.
Not quite — that requires an explicit AfterProcessingTime trigger.
Not quite — a window doesn't wait for the whole pipeline to drain.
8. What is the default allowed lateness, and what does that imply?
Not quite — late data is not retained by default.
Correct: allowed lateness defaults to zero, so stragglers are discarded the moment the watermark passes the window end. Source: Beam Programming Guide, Managing late data.
Not quite — there is no built-in grace period; you set lateness explicitly.
Not quite — allowed lateness is not tied to the window size.
9. When a window fires multiple times, which accumulation mode re-emits the full result each firing?
Not quite — discarding mode emits only what is new since the last pane.
Correct: accumulating mode re-emits the complete window result on every firing. Source: Beam Programming Guide, Window accumulation modes.
Not quite — retracting is not a Beam accumulation mode.
Not quite — buffered is not a Beam accumulation mode.
10. On an unbounded source, the global window produces no useful output until you do what?
Not quite — lateness doesn't make an untriggered global window emit.
Not quite — the timestamp source doesn't force emission.
Correct: the global window only emits by default when the watermark reaches infinity, which never happens on an unbounded source, so you attach a non-default trigger to emit periodically. Source: Beam Programming Guide, Setting your PCollection's windowing function.
Not quite — accumulation mode changes pane contents, not whether it emits.
0 Comments
Leave a Comment