How Should You Window Streaming Noise Data in Dataflow?

You are building a streaming Dataflow pipeline that ingests noise level data from hundreds of sensors placed near construction sites across a city. The sensors measure noise level every ten seconds, and send that data to the pipeline when levels reach above 70 dBA. You need to detect the average noise level from a sensor when data is received for a duration of more than 30 minutes, but the window ends when no data has been received for 15 minutes. What should you do?

Use session windows with a 15-minute gap duration. Source Reference Answer
Use session windows with a 30-minute gap duration.
Use hopping windows with a 15-minute window, and a thirty-minute period.
Use tumbling windows with a 15-minute window and a fifteen-minute .withAllowedLateness operator.

Community Votes

79%

21%

79% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The test probes whether you recognize that a 'gap after no data' defines a session window, not fixed or hopping windows; the 30-minute requirement is a filter, not a window size.

For a streaming Dataflow pipeline that must group sporadic sensor events into sessions, session windows with a 15-minute gap duration are the correct choice. Community consensus strongly favors Option A, with 69 votes for session windows.

Choosing hopping windows (Option C) — 18% of voters — because it misinterprets the 15-minute gap as a fixed window period rather than an inactivity threshold.

Community Discussion (17 comments)

datapassionate 👍 11 Selected: A

to detect average noise levels from sensors, the best approach is to use session windows with a 15-minute gap duration (Option A). Session windows are ideal for cases like this where the events (sensor data) are sporadic. They group events that occur within a certain time interval (15 minutes in your case) and a new window is started if no data is received for the duration of the gap. This matches your requirement to end the window when no data is received for 15 minutes, ensuring that the average noise level is calculated over periods of continuous data

saschak94 👍 10 Selected: A

You need a window that start when data for a sensor arrives and end when there's a gap in data. That would rule out hopping and tumbling windows. - > Windows need to stay open as long as there's data arriving - 30+ mins -> Window Should close when no data has been received for 15 mins -> Gap 15 mins

Pime13 👍 1 Selected: D

D for me, clearly stated on example: https://cloud.google.com/dataflow/docs/concepts/streaming-pipelines#hopping-windows

shanks_t 👍 3 Selected: A

The problem requires detecting average noise levels when data is received for more than 30 minutes, but the window should end when no data has been received for 15 minutes. Session windows are ideal for this scenario because: They are designed to capture bursts of activity followed by periods of inactivity. They dynamically size based on the data received, which fits well with the variable duration of noise events. The gap duration can be set to define when a session ends. The 15-minute gap duration aligns perfectly with the requirement to end the window when no data has been received for 15 minutes. Session windows will naturally extend beyond 30 minutes if data keeps coming in, satisfying the requirement to detect levels for durations of more than 30 minutes.

viciousjpjp 👍 1 Selected: D

D. Using a 15-minute window with a 15-minute tumbling window withAllowedLateness is the most suitable option for the following reasons: Flexibility: By allowing a 15-minute delay, it can accommodate various situations such as network latency or sensor failures. Processing efficiency: Using a fixed window improves processing efficiency. Compliance with conditions: The window ends if no data is received for 15 minutes, meeting the specified condition. Implementation points: .withAllowedLateness: This operator allows delayed events to be included in the current window. Trigger: When 30 minutes of data is collected, a trigger event is generated, and the average value is calculated based on this event. Watermark: By setting a watermark, processing of old data can be terminated.

JamesKarianis 👍 3 Selected: A

Without a doubt A: https://cloud.google.com/dataflow/docs/concepts/streaming-pipelines#session-windows

iooj 👍 1 Selected: A

The requirements are - recieve data for a duration of MORE than 30 minutes - end the window based on inactivity

josech 👍 3

Correct answer: A. Use a session Window to cature data and create an aggregation when the Session is larger than 30 minutes. https://cloud.google.com/dataflow/docs/concepts/streaming-pipelines#session-windows https://beam.apache.org/releases/javadoc/2.6.0/org/apache/beam/sdk/transforms/windowing/Sessions.html

f74ca0c 👍 1 Selected: C

C- Running average: https://cloud.google.com/dataflow/docs/concepts/streaming-pipelines#hopping-windows

joao_01 👍 2

Guys, I think its B. I was considering C, but C is calculating every 30 min, the 15min window gap data.Thats not what the questions wants. The questions wants a solution to get the average data of a 30 min window. So Its B. Look at this relating to C: "Use hopping windows with a 15-minute window, and a thirty-minute period" --> Wrong (IS DIFFERENT THEN) "Use hopping windows with a 30-minute window, and a 15-minute period" --> Right. Thats why I think the B is the right answer.

342f1c6 👍 1 Selected: C

To take running averages of data, use hopping windows. You can use one-minute hopping windows with a thirty-second period to compute a one-minute running average every thirty seconds.

kck6ra4214wm 👍 3 Selected: A

https://cloud.google.com/dataflow/docs/concepts/streaming-pipelines#session-windows A session window contains elements within a gap duration of another element. The gap duration is an interval between new data in a data stream. If data arrives after the gap duration, the data is assigned to a new window. So, we need

imiu 👍 1 Selected: C

https://cloud.google.com/dataflow/docs/concepts/streaming-pipelines#hopping-windows To take running averages of data, use hopping windows. You can use one-minute hopping windows with a thirty-second period to compute a one-minute running average every thirty seconds.

Matt_108 👍 2 Selected: D

Option D to me, It aligns with the specified criteria for detecting the average noise level within a 30-minute duration and handling the end of the window when no data is received for 15 minutes.

BIGQUERY_ALT_ALT 👍 2 Selected: D

OPTION D is correct for the specific scenario where we want to detect the average noise level for a duration of more than 30 minutes but end the window when no data has been received for 15 minutes. Explanation: - Tumbling windows are non-overlapping windows, and in this case, you want to capture data continuously for 30-minute intervals. - Using a tumbling window with a 15-minute window size aligns with your requirement to detect the average noise level for a duration of more than 30 minutes. - Adding a .withAllowedLateness operator with a duration of fifteen minutes ensures that the window will still consider late-arriving data within that time frame. After fifteen minutes of no data, the window will be closed, and any late-arriving data will not be considered. Option A and B invalid as they capture fixed logic with 15 or 30 mins. Option C captures only 15 min average with 30 min trigger hence not suitable.

Sofiia98 👍 2 Selected: C

Hopping windows (called sliding windows in Apache Beam). To take running averages of data, use hopping windows.

scaenruy 👍 3 Selected: C

C. Use hopping windows with a 15-minute window, and a thirty-minute period.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Session windows are the only window type that automatically closes when a configured gap duration of inactivity elapses. With a 15-minute gap, the pipeline groups all events from a sensor until 15 minutes pass without new data, exactly matching the 'no data for 15 minutes' ending condition. The 'more than 30 minutes' requirement is met by filtering the resulting sessions to those whose total duration exceeds 30 minutes; this is a common pattern in Dataflow and does not require changing the window function. Comments [1] and [2] correctly explain that sporadic sensor data fits session windows because the window stays open as long as data arrives and closes only after the gap.

Why the Other Options Are Wrong

Option B uses a 30-minute gap, which is double the required inactivity period and would keep windows open too long. Option C uses hopping windows, which are fixed-time windows that overlap periodically; they cannot detect data-driven gaps and would not properly group events into activity bursts. Option D uses tumbling 15-minute windows; these are aligned to the clock, not to the data, and the allowed lateness parameter does not address the gap-based ending condition. Commenter [8] incorrectly suggests B, and [9]/[10] incorrectly suggest D, but all ignore the explicit 'no data has been received for 15 minutes' clause.

Community Comment Notes

The community strongly agrees on A, with 69 votes versus only 18 for C. Comments [4] and [5] cite official documentation for Dataflow session windows and Apache Beam's Sessions class, reinforcing that this is the intended solution. Commenter [1] provides a clear rationale about sporadic sensor data, while [2] succinctly outlines why hopping and tumbling windows are ruled out. The few dissenting comments (B and D) fail to account for the 15-minute inactivity gap, which is the key determinant for session windows.

Official Reference

Exam Strategy

When a question specifies 'ends when no data has been received for X minutes,' immediately think session windows with a gap duration of X. Apply the other duration (e.g., 30 minutes) as a filter on the session result, not as the window size.

Related Analysis

← Back to PDE Study Guide