数据工程面试：如何为事件 Schema 设计兼容性发布闸门？

题干与适用场景

订单事件由多个团队生产和消费。新版本要增加可选字段、重命名一个字段，并淘汰旧字段；消费者无法同时升级，历史消息仍会被重放。请设计从变更提案、兼容性检查、灰度发布到回滚的闸门，并说明 Avro writer/reader schema、Schema Registry 兼容模式和数据质量验证如何配合。

这道题考察数据契约、Schema 演进、流式发布和运营治理。Schema Registry 能集中存储版本、校验兼容性并让生产者与消费者共享契约，但具体规则会随 Avro、JSON Schema 或 Protobuf 格式而变。

面试官在考察什么

• 是否区分 backward、forward、full 与 transitive，而不是把“兼容”当成单一布尔值。
• 能否从 writer schema 与 reader schema 的真实部署窗口推导发布顺序。
• 能否把注册前检查、运行时 schema ID、消费者 lag 和数据质量接成闸门。
• 能否处理重命名、默认值、删除、枚举和不可逆变更的迁移与回滚。

先澄清哪些问题

1. 使用 Avro、JSON Schema 还是 Protobuf？格式不同，解析和兼容细节不同。
2. 消费者是实时、批处理还是会重放历史？最老的 writer 版本保留多久？
3. 生产者和消费者谁先发布，是否存在跨区域或跨团队的长尾版本？
4. 主题按团队、事件类型还是环境划分 subject？兼容级别是全局还是按 subject？
5. 回滚是恢复旧生产者、停止发布，还是需要双写新旧字段？

30 秒回答框架

先建立版本和消费者窗口，再选兼容方向：新消费者读旧消息需要 backward，旧消费者读新消息需要 forward，两者都要求时才考虑 full，并根据最老版本选择 transitive 检查。所有 Schema 先在注册闸门中校验，再按“读者先、写者后”的安全顺序灰度；新增字段提供默认值，重命名采用别名或双字段迁移，删除要等消费者窗口结束。运行时监控 schema 注册拒绝、反序列化错误、lag、死信和关键字段质量，异常时停止推广并保留旧版本。

分步作答

1. 明确 writer 与 reader 的部署矩阵

消息携带或关联 writer schema；消费者用 reader schema 解析。画出旧生产者/新生产者与旧消费者/新消费者的四种组合，标记哪些组合必须支持。实时升级通常先让新消费者能读旧数据，再让旧消费者能读新数据，最后才切换生产者。

2. 把兼容模式绑定到风险

Backward 检查新 reader 能否读旧 writer；forward 检查旧 reader 能否读新 writer；full 同时检查两者。若需要跨越多个历史版本，选择 transitive 语义或显式测试版本集合。不要把某个注册中心的默认值当成所有格式的通用规则。

3. 设计变更规则

增加字段时给出安全默认值，并验证默认值的业务含义；重命名优先使用格式支持的 alias，或先双写旧、新字段，再迁移读者；删除字段要等最老消费者和重放窗口结束。枚举新增值需要确认旧消费者的未知值行为，类型收窄、含义改变和单位改变应视为破坏性变更。

propose -> lint -> compatibility-check -> consumer-matrix-test
        -> register -> canary-producer -> observe -> expand

4. 建立注册与 CI/CD 闸门

PR 阶段运行格式 lint、规范化 diff、subject 级兼容检查和代表性历史样本反序列化。注册中心保留 schema ID 与版本；发布工具拒绝绕过检查的生产注册。兼容级别可以按 subject 管理，不能只改全局配置而忘记局部覆盖和权限审计。

5. 按读者先、写者后的顺序灰度

先发布能读旧版本的新消费者，观察反序列化错误和 lag；再双写或发布新生产者；最后停止旧消费者和旧字段。跨团队长尾消费者要有清单、负责人和截止时间，不能用“大家升级后再发”作为控制面。

6. 运行时质量与回滚

监控 schema ID 未知、反序列化失败、死信量、字段缺失率、单位异常、消费者 lag、重放成功率和注册拒绝数。回滚优先停止新生产者并恢复仍兼容的旧 writer；若语义已改变，保留新 topic 或版本化 subject，避免把旧数据强行解释成新含义。

高质量示范答案

我会先画出 writer/reader 的部署矩阵，确认需要支持的旧生产者、旧消费者和重放版本，再按格式选择兼容规则。新 reader 读旧消息是 backward，旧 reader 读新消息是 forward，两者都要支持才考虑 full；跨多个历史版本则做 transitive 检查。所有变更先经过 lint、subject 级注册检查和历史样本反序列化。

发布顺序是读者先、写者后：先灰度新消费者，再双写或切换新生产者，最后等待消费者窗口结束后删除旧字段。新增字段给默认值，重命名用 alias 或双字段过渡，删除和枚举变化都要验证旧客户端行为。线上观察注册拒绝、反序列化错误、lag、死信和字段质量；异常时停止扩散、保留旧 schema，必要时回到旧生产者或新旧 topic 分流。兼容模式必须按具体格式验证，不能把一个产品的默认规则当成 Avro、JSON Schema、Protobuf 的共同语义。

常见失分点

• 只说“启用 backward”，却不说明谁是 reader、谁是 writer。
• 直接重命名或删除字段，忽略 alias、双写和历史重放。
• 只在注册时检查 Schema，不测试真实历史消息和旧消费者。
• 先发布新生产者，导致旧消费者收到无法解析或语义错误的数据。
• 把全局兼容配置当成 subject 级策略，忽略权限和配置漂移。
• 只监控 Kafka lag，不监控字段缺失、单位变化、死信和反序列化错误。

追问与参考回答

新增字段为什么常要求默认值？

旧消息没有该字段，新 reader 需要一个确定值才能构造记录；默认值必须符合业务语义，不能用空值掩盖必填数据缺失。

重命名字段应直接改名吗？

通常不应直接改。可先用 alias 或同时写旧、新字段，迁移所有 reader 后再删除旧字段，并保留足够重放窗口。

full 与 full transitive 有什么风险差异？

full 通常检查当前相邻版本的双向兼容；transitive 会扩大到历史版本集合，门禁更严格但升级成本更高，应根据保留和重放范围选择。

为什么 schema 注册成功仍可能丢数据？

兼容性只覆盖结构解析，不保证业务单位、枚举语义、字段质量、权限或下游 SQL 正确；必须结合样本回放、质量规则和运行时观测。

如何为长尾消费者设置退出条件？

登记 owner、版本、最后消费时间和重放需求，设置明确截止日期与告警；到期前提供迁移工具，到期后先隔离或拒绝旧版本，而不是永久放宽兼容规则。

什么时候应该新建 subject 或 topic？

当语义、单位、生命周期或权限边界已改变，无法通过兼容演进表达时。新版本隔离可降低误解析风险，但要承担双写、回放和治理成本。