数据契约的构成要素：生产者与消费者、Schema定义、SLA承诺、变更管理流程
上一章我们聊了数据契约为什么能降本。这一章，咱们把契约拆开看看——它到底长什么样？
说白了，一份完整的数据契约，就像一份商业合同。合同里得有甲方乙方、标的物、交付标准、违约条款。数据契约也一样，核心就四个部分：生产者与消费者、Schema定义、SLA承诺、变更管理流程。
我刚开始推行数据契约时，团队里有人问：“不就定个数据格式吗？搞这么复杂干嘛？”结果第一个月就出了事故——生产者改了字段类型，消费者那边直接崩了。嗯，从那以后，没人再嫌这四个要素多了。
核心观点：数据契约不是文档，是可执行的协议。四个要素缺一不可，少一个，契约就变成了一纸空文。
2.1 生产者与消费者：契约的双方
先搞清楚谁是谁。
- 生产者（Producer）：数据的提供方。通常是业务系统、微服务、数据管道。他们负责产出数据，并保证数据符合契约。
- 消费者（Consumer）：数据的使用方。可能是下游服务、数据仓库、BI报表、甚至外部合作伙伴。
我在项目中遇到过一种典型情况：一个团队既是生产者又是消费者，自己写数据自己读。他们觉得“反正都是自己人，契约没必要”。结果半年后换了个人维护，新人不清楚字段含义，直接改了产出逻辑，下游报表全乱了。
所以我的建议是：哪怕上下游都是同一个团队，也要明确角色。契约里必须写明：
- 生产者的团队名称、负责人、联系方式
- 消费者的团队名称、负责人、联系方式
- 数据流向（从哪来，到哪去）
你想想看，出了事故找谁？没有契约，你只能满公司问“谁动了我的数据”。有了契约，直接定位到人。
小技巧：我习惯在契约里加一个“紧急联系人”字段，留手机号或即时通讯工具。别只留邮箱——半夜出故障时，没人会去看邮件。
2.2 Schema定义：数据的“身份证”
Schema就是数据的结构定义。它告诉双方：数据长什么样，每个字段是什么意思，值域是什么。
一个标准的Schema定义至少包含：
| 要素 | 说明 | 示例 |
|---|---|---|
| 字段名 | 字段的唯一标识 | user_id |
| 数据类型 | 字段的值类型 | string, int64, timestamp |
| 是否必填 | 该字段能否为空 | required / optional |
| 默认值 | 字段为空时的默认取值 | 0, "", null |
| 值域约束 | 字段的取值范围或枚举 | enum: [male, female] |
| 字段描述 | 业务含义说明 | “用户唯一标识，来自用户中心” |
我曾经见过一个团队，Schema里只写了字段名和类型，没写值域约束。结果消费者以为status字段只有0和1，生产者某天突然吐了个2出来，下游直接解析失败。这就是典型的“契约没写清楚”。
Schema定义用什么格式？我个人推荐Avro或Protobuf。它们自带Schema注册和兼容性检查，比JSON Schema更成熟。下面是一个Avro Schema的例子：
{
"type": "record",
"name": "UserEvent",
"namespace": "com.example",
"fields": [
{"name": "user_id", "type": "string", "doc": "用户唯一标识"},
{"name": "event_type", "type": {"type": "enum", "name": "EventType", "symbols": ["login", "logout", "purchase"]}},
{"name": "timestamp", "type": "long", "doc": "事件发生时间戳（毫秒）"},
{"name": "extra", "type": ["null", "string"], "default": null, "doc": "扩展信息"}
]
}
注意：Schema定义里最容易忽略的是兼容性规则。比如：新增字段必须设置默认值，否则旧消费者会报错。我建议在契约里明确写明兼容性策略（BACKWARD、FORWARD、FULL等）。
2.3 SLA承诺：数据交付的“质量标准”
光有Schema还不够。你得告诉消费者：数据什么时候到？多久到一次？出错了怎么办？
SLA承诺就是干这个的。它定义了生产者对消费者的交付质量保证。常见的SLA指标包括：
- 数据时效性：从数据产生到可消费的最大延迟。比如“T+1 08:00前可用”。
- 数据完整性：数据不能丢。比如“单日数据丢失率 < 0.01%”。
- 数据准确性：数据不能错。比如“字段值符合Schema约束的比例 > 99.9%”。
- 可用性：数据服务或接口的可用时间。比如“99.9% uptime”。
我记得有一次，一个实时数据管道承诺“延迟 < 5秒”，但实际经常延迟到30秒。消费者基于这个SLA做了实时风控，结果因为数据迟到，误判了好几次正常交易。后来我们在契约里加了SLA监控和告警条款——生产者必须提供SLA达标率的实时看板，消费者可以随时查看。
这里我建议用表格把SLA指标写清楚：
| SLA指标 | 承诺值 | 测量方式 | 违约后果 |
|---|---|---|---|
| 数据时效性 | 延迟 < 5分钟 | 端到端时间戳对比 | 降级为“准实时”通道 |
| 数据完整性 | 丢失率 < 0.1% | 计数比对 + 抽样校验 | 触发数据补录流程 |
| 可用性 | 99.9% | 健康检查 + 探活 | 赔偿SLA积分（用于资源调拨） |
避坑指南：我曾经把SLA定得太死，比如“延迟 < 1秒”。结果生产者为了达标，疯狂加机器，成本翻了三倍。后来我学乖了——SLA要跟业务分级。核心交易数据用高SLA，日志分析用低SLA，成本一下子就降下来了。
2.4 变更管理流程：契约的“生命线”
数据契约不是一成不变的。业务在变，Schema在变，SLA也在变。怎么变？得有流程。
变更管理流程是契约里最容易被人忽略的部分。很多人觉得“改个字段而已，通知一声就行”。但现实是——你通知了，对方没看到；你改了，对方没适配；你上线了，对方崩了。
我建议变更管理流程至少包含以下步骤：
- 变更申请：生产者提交变更请求，说明变更内容、原因、影响范围。
- 影响评估：自动扫描所有消费者，评估变更是否兼容。不兼容的变更需要消费者确认。
- 变更审批：相关方（消费者代表、数据治理委员会）审批。
- 灰度发布：先在小范围验证，确认没问题再全量。
- 变更通知：通过邮件、即时通讯、甚至契约平台自动推送变更详情。
- 回滚预案：如果变更出问题，怎么回滚？谁负责？多长时间内回滚？
这里我画了一张变更管理流程图，你看一眼就明白了：
你看，流程里最关键的一步是影响评估。我建议用自动化工具来做——每次Schema变更，自动扫描所有消费者，标出哪些会受影响。不兼容的变更，必须让消费者确认后才能继续。
血的教训：我曾经跳过灰度发布，直接全量上线了一个Schema变更。结果有个老消费者没适配，数据全写错了，花了三天才恢复。从那以后，我定了一条铁律——任何Schema变更，必须灰度，没有例外。
小结
数据契约的四个构成要素，就像一张桌子的四条腿：
- 生产者与消费者：明确谁负责产出，谁负责消费
- Schema定义：数据长什么样，每个字段什么意思
- SLA承诺：数据什么时候到，质量怎么样
- 变更管理流程：怎么改，改了怎么通知，出问题怎么回滚