数据契约基础：契约的定义、组成要素与生命周期
聊数据契约之前，我先问个问题：你所在团队有没有出现过这种情况？
数据生产者拍着胸脯说「字段我加了」，消费者一跑任务直接报错。或者，SLA 写着 99.9%，实际延迟两小时没人管。说白了，这就是缺了一份「契约」。
数据契约不是什么玄乎的概念。它就是一份书面约定，写清楚数据提供方和消费方之间，到底该遵守什么规则。我习惯把它类比成租房合同——房东（生产者）承诺房子不漏水，租客（消费者）承诺按时交租。双方签字画押，出了问题按条款追责。
数据契约的核心价值：在数据生产者和消费者之间建立明确的、可验证的、可追溯的承诺关系。
契约的三大组成要素
一份完整的数据契约，至少包含三个部分：Schema、SLA、Owner。缺一个，这契约就不算数。
1. Schema：数据的「身份证」
Schema 定义了数据的结构。字段名、类型、长度、是否为空、枚举值范围……这些都得写清楚。我在项目中遇到过最典型的坑：生产者说「我加了个字段」，但没更新 Schema 定义。消费者按旧 Schema 解析，直接抛异常。
一个规范的 Schema 定义长这样：
{
"table": "user_order",
"version": "1.2.0",
"fields": [
{
"name": "order_id",
"type": "string",
"required": true,
"description": "订单唯一标识",
"format": "UUID v4"
},
{
"name": "user_id",
"type": "string",
"required": true,
"description": "用户ID"
},
{
"name": "amount",
"type": "decimal",
"required": true,
"precision": 10,
"scale": 2,
"description": "订单金额，单位元"
},
{
"name": "status",
"type": "string",
"required": true,
"enum": ["pending", "paid", "cancelled", "refunded"],
"description": "订单状态"
}
],
"partition": ["dt"],
"update_frequency": "每小时"
}注意看，这里我特意写了 version 字段。为什么？因为 Schema 会变。没有版本号，你根本不知道消费者用的是哪个版本。我曾经在一个数据湖项目里，就因为没管版本，导致三个团队同时改了同一张表的结构，最后数据全乱了。
2. SLA：数据的「服务承诺」
SLA 不是玄学，是硬指标。它回答三个问题：
- 什么时候到？——数据产出时间、延迟上限
- 质量多高？——完整性、准确性、一致性指标
- 出问题怎么办？——响应时间、修复时间、补偿机制
我见过最离谱的 SLA 就一句话：「保证数据及时准确」。这跟没说一样。真正的 SLA 得量化：
| 指标 | 定义 | 阈值 | 测量方式 |
|---|---|---|---|
| 数据产出延迟 | 从业务时间到数据可用的最大时间差 | ≤ 30 分钟 | 监控系统打点 |
| 字段完整性 | 必填字段的非空比例 | ≥ 99.9% | 每日质量扫描 |
| 数据准确性 | 与上游源系统的字段级一致率 | ≥ 99.99% | 抽样比对 |
| 故障响应时间 | 从告警到确认问题的时间 | ≤ 15 分钟 | PagerDuty 记录 |
| 故障修复时间 | 从确认到修复完成的时间 | ≤ 2 小时 | 工单系统记录 |
避坑提醒：我曾经见过一个团队把 SLA 定到 99.999%，结果为了达标，每天花 80% 的时间做监控和重跑，真正做业务的时间反而没了。SLA 不是越高越好，得跟业务价值匹配。
3. Owner：数据的「责任人」
数据没人管，等于没人负责。Owner 必须明确到个人，不是团队，不是部门。我习惯在契约里写清楚：
- 生产者 Owner：负责 Schema 定义、数据产出、质量保障
- 消费者 Owner：负责正确使用数据、反馈质量问题
- 契约管理员：负责版本管理、变更审批、争议仲裁
你想想看，如果数据出问题了，你找谁？找团队？团队会说「你找我们组长」。找组长？组长说「这事不归我管」。最后绕一圈，问题没人认领。所以，Owner 必须写全名 + 企业 + 备份人。
契约的生命周期
数据契约不是写一次就完事了。它有自己的生命周期，我把它分成五个阶段：
阶段一：定义
这是最关键的阶段。生产者和消费者坐在一起，把 Schema、SLA、Owner 一条条过。我建议用「契约工作坊」的形式，半天时间，把所有细节敲定。别想着发个文档让大家自己看，那肯定出问题。
定义阶段要产出：
- 一份完整的契约文档（含版本号）
- 双方 Owner 签字确认
- 初始的监控指标基线
阶段二：发布
契约定义好了，得让所有人都知道。发布不只是发个邮件，要注册到元数据中心。这样，消费者在查数据的时候，能直接看到这份契约。
我的习惯：在元数据系统里加一个「契约状态」字段。已发布、履约中、变更中、已废弃。这样一眼就能看出数据当前处于什么状态。
阶段三：履约
契约生效了，开始跑数据。这个阶段的核心是监控和告警。SLA 里写的指标，得一条条落地到监控系统。我见过最蠢的做法：SLA 写得漂漂亮亮，但根本没监控。出了问题全靠用户投诉才知道。
履约阶段要做的事：
- 自动化质量扫描（每天跑）
- SLA 达标率统计（每周出报告）
- 异常告警通知（实时）
- 定期复盘会议（每月一次）
阶段四：变更
数据是会变的。业务调整了，字段要加；性能优化了，产出时间要改。变更不可怕，可怕的是变更没通知。
我定了一条铁律：任何 Schema 变更，必须提前 3 个工作日通知消费者。而且变更要分版本，不能直接覆盖。消费者确认没问题了，才能切换。
我曾经踩过的坑：有一次，数据团队为了赶进度，凌晨两点改了表结构，没通知任何人。第二天早上，下游 12 个任务全部报错。从那以后，我强制要求所有变更必须走审批流程，哪怕改一个字段描述都不行。
阶段五：废弃
数据也有生命周期。业务下线了，数据不再用了，契约就得废弃。但废弃不是直接删掉，要经过双方确认：
- 生产者确认不再产出
- 消费者确认不再使用
- 契约归档到历史库（保留至少 6 个月）
我见过一个团队，废弃了数据但没废弃契约。结果半年后新来的同事看到契约，以为数据还在，直接写了个任务去读，跑了一天发现全是空表。嗯，这种问题其实完全可以避免。
小结一下
数据契约不是什么高大上的东西。它就是一份约定，把「谁该做什么、做到什么程度、出了问题谁负责」写清楚。Schema 管结构，SLA 管质量，Owner 管责任。再加上生命周期的五个阶段，基本就能把数据治理这件事落地了。