Apache Flink非对齐检查点的额外劣势及对端到端精确一次语义的影响

1. 非对齐检查点除额外I/O外的劣势 #

• 状态快照体积与恢复成本上升：非对齐模式下需要缓存未处理的输入数据到快照中，导致快照体积远大于对齐模式。这不仅增加存储占用，恢复时加载快照的时间也会变长，拖慢故障恢复速度。
• 算子恢复逻辑复杂度提升：多输入算子恢复时，需要处理快照中缓存的不同输入流的未对齐数据，相比对齐模式下直接从统一 checkpoint 恢复的逻辑，更容易出现逻辑漏洞或恢复异常。
• 无状态算子额外开销：无状态算子在对齐模式下几乎不需要参与检查点的额外操作，但非对齐模式下必须缓存输入数据，平白增加了内存和CPU开销，违背了无状态算子轻量化的设计初衷。
• 存储系统小文件压力：频繁触发非对齐检查点会生成大量小体积的快照文件，对HDFS这类对小文件敏感的存储系统来说，会增加元数据管理负担，降低存储整体性能。

2. 对端到端精确一次语义的影响 #

非对齐检查点不会破坏端到端精确一次语义，核心原因在于其快照机制与Flink的恰好一次保障逻辑兼容：

• 非对齐检查点会同时保存算子的当前状态，以及各输入流未被完全处理的增量数据。故障恢复时，算子先从检查点恢复状态，然后重放缓存的未处理数据，同时Flink会协调数据源从对应偏移量开始重新发送数据。
• 以多输入Join算子为例：假设检查点触发时，流A已处理到offset 100，流B处理到offset 80，此时快照会保存Join算子的当前状态，以及流A 100之后、流B 80之后的未处理数据。恢复后，算子先回到检查点的状态，再处理缓存的增量数据，同时数据源会重新发送流A从100、流B从80开始的数据，最终Join结果不会出现重复或丢失，依然满足精确一次语义。

内容的提问来源于stack exchange，提问作者Hadi