在实时计算这个圈子里摸爬滚打几年后我越来越觉得Flink的窗口机制是整个流处理体系里最值得反复琢磨的一块。不管是做实时大屏、风控规则引擎还是数据仓库的实时分层window都是绕不开的核心概念。很多人刚开始学 Flink 时把 window 仅仅理解成“把数据攒一批再处理”这个说法大方向没错但如果真按这个思路去写生产作业很容易在触发时机、乱序数据、延迟数据这些细节上栽跟头。这篇文章我想把 Flink 窗口这块内容做个系统梳理从设计思路到代码实现再到实际生产里常见的坑一次性聊透。无论你是刚接触流处理想找一份能“抄作业”的笔记还是已经写了一阵子 Flink 作业但被窗口触发语义折腾过这篇内容都值得你花十几分钟静下心看完。1. 窗口的核心价值流处理为什么需要它流计算处理的是无界数据流数据像河水一样源源不断涌过来。问题在于绝大多数统计需求都是“有界”的——比如每分钟的订单量、每小时的成交额、每 5 分钟的活跃用户数。无界数据流和有界统计口径之间的矛盾需要靠窗口机制来调和。1.1 无界流与有界统计的天然矛盾想象你在高速路口统计车流量。数据是一辆一辆车经过的永远不会停。但如果领导只要“早上 8 点到 9 点经过多少辆车”你必须把这一小时的数据从无限的车辆流里切出来单独计数。Flink 窗口干的事就是这种“切分”只不过它切分的对象是数字化的数据流。没有窗口之前我们要么在内存里自己维护一个状态容器不停往里面塞数据然后靠定时器触发计算要么用类似批处理的手段定期扫描存量数据。这两种方案在数据量大、延迟敏感的场景下都很别扭。Flink 把窗口做成了流处理的一等公民让你用声明式 API 描述“我要算什么时间段的数据”具体的数据划分、状态清理、触发计算全部由框架搞定。1.2 窗口解决的三类实际问题从应用角度看窗口需求大致可以归为三类你可以对照自己的业务场景看属于哪种第一种是固定周期统计典型场景是每隔 5 分钟输出一次过去 5 分钟的成交额。这类需求最直观使用滚动窗口就能实现。第二种是滑动统计比如“过去 1 小时的销售额每 5 分钟刷新一次”。注意这里口径是“过去 1 小时”而不是“最近一个整点小时”这种场景使用滑动窗口窗口长度 1 小时滑动步长 5 分钟。第三种是会话统计比如一个用户在 App 上连续操作如果超过 10 分钟没有新动作就算一次会话结束需要统计每个会话内用户浏览了多少页面。这种“按数据活跃度动态划分”的需求对应会话窗口。这三类基本上覆盖了实时计算里 90% 以上的窗口应用场景。理解清楚业务到底需要哪一种窗口比背 API 重要得多。1.3 窗口 API 的核心抽象Flink 窗口 API 的核心抽象可以拆成三个部分窗口分配器、窗口函数、触发器。分配器决定数据进哪个窗口、窗口什么时候关闭窗口函数决定窗口内的数据如何计算触发器则可以在默认关闭时机之外自定义计算触发点。这三个概念是我在教新人时必定会讲的“铁三角”。很多人上来就写TumblingEventTimeWindows.of(Time.seconds(10))然后以为大功告成其实这一行代码背后藏着分配器、触发器、驱逐器之间的复杂协作。搞清楚这个协作过程才能真正驾驭窗口。2. 四大窗口类型深度拆解原理、场景与代码Flink 内置的窗口类型并不算多满打满算就四种滚动窗口Tumbling Window、滑动窗口Sliding Window、会话窗口Session Window、全局窗口Global Window。但就是这四种配合不同的时间语义能组合出千变万化的业务口径。2.1 滚动窗口最简单的固定切分滚动窗口是最好理解的数据按固定长度切分窗口之间首尾相接互不重叠。比如 10 秒的滚动窗口就是[00:00, 00:10)、[00:10, 00:20)、[00:20, 00:30)这样一个接一个。滚动窗口适合做周期性的、彼此独立的统计比如每分钟的接口调用量、每小时的日志错误数、每天的活跃用户数。代码上是最简洁的DataStreamOrder orders ...; orders .keyBy(Order::getUserId) .window(TumblingEventTimeWindows.of(Time.minutes(5))) .aggregate(new OrderAmountAggregate()) .print();这里keyBy之后调用窗口函数意味着每个用户各自维护一套 5 分钟的窗口状态。不同 key 的窗口是独立的互不影响。这一点在实际生产中很重要因为有些人会误以为窗口是全局唯一的结果算出来的结果和自己预期对不上。滚动窗口的开闭时间是固定的只要设定好窗口长度所有并行子任务里的窗口起止时间是完全一致的基于同一个时间语义。这保证了即使数据分布在不同的并行度上最终统计口径也不会乱。2.2 滑动窗口可重叠的灵活切分滑动窗口比滚动窗口多了一个“滑动步长”参数。窗口长度大于步长时相邻窗口会有重叠。比如窗口长度 1 小时滑动步长 5 分钟那么每 5 分钟会触发一次计算每次计算覆盖最近 1 小时的数据。这里有几个关键点值得展开。滑动窗口是生产环境里最容易产生困惑的窗口类型因为同一个事件可能同时属于多个窗口。假设滑动步长是 5 分钟窗口长度是 1 小时一条 10:03 到达的数据既属于 [09:10, 10:10) 这个窗口也属于 [09:15, 10:15) 这个窗口还可能属于 [09:20, 10:20) 这个窗口。它不会只进一个窗口而是同时进入所有覆盖它的窗口。代码写法如下DataStreamOrder orders ...; orders .keyBy(Order::getSellerId) .window(SlidingEventTimeWindows.of(Time.hours(1), Time.minutes(5))) .aggregate(new OrderCountAggregate()) .print();底层实现上滑动窗口每个并行实例要为当前活跃的多个窗口分别维护状态。窗口长度越长、滑动步长越小同时活跃的窗口数量就越多内存压力也越大。我在实际项目中遇到过这种情况滑动步长 1 分钟、窗口长度 1 天每个 key 要同时维护 1440 个窗口的状态数据量一大直接 OOM。这个容量的数学公式是窗口数量 窗口长度 / 滑动步长如果有 1 万个 key同时存在的窗口实例就是 1440 万个必须充分评估状态存储压力。2.3 会话窗口按活跃间隙动态划分会话窗口和前面两类有本质区别——它没有固定的起止时间完全由数据本身决定。核心机制是如果一段时间内没有新数据到达当前会话窗口就关闭一旦有新数据到达就开启一个新会话窗口。会话窗口特别适合用户行为分析比如统计一次连续操作停留时长、一次网页浏览会话内的页面数、一次游戏对局中的操作次数。它的优势在于能自适应数据的稀疏和密集程度空闲时段窗口自动关闭活跃时段窗口自动延长。Flink 里使用会话窗口DataStreamClickEvent clicks ...; clicks .keyBy(ClickEvent::getUserId) .window(EventTimeSessionWindows.withGap(Time.minutes(10))) .process(new SessionProcessFunction()) .print();withGap里的 10 分钟就是会话间隙——如果某个用户超过 10 分钟没有新的点击事件当前会话就结束。这个参数需要结合业务特性来调不能拍脑袋。算得太短用户稍微走开一下就被拆成两个会话算得太长状态里要维护很久的历史数据内存开销变大。会话窗口的底层实现比滚动和滑动复杂得多它需要为每个 key 维护当前会话的起止时间并且要处理“窗口合并”——当一个新事件落在两个本应断开却又紧挨着的会话边界时Flink 会把它们自动合并成一个更大的会话窗口。这个过程涉及到大量的状态读写和合并计算也是会话窗口性能往往不如前两类的原因。2.4 全局窗口与自定义窗口兜底方案全局窗口对所有数据只维护一个窗口从不自动关闭必须有自定义触发器才能触发计算。它实际使用场景不多一般是需要自己完全控制窗口逻辑时才用。举个例子如果你想实现“连续累计销售额达到 10 万就触发一次通知”内置窗口类型都做不到。这时候可以使用全局窗口加自定义触发器通过触发器里的状态和定时器来判断是否达到阈值DataStreamOrder orders ...; orders .keyBy(Order::getSellerId) .window(GlobalWindows.create()) .trigger(new CustomTrigger()) .aggregate(new TotalAmountAggregate()) .print();自定义窗口实现的难点在于assignWindows方法如何分配窗口、getDefaultTrigger返回什么触发器、isEventTime返回什么时间语义。这个开发门槛比前三种高不少非必要不建议轻易上手。3. 时间语义与 Watermark窗口触发的真正驱动力窗口类型是数据划分的框架但真正决定“窗口什么时候触发计算”的是时间语义和 Watermark。这里也是 Flink 初学者最容易掉进去的坑。3.1 处理时间与事件时间的选择逻辑Flink 支持两种主流时间语义。处理时间是数据到达算子时的机器时间简单粗暴、延迟低、不关心乱序但结果不稳定——同样的数据重播一次因为处理时间不同统计结果可能不一样。事件时间则是数据自身携带的时间戳比如日志里的event_time字段它反映了事情真实发生的时刻能正确处理乱序数据但需要额外机制来应对延迟。选择依据就一句话业务口径关心的是“事情实际什么时候发生的”还是“数据什么时候被算到的”。实时大屏的流量监控通常用处理时间就够因为口径是实时变化的指标而计算订单归属日期、分析用户行为路径必须用事件时间否则跨天、乱序的数据会把统计搅成一团浆糊。3.2 Watermark 如何推动窗口前进Watermark 是 Flink 中用来度量事件时间进展的机制我习惯把它理解成“数据的迟到线”。它的含义是时间戳小于 Watermark 的数据都已经到达或可以被认为到达了那些晚于 Watermark 到达的数据都属于迟到数据需要单独处理。Watermark 的生成有两种方式周期性生成和间歇性生成。最常用的是周期性生成通过WatermarkStrategy来配置DataStreamOrder ordersWithWatermark orders .assignTimestampsAndWatermarks( WatermarkStrategy.OrderforBoundedOutOfOrderness(Duration.ofSeconds(10)) .withTimestampAssigner((order, timestamp) - order.getEventTime()) );forBoundedOutOfOrderness(Duration.ofSeconds(10))的意思就是允许数据最多乱序 10 秒超过 10 秒的迟到的数据就不被窗口计算了。这里 10 秒不是一个随便拍出来的数字它需要结合数据源的真实延迟情况来定——如果数据是从上游消息队列同步过来的通常延迟都在毫秒级10 秒的容忍度绰绰有余如果是移动端上报的埋点数据网络波动影响较大可能就需要 30 秒甚至更长。还有一点Flink 的窗口关闭条件是窗口的end时间小于等于当前的 Watermark。举例来说一个[10:00, 10:10)的滚动窗口它的 end 是 10:10:00。只有当 Watermark 推进到 10:10:00 或之后这个窗口才会触发计算。所以 Watermark 推进得越快窗口触发越及时但乱序数据丢失的也越多Watermark 推进得越慢结果越准确但实时性越差。这本质上是一个准确性和延迟之间的 trade-off没有绝对正确的配置只有适合当前业务的配置。3.3 迟到数据的三种处理策略窗口触发之后依然会有迟到的数据到达这时候有三种处理办法。默认策略是丢弃直接不管。适合对准确性要求不高的场景。第二种是allowedLateness窗口触发后不会立刻销毁状态而是再等一段时间期间迟到的数据到达时会重新触发计算window.allowedLateness(Time.minutes(5))第三种是把迟到数据放进侧输出流单独处理OutputTagOrder lateTag new OutputTagOrder(late-orders) {}; // 在窗口上定义侧输出 WindowedStreamOrder, String, TimeWindow windowed ... windowed.sideOutputLateData(lateTag);侧输出流里拿到的迟到数据可以写进专门的迟到数据表供离线核对或者做补偿计算。这是最规范的迟到数据处理方式但很多项目为了省事根本没做这一步。我个人强烈建议凡是核心交易链路迟到数据一定要进侧输出流否则对不上账的时候排查成本远超当时的开发成本。4. 窗口函数实战三种计算方式的优劣对比窗口划分完成、触发条件满足后数据在窗口内如何计算Flink 提供了多种窗口函数 API每种在性能上有显著差异选错会影响作业吞吐量。4.1 增量聚合性能最优的选择增量聚合的含义是数据每进入窗口一条就立即进行计算窗口内不保留原始数据只保留当前累加值。reduce和aggregate都属于增量聚合。以计算实时订单总额为例DataStreamOrder orders ...; orders .keyBy(Order::getSellerId) .window(TumblingEventTimeWindows.of(Time.minutes(5))) .aggregate(new AggregateFunctionOrder, Double, Double() { private static final long serialVersionUID 1L; Override public Double createAccumulator() { return 0.0; } Override public Double add(Order value, Double accumulator) { return accumulator value.getAmount(); } Override public Double getResult(Double accumulator) { return accumulator; } Override public Double merge(Double a, Double b) { return a b; } }) .print();这里createAccumulator是创建累加器add是每来一条数据就做一次累加getResult是窗口触发时输出结果。整个过程中窗口状态里只维护了一个 Double 类型的累加值内存开销几乎可以忽略。这也是我日常开发中使用频率最高的窗口函数类型。4.2 全量聚合灵活但耗内存全量聚合的特点是窗口触发前把所有原始数据都存进状态窗口触发时一次性遍历所有数据计算。apply和process都属于全量聚合。DataStreamOrder orders ...; orders .keyBy(Order::getSellerId) .window(TumblingEventTimeWindows.of(Time.minutes(5))) .process(new ProcessWindowFunctionOrder, Object, String, TimeWindow() { private static final long serialVersionUID 1L; Override public void process(String key, Context context, IterableOrder elements, CollectorObject out) { long sum 0; for (Order order : elements) { sum order.getAmount(); } out.collect(sum); } }) .print();全量聚合的优点是非常灵活——可以拿到整个窗口内的所有数据做排序、TopN、去重、关联等复杂操作。缺点是数据量大的时候要把全量数据存在 RocksDB 或者内存里IO 开销和内存压力都很大。实际生产里往往采用“增量聚合 全量聚合”组合的方式先用aggregate做预聚合然后在自定义的ProcessWindowFunction里拿到预聚合的中间结果进行二次加工。这种混合模式可以用极低的开销实现复杂计算。这里有一个常见误区很多人以为apply和process完全一样其实process能拿到Context里的窗口元信息窗口起止时间、当前 Watermark 等能操作侧输出流能力比apply强得多。日常开发能选process就选process。4.3 窗口函数内部的定时器使用窗口函数里可以注册定时器来实现更高阶的窗口计算比如窗口关闭后输出一个延迟触发的补充通知或者在窗口内做超时判断。定时器在ProcessWindowFunction中通过context.timerService()来注册Override public void process(String key, Context context, IterableOrder elements, CollectorObject out) { long windowEnd context.window().getEnd(); context.timerService().registerEventTimeTimer(windowEnd 5000); }这个定时器会在窗口 end 之后 5 秒触发可以用来做窗口修正或补充日志输出。定时器是由 Flink 的 keyed state 后端管理的大部分情况下保存在 RocksDB 里底层是按 key 和时间排序存储的因此大量定时器不会阻塞主处理链路但也别滥用否则定时器的读写压力会明显拖慢检查点。5. 状态清理、内存调优与常见故障排查窗口用着用着最容易出现的问题就集中在状态越来越大、内存爆掉、结果对不上这三类。前两类是资源和稳定性的问题第三类是正确性问题。5.1 窗口状态膨胀的根源与对策状态膨胀几乎都出在同一种写法上用滑动窗口步长很短窗口长度很长。前面已经算过账了窗口数量 窗口长度 / 滑动步长这个值乘以 key 的数量就是同时存在的窗口实例总数。每个窗口实例都要维护一份独立的状态状态一旦膨胀就算 RocksDB 扛住了容量检查点的耗时也会越来越长。解决办法有几个方向一是优化窗口参数看业务能不能接受更短的窗口或者更粗的步长二是把滑动窗口改成滚动窗口加在线累加的方式——也就是自己维护一份更长的累加状态用类似“累积窗口”的思路实现长周期统计三是用增量聚合代替全量聚合不让窗口缓存太多原始数据。真实案例里我见过把一天的滑动窗口改成 5 分钟滚动窗口累加之后状态大小直接降了 90% 以上。5.2 长时间无数据时的空闲窗口问题Watermark 长时间不推进窗口就不触发。这种情况常见于某个 key 的数据量很少甚至完全没数据。比如一个电商卖家一天只成交了几单另一个卖家的数据把全局 Watermark 推进得很快但前者的窗口迟迟不触发——错这里要仔细想清楚如果按 key 分流之后每个 key 有自己的窗口Watermark 是按算子实例推进的。但一个算子实例往往处理多个 key只要任何一个 key 有数据到来算子实例的 Watermark 就会推进从而触发所有 key 的窗口。真正要注意的是另一个情况整个数据源断流或者上游分区长时间无新消息。此时 Watermark 停止推进所有窗口都卡住不触发。Flink 提供了WatermarkStrategy.withIdleness(Duration.ofSeconds(30))来应对意思是如果某个上游超过 30 秒没有数据就忽略它的 Watermark 滞后影响用其他活跃分区的 Watermark 继续推进。这个参数在 Kafka 多分区消费时特别重要。假设一个主题有 10 个分区其中 9 个分区数据正常1 个分区业务量很低一分钟才一条消息那这一个分区的 Watermark 会拖住整个作业的窗口触发。设置合理的空闲超时之后低活跃分区不会阻挡高活跃分区推进。但注意空闲超时也会导致低活跃分区的数据被当作迟到数据丢弃需要在容忍度和准确性之间做取舍。5.3 窗口结果不一致的排查思路窗口算出来的结果和离线对不上是实时计算里最让人头大的问题。我的排查顺序一般是第一步查时间字段有没有解析错埋点上报的 eventTime 是秒还是毫秒时区是不是 UTC这俩问题能干掉一半的错误场景。第二步查 Watermark 配置乱序容忍时间是不是设得太短大量迟到数据被默认丢弃了。第三步查 allowedLateness 和侧输出里有没有数据如果有大量迟到数据说明 Watermark 策略不合理。第四步查 keyBy 的 key 是不是选错字段导致数据被分到了错误的窗口统计维度上。实际生产里90% 的“结果不对”都出在时间字段的解析和 Watermark 配置这两块而不是窗口 API 本身。所以排查时沿着“时间 - 水印 - 窗口”的链路走思路会清晰很多。5.4 检查点与状态后端的配置建议窗口状态最终要落到状态后端这决定了作业的容错和恢复能力。默认情况下 Flink 使用内存状态后端窗口状态全在堆内存里。小数据量没问题一旦窗口多、key 多、状态大GC 停顿就会拖垮吞吐。生产环境我一般直接上 RocksDB 状态后端它在容量上几乎没有上限取决于磁盘还能增量做检查点对超大规模状态友好。配套的配置项也需要一起调整比如state.backend.rocksdb.memory.managedtrue让 RocksDB 使用托管内存避免堆外内存失控。另外一个容易被忽视的问题是状态后端切换后重新部署作业之前的状态会丢需要通过 savepoint 来迁移。所以项目早期就要定好状态后端和检查点策略不要运行到一半再换。6. 实战案例一个完整的 5 分钟滚动窗口计算前面把原理拆完了我们来做一个完整的实战把整个链路串起来。假设场景是某个电商平台需要实时统计每个卖家最近 5 分钟内支付成功订单的总金额每 5 分钟输出一次同时允许最多 30 秒的数据乱序迟到超过 30 秒的数据进入侧输出流。6.1 代码实现先定义数据结构public class Order { public String sellerId; public double amount; public long eventTime; }主逻辑如下import org.apache.flink.api.common.eventtime.WatermarkStrategy; import org.apache.flink.api.common.eventtime.SerializableTimestampAssigner; import org.apache.flink.api.common.functions.AggregateFunction; import org.apache.flink.streaming.api.datastream.DataStream; import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment; import org.apache.flink.streaming.api.windowing.assigners.TumblingEventTimeWindows; import org.apache.flink.streaming.api.windowing.time.Time; import org.apache.flink.util.OutputTag; import java.time.Duration; public class WindowDemo { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env StreamExecutionEnvironment.getExecutionEnvironment(); // 允许事件时间乱序 30 秒 WatermarkStrategyOrder watermarkStrategy WatermarkStrategy .OrderforBoundedOutOfOrderness(Duration.ofSeconds(30)) .withTimestampAssigner(new SerializableTimestampAssignerOrder() { private static final long serialVersionUID 1L; Override public long extractTimestamp(Order element, long recordTimestamp) { return element.eventTime; } }); OutputTagOrder lateTag new OutputTagOrder(late-orders) {}; DataStreamOrder orders ... // 从 Kafka 等数据源接入 DataStreamDouble result orders .assignTimestampsAndWatermarks(watermarkStrategy) .keyBy(order - order.sellerId) .window(TumblingEventTimeWindows.of(Time.minutes(5))) .sideOutputLateData(lateTag) .aggregate(new AggregateFunctionOrder, Double, Double() { private static final long serialVersionUID 1L; Override public Double createAccumulator() { return 0.0; } Override public Double add(Order value, Double accumulator) { return accumulator value.amount; } Override public Double getResult(Double accumulator) { return accumulator; } Override public Double merge(Double a, Double b) { return a b; } }); result.print(); DataStreamOrder lateOrders result.getSideOutput(lateTag); lateOrders.print(); env.execute(seller-order-window-demo); } }这段代码里面有几个细节值得强调。forBoundedOutOfOrderness接受的是一个Duration对象表示允许的乱序时间上限。事件时间字段直接用了Order.eventTime这里没有做毫秒和秒的转换逻辑实际业务里 Kafka 里的时间戳经常是字符串、秒级时间戳或者带时区的字符串必须先用解析函数处理好再提交到这里。sideOutputLateData必须在窗口算子之后调用这样在窗口触发时迟到的数据会被路由到名为late-orders的侧输出流中。这里我在result这个 DataStream 上调用getSideOutput(lateTag)拿到迟到数据流可以直接写到外部存储里做事后补偿。注意侧输出流的 tag 必须是OutputTagOrder这种匿名内部类如果写成OutputTagOrder lateTag new OutputTag(late-orders)不带大括号运行时可能会因为泛型擦除而丢失类型信息导致序列化异常。这是一个非常隐蔽的坑。6.2 运行时的执行逻辑作业启动后数据从 Kafka 进来首先经过assignTimestampsAndWatermarks算子它会给每条数据抽取事件时间并周期性生成 Watermark。接着数据经过keyBy按卖家 ID 分组进入对应的窗口。窗口初始化时分配器会把每条数据按照事件时间划分到对应的 5 分钟窗口里。比如一条 12:03:20 的事件它属于[12:00:00, 12:05:00)这个窗口。增量聚合器add方法会被立即调用把金额累加到该窗口的累加器中。状态中不存原始订单只存一个 Double 值。当 Watermark 推进到 12:05:00 之后系统判定[12:00:00, 12:05:00)窗口到期就调用getResult方法取出累加值输出到下游。而 eventTime 在 12:05:00 之前但实际到达时间晚于 Watermark 12:05:00 的数据会进入lateTag标记的侧输出流。整个过程中每条数据最多被处理一次计算延迟主要取决于 Watermark 的生成间隔和数据源的数据到达速度。6.3 如何验证窗口结果是否正确写完作业别急着上线先在本地用测试数据验证。我常用的办法是在 source 阶段写一个简单的集合数据源手动构造几条故意乱序的数据然后输出验证ListOrder orderList new ArrayList(); orderList.add(new Order(sellerA, 100, parseTimeMs(2024-01-01 12:04:50))); orderList.add(new Order(sellerA, 200, parseTimeMs(2024-01-01 12:05:10))); orderList.add(new Order(sellerA, 300, parseTimeMs(2024-01-01 12:03:30)));注意这里 12:05:10 这条数据虽然事件时间在窗口外但因为 Watermark 还没推进到 12:05:00 之前实际上它不会进入[12:00, 12:05)窗口。而 12:03:30 这条数据事件时间在窗口内哪怕它的处理时间是 12:06只要 Watermark 允许乱序 30 秒它依然会被正确分配到[12:00, 12:05)窗口并参与累计。验证时要关注两件事窗口输出的值是否包含所有事件时间在窗口内的数据迟到数据是否进入侧输出流。如果这两点都符合预期再上真实数据源跑大概率不会出幺蛾子。7. 一些值得单独记住的经验最后分享几个我在写窗口作业时踩过坑后总结出来的经验不系统但每条都值钱。第一keyBy的 key 选择会直接影响窗口的语义。同一个窗口分配器按用户 ID 和按商品 ID 做 keyBy统计口径完全不一样。先想清楚统计维度再写代码。第二窗口函数里的merge方法在会话窗口里会被调用但滚动窗口和滑动窗口不会。如果你想把代码从滚动窗口改造成会话窗口别漏掉merge的实现否则合并时数据就丢了。第三allowedLateness只能用于事件时间窗口处理时间窗口没这个选项。可以理解为处理时间窗口触发后立即销毁状态没有等待窗口。有些文档写得不清楚实际写代码时会发现编译直接报错。第四不要在窗口函数里做外部系统的同步 IO。窗口触发时往往有大量窗口同时触发每个窗口都去查一遍数据库或调用一次远程接口很容易把下游打挂。需要关联维表数据时用异步 IO 或旁路缓存把 IO 压力控制在可控范围。第五仔细区分TimeWindow的getStart()和getEnd()方法返回的边界。把数据写到下游存储时用这两个值拼出窗口的起止时间可以方便下游做监控和排查也是最容易被忽略的埋点信息。第六allowedLateness和sideOutputLateData不是互斥的。在实际生产里我经常组合使用先设置allowedLateness(Time.minutes(1))允许 1 分钟内迟到数据重新触发窗口超过 1 分钟的迟到数据再进侧输出流。这样既能保证大部分乱序数据被正确处理又能保留极端迟到数据的补偿入口。窗口这个东西表面上只是几个 API 的组合但真正能不能用得漂亮拼的是对时间语义和状态管理的理解深度。希望这篇笔记能帮你把 Flink 窗口这根骨头啃下来也少踩几个我踩过的坑。下一篇我打算写 Flink 的状态管理与检查点机制同样是生产级踩坑指南到时候见。
