指标口径变更的「守门员」到底该交给谁：工程侧 schema 版本化 vs 数据侧口径冻结评审，你站哪边？

【背景】

在数据驱动的系统中，指标口径变更是一个常见但高风险的操作。当指标口径发生变更时，可能导致历史数据的不可比、下游分析的偏差，甚至业务决策的失误。因此，如何有效地控制指标口径变更的节奏和范围，成为数据团队和工程团队之间的一个核心议题。

【常见分歧】

1. 工程侧 schema 版本化：在工程侧通过 schema 版本化管理指标定义，允许逐步更新和回滚，确保数据结构的稳定性。

2. 数据侧口径冻结评审：在数据侧通过冻结口径评审机制，限制指标口径的变更频率和范围，确保数据的一致性。

【我的倾向】

我倾向于工程侧 schema 版本化。在实际操作中，工程侧的 schema 版本化管理可以更灵活地应对指标口径的变化，同时确保数据结构的兼容性和稳定性。通过版本化管理，可以明确变更的范围、影响和回滚机制，从而降低变更带来的风险。

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

• 在哪些场景下，工程侧 schema 版本化更合适？
• 在哪些场景下，数据侧口径冻结评审更有效？
• 你们在实际工作中是如何平衡这两种做法的？

欢迎分享你们的经验和见解。