📚 课程目录第4章会话窗口（Session Window）

4. 会话窗口（Session Window）：原理与特点、DataStream API实现、SQL实现、会话超时时间设置

会话窗口，我把它叫做「静默窗口」。它不像滚动窗口那样固定拍子，也不像滑动窗口那样有固定步长。它的核心逻辑就一句话：一段时间没收到数据，窗口就关闭。

你想想看，用户访问网站的行为就是典型的会话场景。用户点开页面，浏览商品，加购物车，然后去付款。这一系列操作之间可能有间隔，但整体上属于一次「会话」。如果用户离开去喝了杯咖啡，半小时后又回来继续操作——这算两次会话还是一次？

嗯，这就是会话窗口要解决的问题。

4.1 会话窗口的核心原理

会话窗口没有固定的长度。它的边界由数据之间的时间间隔决定。我习惯把这个间隔叫做「静默阈值」——也就是 session gap。

举个例子：

你设置会话超时时间为 5 分钟
第 1 条数据在 10:00 到达，窗口开始
第 2 条数据在 10:03 到达，还在 5 分钟内，属于同一个会话
第 3 条数据在 10:09 到达——距离上一条已经过了 6 分钟，超过了 5 分钟阈值
于是 10:00~10:03 的数据形成一个会话窗口，10:09 的数据开启新会话

关键点：会话窗口的结束时间 = 最后一条数据的时间 + session gap。窗口关闭后，新数据到来时重新开始计时。

我在项目中遇到过一种情况：用户行为日志偶尔会延迟到达。比如用户 10:00 点击了按钮，但日志在 10:06 才发到 Flink。如果 session gap 设成 5 分钟，这条延迟数据就会「落单」，自己形成一个单独的会话。嗯，这里要注意——会话窗口对数据乱序非常敏感。

4.2 会话窗口的特点

说白了，会话窗口有三个核心特点：

特点	说明
长度不固定	窗口大小由数据活跃程度决定，数据密集时窗口长，稀疏时窗口短
天然合并	两个会话如果间隔小于 gap，会自动合并成一个窗口
无重叠	每个数据只属于一个会话窗口，不会像滑动窗口那样被重复计算
依赖 watermark	会话窗口的触发依赖于 watermark 推进，否则可能迟迟不关闭

我曾经踩过一个坑：在测试环境里 session gap 设了 30 秒，但 watermark 生成策略没配好，导致窗口一直不触发。结果就是——数据全积在状态里，内存爆了。所以，用会话窗口一定要配好 watermark。

4.3 DataStream API 实现

Flink 的 DataStream API 提供了两种方式创建会话窗口：

4.3.1 固定超时时间

这是最常用的方式。所有会话使用同一个 gap 值。

DataStream<UserAction> actions = ...;

actions
    .keyBy(UserAction::getUserId)
    .window(ProcessingTimeSessionWindows.withGap(Time.minutes(5)))
    .aggregate(new SessionAggregator());

我个人的习惯是：生产环境优先用事件时间。处理时间会话窗口在数据重放时会产生不一致的结果。

// 事件时间会话窗口
actions
    .keyBy(UserAction::getUserId)
    .window(EventTimeSessionWindows.withGap(Time.minutes(5)))
    .aggregate(new SessionAggregator());

4.3.2 动态超时时间

有些场景下，不同用户的会话行为差异很大。VIP 用户可能希望 gap 长一些，普通用户短一些。这时候可以用动态 gap。

actions
    .keyBy(UserAction::getUserId)
    .window(EventTimeSessionWindows.withDynamicGap(
        (UserAction action) -> {
            if ("vip".equals(action.getUserLevel())) {
                return Time.minutes(10).toMilliseconds();
            } else {
                return Time.minutes(3).toMilliseconds();
            }
        }
    ))
    .aggregate(new SessionAggregator());

小技巧：动态 gap 函数可以访问当前数据的字段，但不能依赖状态。如果你需要根据历史行为动态调整 gap，建议在 keyBy 之前先做一次预处理，把 gap 值算好放到数据里。

4.4 SQL 实现

Flink SQL 里会话窗口的语法很简洁。我刚开始用的时候觉得它比 DataStream API 更直观。

SELECT
    userId,
    SESSION_START(ts, INTERVAL '5' MINUTE) AS sessionStart,
    SESSION_END(ts, INTERVAL '5' MINUTE) AS sessionEnd,
    COUNT(*) AS actionCount,
    SUM(duration) AS totalDuration
FROM user_actions
GROUP BY
    userId,
    SESSION(ts, INTERVAL '5' MINUTE);

这里 SESSION(ts, INTERVAL '5' MINUTE) 表示：以 ts 作为时间字段，5 分钟为会话超时时间。

SQL 里也支持动态 gap，但写法稍微绕一点：

SELECT
    userId,
    SESSION_START(ts, userGap) AS sessionStart,
    SESSION_END(ts, userGap) AS sessionEnd,
    COUNT(*) AS actionCount
FROM user_actions
GROUP BY
    userId,
    SESSION(ts, userGap);

这里的 userGap 必须是数据中已经算好的字段，单位是毫秒。

注意：SQL 会话窗口的 gap 字段必须是 BIGINT 类型（毫秒）。如果你用 INTERVAL 字面量，Flink 会自动转换。但如果你用字段引用，一定要确保字段类型正确。我曾经因为字段类型是 INT 导致窗口行为异常，排查了半天才发现是类型溢出。

4.5 会话超时时间设置

这个参数直接决定了会话窗口的行为。设得太短，一次完整的用户操作会被拆成多个会话；设得太长，不同用户的会话会合并到一起。

我一般遵循这几个原则：

业务驱动：先问业务方「用户多久不操作算一次新会话？」。电商场景通常是 30 分钟，游戏场景可能是 5 分钟。
数据密度：看数据到达的频率。如果平均每 10 秒一条数据，gap 设 5 分钟就太长了。
状态大小：gap 越大，窗口等待时间越长，状态中积压的数据越多。我见过一个案例，gap 设了 1 小时，结果状态膨胀到几十 GB。

场景	推荐 gap	说明
网页浏览	30 分钟	行业标准，用户离开页面 30 分钟算新会话
移动端 App	5~10 分钟	用户切换 App 频繁，gap 不宜过长
IoT 传感器	1~5 分钟	传感器上报间隔通常较短
金融交易	1 秒~1 分钟	高频交易场景，gap 必须很短

嗯，这里还要提一个我踩过的坑：gap 不要设成 0。虽然语法上允许，但实际运行时每个数据都会自成一个窗口，性能极差。

4.6 会话窗口的完整流程

下面这张图展示了会话窗口从创建到关闭的完整生命周期：

4.7 会话窗口的合并机制

会话窗口有一个很有意思的特性：窗口合并。当两个会话窗口的间隔小于 gap 时，Flink 会自动把它们合并成一个。

举个例子：

窗口 A：10:00~10:05（最后一条数据 10:00，gap 5 分钟，所以结束于 10:05）
窗口 B：10:03~10:08（最后一条数据 10:03，结束于 10:08）
窗口 A 的结束时间 10:05 与窗口 B 的开始时间 10:03 重叠 → 合并成一个窗口 10:00~10:08

这个合并逻辑是 Flink 内部自动完成的。你不需要写任何额外代码。但要注意：合并后的窗口会重新计算触发时间，以合并后最后一条数据的时间 + gap 为准。

性能警告：会话窗口的合并操作会触发状态读写。如果数据量极大（每秒百万级），合并操作可能成为瓶颈。我建议在这种场景下先用滚动窗口做预聚合，再在结果上做会话窗口。

4.8 会话窗口的常见问题

最后，我总结几个实际开发中容易遇到的问题：

窗口不触发：检查 watermark 是否正常推进。如果 watermark 一直停在初始值，会话窗口永远不会关闭。
状态爆炸：gap 设得太大，或者数据乱序严重，导致大量窗口处于等待状态。建议设置 state.time-to-live 来兜底。
数据倾斜：某些 key 的数据特别多，导致单个 TaskManager 压力过大。可以考虑二次 keyBy 或者调整并行度。
延迟数据处理：会话窗口的 allowedLateness 要谨慎设置。设得太长，窗口迟迟不清理；设得太短，延迟数据可能丢失。

嗯，会话窗口的内容就这些。它不像滚动窗口那么「规矩」，但处理用户行为、IoT 设备上报这类场景时，它是最自然的选择。记住一句话：会话窗口不是看时间，而是看沉默。