Flink 作业升级：用双跑与 Diff 把正确性变成证据

工程学习与设计笔记。示例使用合成场景；适用版本与参考资料见正文。

Flink 升级成功启动，只证明新程序可以运行。它不证明旧状态完整恢复，也不证明输出语义相同。真正的迁移验收需要三条独立证据：状态能恢复、业务结果符合预期、运行指标可接受。

本文以迁移到 Flink 1.15 为讨论基线。跨越多个版本时，需要逐项核对各版本和连接器的兼容说明，不能仅凭“使用 savepoint”就承诺任意版本直接升级。

先冻结比较对象

把运行时升级、业务逻辑修改、schema 修改、来源切换放在同一个发布里，一旦结果变化就很难归因。条件允许时应拆开；必须合并时，也要为每类变化建立独立预期。

迁移清单至少包含：Flink 与 Java 版本、connector 版本、算子 UID、状态名称、序列化器、key 类型、最大并行度、checkpoint 配置、时区、外部依赖版本和 sink 语义。很多所谓“Flink 升级问题”其实来自默认配置或依赖冲突。

Flink 的 savepoint 通过算子身份关联状态，官方建议显式分配 UID，以降低拓扑变化对自动 ID 的影响。Flink 1.15：Savepoints

稳定 UID 只是必要条件之一。状态字段改动能否兼容取决于序列化器；key 的 schema 变化尤其不能当作普通字段升级处理。Flink 1.15：State Schema Evolution

旧、新作业读取同一段逻辑输入，分别输出到隔离结果集。Kafka 可以使用独立消费组并对齐分区边界；文件回放应冻结文件清单与版本。影子作业不应重复触发计费、通知或不可逆写入。

外部维表是常被忽略的变量。旧作业上午查到用户标签 X，新作业下午查到 Y，即使代码完全一样也会产生差异。可以在验证中冻结维表快照、记录外部响应或固定版本；无法固定时，把这类非确定性字段单独统计，不能直接归因成升级错误。

双跑期间还要标出预热边界。新任务从空状态启动，去重、窗口和维表缓存尚未完整，与旧任务自然不同。应选择可比的初始状态，或者明确预热区间并只比较覆盖充分的事件范围。

第一层比较守恒关系：输入数、过滤数、异常数、输出数。第二层按业务键做集合差异。第三层才比较双方共同记录的字段。

left_only     旧链路有，新链路没有
right_only    新链路有，旧链路没有
field_diff    同一业务键存在字段差异
duplicate     一侧相同业务键出现多次

先检测重复再 join，否则多对多连接会放大差异。嵌套 map 应按语义比较键值，浮点数只在业务允许时使用容差，处理时间、trace ID 等非业务字段应有显式忽略清单。不能用一份未经解释的正则规则删掉所有“不好对”的字段。

对于窗口聚合，比较的是已确定窗口内的业务值，不能随手拿两次实时快照相减。需要对齐 event-time 范围、watermark 进度、迟到处理和最终结果版本。总量一致也不充分：两个来源一增一减可能完全抵消。

至少执行一次“新版本从目标状态恢复 → 处理受控输入 → 再失败恢复”的演练。观察定时器、去重状态和外部写入是否符合预期。使用忽略未恢复状态的参数前，要清楚被放弃的究竟是什么；它不应该成为让启动变绿的通用开关。

验收报告可以很短，但必须可追查：

维度	证据
正确性	比较区间、样本量、差异类型及解释
状态	savepoint 恢复结果、关键状态断言
性能	相同负载下的延迟、积压、CPU、状态与 checkpoint
恢复	人为故障后的耗时与重复/缺失事件统计
回退	旧产物、可恢复状态、输入保留期、外部输出处理方式

回滚运行版本不会自动撤销新版本已经写出的数据。迁移前就要设计幂等键或修复批次，并确认旧版本能否读取回退用状态。把回退理解成“重新发一个旧包”，会漏掉最难补救的部分。