上游事件流 schema 悄悄变更导致 3 个核心指标口径漂移 8%：指标计算链路里怎么自动评估 schema 变更的影响面？

【背景】 我负责一个 B 端 SaaS 的指标体系，核心 + 过程指标共 80+ 个，底层依赖 12 种 Kafka 事件流（用户行为、订单、支付、功能调用等），计算链路是 Kafka → Flink（实时清洗 + 聚合）→ ClickHouse（明细 + 预聚合）→ BI 看板。上游有 6 个业务团队各自往事件流里加字段、改枚举，我对他们来说只是"下游之一"。

【现象——两次真实踩坑】 ① 上个月上游在"用户行为事件"里把 action_type 从 5 个枚举值扩展为自由字符串（新增了 12 个值），同时加了个 ab_group 字段。结果我的 DAU、次日留存、功能渗透率 3 个指标的分母悄悄变大了（原来 SQL 里 WHERE action_type IN ('view','click','submit','purchase','cancel')，新值进来后这 3 个指标的"全量用户池"膨胀了约 8%，但分子逻辑没变，指标"看起来"跌了 8%）。业务方以为是产品问题，其实是我这边口径被上游"扩"了。 ② 更隐蔽的：ab_group 加入后，Flink 的 schema 注册中心没同步更新，2 个下游 Flink 任务在反序列化时静默丢弃了这个字段——没报错、没告警、日志里只有 info 级别一行。基于 ab_group 分组的实验看板数据全为 0，业务方看了 3 天才发现"实验没跑起来"，其实是数据根本没进来。

【已尝试的排查与结果】

1. 手动对比 12 种事件流的 schema 变更 git log 和 80+ 指标的计算 SQL，花了 2 天找到 5 个受影响指标（还有 3 个"可能受影响"没确认）；
2. 在 Flink 侧加了 deserialization 失败率告警（> 0.1% 触发），但"静默丢弃"这种不会触发反序列化失败，所以没兜住；
3. 目前靠"人肉 review 上游 schema 变更 PR"来预防，但 6 个团队、每周 3~5 个 PR，review 经常漏——尤其非核心字段的变更经常被批"LGTM 合了"。

【期望得到的答案形态】

1. schema 变更 → 下游指标影响面的自动评估：有没有基于字段血缘 + 指标 SQL 解析（比如解析 ClickHouse / Flink SQL 中引用的字段名），当上游 schema 变更时自动列出"哪些指标的计算逻辑会受影响"的机制或工具？你们团队是怎么做的？
2. Flink 反序列化"静默丢弃"的兜底：除了 deserialization 失败率告警外，有没有更可靠的手段（比如 schema 指纹校验、字段覆盖率监控、consumer lag 的异常检测）能兜住"字段被静默丢弃但任务不报错"的情况？
3. 硬编码枚举值的反模式：指标计算 SQL 里 WHERE action_type IN (...) 这种写法，有没有更优雅的替代（比如引用一张"有效 action_type 枚举表"、或用 Flink 的 schema registry 动态匹配），让上游新增枚举值时下游自动适配而不是悄悄漏掉？

如果能附一个你们团队真实踩过的案例或落地方案就更好了。