2. 窗口概念：为什么批流一体的核心在这里

2.1 我们为什么需要窗口

先从一个最日常的场景说起。假设你在负责某公司的一套实时交易风控系统，上游不断传来订单事件，每个事件是一个独立的订单创建或支付动作。你要回答的问题却是“最近5分钟内支付金额超过某阈值的用户有哪些”——这个问题天然带有时间范围属性：最近5分钟。

流计算引擎处理的是无界数据流，事件一个接一个地来，没有尽头。但我们实际业务里的绝大多数统计、告警、聚合，都是围绕某个有限的时间范围展开的。这就产生了矛盾：无界的数据流，配上有限的统计需求，中间必须要有一个“切分”动作。窗口就是这个切分动作的具体实现。

在Flink里，窗口并不是把数据攒到一个物理缓冲里然后一次性处理那么简单。它是把无限流按照某种规则划分成有限大小的“分片”，每个分片内部可以独立做聚合、排序、连接等操作，分片之间互不干扰，处理完一个分片就可以输出一个结果。理解这一点，后面再看窗口机制的细节就不会跑偏。

我经常跟同事说一句话：窗口是流计算里最像“批处理”的地方，也是流计算真正产生业务价值的地方。没有窗口，你只能对一个事件做单条处理，或者把整个流forever攒着——那都不是合理的实时计算。窗口让“实时统计”这件事变成了可能。

2.2 窗口的核心分类与选型逻辑

Flink窗口从大类上分为三种：滚动窗口、滑动窗口、会话窗口。它们的区别在于“如何决定一个事件属于哪个窗口”。

滚动窗口是固定长度、互不重叠的分片。比如每5分钟一个窗口，那么0:00-0:05一个窗口，0:05-0:10一个窗口。每个事件唯一属于一个窗口，不存在跨窗口事件。

滑动窗口也是固定长度，但有两个参数：窗口长度和滑动步长。比如窗口长度10分钟、滑动步长1分钟，那么0:00-1:00的窗口、0:01-1:01的窗口是同时存在的，一个事件会同时属于多个窗口。这类窗口适合“每隔1分钟要看最近10分钟状态”的场景，比如监控页面的实时趋势曲线。

会话窗口是按活动间隔切分的。它没有固定长度，而是定义了一个会话间隔（gap）。如果一个新事件距离上一个事件的间隔小于这个gap，就归属于同一个会话窗口；否则开启新窗口。这类窗口适合分析用户行为路径、连续操作序列，比如判断用户一次访问会话内浏览了多少页面。

选型逻辑其实很直接：只要能回答“我到底想看什么粒度的聚合”，窗口类型就定了一大半。想固定周期出报表，用滚动窗口；想要跟随时间轴滚动的滑动统计，用滑动窗口；想按用户活跃段做分析，用会话窗口。窗口类型没有绝对优劣，只有匹配不匹配。

3. 时间与水印：窗口的物理基础

3.1 事件时间、处理时间与摄入时间

窗口的切分依据是时间，但“时间”这个在批处理里无比简单的东西，在流处理里成了最容易出问题的地方。

Flink里有三种时间语义。处理时间是算子本地机器的系统时钟，也就是数据被处理那一刻的时间；事件时间是事件本身携带的时间戳，比如订单创建时间；摄入时间是数据进入Flink系统的时间。

把窗口建立在处理时间上，代码最简单，延迟最低，但结果不稳定——只要机器时钟抖动、上游数据延迟、任务重启，统计结果就会变。把窗口建立在事件时间上，能真实反映业务发生顺序，但这依赖事件本身的乱序程度和迟到情况，需要配套处理机制。摄入时间介于两者之间，实际生产中用得不多。

我在生产环境里见到的绝大多数项目都用事件时间窗口，原因很简单：我们的业务关心的是“业务发生那一刻”的统计，不是“数据被计算那一刻”的统计。线上订单支付金额、用户点击行为曲线、IoT传感器读数，这些天然都是事件时间语义。处理时间窗口最多用来做调试、做本地演示、或者对准确性要求极低的监控场景。

3.2 水位线：乱序流里的计算红线

选定事件时间后，立刻遇到一个问题：一个事件携带的时间戳是10:00:00，但它可能因为网络抖动、上游处理慢等原因，10:00:00过后很久才到达。如果你的窗口截止时间是10:00:00，那么这个事件到底算不算进窗口？

算进去，那么窗口计算结果就得推迟输出，延迟无法保证；不算进去，那么统计结果就不准确。水位线机制就是解决这个矛盾的。

水位线本质上是一个流动的时间戳标记，它表示“我保证在这个时间戳之前的所有数据都已经到达了”。每收到一个事件，结合你配置的乱序容忍度（out-of-order tolerance）或周期性策略，Flink会推进水位线。当水位线超过窗口的结束时间时，窗口触发计算并输出结果。

举个例子：窗口范围是10:00-10:05，乱序容忍度设为30秒。那么水位线超过10:05那一刻窗口才会计算。事件时间戳为10:04:50的事件，只要在水位线越过10:05之前到达，都能正确进入窗口。这个机制让我可以人为设定“等多久再下结论”，兼顾延迟和准确性。

水位线有三种常见生成方式：周期性（ProcessingTime周期推进）、标点式（遇到特定标记事件时推进）、以及自定义混合型。实际生产环境超过九成用的是周期性生成器，因为实现简单、行为稳定。乱序容忍度的选择是权衡：设得太大窗口出结果慢，设得太小迟到数据被丢弃导致结果偏差。

3.3 迟到数据的三级处理策略

迟到事件是事件时间窗口绕不开的话题。水位线设了容忍度，但总有数据迟到得超乎想象，比如上游任务故障恢复后补发的历史数据。

Flink用三层策略来处理迟到数据：窗口触发前到达的数据正常参与计算；水位线已经越过窗口但数据才到的，如果窗口状态还保留着，默认情况下会被丢弃；如果想挽回这部分数据，可以在窗口上设置允许延迟时间（allowedLateness），或者把迟到数据路由到侧输出流（side output）。

允许延迟时间的本质是延长窗口状态的生命周期。比如窗口截止10:05，水位线在10:05:30越过了它，但窗口状态会保留到10:05:30+60秒。在10:05:30之后、10:06:30之前到达的10:05之前的事件，会触发窗口的再次计算，输出一个更新后的结果。侧输出流则是在窗口状态也解散之后，把仍然迟到的数据单独放入一个旁路流，由你决定怎么用这部分数据。

这三层策略应该配合使用：正常窗口输出一个“基本结果”，允许延迟时间修正“大概率迟到但还有救”的数据，侧输出流承接“彻底没赶上”的数据供离线分析或人工修复。我见过不少团队只用了前两层，最后一层干脆不处理，其实侧输出流才是数据质量兜底的方案。

4. 实操：三大窗口类型的完整实现

4.1 工程环境与模拟数据源准备

先说工程环境，我用的是Flink 1.17版本，Java实现，依赖如下：

<dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-streaming-java</artifactId> <version>1.17.2</version> </dependency> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-clients</artifactId> <version>1.17.2</artifactId> </dependency>

生产项目里还会配上flink-connector-kafka和flink-cep等依赖，但今天讲窗口本身，数据源我用自定义Source模拟一个带事件时间的订单流：每秒钟产生一条订单事件，事件包含订单ID、用户ID、商品类目、金额、事件时间戳五个字段。

模拟数据要刻意注入乱序，比如让一部分事件时间戳晚于当前生成时刻，这样才能验证水位线机制是否真正起作用。真实环境里不可能顺序完美，测试阶段故意制造乱序是一种非常有效的自测手段。

然后设置执行环境，启用checkpoint，定义事件时间语义和水位线策略：

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime); // 1.13之后不需要显式设置 env.enableCheckpointing(5000); env.getConfig().setAutoWatermarkInterval(200);

从Flink 1.13开始，事件时间成了默认语义，不用再显式设置TimeCharacteristic，这个API已经废弃了。但setAutoWatermarkInterval还是要注意，周期性水位线靠这个配置控制推进频率，默认值是200ms，通常不需要改动。

4.2 滚动窗口与滑动窗口的代码对照

滚动窗口的代码非常简洁，核心是timeWindow和聚合函数：

DataStream<OrderEvent> orderStream = env.addSource(new OrderSource()); DataStream<WindowResult> result = orderStream .assignTimestampsAndWatermarks(new MyWatermarkStrategy()) .keyBy(OrderEvent::getCategory) .window(TumblingEventTimeWindows.of(Time.minutes(5))) .aggregate(new CategoryAggregate(), new WindowResultProcess());

这里把订单按类目分组，每5分钟统计一次某类目的总金额和订单量。注意窗口在keyBy之后调用，因为窗口计算天然是分组维度下的并行操作。不分组直接开窗口也支持，但那样所有数据都进一个窗口，无法并行、无法按维度拆分，业务上很少用。

滑动窗口只换一行窗口类型：

.window(SlidingEventTimeWindows.of(Time.minutes(10), Time.minutes(1)))

窗口长度10分钟、滑动步长1分钟，代表每分钟输出一个“最近10分钟”的聚合结果。滑动窗口在底层需要同时维护多个窗口切片的状态，内存开销通常比滚动窗口大，如果步长太短、窗口太长，容易造成状态膨胀。这个后面讲状态清理时专门说。

4.3 会话窗口与全局窗口的边界场景

会话窗口用EventTimeSessionWindows：

.window(EventTimeSessionWindows.withGap(Time.minutes(10)))

这句话的意思是按事件时间间隔10分钟切分会话。同一用户相邻两条事件时间间隔小于10分钟归属同一会话，大于10分钟则开启新会话。会话窗口没有固定起止边界，Flink能够动态创建和合并会话窗口，这在底层依赖窗口合并机制。

会话窗口在电商用户行为分析里很常见，比如计算某用户一次购物会话里浏览的类目数和总停留时长。但要注意：会话窗口的触发条件是gap结束且水位线越过当前会话末端，假如一个用户每9分钟一个事件，会话会无限延续下去，窗口迟迟不触发，延迟会很大。设计gap参数时要结合业务会话间隔分布来定，不能拍脑袋。

全局窗口是一个特殊存在：它把所有同key数据放在一个窗口，默认永远不触发，必须配合自定义触发器才能结出结果。全局窗口适合做“全量数据计算”，比如去重统计全局UV，或者把增量数据累积到某种自定义结构中。它和普通窗口不属于同一思维模型，用的时候要清楚自己在做什么，不要拿全局窗口做传统聚合，很容易造成状态无限增长。

4.4 聚合函数与富函数的搭配技巧

窗口触发时，Flink提供三种处理方式：ReduceFunction、AggregateFunction、ProcessWindowFunction。

ReduceFunction适合简单累加场景，代码最少：

.window(...) .reduce((o1, o2) -> /* 返回合并结果 */);

AggregateFunction是增量聚合接口，它允许你维护一个中间累加器类型。举个例子，计算窗口内订单平均金额，中间累加器只需要存金额总和和订单数，到窗口结束时一次性输出均值。这种增量聚合不需要把窗口内所有原始数据都存进状态，内存占用极低，是生产环境首选。

ProcessWindowFunction则能拿到窗口全量数据和窗口上下文信息，可以做排序TopN、去重、逐条遍历等操作。它是全量聚合，窗口内数据越多，开销越大，不适合做主聚合逻辑，但适合做“结果补全”，因为ProcessWindowFunction能拿到窗口的起止时间、当前watermark等元信息。

实用技巧是把AggregateFunction和ProcessWindowFunction组合使用：

.window(TumblingEventTimeWindows.of(Time.minutes(5))) .apply(new CategoryAggregate(), new WindowResultProcess());

第一个函数做增量聚合，第二个函数在窗口结束时拿到增量聚合的最终值和窗口元信息，一起封装成输出对象。这个组合既保证了低内存占用，又能输出带窗口时间范围的结果对象，我在90%的生产任务里都是用这种方式。

5. 自定义触发器：窗口计算的“发令枪”

5.1 触发器的触发逻辑与默认行为

窗口本身不产生结果，触发器决定“什么时候调用窗口函数”。默认情况下，事件时间窗口的触发器是EventTimeTrigger，它的触发逻辑很纯粹：当前水位线越过窗口结束时间时触发。

但业务有时候不满足于默认行为。比如你要做“准实时”统计，等水位线到了窗口结束时间太慢，你希望每隔30秒提前输出一次当前累积值，最后窗口结束时再输出一次最终值。或者你想在窗口收到第一条数据时就立即触发一次空计算，用于初始化某些外部状态。这些都需要自定义触发器。

自定义触发器需要实现一个Trigger接口，核心方法是onElement、onProcessingTime、onEventTime。onElement在每条数据进入窗口时调用，可以注册定时器；onProcessingTime和onEventTime分别在处理时间定时器触发和事件时间定时器触发时调用。这三个方法都返回一个TriggerResult枚举，包含CONTINUE（什么都不做）、FIRE（触发计算）、PURGE（清空窗口但不算）、FIRE_AND_PURGE（触发计算并清空窗口）。

FIRE_AND_PURGE是关键操作，它可以在提前输出结果后主动清理窗口状态。默认的EventTimeTrigger在触发时不会自动PURGE，窗口状态保留到水位线超过窗口结束时间加允许延迟之后才清理。自定义触发器里可以用FIRE_AND_PURGE来控制清理时机，避免状态残留时间过长。

5.2 自定义触发器示例：每10秒预聚合一次

假设我的业务需求是：每5分钟一个滚动窗口，正常触发点在水位线越过窗口末端，但窗口运行期间每10秒输出一次中间累计结果。

实现步骤是：onElement时注册一个处理时间定时器，当前处理时间+10秒，同时注册事件时间定时器（窗口结束时间，这个其实是框架自动注册的，但自定义时需要手动逻辑）。onProcessingTime被触发时，返回FIRE，输出当前累计值，然后重新注册下一个10秒定时器。onEventTime触发时，返回FIRE_AND_PURGE，输出最终结果并清理窗口。

每个窗口的定时器都要独立管理，因为并行子任务中每个key都有各自的窗口实例。注册定时器时保存一个时间戳集合，清理时把这些定时器都删掉，否则定时器会泄漏导致内存占用升高。

这里有个经验教训：自定义触发器的定时器数量增长曲线要提前估算。如果事件流量大、窗口数量多，每次onElement都注册定时器会带来大量定时器对象，可能触发Flink的定时器数量限制。合理做法是onElement里先判断当前定时器集合是否已经有该时间的定时器，没有才注册，有就跳过。

5.3 触发器与增量聚合的协作关系

触发器触发时，调用的是窗口函数。如果窗口上挂的是AggregateFunction增量聚合器，触发时的动作是把当前累加器的值输出，然后根据需要决定是否重置累加器。如果挂了ProcessWindowFunction全量函数，每次触发都会把当前窗口缓存的所有数据重新遍历一遍，开销会大很多。

因此，做“提前输出中间结果”这种需求时，优先选增量聚合函数作为主聚合逻辑，配合自定义触发器做定时FIRE。这样每次触发只输出一个累加结果，不会因为窗口内数据量太大而卡住。

我踩过的一个坑是：某系统里窗口聚合用ProcessWindowFunction做TopN排序，为了“提前输出中间排名”，每分钟触发一次。窗口长度30分钟，高流量时窗口里有几万条数据，每分钟遍历一遍所有数据，CPU一下子就顶上来了。后来改成两层设计：第一层用AggregateFunction做类目金额增量汇总，第二层再对汇总结果做TopN，触发器只针对第一层窗口触发，问题就解决了。

6. 窗口状态生命周期与清理机制

6.1 窗口状态到底存储在哪里

窗口状态在Flink里是一类特殊的状态，叫window state。它由WindowOperator管理，底层的存储介质取决于你配置的StateBackend。默认的HashMapStateBackend把状态存在TaskManager的堆内存里；生产环境一般配RocksDBStateBackend，把状态落到本地磁盘，用内存做缓存，适合大状态场景。

理解窗口状态的存储位置很重要。滚动窗口每秒一个、每个key都有独立状态时，如果key多、窗口多，内存会被快速撑满。用RocksDB之后，虽然读写速度变慢了一些，但至少不会因为状态过大导致内存溢出。

窗口状态包含两部分：一部分是窗口内部的数据缓冲，比如全量窗口函数需要缓存所有进入窗口的事件；另一部分是触发器注册的定时器。两个部分都要考虑清理。

从Flink 1.13开始，过期窗口状态会在水位线越过窗口结束时间+允许延迟时间后被自动清除，不需要手动清理。但是滑动窗口和会话窗口有些特殊：滑动窗口的同一个事件同时属于多个窗口切片，每个切片都有独立的状态。一个数据会写入多个窗口状态，状态膨胀速度是窗口重叠数倍的。

6.2 大窗口场景的状态优化策略

举个例子：窗口长度24小时、滑动步长1小时，那么一个事件会被复制进24个窗口切片中，对相同key来说，状态占用直接翻24倍。这个场景如果流量再大点，RocksDB都顶不住。

我处理过这类问题，几个有效手段供参考：

第一，把大窗口拆成两级聚合。比如一天窗口，先做1分钟的滚动窗口聚合，再把1分钟聚合结果作为数据源做一天窗口聚合，事件复制数量大幅减少。

第二，修改窗口分配逻辑。如果业务允许，把一些长时间窗口改成“只保留累加值”的模式，也就是增量聚合优先，全量ProcessWindowFunction尽量不用，避免缓存全部原始事件。

第三，配置TTL。窗口状态本身有自己的生命周期，但如果你用了自定义keyed state做辅助逻辑，比如在窗口内存储中间值，要记得给这些状态设置StateTtlConfig，否则它们会脱离窗口生命周期，长期驻留状态后端。

StateTtlConfig ttlConfig = StateTtlConfig .newBuilder(Time.hours(1)) .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite) .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired) .build();

6.3 状态清理的观察方法

观察窗口状态是否异常，最直接的方式是看Flink Web UI里每个算子节点的状态大小变化曲线。正常情况下，窗口算子的状态大小随着处理速率增长，但在水位线越过窗口末端后应该逐步下降。如果状态曲线只涨不降，先查有没有大量未触发的会话窗口，比如gap设置不合理导致会话永不结束；再查自定义触发器是否有定时器未清理；最后查是否用了全局窗口而不自知。

我还习惯在窗口处理的Sink端做一个额外监控指标：对每个窗口结果对象写入一个_processed_timestamp字段。这样通过查询结果表就能反推窗口输出是否准时，配合任务本身的事件时间指标，可以快速定位窗口延迟是数据源造成还是算子处理造成。

7. 生产环境必踩的坑与排查实录

7.1 时间语义配置失效

Flink 1.13之前，事件时间需要显式配置env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)。很多人升级到1.14之后还保留这段代码，虽然不报错，但这段配置已经没有任何作用了，因为事件时间已经是默认语义了。

更隐蔽的问题是这个：在旧版本里，如果在setStreamTimeCharacteristic(TimeCharacteristic.EventTime)之后再调用env.setParallelism()，watermark传递逻辑在某些情况下会变得异常。升级到新版本后，很多人误以为是时间语义问题，排查半天发现WatermarkStrategy根本没加到source上。所以第一步永远都是检查assignTimestampsAndWatermarks是否真的被调用，以及事件时间字段有没有被正确提取。

7.2 并行度导致的水位线推进不均匀

水位线的传播是按并行通道独立进行的。假设某个算子的并行度是8，它会接收上游8个并行子任务各自的水位线，最终水位线是所有输入通道水位线的极小值，也就是最慢的那条通道决定了整个算子的水位线。

这个机制带来的问题是：某个分区的数据流发生积压，它的水位线迟迟不前进，整个下游窗口触发都会被拖住，哪怕其他分区早就处理完了。

排查方法：查看窗口算子的Input Watermark指标。如果看到最小值水位线长时间停滞，而其他水位线已经推进，基本可以判定是数据倾斜或某个上游并行子任务处理能力不足。解决办法是调整分区策略、增加该上游并行度、或者检查是否有某个key的数据量异常巨大导致单点瓶颈。

7.3 状态恢复后水位线回退

任务从checkpoint恢复时，状态会回到保存点，但水位线也会恢复到checkpoint时保存的水位线。如果你恢复了旧checkpoint，而Kafka里最新数据的offset已经远超保存点的offset，那么水位线会从旧位置重新开始推进，窗口会重新计算一遍已经算过的窗口数据。

这类问题常常表现为“任务恢复后，结果表突然出现大量历史窗口的重复写入”。解决办法有几个方向：保证写入结果表是幂等的；恢复时故意丢弃过期偏移量；或者在恢复后清空相关窗口状态再重启计算。没有通解，更多是要在业务写入端做好去重或幂等设计。

7.4 会话窗口的gap陷阱

会话窗口gap配大了，窗口长期不触发，状态无限累积。配小了，又导致用户的一个连续会话被切得七零八落。这个参数本质上是业务定义，不是技术参数。

我在一个用户行为分析项目里做过最合适的gap值估算：把用户事件的间隔做分位数统计，选P80间隔作为gap初始值，再结合后续离线数据分析会话切分结果微调。这个思路比拍脑袋定一个10分钟有效得多。对生产环境而言，会话窗口建议定期监控状态大小，设定告警，一旦某key的会话窗口长时间不关闭就要留意。

8. 窗口性能调优的一些实测经验

8.1 减小窗口覆盖重叠度的两种思路

滑动窗口的重叠因子直接与状态大小成正比。某实时大屏项目里，原本需求是“最近10分钟交易额，每30秒刷新”，窗口长度10分钟、滑动步长30秒，重叠因子20倍。高流量时段状态量就很吃紧。

我调整后的方案是：把计算拆成两层，底层1分钟滚动窗口做增量汇总，上层把最近10个一分钟结果做滑动拼接。虽然代码变复杂了一些，但状态占用从20倍降到只有1分钟窗口加10条汇总记录，效果非常明显。这个思路也适用于那些“展示形态需要滑动窗口、但业务聚合本质只要滚动窗口”的场景。

8.2 增量聚合永远优于全量聚合

窗口里挂ProcessWindowFunction做全量计算非常安逸，因为它能直接用循环遍历所有数据，写起来直观。但全量计算和性能是天然对立的，尤其是高吞吐场景。

基本策略是：能用AggregateFunction完成的聚合，不要用ProcessWindowFunction；需要全量遍历才能算出来的指标，比如TopN、去重，先看看能不能用增量结构维护，比如使用SortedMap、BloomFilter等结构做增量更新，再在窗口结束时直接输出。

真实案例：某系统做“15分钟内用户购买类目Top3”统计，第一版实现是全量窗口内排序，15分钟窗口、高流量时每秒钟几十条数据，排序一次要遍历上万条记录。改成增量结构后，每种商品类目只维护一个计数Map，触发时取Top3，性能提升了约一个数量级，结果语义完全不变。

8.3 全局窗口慎用，大窗口切分优先

全局窗口默认不触发、状态累计到内存爆炸的踩坑案例，在不少团队都发生过。它的适用面很窄，一般只用于“全量去重”或“全量批处理兼容”场景。

如果把Flink当“准批处理”来用，一个小时的窗口数据量巨大，可以考虑不设窗口，而是直接用状态存储中间结果，配合定时器定期输出。本质上和全局窗口的结果一致，但可以细粒度控制状态的生命周期，也不容易一次性撑爆内存。

9. 后续还能做什么

窗口机制本身覆盖了实时计算里很大一部分需求，但它和上下游的联动还有很多扩展空间。比如窗口结果接入实时数仓做OLAP分析，窗口内的累计状态结合外部数据库做动态阈值判断，或者把两个窗口的联合计算用于跨周期对比。把窗口这件事吃透，实时计算的底座基本就稳了。

个人习惯是每做一个窗口相关的任务，都会在文档里记录三件事：窗口参数选型的业务理由、水位线容忍度的估算过程、迟到数据的处理策略。这样做的好处是任务上线几个月后再回头看，能清楚想起当初为什么这么设计，排查问题也更省力。最后留一个小提醒：窗口参数的配置一定要纳入上线评审，因为它直接决定计算延迟、结果准确性和资源消耗。改一个gap值或者容忍度，背后都是业务语义的变化。