指标口径变更后，历史报表怎么兼容？
面试怎么回答
我会先区分数据纠错还是业务定义升级，再为指标建立版本、生效时间、负责人和依赖。历史处理可选全量重算、从生效日切换或双版本并存，并根据审计和趋势连续性决定。上线前做新旧口径影响对比，识别报表、API 和告警，下游按计划迁移，同时在看板标注趋势断点。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
“从下个月开始，支付成功才算订单。”业务的一句话，可能让过去两年的订单量全部改变。
口径变更不是改一段 SQL，而是决定历史重算、版本并存和报表解释方式。
指标口径必须版本化，并明确新规则从何时生效、历史是否重算以及下游如何选择。
先判断变更类型
字段修错、过滤条件变化、业务定义升级和数据源替换影响不同。纠错通常需要回溯，业务制度变化可能只从生效日使用新口径，不能混在一次发布里。
给口径分配版本
记录指标 ID、版本、定义、负责人、生效时间、依赖字段和变更原因。计算结果也应带口径版本，避免同名指标在不同报表中含义不明。
选择历史策略
常见策略是全量重算、从生效日切换、双版本并存或提供桥接指标。选择要考虑审计要求、趋势连续性、计算成本和业务解释。
管理下游迁移
发布前识别报表、API、告警和导出任务，提供影响对比和切换窗口。不能只通知开发者，还要让业务知道趋势断点来自定义变化，而不是经营异常。
为什么不能只回答概念？
“误区：直接改公共 SQL，所有报表自动变正确”之所以常见，是因为它在理想数据和单次执行里往往说得通。但生产环境会加入数据规模、异常值、并发、版本、失败重试和下游口径，这些条件一变化，只记住术语就很容易给出错误结论。
所以我会把 先判断变更类型、给口径分配版本、选择历史策略、管理下游迁移 串成一条完整链路。最终判断标准不是某个函数或配置是否出现，而是能否稳定得到可解释、可验证、可恢复的业务结果。
落地时我会检查什么？
- 输入边界：确认数据范围、时间口径、主键和异常值是否符合假设。
- 执行过程：观察分区、并行度、状态、Shuffle 或资源变化，验证方案是否真正生效。
- 输出结果：用行数、唯一性、关键指标和样本明细证明结果正确，而不是只看任务成功。
- 失败恢复：说明重跑、回滚、版本兼容和责任人，避免一次成功后无人维护。
这些检查不一定全部写进一条 SQL 或一个任务，但面试时能主动补充，说明你回答的不是背诵题，而是在描述一套可上线的工程方案。
一个典型场景
一个典型场景是活跃用户从“打开 App”改为“完成核心行为”。公共层直接替换 SQL 后，历史曲线整体下降，经营团队误以为产品活跃骤降。后来恢复旧版本，并让新旧口径并行一个周期，在看板标出生效日和差异拆解后再完成迁移。
指标可以同名，口径不能无版本。