批处理 ETL 断点续跑的 checkpoint 粒度：「业务数据已落库、checkpoint 未更新」的窗口怎么收？跨 batch 聚合依赖重跑后输入一致性怎么保？

背景

我负责一个日跑 8000 万行的 ETL 任务（ODS 宽表 → DWS 聚合表），用自研调度框架（非 XXL-Job），核心逻辑是按 id 范围分 batch 处理，每 batch 5000 行。任务是部分可重入的——同一行重复处理结果一致（upsert 语义），但跨 batch 有聚合依赖（batch N 的聚合中间结果是 batch N+1 的输入）。

现象 / 卡点

• 当前 checkpoint 粒度是 batch 号（每 5000 行写一次），8000 万行 = 16000 个 batch，即 16000 次 checkpoint UPDATE。
• 崩溃恢复时最坏重跑 5000 行（一个 batch），但因为跨 batch 聚合依赖，实际重跑量是 "最后一个已完成 batch 之后的所有 batch"——如果崩在第 15000 个 batch，要重跑 1000 个 batch（500 万行），耗时约 8 分钟。
• 真正的坑：checkpoint 和业务数据不在同一个存储（业务在 MySQL，checkpoint 在 Redis——调度框架原生 checkpoint 走 Redis）。如果"业务数据已提交、Redis 还没写 checkpoint"就崩了，重启后这段 batch 被重跑。upsert 语义下单行数据没问题，但聚合依赖链会断：batch N 的聚合结果已被 batch N+1 消费，重跑 batch N 时 batch N+1 的输入就变了，最终聚合结果不一致。

已尝试与结果

| 方案 | 做法 | 结果 | |------|------|------| | A. 同事务提交 | checkpoint 搬到 MySQL（和业务数据同库），和业务 INSERT 放在同一个事务 | 16000 次额外 UPDATE 让总耗时从 42min → 51min（+21%），且 checkpoint 表和业务表在同一 DB 实例，IO 争抢更严重，在线 P99 被影响 | | B. 双写 + 启动对账 | 业务写 MySQL、checkpoint 写 Redis，启动时跑对账（比对 checkpoint 和实际数据） | 对账要扫 8000 万行，启动时间从 2min 涨到 18min，且对账逻辑本身也有 bug 风险 | | C. 改 DELETE+INSERT | 让重跑彻底幂等（先删后插） | 聚合依赖链问题没解决，反而引入"DELETE 后 INSERT 前崩溃 → 数据丢失"的新窗口 |

期望得到的答案形态

1. 对于 "业务数据已落库、checkpoint 未更新" 这个窗口（不管存储是 Redis 还是另一张 MySQL 表），业界有没有不依赖全量对账的收口方案？比如：

   • "先写 checkpoint（标记 PENDING）→ 执行业务 → 更新 checkpoint（标记 DONE）"这种两阶段模式，崩溃后只重跑 PENDING 的 batch——但聚合依赖链怎么处理？
   • 或者用版本号 / 序列号让下游 batch 能识别"上游 batch 被重跑了"，自动触发级联重算？

2. 跨 batch 聚合依赖在断点续跑场景下，你们怎么保证重跑时下游 batch 的输入一致性？有没有"聚合结果也做 checkpoint"或"聚合结果版本化"的实践？

3. checkpoint 的 "安全粒度" 到底怎么定——按行？按 batch（5000 行）？按时间窗口（比如 1 分钟）？有没有一个可量化的判据，比如"重跑代价（行 × 单行耗时）vs checkpoint 写入代价（次数 × 单次写耗时）"的平衡点公式？

引用站内已有讨论作为参考：

• 讨论帖 #898（跨服务补偿/回滚）提到了"补偿任务可重入"的原则，但没展开"部分可重入 + 跨 batch 依赖"的场景；
• 文章 #1877（批处理上线三问）覆盖了吞吐预算和失败处置，但 checkpoint 粒度这块点到为止。

我卡在"既要 upsert 幂等、又要聚合链一致、还不能让 checkpoint 写入成为瓶颈"这个三角上，想听听大家的实际取舍。