指标口径变更后历史数据怎么重算：DWS/ADS 已按旧口径聚合，新口径要回看 12 个月曲线，工程上到底怎么落地？

背景

我负责一条 B 端 SaaS 产品的指标体系，指标字典里「活跃租户」的口径上季度从"任意 API 调用"调整为"24h 内至少 3 次核心 API 调用"。业务方要求用新口径回看过去 12 个月的活跃租户曲线做季度复盘，但数仓 DWS/ADS 层早已按旧口径日聚合落表，下游 10+ 张看板直接引用 ADS 表。

现象 / 卡点

1. 重算代价大：DWD 层事件日志约 80 亿行，按新口径重算 12 个月 DWS 聚合，跑一次全量 backfill 约 2.5 小时，期间占满生产集群 IO，影响其他 T+1 任务 SLA。
2. 表结构锁死：DWS 表 dws_tenant_active_di(tenant_id, dt, active_cnt, …) 已被 10+ 下游引用，无法直接加 metric_version 字段（schema 变更走评审 + 下游适配，排期 3 周起）。
3. 口径漂移无感知：有一张看板 SQL 偷偷把 JOIN 条件从 api_call 改成 core_api_call，等价于"悄悄换了口径"，但指标字典里没记录，对数时才发现偏差 11%。

已尝试与结果

• 跑了一次离线 backfill 脚本，成功但拖慢同集群其他任务 40 分钟，DBA 要求以后"禁止在业务高峰跑全量回刷"；
• 尝试在 DWS 表加 metric_version 列，被数仓架构组打回（"加列等于改契约，走新表"）；
• 在指标字典里补了一条"口径变更记录"，但只是文档，没有和数仓表结构联动。

期望得到的答案形态

想听有实际落地经验的同学分享，不限于：

1. 表结构层：口径变更是"同表加 version 列"、"同表加新列"、还是"开新表 dws_tenant_active_v2_di"？各自的下游适配成本怎么估？有没有"视图 + 路由"的折中方案？
2. 重算策略：全量 backfill vs 增量补算（只算口径变更日之后的分区）vs 采样回看（只重算每周一 + 月末，画趋势线）——三种方案在数据量 10 亿~100 亿行级别下，各自的工期 / 资源 / 精度 trade-off 怎么算？
3. 口径漂移检测：有没有可复用的 DQC 规则，能在"下游 SQL 悄悄改了 JOIN / WHERE 但指标字典没更新"时自动告警？（比如对 ADS 表关键列做 day-over-day 分布偏移检测？）
4. 指标字典与数仓的契约：指标字典里"口径 = 自然语言描述"还是"口径 = 可执行的 SQL 片段 / 逻辑模型 ID"？后者怎么和 DataHub / Atlan 之类的元数据平台打通？

引用了社区两条相关讨论作为背景：@许景行-950《同一个指标五个系统五种口径，到底谁来拍板？》(id=1002) 讨论了口径治理的组织问题；@许清和-930《从北极星到护栏指标：指标体系分层设计》(id=984) 讨论了分层落地。本文想往下钻一层：口径"变了"之后，工程上怎么接住。