数据合同 Data Contract 怎么设计？

面试问 185 约 2 分钟读完 1 次阅读

本文目录

面试怎么回答

我会把数据合同定义为生产者与消费者之间可机器校验的接口约定。内容包括 Schema、业务语义、质量阈值、SLA、安全分级、Owner 和版本变更策略。落地上以数据产品为边界，把 Schema 校验放到发布前，把质量与时效放到运行期；破坏性变更必须做影响分析、版本升级和过渡，不能只发一条群消息。

先把这段讲顺；面试官追问时，再展开下面的原理和细节。

详细讲解

上游把金额从“分”改成“元”，字段名和类型都没变，下游报表却悄悄放大了 100 倍。

数据合同要管的，正是这种 Schema 没变、业务含义已经变了的兼容性问题。

数据合同不是一份字段清单，而是生产者与消费者共同认可的可机器校验约定，覆盖结构、语义、质量、时效、变更和责任。

第一类是 Schema：字段、类型、是否为空和主键；第二类是语义：单位、枚举、口径与时间含义；第三类是质量：唯一性、完整性、范围和一致性；第四类是服务等级：更新频率、延迟和可用性；第五类是安全分级；第六类是 Owner、版本、变更流程与故障联系人。

合同不应细到每个临时 CTE，也不能大到整个数仓只有一份。更合适的边界通常是一个稳定的数据产品、主题表、事件流或对外服务。它必须有明确生产者、已知消费者和可以独立发布的版本。

数据合同的六层约束

Schema 兼容性可以在 CI 或注册中心校验，质量规则在产出后运行，时效由调度和可观测平台监控。只有能自动发现违约，合同才不是放在文档里的“愿望”。严重规则阻断发布，非阻断规则告警并保留豁免记录。

新增可空字段通常向后兼容；删除字段、收窄类型、改变单位或枚举语义往往是破坏性变更。破坏性变更需要新版本、影响分析、双写或过渡期，以及消费者确认。即使 Schema 没变，只要业务口径变了，也应该走合同变更。

合同如何进入交付链路

生产者负责真实、稳定地发布数据并提前声明变化，消费者负责说明依赖和使用边界，平台负责提供模板、注册、校验和可观测能力。若出了问题所有人都找“数据组”，说明 Owner 和升级路径没有进入合同。

不要一上来给几千张表补合同。先挑收入、成本、核心用户和对外数据等高风险链路，梳理已有消费者，把事故中出现过的字段单位、延迟、重复和枚举变化写成第一批规则。合同应随着真实问题演进。

刷题进度保存在当前浏览器