数据契约驱动开发流程 - 第2节
数据契约在数据治理中的角色
数据治理这件事，说起来挺大的。很多公司一上来就搞数据治理委员会、定几百条规范、上各种平台。结果呢？三个月后，该乱还是乱。
我个人习惯是，先找到那个能「卡住脖子」的点。数据契约，就是这个点。
说白了，数据契约是数据治理从「事后追责」转向「事前约定」的关键抓手。你想想看，传统的数据治理，往往是数据出问题了——报表对不上、模型跑不出来、下游告警了——然后大家开始拉群、扯皮、定位、修复。这个流程走下来，少则半天，多则一周。
数据契约的思路不一样。它要求在数据被生产出来的那一刻，就明确告诉消费者：我承诺给你什么格式、什么质量、什么时效的数据。如果做不到，我提前告诉你，或者直接拒绝生产。
核心观点：数据契约是数据治理的「执行单元」。没有契约，治理就是空中楼阁。
数据治理的三层结构
我在项目中遇到过不少团队，把数据治理理解成「定规范+写文档」。其实不是的。数据治理应该分三层：
- 战略层：定方向、定目标、定组织。比如「我们要做到数据不出错」「我们要实现数据资产化」。
- 制度层：定流程、定标准、定角色。比如「数据变更要走审批」「字段命名用下划线」。
- 执行层：定契约、定检查、定反馈。这就是数据契约发挥作用的地方。
很多公司战略层和制度层做得挺漂亮，PPT 一页一页的。但到了执行层，就变成了「大家自觉遵守」。嗯，自觉这东西，在数据领域是最靠不住的。
数据契约把执行层的三个关键动作串起来了：
- 约定：生产者和消费者坐下来，把接口、格式、质量要求写进契约。
- 验证：每次数据生产，自动检查是否满足契约。不满足就告警或阻断。
- 反馈：契约的变更、违约情况、质量趋势，都要有记录和通知。
我的经验：刚开始推行数据契约时，别想着一步到位。先选一个核心链路，把契约跑通。哪怕只有 3 个字段的契约，也比 100 条没人看的规范强。
数据契约与数据血缘的关系
数据血缘，说白了就是「数据从哪里来，经过了谁，变成了什么」。它像一张数据流转的地图。
那数据契约和血缘是什么关系？我打个比方：血缘是路网，契约是交通规则。没有路网，车没地方跑；没有规则，路网就是个堵车现场。
契约给血缘注入「语义」
传统的数据血缘工具，能帮你画出字段级的上下游关系。但它只能告诉你「A 表的 b 字段流到了 C 表的 d 字段」，它说不清楚：
- 这个流转有没有经过生产者承诺？
- 流转过程中质量有没有下降？
- 如果下游改了消费方式，上游知不知道？
数据契约可以给血缘的每条边加上「标签」。比如：
| 血缘边 | 契约状态 | 质量等级 | 变更影响 |
|---|---|---|---|
| 订单表.金额 → 报表.销售额 | 已签约 | SLA: 99.9% | 需审批 |
| 用户表.手机号 → 分析库.手机号 | 未签约 | 无保障 | 无通知 |
| 日志表.时间戳 → 实时看板.时间 | 已签约 | SLA: 99.5% | 需审批 |
你看，有了契约的血缘，不再是冷冰冰的线。它告诉你每条数据链路「有没有保障」「出了事找谁」「变更了会不会影响下游」。
避坑指南：我曾经见过一个团队，血缘图画得特别漂亮，每个字段的上下游清清楚楚。但一查，80% 的链路没有契约。结果一次上游改字段类型，下游直接崩了三天。血缘图再漂亮，没有契约兜底，就是一张「事故地图」。
血缘反哺契约治理
反过来，血缘也能帮我们发现「该签契约却没签」的地方。我习惯的做法是：
- 跑一遍全链路血缘，找出所有跨团队、跨系统的数据流转。
- 检查每条流转是否有对应的数据契约。
- 对没有契约的流转，按影响范围排序，优先补签。
这就像先画地图，再查哪些路口没有红绿灯。没有血缘，你连哪些地方缺契约都不知道。
数据契约与数据质量的关系
数据质量是个老话题了。非空、唯一、范围、格式、一致性……每个公司都有质量规则。但问题在于：这些规则谁来定？谁来执行？谁来负责？
数据契约给出了一个很清晰的答案：质量规则是契约的一部分，由生产者和消费者共同商定。
契约驱动的质量闭环
我参与过的一个项目，之前质量规则是数据平台团队统一配置的。结果呢？生产者觉得规则太严，天天报障；消费者觉得规则太松，数据不敢用。两边都不满意。
后来我们改成「契约驱动」的模式：
- 生产者提约：「我承诺这个字段非空率 99.9%，格式为 yyyy-MM-dd。」
- 消费者确认：「可以，但我要求延迟不超过 5 分钟。」
- 平台自动校验：每次生产，检查非空率、格式、延迟。不满足就告警。
这个闭环跑起来之后，质量问题的定位时间从平均 4 小时降到了 15 分钟。为什么？因为契约里写清楚了「谁承诺了什么」，出了问题直接找对应方，不用再拉群排查。
关键点：数据质量不是「越高越好」，而是「满足契约就好」。99.9% 的非空率如果够用，就别要求 99.99%，否则成本翻倍，收益微乎其微。
质量度量与契约对齐
传统的数据质量度量，往往用一套统一的指标：完整性、准确性、一致性、时效性。但不同场景对这四个维度的要求是不一样的。
举个例子：
| 数据场景 | 完整性要求 | 准确性要求 | 时效性要求 |
|---|---|---|---|
| 实时风控 | 中（可容忍少量缺失） | 高（错一个可能误判） | 极高（秒级） |
| 离线报表 | 高（缺数据报表对不上） | 高 | 低（T+1 即可） |
| 推荐系统 | 低（少量缺失不影响） | 中（可接受近似值） | 中（分钟级） |
数据契约允许每个链路定义自己的质量阈值。你在契约里写清楚「完整性 ≥ 99%」「延迟 ≤ 5 分钟」，平台就按这个标准去度量。而不是用一把尺子量所有数据。
我的建议：质量规则不要一开始就定得太细。先定 3-5 条核心规则，跑通流程。等大家习惯了，再逐步增加。我见过一个团队，第一次签契约就定了 20 条质量规则，结果没人愿意签了。
三者关系全景图
说了这么多，我把数据契约、数据血缘、数据质量的关系画成一张图，方便你理解：
这张图想表达的核心就一句话：数据契约不是孤立存在的。它需要血缘来发现「该签哪里」，需要质量来定义「签什么标准」，最终服务于数据治理这个更大的目标。
嗯，这一章的内容就到这里。记住，数据治理不是靠文档和口号落地的，是靠一个个具体的契约、一条条清晰的血缘、一次次自动化的质量检查。把这些做实了，治理自然就到位了。