埋点数据从采集到入仓之间字段悄悄漂移，你们在数据管道哪一层做契约校验？

【背景】 我在做一套面向 B 端的数据分析平台，前端埋点通过 Kafka 上报，经 Flink 清洗后写入 ClickHouse，下游是业务方直接查的指标看板。链路本身不复杂，但最近反复踩到一个让我很头疼的问题。

【现象】 前端埋点字段发生了"静默漂移"：同一个事件名 order_submit，前端在某个版本把 amount 从整数（分）改成了浮点（元），且没有走任何变更评审。下游一个"客单价"指标因此悄悄虚高了 100 倍，业务方在大盘上看到数字"异常好看"，三天后才被我们核对原始日志发现。更糟的是，ClickHouse 的列类型是 Float64，所以类型不匹配根本没报错——数据"合法地"错了。

【已尝试的排查与结果】

1. 在 Flink 清洗层加了字段非空校验和基础范围检查（amount > 0），能拦住空值，但拦不住"单位变了"这种语义漂移；
2. 试过对核心事件做"同环比突增告警"，能兜住大偏差，但小幅度漂移（比如 1.2 倍）经常漏报，且误报率高到值班同学开始忽略；
3. 考虑过让前端每次发版必须提"埋点变更单"，但推动成本高，且总有人绕过。

【期望得到的答案形态】 想听听大家在实际生产环境里是怎么在"采集 → 清洗 → 入仓"这条链路上做埋点契约校验的：

• 你们是在哪一层（SDK 侧 / Kafka 消费侧 / 入仓前）做 schema 校验？用的什么工具或自建方案？
• 对"字段类型没变但语义/单位变了"这种漂移，有没有可落地的检测手段（比如黄金数据集比对、采样回放、统计分布漂移检测）？
• 校验失败的埋点是直接丢弃、降级到影子表、还是走人工审核队列？
• 有没有踩过"校验规则太严把正常埋点拦了"或"太松等于没校验"的坑？

最好能给出你们的具体配置思路或分层策略，而不只是"建议加监控"这类方向性建议。