Using Session Windows for Inactivity-Based Aggregation in Dataflow

PDE By islever Editorial Last updated

Short answer

A Use session windows with a 15-minute gap duration to dynamically group sensor data bursts and close the window after 15 minutes of inactivity, while filtering for sessions lasting over 30 minutes.

Question

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?
  1. Use session windows with a 15-minute gap duration. Correct Answer
  2. Use session windows with a 30-minute gap duration.
  3. Use hopping windows with a 15-minute window, and a thirty-minute period.
  4. Use tumbling windows with a 15-minute window and a fifteen-minute .withAllowedLateness operator.

Key Takeaways

The question tests the distinction between fixed-time windows (tumbling/hopping) and activity-based windows (session), specifically requiring the use of gap duration to define session boundaries.

Learn how to use session windows with a 15-minute gap duration in Google Cloud Dataflow to aggregate noise data from sensors based on activity bursts and inactivity timeouts.

Common mistake: Choosing tumbling windows (Option D) is a common error; candidates may confuse fixed-time intervals with the need to handle irregular data arrival patterns and inactivity timeouts.

Expert Analysis

The core requirement is to aggregate data for a sensor only when activity persists for more than 30 minutes, but to close the aggregation window immediately after 15 minutes of inactivity. This behavior maps directly to session windows in Apache Beam and Google Cloud Dataflow.

Session windows group elements based on gaps of inactivity. The gapDuration parameter defines the timeout; if no new element arrives within this duration, the current session closes and output is triggered. Here, setting the gap duration to 15 minutes ensures that any pause longer than 15 minutes ends the window. To satisfy the "more than 30 minutes" condition, you apply an aggregation (like average) and use a trigger or filter that only emits results if the session duration exceeds 30 minutes. If the session is shorter, it is discarded.

Other options fail because:

  • Tumbling windows (Option D) are fixed-size, non-overlapping intervals. They do not adapt to inactivity patterns and would split continuous data into rigid 15-minute chunks regardless of logical continuity.
  • Hopping windows (Option C) have fixed sizes and slide at regular intervals. They produce overlapping windows, which does not match the requirement for a single continuous session per activity burst.
  • Session windows with a 30-minute gap (Option B) would wait 30 minutes of inactivity before closing, violating the explicit 15-minute timeout constraint.

Community comments overwhelmingly support Option A, correctly identifying that session windows are designed for variable-duration bursts separated by inactivity gaps. One comment incorrectly suggests tumbling windows, confusing fixed-time processing with activity-based sessioning.

Official Reference

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

This link opens the official vendor documentation in a new tab.

Exam Strategy

When designing streaming pipelines, always map 'inactivity' or 'gap' requirements to session windows. For fixed time periods, use tumbling or hopping. Use triggers to handle conditions like 'minimum duration' or 'max count' on top of the chosen window strategy.

Frequently Asked Questions

What is the difference between session and tumbling windows?

Tumbling windows are fixed-size, non-overlapping time intervals. Session windows are dynamic and group events based on gaps of inactivity, closing only when no new data arrives within the specified gap duration.

How do I enforce a minimum duration for a session window?

Apply a trigger or filter after aggregation. You can calculate the session duration and only emit the result if it exceeds the required threshold, discarding shorter sessions.

More PDE FAQ →

Community Votes

A
47%
C
33%
D
20%

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

Discussion 20 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 20

  1. datapassionate 👍 11 Answered 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
  2. saschak94 👍 10 Answered 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
  3. shanks_t 👍 3 Answered 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.
  4. kck6ra4214wm 👍 3 Answered 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
  5. 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
Show 15 more comments
  1. ashdam 👍 3
    But you are not fulfilling this requirement "You need to detect the average noise level from a sensor when data is received for a duration of more than 30 minutes". I would say C
  2. JamesKarianis 👍 3 Answered A
    Without a doubt A: https://cloud.google.com/dataflow/docs/concepts/streaming-pipelines#session-windows
  3. scaenruy 👍 3 Answered C
    C. Use hopping windows with a 15-minute window, and a thirty-minute period.
  4. BIGQUERY_ALT_ALT 👍 2 Answered 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.
  5. 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.
  6. Matt_108 👍 2 Answered 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.
  7. Sofiia98 👍 2 Answered C
    Hopping windows (called sliding windows in Apache Beam). To take running averages of data, use hopping windows.
  8. carbonscave 👍 1 Answered A
    Why A is the correct choiceThe Inactivity Trigger: The prompt specifies that the window must end when "no data has been received for 15 minutes." In Apache Beam and Dataflow, Session Windows are explicitly designed for this behavior. They group events based on activity patterns rather than fixed time intervals. Gap Duration: The threshold of inactivity that closes a session is defined as the gapDuration. By setting a 15-minute gap duration, the pipeline will continuously expand the current window as long as new noise spikes (above 70 dBA) arrive within 15 minutes of the last one. As soon as 15 minutes pass with silence, the window automatically closes and the session is emitted. Handling the 30-minute requirement: The windowing logic handles the grouping. Once the session window is emitted, you can easily apply a downstream filter transform in your code to calculate the session's total length (End Time minus Start Time) and only process averages for sessions that lasted longer than 30 minutes.
  9. viciousjpjp 👍 1 Answered 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.
  10. imiu 👍 1 Answered 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.
  11. joao_01 👍 1
    Actually I think with B, the window will never be closed because the probability of having a period of inactivity of 30 minutes is very low. In that case I think the option A is the more correct one.
  12. 342f1c6 👍 1 Answered 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.
  13. iooj 👍 1 Answered A
    The requirements are - recieve data for a duration of MORE than 30 minutes - end the window based on inactivity
  14. f74ca0c 👍 1 Answered C
    C- Running average: https://cloud.google.com/dataflow/docs/concepts/streaming-pipelines#hopping-windows
  15. AllenChen123 👍 1
    Agree D. Data comes -> 30 mts duration. Data didn't come in 15 mts -> 15 mts duration

Reader comments & corrections

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

Log in to comment, report an error, or add a note about this question.

← Back to PDE Study Guide