数仓 DWD 表字段变更，下游 20 个任务受影响，你们是怎么「安全改字段」的？

背景

10 年大数据平台，最让我头疼的不是慢查询，而是"业务方一句口径改一下，我们得回刷 N 个月、通知 20 个下游"。最近半年在几个团队里反复看到同一个场景：DWD 层一张订单明细表，channel 从「渠道 ID」改成「渠道名称 + 渠道 ID 双字段」，或者 order_status 枚举扩了一个值。看起来是"加个字段"或"多一个枚举"，实际牵动的是：

• 下游 20 个 DWS / ADS 任务的 SQL 要不要改？谁改？谁验收？
• 已物化的报表、BI 数据集、下游服务的缓存要不要清？
• 历史 N 个月的数据要不要回刷？回刷窗口多长（30 天 / 90 天 / 全量）？
• 回刷期间下游读到的"新旧口径混着"，业务方会不会投诉？
• 如果改字段时发现某个下游其实已经"野了"（没人维护），是顺手下线还是继续背着？

常见分歧 / 几种做法

1. 冻结派：核心 DWD 表字段一律不加、不改，业务需求一律走"新建 DWD_v2"，老表只读不再回刷。优点是下游稳定、血缘干净；缺点是表越积越多，最后没人说得清该查哪张，半年后 DWD 层变成"墓地"。

2. 兼容派：允许加字段（新列、新枚举），但禁止改语义；下游"按需取数"，老逻辑不动、新逻辑用新字段。听起来最优雅，实际执行最容易翻车——加字段时没人校验"语义是否真的兼容"（比如 channel 从 ID 变 name，下游 WHERE 条件直接失效），半年后没人敢动老字段，新字段也没人敢删。

3. 血缘驱动派：上数据血缘平台（Atlas / DataHub / 自研），改字段前自动列出下游任务、负责人、SLA，走审批流；回刷走统一调度，下游任务按拓扑序自动触发。平台是有了，但血缘覆盖率通常只有 60%~80%（尤其是 Spark 动态 SQL、Python 脚本、Excel 手查这几类），剩下那 20% 的"野下游"照样翻车。

4. 回刷兜底派：不做前置治理，出问题就回刷。回刷窗口 30 / 90 / 180 天三档，按业务方出算力预算决定。简单直接，但每次回刷都是一次小型 P1 事故——回刷期间集群 IO 打满、上游任务排队、下游数据抖动，业务方投诉是标配。

我的倾向

我倾向「兼容派 + 血缘兜底 + 回刷 SOP」的组合，理由：

• 字段变更 90% 是"加"而不是"改"，加字段的兼容性是可以在代码评审阶段用规则卡住的：新列必须有默认值、新枚举必须有映射表、WHERE 条件命中的列禁止改类型——这三条不卡住，什么血缘平台都救不了；
• 血缘平台别追求 100% 覆盖，追求"核心 20 张表的 100% 覆盖"，剩下 80% 的野下游用"回刷兜底"覆盖，成本更可控；
• 回刷本身要有 SOP：窗口、算力预算、通知模板、回滚方案，四件事缺一不可。我见过最离谱的一次回刷，回滚方案是"再回刷一次"——这就是没有 SOP 的下场。

想听大家

• 你们团队 DWD 层字段变更走什么流程？有没有成文的"字段变更 SOP"？
• 血缘平台覆盖率你们做到多少？剩下的"野下游"怎么兜底（人工盘点？告警兜底？）？
• 回刷窗口的算力预算，业务方出还是数据团队出？有没有"业务方不肯出预算、数据团队硬扛"的案例？
• 有没有"改字段改出 P1 事故"的血泪史？想听细节，尤其是"野下游"那部分。

欢迎拍砖。