Stream Windowing

Stream windowing divides an unbounded stream into finite groups so that aggregates can be computed over them. Apache Beam’s programming guide describes the purpose plainly: windowing “divide[s] a continuously updating unbounded PCollection into logical windows of finite size.” Descriptions below follow that guide, checked in September 2026.

The word doing the work is logical. A window is a set of records selected by their event times — not a moment at which something runs. The same window can be computed early, recomputed when more data arrives, and revised again later; it remains the same window. Confusing the window with the schedule is the most common source of misunderstanding about streaming results, because it leads people to expect that a window “finished” when a job ran.

Three shapes, three promises

ShapeDefinitionEach record belongs to
Fixed (also called tumbling)“A consistent duration, non overlapping time interval in the data stream.” With 30-second windows, elements from 0:00:00 up to but not including 0:00:30 form the first window, then 0:00:30 to 0:01:00, and so onExactly one window
SlidingIntervals that “can overlap” — the guide’s example captures 60 seconds of data with a new window starting every 30 seconds, the start frequency being called the periodUsually several: “most elements in a data set will belong to more than one window”
SessionElements “within a certain gap duration of another element,” applied “on a per-key basis.” A record arriving after the gap “initiates the start of a new window”One window per key, whose length depends on the data

Choosing, and what you are promising by choosing

The shape follows from the question, and it also settles what consumers may do with the output.

  • Fixed windows are the reporting shape. Because a record lands in exactly one, nothing is counted twice — so for an aggregate that is additive over time, twenty-four hourly figures sum to the day. That covers sums and counts. It does not cover averages, which need their numerator and denominator carried separately, nor distinct counts, which cannot be summed at all because the same user appears in several hours. Non-overlapping windows remove double-counted records; they do not make every aggregate addable.
  • Sliding windows describe rather than tally. They give a smooth recent view — a running average, a rate over the last hour updated every minute — and because elements repeat across windows, adding the windows together double-counts. This is worth saying to consumers before they build a total from them.
  • Session windows follow behavior. When the boundary belongs to the data — a visit, a period of device use, a burst of activity — a gap is a better definition than a clock. The cost is that a session has no fixed length, so no schedule can promise that all of today’s sessions are complete by a given time: a session that is still receiving records has not ended yet, by definition.

A fourth shape exists and is worth naming because the others imply it does not. A single unbounded window covers the whole stream, with no time boundary at all, and the output is whatever the trigger decides to emit from a running aggregate. It fits a figure that is meant to be cumulative rather than periodic — a total since launch, a current count of open items — and it comes with two conditions. The state for each key is never released by a window ending, so retention has to be decided some other way; and because there is no boundary, output exists only when a trigger produces it, which makes the trigger part of the definition rather than a tuning detail. Where a periodic figure is what someone will reconcile, a fixed window is the right shape instead.

Session windows also grow state per key, since the engine must hold an open window for every key that might still receive a record within the gap. A gap chosen generously is a memory decision as much as an analytical one.

What windowing does not decide

A window says which records belong together. It does not say when a result is published, whether a later publication replaces or adds to the earlier one, or what happens to a record that arrives after the window was considered closed. Those are separate settings, and leaving them at their defaults is itself a decision — see trigger and accumulation mode and allowed lateness. The boundary that decides when a window is considered complete is the event-time watermark, and it is an estimate rather than a fact.

Nor does windowing change which clock the question is about. A window over processing time groups records by when the pipeline reached them, which makes the same hour’s figure depend on how fast the pipeline was running. How these choices combine into a result someone can rely on is worked through in Stream Processing Semantics.

Reference: Apache Beam Programming Guide, Windowing.


Discover more from Insightful Data Lab

Subscribe to get the latest posts sent to your email.

Similar Posts

Questions, corrections, or additional insights?

This site uses Akismet to reduce spam. Learn how your comment data is processed.