Flink 时间和窗口:给无界流"切片"的艺术

摘要:本文梳理 Flink 处理无界数据流的核心机制——窗口(怎么切片)、时间语义(以谁的时钟为准)、水位线(怎么判断"这批数据到齐了")、迟到数据处理、双流 Join。重点讲清楚"水位线是延迟和正确性的权衡"这条主线,而不是罗列每种窗口分配器的参数写法。本文整理自尚硅谷《大数据技术之Flink》课程。

---

一、为什么需要窗口

批处理可以等一批数据全部到齐再统一处理,但流处理是数据源源不断到来、永远没有"到齐"这一说的。要统计"最近一段时间内"的数据,就必须把无限的流切成有限的"数据块"——这就是窗口(Window)。

有一点容易被忽略:Flink 里的窗口不是提前准备好的固定容器,而是动态创建的——只有当有数据落在某个窗口的时间区间内时,这个窗口才会被创建出来。理解这一点后,后面"窗口什么时候触发、什么时候关闭"才有讨论的基础。

---

二、窗口的两个分类维度

按驱动方式分:时间窗口 vs 计数窗口

• 时间窗口:按时间长度切,比如"每 10 秒一个窗口"
• 计数窗口:按数据条数切,比如"每 10 条数据一个窗口"

计数窗口本质上是全局窗口(Global Window)的一种简化封装,概念上更简单,但实际业务里用时间窗口的场景远多于计数窗口——因为业务通常关心的是"某个时间段内"的统计,而不是"固定条数"的统计。

按分配规则分:滚动 / 滑动 / 会话 / 全局

这四种是这一章要记的核心概念:

• 滚动窗口(Tumbling):窗口之间首尾相接、不重叠、长度固定。比如每 5 秒一个窗口,数据只会落进一个窗口。
• 滑动窗口(Sliding):窗口有固定长度,但按一个"滑动步长"滚动前进,窗口之间会重叠。比如"窗口长度10秒、步长5秒",意味着每5秒就统计一次"过去10秒"的数据——同一条数据可能同时属于多个窗口,这是它和滚动窗口最本质的区别。
• 会话窗口(Session):没有固定长度,靠"间隔时间"来划定——只要相邻两条数据的时间间隔不超过设定的 gap,就属于同一个窗口;一旦间隔超过 gap,当前窗口关闭,下一条数据开启新窗口。适合"用户会话"这类天然有空档期的场景。
• 全局窗口(Global):所有数据都在一个窗口里,默认不会自动触发计算,必须配合自定义触发器使用,一般是自定义窗口逻辑时的底层工具,日常业务直接用得不多。

按键分区窗口 vs 非按键分区窗口

在调用窗口算子之前有没有做 keyBy,决定了窗口计算的并行度:

• 有 keyBy(得到 KeyedStream),再调 .window():每个 key 各自维护一组窗口,并行处理
• 没有 keyBy,直接调 .windowAll():所有数据汇总到一个任务里处理,并行度强制为 1,手动调大也没用

这个区别在实际项目里很关键——如果你的统计需求是"分维度汇总"(比如按商品分类统计销量),一定要先 keyBy 再开窗;如果需求是"全局只要一个汇总结果",才用 windowAll,但要清楚这样会牺牲并行处理能力,数据量大时可能成为瓶颈。

---

三、窗口算子的两个组成部分

一段窗口代码的标准结构:

stream.keyBy(<key selector>)
      .window(<window assigner>)     // 窗口分配器:决定怎么切
      .aggregate(<window function>)  // 窗口函数:决定切完之后怎么算

.window() 负责"分配"——数据该进哪个窗口;后面的窗口函数负责"计算"——窗口里的数据具体怎么处理。这两件事是解耦的,理解了这个结构,再看各种窗口分配器(滚动/滑动/会话对应时间语义还是处理时间语义)的具体参数,就只是记忆细节的问题了。

窗口函数的两条路线

这是本章第二个重要分水岭:窗口函数按处理方式分成增量聚合和全窗口函数两类,它们代表了两种完全不同的资源权衡。

增量聚合函数(ReduceFunction / AggregateFunction):数据来一条就立刻参与计算一次,窗口内只需要保存一个"中间聚合结果",不用缓存所有原始数据。优点是省内存,适合简单的求和、计数、求最值这类场景。

ReduceFunction 的限制是输入、中间状态、输出的类型必须一致;AggregateFunction 突破了这个限制,分别定义累加器类型(ACC)、输入类型(IN)、输出类型(OUT),更灵活,是生产环境更常用的选择。

全窗口函数(WindowFunction / ProcessWindowFunction):必须先把窗口内所有数据缓存起来,等窗口触发时一次性拿到全部数据再计算。优点是能拿到窗口的上下文信息(比如窗口起止时间),缺点是要缓存所有原始数据,内存开销大。

ProcessWindowFunction 是这两者里更常用、更底层的一个——它属于"处理函数"家族,不仅能拿到窗口全部数据,还能访问窗口元数据、当前时间和状态,是全窗口函数里能力最全的选择。

这两条路线不是二选一,可以组合使用:窗口内用增量聚合(节省内存、来一条算一条),等窗口触发时,再把这一个聚合结果交给全窗口函数包装上下文信息(比如把窗口起止时间拼进最终输出)。这个组合模式是实际项目里最常见的写法——既要性能,又要窗口的元数据,鱼与熊掌兼得。

---

四、时间语义:以谁的时钟为准

Flink 有两种时间语义:

• 处理时间(Processing Time):以数据被算子处理的那一刻的系统时间为准,简单直接,没有延迟,但数据的处理顺序完全取决于到达顺序,一旦网络抖动或者数据积压,统计结果会失真。
• 事件时间(Event Time):以数据自身携带的时间戳(比如日志里记录的生成时间)为准。这才是业务真正关心的时间,不会受传输延迟影响,但代价是需要额外机制去判断"这个时间点之前的数据是不是都到齐了"——这就引出了水位线。

从 Flink 1.12 开始,事件时间是默认语义,这个选择本身就说明了:在大多数真实业务场景里,数据自身的产生时间比处理这条数据时的系统时间更重要。凡是涉及"补数据"“数据重放”"网络延迟"的场景,处理时间语义算出来的结果都不可信,必须用事件时间。

---

五、水位线:延迟和正确性的权衡机制

水位线是什么

水位线(Watermark)是插入到数据流里的一种特殊标记,本质是一个时间戳,用来告诉下游"当前的事件时间推进到这里了,这个时间点之前的数据,原则上不会再有了"。

全篇最核心的一句话

Flink 中的水位线,其实是流处理中对低延迟和结果正确性的一个权衡机制,而且把控制权交给了程序员。

这句话是理解水位线的钥匙:

• 水位线设得越"激进"(不等或少等乱序数据),窗口触发得越快,延迟越低,但迟到的数据可能被漏算,结果不准
• 水位线设得越"保守"(等待时间拉长),数据越齐全,结果越准,但窗口触发得晚,延迟越高

没有一个绝对正确的设置,只有适合业务的取舍。 对实时性要求高、能容忍一点误差的场景(比如实时大屏),水位线可以设得激进一些;对准确性要求高的场景(比如计费、对账),要么把等待时间设长,要么靠后面讲的"迟到数据处理"机制兜底。

怎么生成水位线

核心方法是 assignTimestampsAndWatermarks(),需要指定两件事:从数据里提取时间戳的逻辑,以及按什么策略生成水位线。

Flink 内置了两种常用策略:

• 有序流:forMonotonousTimestamps()——假设时间戳单调递增,不等待,水位线直接等于当前最大时间戳。适合能保证顺序的场景(比如单分区 Kafka)。
• 乱序流:forBoundedOutOfOrderness(maxOutOfOrderness)——传入一个"最大乱序程度",水位线 = 当前观察到的最大时间戳 − 这个乱序容忍值。相当于把系统时钟故意调慢一点,给乱序数据留出到达的时间窗口。

这是绝大多数生产场景的标准写法——先判断数据源大概率会不会乱序(比如多分区 Kafka 天然会乱序),再决定用哪种策略、容忍多大的乱序程度。

水位线怎么传递

水位线会随数据流向下游广播。当一个任务从多个上游并行子任务接收到多个水位线时,要以其中最小的那个作为自己的当前事件时钟——这是个保守策略,因为只要还有一个上游分支的数据没到齐,就不能认为"这个时间点之前的数据都到齐了"。这也是为什么数据倾斜、某个分区处理慢,会拖慢整个下游的窗口触发进度。

---

六、迟到数据:水位线之外的兜底机制

即使设置了乱序容忍,总会有极端迟到的数据在水位线过了之后才姗姗来迟。Flink 给了三层递进的应对手段:

1. 推迟水位线推进(forBoundedOutOfOrderness)——第一道防线,前面已经讲过,治标也治本,但不可能覆盖所有极端情况
2. 允许窗口延迟关闭(.allowedLateness(Time.seconds(n)))——窗口触发计算之后先不立刻销毁,而是再等一段时间。这段时间内每来一条迟到数据,就触发一次增量重算,直到真正超过"窗口结束时间 + 延迟时间"才彻底关闭。注意这只能用在事件时间语义下。
3. 侧输出流兜底(.sideOutputLateData(outputTag))——即使 allowedLateness 也扛不住的极端迟到数据,不会被默默丢弃,而是被送进一个侧输出流,后续可以单独处理(比如落到一张"迟到数据"表里,做人工或离线补偿)。

这三层是层层递进的关系,分别对应"预防"“补救”“兜底”,生产环境的严肃数据管道(尤其是涉及金额、计费的场景)三层往往都要配置,不能只依赖第一层。

---

七、双流 Join:窗口的另一个用途

connect 已经能通过 keyBy + 状态自己实现双流关联的逻辑,但那是底层、手动挡的做法。如果需求是"固定时间范围内的数据匹配",Flink 提供了更省心的内置算子。

窗口联结(Window Join)

stream1.join(stream2)
       .where(<KeySelector>)
       .equalTo(<KeySelector>)
       .window(<WindowAssigner>)
       .apply(<JoinFunction>)

语法结构和 SQL 的 WHERE t1.id = t2.id 几乎一一对应——本质就是限定时间窗口内的 inner join:只有两条流的数据落在同一个窗口、且 key 相同,才会触发 JoinFunction;窗口内没有匹配上的数据,直接被丢弃,不会有任何输出。

间隔联结(Interval Join)

窗口联结有个局限:如果两条匹配的数据刚好卡在窗口边界两侧(比如一个在窗口A末尾,一个在窗口B开头),即使它们时间上很接近,也会因为分属不同窗口而匹配不上。

间隔联结解决的正是这个问题——它不按固定窗口切,而是给每条数据定义一个时间偏移区间(比如"这条数据的下界时间-5秒 到 上界时间+5秒"),只要另一条流中有数据落在这个区间内,就算匹配成功,不受窗口边界的束缚。这在关联两条速率不同、时间间隔不固定的流时(比如下单流和支付流,支付可能延迟几分钟到几小时)更贴近实际业务。

怎么选:能用固定窗口描述清楚的匹配需求用 Window Join,时间间隔不固定或者需要跨窗口边界匹配的场景用 Interval Join。

---

八、写在最后:这一章的核心脉络

如果只保留几条结论:

1. 窗口分配器管"怎么切",窗口函数管"切完怎么算",两者解耦,组合使用(增量聚合+全窗口函数)是生产最常见写法
2. 事件时间是默认语义,处理时间只在对准确性完全不敏感时才用
3. 水位线的本质是"延迟"和"正确性"的权衡,没有标准答案,取决于业务能接受多大误差
4. 迟到数据处理是三层递进的防线:水位线容忍 → 窗口延迟关闭 → 侧输出流兜底,严肃场景三层都要配
5. 双流 Join 选型:固定时间范围用 Window Join,时间间隔不固定用 Interval Join

这一章的知识点看起来分散(窗口分类、时间语义、水位线生成、迟到处理、双流Join),但串起来其实是一条完整的逻辑链——先解决"怎么切片",再解决"以谁的时钟为准",再解决"怎么判断齐不齐",最后解决"齐不了怎么办"。把这条主线记住,具体的 API 参数忘了随时可以查。