滚动窗口（Tumbling Window）：原理与特点、DataStream API实现、SQL实现、应用场景与案例

滚动窗口，我习惯叫它「翻斗车窗口」。为什么？因为它的工作方式特别像工地上那种自动翻斗车——时间一到，斗子一翻，里面的数据全部卸掉，然后重新开始装。没有重叠，没有滑动，干干净净。

说白了，滚动窗口就是把数据流按照固定的时间长度切成一段一段的「桶」。每个数据只会落在一个桶里，不会重复。你想想看，这种机制在实时计算里有多常用？我做过的大多数实时看板、监控报警，底层基本都是滚动窗口。

原理与特点

滚动窗口的核心逻辑其实就三句话：

• 固定长度：窗口大小是固定的，比如5分钟、1小时、1天。
• 不重叠：每个数据只属于一个窗口，不会出现「同一个数据在两个窗口里各算一次」的情况。
• 自动触发：窗口结束时自动触发计算，输出结果。

举个例子。假设窗口大小是5分钟，那么时间轴会被切成 [0:00, 0:05)、[0:05, 0:10)、[0:10, 0:15)…… 每个窗口独立计算，互不干扰。

我记得刚带团队时，有个同事把滚动窗口和会话窗口搞混了，结果线上报警延迟了整整一个窗口周期。嗯，这里要注意——滚动窗口的触发时间是完全确定的，跟数据量多少、数据到达早晚没关系。

DataStream API 实现

用 Flink 的 DataStream API 实现滚动窗口，其实就三步：指定窗口分配器、设置窗口函数、处理结果。我直接上代码，咱们边看边说。

// 1. 创建执行环境
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

// 2. 数据源（假设是传感器温度数据）
DataStream<SensorReading> sensorStream = env
    .addSource(new SensorSource())
    .assignTimestampsAndWatermarks(
        WatermarkStrategy.<SensorReading>forBoundedOutOfOrderness(Duration.ofSeconds(5))
            .withTimestampAssigner((event, timestamp) -> event.getTimestamp())
    );

// 3. 滚动窗口聚合：每5分钟计算一次平均温度
DataStream<AvgTemperature> avgTempStream = sensorStream
    .keyBy(SensorReading::getSensorId)
    .window(TumblingEventTimeWindows.of(Time.minutes(5)))
    .aggregate(new AvgTempAggregate(), new AvgTempProcessWindowFunction());

// 4. 输出结果
avgTempStream.print();

这里我用了 TumblingEventTimeWindows.of(Time.minutes(5))，这是最常用的滚动窗口定义方式。当然，如果你要用处理时间，也可以用 TumblingProcessingTimeWindows。我个人建议，只要业务允许，优先用事件时间——处理时间太容易受系统负载影响了。

再看一个更完整的例子，带窗口函数的实现：

// 自定义聚合函数
public static class AvgTempAggregate 
    implements AggregateFunction<SensorReading, Tuple2<Double, Long>, Double> {
    
    @Override
    public Tuple2<Double, Long> createAccumulator() {
        return Tuple2.of(0.0, 0L);  // (总和, 计数)
    }
    
    @Override
    public Tuple2<Double, Long> add(SensorReading value, Tuple2<Double, Long> accumulator) {
        return Tuple2.of(accumulator.f0 + value.getTemperature(), accumulator.f1 + 1);
    }
    
    @Override
    public Double getResult(Tuple2<Double, Long> accumulator) {
        return accumulator.f0 / accumulator.f1;  // 平均值
    }
    
    @Override
    public Tuple2<Double, Long> merge(Tuple2<Double, Long> a, Tuple2<Double, Long> b) {
        return Tuple2.of(a.f0 + b.f0, a.f1 + b.f1);
    }
}

这段代码里，AggregateFunction 是增量聚合，性能最好。窗口每来一条数据就更新累加器，窗口结束时直接取结果。你想想看，如果窗口里有 1000 万条数据，用增量聚合只需要维护一个很小的累加器状态，内存开销几乎可以忽略。

SQL 实现

如果你用 Flink SQL，滚动窗口的实现更简洁。我个人觉得，对于纯聚合场景，SQL 的可读性比 DataStream API 好太多了。

-- 创建源表
CREATE TABLE sensor_data (
    sensor_id STRING,
    temperature DOUBLE,
    ts TIMESTAMP(3),
    WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
) WITH (
    'connector' = 'kafka',
    'topic' = 'sensor-topic',
    'properties.bootstrap.servers' = 'localhost:9092',
    'format' = 'json'
);

-- 滚动窗口聚合查询
SELECT 
    sensor_id,
    TUMBLE_START(ts, INTERVAL '5' MINUTE) AS window_start,
    TUMBLE_END(ts, INTERVAL '5' MINUTE) AS window_end,
    AVG(temperature) AS avg_temp,
    COUNT(*) AS record_count
FROM sensor_data
GROUP BY 
    sensor_id,
    TUMBLE(ts, INTERVAL '5' MINUTE);

这里的关键是 TUMBLE(ts, INTERVAL '5' MINUTE)，它告诉 Flink：按 ts 字段做 5 分钟的滚动窗口。TUMBLE_START 和 TUMBLE_END 分别返回窗口的起止时间，方便下游做时间对齐。

应用场景与案例

滚动窗口的应用场景，说白了就是「按固定周期做统计」的需求。我挑三个最典型的说说。

场景	窗口大小	典型输出
实时监控告警	1分钟 / 5分钟	每分钟平均延迟、错误率
业务指标看板	1小时 / 1天	每小时GMV、日活用户数
流量计费	按自然月	每月流量使用总量

案例一：实时监控告警

我之前做过一个电商系统的实时监控。需求很简单：每 1 分钟统计一次各接口的 P99 延迟，超过 500ms 就报警。用滚动窗口实现，窗口大小 1 分钟，窗口结束时计算 P99，跟阈值比较。这里有个坑——如果窗口内数据太少，P99 的统计意义不大。我当时的做法是加了一个 COUNT(*) > 100 的过滤条件，数据量不足的窗口直接跳过。

案例二：业务指标看板

这个更常见。每 1 小时统计一次各品类的 GMV，展示在实时大屏上。窗口大小 1 小时，用事件时间保证数据准确性。我记得有一次双十一，流量暴增导致数据延迟严重，watermark 设置得太小，很多窗口的数据没等到就触发了。后来我把 watermark 的乱序容忍度从 5 秒调到了 30 秒，问题就解决了。

案例三：流量计费

这个场景比较特殊。计费周期通常是自然月，但自然月不是固定长度的——2 月只有 28 天，7 月有 31 天。滚动窗口的 of(Time.days(30)) 并不能精确对齐自然月。怎么办？我当时的方案是用 TumblingEventTimeWindows.of(Time.days(1)) 做天级聚合，然后在外部存储（比如 HBase）里按月累加。这样既保证了窗口触发的确定性，又解决了自然月对齐的问题。