线上数据出错了：全量重跑、增量修补、双跑对账，你们到底怎么选？

背景

站内聊「幂等」「异步化」「缓存一致性」都聊得很透了，但有一个我作为数据工程师天天被追问、却几乎没人正面展开的问题：线上数据已经错了，怎么修？

我习惯从现象倒推。上个月我们一张核心指标表出错了——不是 bug，是上游口径悄悄改了字段语义，导致过去 90 天的分区都按错误口径聚合了一版。业务方盯着看板说「数不对」，第一反应是「重跑」。可 90 天分区、底层 1.2 亿行流水、下游还挂着 4 张汇总表 + 2 个 BI 数据集，全量重跑一次要 6 小时、占满集群还影响当天调度。更麻烦的是：上游口径本身还在变，你重跑的「正确版本」和它现在跑的「最新版本」对不齐，修完第二天又漂了。

常见分歧 / 几种做法

1. 全量重跑：把出错窗口整段按新口径重算。干净、可解释，但贵、慢、对下游有冲击，且上游还在动时容易「追不上」。
2. 增量修补：只补错的那几天 / 那几个分区，其余不动。快、便宜，但前提是「错的范围能精确圈定」——一旦口径是渐进式漂移，你圈不准边界，补出来的仍是缝补品。
3. 双跑对账：新旧两套口径并行算一段时间，diff 出差异区间，确认收敛后再切。最稳，但要双倍算力，且需要有人天天盯 diff。
4. 回刷 + 幂等落表：把修复做成一个可重入的 job，带幂等键（分区 + 口径版本）落表，重跑多少次结果一致，出错了能整段重来。工程上最省心，但要求管道本身幂等、且下游能感知「口径版本」这个维度。

我的倾向与理由

我倾向 4（幂等回刷为主）+ 3（双跑兜底校验），而不是上来就 1 或 2。理由：

• 全量重跑（1）最大的坑不是慢，而是不可重入——跑一半挂了、上游又变了，你就得手工对齐，最后往往变成「谁也不敢动」的烂尾。把它做成幂等 job（幂等键 = 分区 + 口径版本号，ON DUPLICATE KEY 或先删后插），重跑才是安全的，这是「能反复修」和「只能修一次」的本质区别。
• 增量修补（2）只在「错误边界清晰」时成立。如果根因是口径漂移（像我们这次），边界是模糊的，硬圈边界会把「对的数据」也误伤。修之前必须先定位根因是「点状错误」还是「面状漂移」，这决定了 1/2/3 哪个才对症——这也是我说的从现象倒推根因：别一上来就选工具，先判断错误的「形状」。
• 双跑对账（3）不该是默认动作（太贵），而是切换前的验收门槛：新旧版本 diff 收敛到一个可接受阈值（比如关键指标相对差异 <0.1%），才允许把下游指过去。

想听大家在什么场景下怎么选

• 你们线上数据纠错，默认是 1/2/3/4 哪种？有没有踩过「增量修补结果越补越乱」的坑？
• 口径版本这个维度，你们管道里有吗？还是修数据只能「整表覆盖」？
• 全量重跑你们怎么和「当天调度」抢资源、怎么避免重跑把下游打挂？
• 双跑对账的 diff 阈值你们怎么定？谁来定、定错了谁负责？
• 对「上游口径还在变、你追不上」这种局面，你们最后是怎么收的——硬追、冻结口径、还是和业务谈改 SLA？

欢迎贴具体数字（分区数、行数、重跑耗时、diff 阈值），别只给结论——我想看看大家在什么数据量级、什么口径稳定性下，才敢真把「全量重跑」当默认手段。