企业官网建设流程全解析

做实时计算这行的人，聊到 Flink 里的时间和窗口，基本都有一段不太愉快的回忆——本地跑得好好的作业，一上生产窗口就是不吐结果；或者结果出来了，跟自己用离线表对不上。我前后接手过几套实时统计链路，从一开始把窗口当成 SQL 的 GROUP BY 用，到后来老老实实去研究 Watermark 怎么推进、窗口状态什么时候清理，中间踩的坑够写满两个笔记本。这篇就围绕 Flink 的时间语义与窗口机制展开，把事件时间、水位线、窗口分配器、触发器、迟到数据这几块拆开讲透，顺带把参数怎么算、状态怎么估、故障怎么查一并交代清楚。不管你是刚接触 Flink 窗口的新手，还是已经在调 watermark 延迟的老手，下面这些内容应该都能对上你的某一段经历。

1. 先把时间这件事说透：三种时间语义与选型逻辑

窗口这个概念本身不复杂，难的是"一条数据该算到哪个时间段里"。Flink 提供了三种时间语义，选错了这一层，后面所有的窗口参数都是在错误的基座上做微调，白费力气。

1.1 三种时间语义到底差在哪

**事件时间（Event Time）**取的是数据自身携带的时间戳，也就是业务真正发生的那一刻。用户下单是在 10:00:03，这条记录里就带着 10:00:03，无论它什么时候被采集、什么时候被处理，都算在 10:00 这一分钟里。**处理时间（Processing Time）**取的是算子所在机器处理这条数据的系统时钟，谁先到就算谁的，简单粗暴但结果不可复现。**摄入时间（Ingestion Time）**介于两者之间，取数据进入 Flink 源头那一刻的时钟，实际生产里用得很少，因为源端时钟本身也会漂移，出问题时既没有事件时间的准确，也没有处理时间的省事。

这三者的差异，用一个生活化的类比：事件时间是"按快递面单上的寄出时间归档"，处理时间是"按快递员今天几点把包裹扔进驿站归档"。前者反映真实业务节奏，后者反映系统负载节奏。双十一凌晨下单量暴涨，但快递员可能第二天才集中揽收，这两种口径统计出来的"每分钟订单量"会差出几个小时。

1.2 为什么生产环境几乎只用事件时间

我自己经手的作业里，只要结果需要跟业务方对账、需要进报表、需要支持补数据重跑，一律用事件时间。原因很实际：处理时间的结果不可复现。同一个作业在凌晨低峰跑出来的数字，和白天高峰跑出来的数字，即便输入数据完全一样，也会因为系统负载不同而被切分到不同的窗口里。一旦业务方问"昨天下午三点的转化率怎么比前天低"，你没法解释，因为重跑一遍数字就变了。

事件时间则依赖 Watermark 这个机制来定义"什么时候可以认为某个时间段的数已经到齐了"。这多出来的一层复杂度，换来的是口径稳定：同一份数据，无论今天跑还是明天跑，无论并发调成 4 还是 40，窗口结果都一致。对账、计费、结算这类场景，这个性质是不可让步的。

注意：选事件时间不等于完全放弃处理时间。很多作业里会同时存在两套逻辑——业务指标走事件时间窗口，而"作业是否健康""消费速率是否异常"这类监控指标走处理时间，两者互不干扰。别为了统一而把监控指标也塞进事件时间窗口，那样连实时性都看不出来。

1.3 时间语义的设置与代价

设置事件时间只有两步：用assignTimestampsAndWatermarks给流打上时间戳和水位线，然后窗口基于EventTime分配器创建。看起来轻量，代价其实藏在后面——你需要为乱序买单。乱序越大，Watermark 必须延迟得越多，结果输出的延迟就越大；延迟压得越小，迟到数据就越多，结果就越不准。这是一个纯粹的权衡，没有两全其美的配置，只有跟业务 SLO 匹配的配置。

2. Watermark：窗口能"关门"的唯一凭据

很多人第一次用事件时间窗口时，会下意识以为"时间到了窗口就出结果"。不是的。窗口触发只认 Watermark，系统时钟走过去多少都不会让一个事件时间窗口提前关门。理解这一点，能省掉大量"为什么窗口不输出"的排查时间。

2.1 Watermark 的本质与推进机制

Watermark 可以理解为一句话广播："从今往后，不会再有时间戳小于等于 T 的数据到来了"。它不是一个独立的定时器，而是随数据流一起向下游传递的特殊标记。算子收到watermark = T之后，就认为所有maxTimestamp <= T的窗口可以关账计算并输出结果了。

关键点在于：Watermark 是单调递增的，不会回退。如果新算出来的水位比当前小，直接丢弃。算子内部维护的当前水位currentWatermark = max(currentWatermark, incomingWatermark)，这个设计保证了窗口不会反复关闭又打开。

要理解 Watermark 的生成，得先看它在源头怎么算。以最常用的有界乱序策略为例，一个并行子任务内部维护一个"见过的最大事件时间戳"maxTimestamp，每来一条数据就更新，然后周期性发出maxTimestamp - maxOutOfOrderness作为水位。所以maxOutOfOrderness这个参数，字面意思就是"我最多容忍多大的乱序"。

2.2 生成策略与延迟参数怎么算

maxOutOfOrderness到底设多少，不能拍脑袋。我一般这么做：先拿真实数据做一次乱序分布的统计，算出"数据到达时刻与事件时刻的差值"的 P99 分位数，把这个值作为基准，再往上留 30% 到 50% 的余量。

举个实际算过的例子：某业务链路的乱序差值分布为 P50 = 1.2 秒、P90 = 4.5 秒、P99 = 8.3 秒、P99.9 = 21 秒。如果目标是 99% 的数据准时，参数设 10 秒（8.3 × 1.2）就够了；如果要覆盖 99.9%，得设到 25 秒以上，但那样窗口结果要多等 25 秒才能输出。最终我们选了 10 秒，剩下 1% 的极端乱序数据用迟到数据机制兜底，而不是靠无限放大延迟去换。

WatermarkStrategy<OrderEvent> strategy = WatermarkStrategy .<OrderEvent>forBoundedOutOfOrderness(Duration.ofSeconds(10)) .withTimestampAssigner((event, recordTs) -> event.getEventTime()) .withIdleness(Duration.ofSeconds(30));

除了有界乱序，还有forMonotonousTimestamps()（等价于乱序为 0，只适用于严格有序的数据源，比如单分区且无重发的场景），以及自定义WatermarkGenerator实现更复杂的策略，比如"没有新数据时按处理时间推进水位"。后者在处理稀疏数据源时很有用，但不是银弹，容易造成"窗口提前关闭导致数据被判定为迟到"，用之前要想清楚。

2.3 多并行度下的 Watermark 对齐与空闲分区

这是最容易出问题的地方。当上游有多个并行子任务时，下游算子收到的 Watermark 是所有输入通道的最小值。上游 4 个分区，只要有一个分区不再产生数据，它就不再推进水位，整个下游的水位就被这个"拖油瓶"卡住，所有窗口都不触发。我在一个按地域分区的源上撞过这个坑：某个地区凌晨没有流量，对应分区静默了三个小时，结果全量作业的窗口三个小时没输出，监控上看着就是"作业卡死"。

解决办法是配置空闲检测：

WatermarkStrategy<OrderEvent> strategy = WatermarkStrategy .<OrderEvent>forBoundedOutOfOrderness(Duration.ofSeconds(10)) .withTimestampAssigner((event, ts) -> event.getEventTime()) .withIdleness(Duration.ofSeconds(30));

withIdleness的含义是：某个分区超过 30 秒没有数据，就把它标记为空闲，不再参与水位取最小值的计算。等它有数据回来，自动恢复参与。这个参数的最佳值一般设在"正常数据间隔的 3 到 5 倍"，设太小会频繁切换空闲状态造成水位抖动，设太大则起不到解卡的作用。作业本身没有空闲分区问题时，配了也不会有副作用，我现在的习惯是默认加上。

提示：如果你在 SQL 层写窗口，对应的是table.exec.source.idle-timeout这个参数，语义一致，别忘了配。

2.4 水位卡住的几个真实原因

排查"窗口不触发"，我现在基本按这个顺序过一遍：先看上游是否所有分区都在产数据，再看水位值是否在推进，再看时间戳字段是不是解析失败变成了Long.MIN_VALUE或者被默认成了 0。

第三种情况很隐蔽。当assignTimestampAssigner返回的时间戳小于 0 或者解析异常时，Flink 会把这行数据的时间戳视为无效，它不会推进水位，但数据本身照样往下走，最后全部落到迟到侧输出里或者被窗口丢弃。我见过一次是上游把时间字段从yyyy-MM-dd HH:mm:ss改成了毫秒字符串，下游的时间戳提取器还在按原格式解析，返回了一堆异常值，表现就是"数据量对得上、窗口结果全是 0"。

还有一个常被忽略的点：故障恢复后水位会回退到 checkpoint 里的值。这意味着恢复瞬间，一部分原本已经算过的窗口可能被重新触发，下游如果没做幂等，数字就会被重复累加。这是设计使然，不是 bug，处理方式是让下游写存储时用(window_start, window_end, key)做主键覆盖，而不是简单 append。

3. 窗口类型与分配器：按业务形态选窗口

窗口分类看着五花八门，归类其实就两把尺子：按什么切分（时间还是数量）和切分后是否重叠（是否滑动）。搞清楚这两点，选择就不难了。

3.1 滚动、滑动、会话、全局四类窗口的实际差异

**滚动窗口（Tumbling）**把时间轴切成首尾相接、不重叠的等长段，每条数据严格属于一个窗口。它最直观，也最适合做标准的分钟级、小时级指标。**滑动窗口（Sliding）**的窗口长度大于滑动步长，窗口之间重叠，一条数据可能同时属于多个窗口，用来做"最近 5 分钟的移动平均"这类需求。**会话窗口（Session）**按数据之间的空闲间隔切分，间隔超过阈值就断言会话结束，适合用户行为分析，比如"用户一次浏览会话内的点击次数"。**全局窗口（Global）**把所有数据放进同一个窗口，只有配上自定义触发器才有意义。

3.2 窗口分配器的实现细节与选择

滚动窗口的分配逻辑最简单：start = timestamp - (timestamp - offset + windowSize) % windowSize，直接算出归属窗口的起点。滑动窗口则是把每条数据分配给所有包含它的窗口，实现上是循环生成多个窗口实例，这也是它状态放大的根源。会话窗口比较特殊，它先给每条数据创建一个"以自己为中心"的窗口，然后当两条数据的间隔小于 gap 时触发窗口合并（merge），合并过程要搬运状态，代价比前两者高。

关于offset参数，很多人不知道它的作用。它用来对齐时区或者对齐业务周期。比如需要按"每天 08:00 到次日 08:00"统计，而不是自然日，就把 offset 设成 8 小时。这个参数在小时间粒度上一般不用，但一旦涉及日、周维度的统计，设不设 offset 结果完全不同。我见过一次日活统计对不上，排查两天才发现是对方用了 UTC+8 的 offset，而我们的作业没设。

3.3 窗口大小与滑动步长的推算方法

滑动窗口的状态开销是可以精确算出来的。一条数据归属的窗口数 =窗口长度 / 滑动步长（向上取整）。如果窗口是 5 分钟、滑动步长 10 秒，那么每条数据要写入 30 个窗口，状态量直接放大 30 倍。

算一个具体的：假设每秒 5000 条数据，每条数据的聚合状态约 200 字节，key 基数 2000，5 分钟窗口、10 秒滑动。每个 key 同时活跃的窗口数约为 30 个，总活跃窗口实例约2000 × 30 = 60000个，每个实例平均积累约5000 × 300 / 2000 = 750条数据的聚合值。如果状态里存的是原始记录而不是聚合结果，内存占用就是60000 × 750 × 200 字节 ≈ 9GB，早就爆了。所以我给所有滑动窗口定的第一条规矩：必须用增量聚合函数，绝不把原始数据堆在窗口状态里。

提示：能滚动就不要滑动。如果业务其实只关心"每分钟"和"每 5 分钟"两个粒度，用两个滚动窗口分别算，比用一个 5 分钟窗口配 1 分钟滑动省 5 倍状态。

4. 窗口函数与触发器：算子内部到底发生了什么

窗口分配器只负责"数据归哪个窗"，真正决定输出什么、什么时候输出、输出几次的，是窗口函数和触发器这两层。这块如果不清楚，配置参数全靠试。

4.1 增量聚合与全量聚合的取舍

ReduceFunction、AggregateFunction属于增量聚合：每来一条数据，就跟当前的累加器合并一次，状态里只保留累加器，内存占用恒定。ProcessWindowFunction属于全量聚合：它把窗口内所有数据缓存成一个Iterable，等窗口触发时一次性遍历。后者的内存占用跟窗口内数据量成正比，是 OOM 高发区。

但全量聚合有一个增量聚合一比不上的优势：能拿到窗口的元信息。窗口起止时间、窗口内的数据条数、当前 watermark 是多少，这些ProcessWindowFunction都能拿到，增量聚合拿不到。这就引出了最实用的组合方式——aggregate(AggregateFunction, ProcessWindowFunction)，用增量聚合打底控制内存，再用ProcessWindowFunction在最终输出时补上窗口元信息。这个写法我现在是标配，几乎不用裸的ProcessWindowFunction。

public class OrderAgg implements AggregateFunction<OrderEvent, OrderAcc, OrderAcc> { @Override public OrderAcc createAccumulator() { return new OrderAcc(0L, 0L, 0); } @Override public OrderAcc add(OrderEvent value, OrderAcc acc) { return new OrderAcc(acc.getAmount() + value.getAmount(), acc.getTs() == 0L ? value.getEventTime() : acc.getTs(), acc.getCount() + 1); } @Override public OrderAcc getResult(OrderAcc acc) { return acc; } @Override public OrderAcc merge(OrderAcc a, OrderAcc b) { return new OrderAcc(a.getAmount() + b.getAmount(), Math.min(a.getTs(), b.getTs()), a.getCount() + b.getCount()); } }

注意merge方法的场景：会话窗口在合并时会调用它。滚动窗口不用合并，但方法必须实现，不能省。如果累加器不是可合并的（比如存了一个平均数），合并语义就会出错，这时候应该存(sum, count)而不是avg，等到getResult时再除。这是我见过最多的聚合错误——滑动窗口里用平均值做累加器，结果对不上，排查半天。

4.2 触发器、驱逐器与清理的边界

触发器决定"什么时候计算并输出"，Flink 内置了几种：EventTimeTrigger（watermark 越过窗口末尾时触发）、ProcessingTimeTrigger（本地时钟越过窗口末尾时触发）、CountTrigger（元素数达到阈值时触发）、ContinuousEventTimeTrigger（每隔固定事件时间间隔连续触发）。默认情况下，事件时间窗口挂的是EventTimeTrigger，触发一次之后就进入"允许迟到"阶段。

PurgingTrigger是个包装器，触发后立刻清空窗口内容，它常跟ContinuousEventTimeTrigger搭配做"持续输出+不重复累加"的效果。但这个组合要慎用，清空之后再来的数据等于进入空窗口重新算，输出语义会变成"增量上报"而不是"最终结果"，下游消费方式完全不同。

驱逐器Evictor的作用是"在触发前后踢掉一部分元素"。CountEvictor保留最近 N 条，TimeEvictor保留最近一段时间内的数据。它的使用场景其实很窄，因为驱逐需要遍历窗口内元素，跟增量聚合冲突，一旦挂了 Evictor，聚合方式就会退化成逐条遍历，性能断崖式下跌。我的建议是：能用allowedLateness解决的问题，就别用 Evictor。

窗口的生命周期收尾也要说清楚。窗口在maxTimestamp <= currentWatermark时触发计算，但不会被立刻清理，它会继续保留一段时间等待迟到数据，清理时机是currentWatermark > window.maxTimestamp + allowedLateness。这条规则解释了为什么allowedLateness调大之后状态会持续增长——每个窗口的存活时间都变长了，同一份 key 上叠加未清理窗口就多。所以allowedLateness不是保险丝，是有成本的。

5. 迟到数据治理：三种兜底方式与参数估算

乱序不会因为配了 Watermark 就消失，只是被压制到一定比例以下。超出容忍范围的数据就是迟到数据，怎么处理直接决定结果的准确性和下游的消费复杂度。

5.1 迟到数据的三种处理方式与代价对比

默认行为是直接丢弃。窗口触发并清理之后，再来属于该窗口的数据，Flink 直接扔掉，不报错、不提示。这种方式实现最简单，但会造成数据静默丢失，业务方如果较真，对账就会差那么一点点。

配置allowedLateness之后，窗口在触发后仍保留一段时间，期间到达的迟到数据会再次触发窗口计算并输出一条新结果。注意这里是"再输出一条"，而不是"更新上一条"，下游会看到同一个窗口有多个结果版本。如果不做去重或覆盖，数字会翻倍。这是很多人第一次用allowedLateness时踩的坑，也是最容易引发线上数据事故的地方。

第三种是sideOutputLateData，把超出容忍范围的迟到数据打到侧输出流，走单独的处理链路。它适合"主链路要求低延迟，迟到数据事后补偿"的场景。缺点是要额外维护一条链路，而且侧输出里的数据需要自己去做幂等合并，复杂度不低。

5.2 参数配置与状态增长估算

allowedLateness设多大，同样看数据分布。我的经验值是取maxOutOfOrderness的 2 到 3 倍，覆盖掉那部分极端长尾。比如水位延迟设 10 秒，allowedLateness设 30 秒，能覆盖到 P99.95 左右。

状态增长要算清楚。假设窗口 1 分钟、并行度 8、每并行子任务每窗口 5000 个 key、每个 key 的聚合状态 100 字节，allowedLateness设为 30 秒。窗口存活时长从 60 秒变成 90 秒，同时存活的窗口从 1 个变成约 2 个（60 秒窗口 + 30 秒宽限期），状态量翻倍。如果allowedLateness设成 5 分钟，同时存活的窗口就变成 6 个，状态变成 6 倍。这个放大是指数级感受的，只是斜率线性。

SingleOutputStreamOperator<OrderStat> result = stream .keyBy(OrderEvent::getProductId) .window(TumblingEventTimeWindows.of(Time.minutes(1))) .allowedLateness(Time.seconds(30)) .sideOutputLateData(lateTag) .aggregate(new OrderAgg(), new OrderWindowResult()); DataStream<OrderEvent> lateStream = result.getSideOutput(lateTag);

5.3 侧输出流的落地方式与幂等设计

侧输出流的OutputTag必须用匿名子类声明，因为它依赖泛型类型信息做序列化，写成(OutputTag<OrderEvent>) new OutputTag(...)这种强制转换在部分版本上会拿不到类型信息，运行时抛异常。这个细节文档里提了一句，但稍不注意就写错。

OutputTag<OrderEvent> lateTag = new OutputTag<OrderEvent>("late-orders"){};

侧输出数据我一般落到一个单独的存储表里，用一个补偿作业按小时级重算，把主链路和补偿链路的结果分表存储，查询时做聚合。这样做的好处是主链路永远只输出一版结果，不存在重复，补偿链路慢一点无所谓，业务方查历史时把两张表合并即可。

6. 实操：把一条实时统计链路从零跑通

前面讲的都是机制，这一节把它落成一个能跑的完整链路。需求很典型：按商品维度统计每分钟的订单金额和笔数，允许一定乱序，迟到数据单独收集。

6.1 数据结构和时间戳字段的约定

事件类里带三个字段：商品 ID、金额、事件时间戳（毫秒）。时间戳由上游埋点写入，不走服务端接收时间，这一点必须在上游约定死，否则事件时间的准度就没了。我在项目里会把这个约定写进接入文档，并且在下游加一层校验：事件时间与当前系统时间差值超过一小时的记录单独统计，用来发现上游时钟异常。

public class OrderEvent { private String productId; private long amount; private long eventTime; // getter / setter 省略 } public class OrderAcc { private long amount; private long firstTs; private int count; // 构造、getter 省略 }

6.2 完整作业骨架与关键参数

作业的骨架不长，但每一步都有讲究。源端并行度决定了水位的对齐方式，水位策略决定了结果的延迟，窗口参数决定了状态规模。

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setParallelism(8); env.enableCheckpointing(60000); env.getCheckpointConfig().setMinPauseBetweenCheckpoints(30000); DataStream<OrderEvent> source = env.addSource(new OrderSource()); SingleOutputStreamOperator<OrderStat> statStream = source .assignTimestampsAndWatermarks( WatermarkStrategy.<OrderEvent>forBoundedOutOfOrderness(Duration.ofSeconds(10)) .withTimestampAssigner((e, ts) -> e.getEventTime()) .withIdleness(Duration.ofSeconds(30))) .keyBy(OrderEvent::getProductId) .window(TumblingEventTimeWindows.of(Time.minutes(1))) .allowedLateness(Time.seconds(30)) .sideOutputLateData(lateTag) .aggregate(new OrderAgg(), new OrderWindowResult()); statStream.addSink(new StatSink()); statStream.getSideOutput(lateTag).addSink(new LateSink()); env.execute("order-window-stat");

checkpoint间隔设 60 秒、最小间隔 30 秒，这个组合是在状态量几十 GB 的规模下调出来的。间隔太短会让整个作业的时间大量花在快照上，吞吐掉得明显；间隔太长则故障恢复时要重放更多数据。这两个值没有标准答案，看状态大小和恢复时长的容忍度。

OrderWindowResult里做的是把窗口起止时间、商品 ID 和聚合结果拼成输出对象，并用window.getEnd()减 1 作为窗口的右边界时间戳，避免"窗口结束时间落在下一个窗口起点"这种边界混淆。这类边界问题在跟离线表对账时特别致命，差一条数据要查很久。

6.3 结果校验与压测记录

作业上线前我做了两轮校验。第一轮是同源对比：把同一份历史数据灌进作业，同时用批处理算一份结果，逐窗口比对。这一步能揪出大部分逻辑错误，比如聚合函数的merge写错、窗口边界偏移、key 分组遗漏。

第二轮是乱序注入压测：人为打乱输入顺序，把乱序程度从 P50 推到 P99.9，观察窗口输出的一致性和迟到数据比例。实测下来，水位延迟设 10 秒时，迟到数据占总量 0.7%；设 3 秒时，迟到比例涨到 5.2%，且窗口结果与基准值的偏差达到 1.8%。这个数据直接决定了最终参数，也成了跟业务方沟通"为什么结果有 1% 以内的浮动"的依据。

压测还暴露了一个问题：并行度从 4 提到 16 之后，吞吐只涨了 1.6 倍，没有再线性提升。最后定位到是keyBy后的热点商品——某几个爆款商品占了 40% 的订单量，全部分到同一个子任务上。解决办法是在 key 上做两层聚合：第一层在productId后拼一个随机后缀（0 到 9）做局部聚合，第二层再按productId汇总。代价是多了一个窗口的延迟，但吞吐提上去了。

6.4 SQL 层的等价写法与参数映射

如果团队更倾向写 SQL，TUMBLE、HOP、SESSION三个窗口函数能覆盖同样的场景。要注意的是 SQL 层的时间属性必须显式声明为WATERMARK FOR ... AS ...，否则窗口函数会退化到处理时间语义。

CREATE TABLE orders ( product_id STRING, amount BIGINT, event_time BIGINT, ts AS TO_TIMESTAMP_LTZ(event_time, 3), WATERMARK FOR ts AS ts - INTERVAL '10' SECOND ) WITH ( 'connector' = '...' ); SELECT product_id, TUMBLE_START(ts, INTERVAL '1' MINUTE) AS win_start, TUMBLE_END(ts, INTERVAL '1' MINUTE) AS win_end, SUM(amount) AS total_amount, COUNT(1) AS order_cnt FROM orders GROUP BY product_id, TUMBLE(ts, INTERVAL '1' MINUTE);

SQL 层有一个 DataStream 里没有的便利：table.exec.emit.early-fire.enabled和table.exec.emit.late-fire.enabled能控制"窗口未结束时提前输出"和"迟到数据触发更新输出"，配合下游的 upsert 存储，可以实现结果持续刷新的效果。这个能力用起来很爽，但要清楚它输出的是更新流，下游如果是 append-only 的存储，接不住。

7. 常见问题与排查速查表

这一节把我在生产上真遇到过的几类问题整理出来，按"现象—定位—处理"的顺序写，遇到问题时可以直接对着查。

7.1 窗口完全不触发或延迟触发

最典型的两个原因：一是水位不推进，二是窗口根本不在等水位。前者查上游分区是否全部活跃、时间戳字段是否解析异常、withIdleness是否配置；后者常见于误用了ProcessingTime分配器但时间语义设成了事件时间，或者源端根本没调用assignTimestampsAndWatermarks——这种情况下 Flink 会用记录进入算子的时间作为事件时间，行为上接近处理时间，但因为乱序参数为 0，一有乱序就大面积丢数据。

还有一种情况是窗口确实触发了，但结果没到下游。这时候去看 sink 的批量提交参数，有时候是攒批时间设得太长，数据在缓冲里没刷出去，跟窗口本身无关。

7.2 数据倾斜与窗口热点

表现为个别子任务的吞吐、状态、CPU 显著高于其他。定位方法是看 Flink UI 里各子任务的 records 和 bytes 分布，差异超过 3 倍基本就是倾斜。常见于按用户 ID、商品 ID 这类长尾分布明显的字段做 key。处理方式有两层聚合加盐、把热点 key 单独拆一条流、或者给 key 加时间桶前缀（每 5 分钟换一批后缀），最后一种能同时缓解热点和状态膨胀。

7.3 状态膨胀与 checkpoint 变慢

状态增长快于数据增长，一般是三个原因：滑动窗口倍数太大、allowedLateness设得太久、聚合函数不是增量式的。排查时先看 checkpoint 大小的时间曲线，如果呈台阶式上涨，多半是某个 key 的窗口没被清理；如果是线性上涨，跟数据量增长相关，要检查窗口参数。RocksDB 状态下还可以看state.backend.rocksdb.block.cache的命中率，命中率低说明状态访问模式有问题，可能要调整 key 的设计。

7.4 参数与问题速查表

7.5 几条不写在文档里的实操习惯

第一，永远给水位单独打一条监控。通过ProcessFunction在流里读context.timerService().currentWatermark()，周期性输出到监控系统，画一条"水位延迟曲线"。这条曲线能提前发现上游异常，比等业务方来问强得多。

第二，上线前先跑一遍全迟到场景。把水位参数设成 0，故意制造乱序，看侧输出能不能正常收到数据、下游能不能正确处理。这条链路平时不工作，真到出问题的时候才发现没通，代价太大。

第三，窗口的右边界统一用"闭区间左、开区间右"。即[start, end)，输出时把end减 1 毫秒作为展示用的结束时间。这个约定要在团队内统一，否则跟离线表对账时总会差一条。

第四，别用allowedLateness去救本来就不准的时间戳。时间戳字段本身有问题，再大的宽限期都是治标，先把上游的埋点修好，再回来调参数。

第五，并行度不要盲目拉高。窗口作业的并行度受限于 key 的分布和状态后端的承载能力，加到某个点之后吞吐不再上升，反而是 checkpoint 时间变长、恢复变慢。我一般会做一次并行度扫描，从 4 到 32 各跑一遍，看拐点在哪。

最后分享一点我自己的体会：窗口参数调优这件事，本质上是在延迟、准确率、资源三者之间找平衡点，不存在一劳永逸的配置。业务量涨了、上游改版了、数据分布变了，原来那套参数就可能不适用。我现在习惯在每个窗口作业里内置一个"参数自检"的小模块，每天统计一次乱序分布和迟到比例，一旦超出阈值就告警，让人主动去看，而不是等结果出偏差之后再回头翻日志。这套东西不复杂，但确实能让人睡得踏实一些。