📚 课程目录第3章滑动窗口（Sliding Window）

滑动窗口（Sliding Window）：原理与特点、DataStream API实现、SQL实现、窗口大小与滑动步长设计

滑动窗口，我更喜欢叫它「滚动计算窗口」。它跟滚动窗口最大的区别在于——窗口之间是有重叠的。说白了，就是每过一段时间，就往前滑一下，算一次结果。

你想想看，滚动窗口是「一刀切」，每个数据只属于一个窗口。但滑动窗口不一样，一个数据可能同时属于多个窗口。这听起来有点绕，但实际场景里特别常见。

原理与特点

滑动窗口有两个核心参数：窗口大小（size）和滑动步长（slide）。窗口大小决定了每次计算的数据范围，滑动步长决定了窗口移动的间隔。

举个例子：窗口大小10分钟，滑动步长5分钟。那么每5分钟就会触发一次计算，每次计算最近10分钟的数据。你看，窗口之间有5分钟的重叠。

核心公式：窗口数量 = 窗口大小 / 滑动步长（当窗口大小能被滑动步长整除时）

比如 size=10, slide=5 → 窗口数量 = 2。每个数据点会被两个窗口包含。

我在项目中遇到过这样一个场景：需要实时统计过去1小时的页面PV，但要求每5分钟更新一次。如果用滚动窗口，要么1小时更新一次（太慢），要么5分钟更新一次但只算5分钟的数据（太短）。滑动窗口完美解决了这个问题——每5分钟算一次过去1小时的数据。

我的习惯：滑动步长一般设为窗口大小的1/3到1/2，这样既能保证数据平滑，又不会产生太多窗口导致性能开销过大。

DataStream API实现

Flink的DataStream API对滑动窗口的支持非常直接。我们来看一个实际例子：

// 窗口大小10秒，滑动步长5秒
DataStream<SensorReading> sensorStream = ...

sensorStream
    .keyBy(SensorReading::getId)
    .window(SlidingProcessingTimeWindows.of(
        Time.seconds(10),  // 窗口大小
        Time.seconds(5)    // 滑动步长
    ))
    .aggregate(new AverageAggregate())
    .print();

这里要注意几个关键点：

窗口分配器：使用 SlidingProcessingTimeWindows 或 SlidingEventTimeWindows
两个时间参数：第一个是窗口大小，第二个是滑动步长
触发时机：每个滑动步长触发一次计算，而不是窗口结束时才触发

我曾经踩过一个坑：把滑动步长设得比窗口大小还大。结果呢？窗口之间出现了「空洞」，有些数据没有被任何窗口覆盖。嗯，这其实就退化成了滚动窗口，而且还有数据丢失的风险。

避坑指南：滑动步长必须小于等于窗口大小。如果滑动步长大于窗口大小，会有数据点不属于任何窗口，造成数据丢失。

SQL实现

在Flink SQL里，滑动窗口用 HOP 函数来表示。语法也很直观：

SELECT
    window_start,
    window_end,
    id,
    AVG(temperature) AS avg_temp
FROM sensor_data
GROUP BY
    HOP(row_time, INTERVAL '5' SECOND, INTERVAL '10' SECOND),
    id;

这个SQL的意思是：每5秒滑动一次，每次计算过去10秒的数据。注意参数的顺序——HOP(时间字段, 滑动步长, 窗口大小)。

我个人的习惯是，在SQL里把滑动步长写在前面，窗口大小写在后面。这样读起来更符合「每X时间滑动一次，计算Y时间的数据」这个逻辑。

参数	含义	示例值
时间字段	事件时间或处理时间	row_time
滑动步长	窗口移动的间隔	INTERVAL '5' SECOND
窗口大小	每次计算的数据范围	INTERVAL '10' SECOND

窗口大小与滑动步长设计

这是滑动窗口设计里最考验经验的地方。我见过不少同学直接把窗口大小设成业务需求里的「统计周期」，滑动步长设成「刷新频率」。但实际跑起来，性能问题就暴露了。

为什么会这样？因为滑动窗口会产生大量重叠的窗口对象。每个数据点要复制到多个窗口里，内存开销是成倍增长的。

给你一个经验公式：

窗口数量 = 窗口大小 / 滑动步长
每个数据点的副本数 = 窗口数量
总内存开销 ≈ 窗口数量 × 每个窗口的状态大小

举个例子：窗口大小1小时，滑动步长1秒。那么窗口数量是3600个。每个数据点要复制3600份！这谁顶得住？

设计建议：

滑动步长不要太小，建议至少是窗口大小的1/10
如果刷新频率要求很高（比如每秒），考虑用滚动窗口+增量聚合替代
窗口大小超过1小时时，注意检查状态大小

我记得有一次做实时大屏，业务要求「每1秒刷新过去1小时的累计数据」。如果直接用滑动窗口，窗口数量是3600个，每个数据点复制3600次。后来我换了个方案：用滚动窗口每分钟聚合一次，然后在前端做滑动累加。性能直接提升了10倍。

下面这张图展示了滑动窗口的核心逻辑：

从这张图可以看得很清楚：数据点5s和10s同时属于窗口1和窗口2。这就是滑动窗口「重叠」的本质。

我的经验：如果业务对实时性要求很高（秒级刷新），但统计周期又很长（小时级），建议用「滚动窗口+外部存储累加」的方案。Flink只负责分钟级的滚动聚合，前端或Redis负责累加。这样既保证了实时性，又避免了滑动窗口的巨额内存开销。

最后总结一下滑动窗口的设计要点：

窗口大小：由业务统计周期决定，但不要超过状态后端的承载能力
滑动步长：由刷新频率决定，但不要太小导致窗口数量爆炸
性能权衡：窗口数量控制在100以内比较安全，超过500就要考虑优化方案
适用场景：需要平滑统计、频繁刷新的场景，比如实时大屏、监控告警

嗯，滑动窗口就讲到这里。记住一句话：滑动窗口是「用空间换时间」的典型代表，用得好是利器，用不好是性能杀手。