1、数据契约概述：什么是数据契约、为什么需要数据契约、数据契约与传统数据治理的区别

大家好，我是老赵。今天咱们开始聊数据契约。

先问个问题：你经历过数据对不上、口径打架、下游报表突然飘红的情况吗？我猜十有八九你点过头。我在过去十年里，几乎每个数据项目都踩过类似的坑。后来我发现，很多问题的根源不是技术不行，而是——人和人之间没约定好。

数据契约，就是来解决这个事的。

1.1 什么是数据契约

说白了，数据契约就是数据生产方和消费方之间的一份“君子协定”。

它不像传统文档那样写完了就扔进 wiki 吃灰。数据契约是活的、可执行的。它约定了：

• 数据长什么样（字段名、类型、长度）
• 数据怎么来（加工逻辑、调度依赖）
• 数据质量底线（非空率、唯一性、取值范围）
• 出了问题谁负责（SLA、响应时间）

举个例子。我在一个电商项目里，订单表的下游有十几个团队在用。以前大家各查各的文档，口径经常对不上。后来我们给订单表写了一份契约：

表名: dwd_order_detail
生产者: 数据中台-实时组
消费者: 推荐、风控、BI、运营

字段契约:
  - order_id: string, NOT NULL, 唯一
  - user_id: string, NOT NULL
  - pay_amount: decimal(18,2), >= 0
  - order_status: string, 枚举 ['已支付','已取消','已退款']

质量SLA:
  - 延迟: 从binlog到产出 < 30秒
  - 空值率: order_id 0%, user_id < 0.1%
  - 异常告警: 连续3分钟延迟 > 30秒 触发P0

这份契约不是写给人看的，而是写给人和机器一起看的。它可以直接被监控系统解析，自动校验、自动告警。

1.2 为什么需要数据契约

你可能会想：我们公司有数据字典，有元数据平台，还不够吗？

嗯，我刚开始也这么觉得。直到有一次，业务方说“昨天的DAU怎么少了10万”，我们查了三天，最后发现是埋点团队改了字段名，但没通知任何人。那三天，大家互相甩锅，数据质量一塌糊涂。

为什么会这样？因为传统方式有几个硬伤：

• 文档滞后：数据字典往往是上线后补的，甚至不补
• 责任模糊：数据出了问题，生产方说“我改了”，消费方说“我不知道”
• 质量靠人盯：没有自动校验，全靠人工巡检，漏了就是事故
• 变更无感知：字段改名、类型变更，下游完全不知情

数据契约正好补上这些短板。它的核心价值有三点：

1. 明确边界：谁生产、谁消费、谁负责，白纸黑字写清楚
2. 自动校验：契约一旦生效，系统自动检查数据是否合规
3. 变更可控：任何改动都要先改契约，契约变了，下游立刻收到通知

1.3 数据契约 vs 传统数据治理

很多人把数据契约当成数据治理的一个子集。我不完全同意。它们有本质区别。

我画了一张对比图，你看完就明白了。

你看，传统数据治理更像是一个“管理体系”，它告诉你数据标准是什么、流程怎么走。但到了执行层面，往往就断了。数据契约正好卡在生产者和消费者之间，把治理要求落地成可执行的规则。

我再用一个表格帮你理清区别：

对比维度	传统数据治理	数据契约
驱动方式	自上而下，治理委员会推动	自下而上，生产者消费者约定
载体	文档、制度、流程	代码、配置文件、自动化工具
时效性	事后补录，滞后严重	事前约定，实时生效
校验方式	人工巡检、定期审计	自动校验、实时告警
变更管理	邮件通知、会议评审	契约变更自动通知下游
责任归属	模糊，容易推诿	明确，契约即承诺
适用范围	全企业数据资产	重点链路、实时数据流

我个人习惯把数据契约看作数据治理的“最后一公里”。治理定方向，契约保执行。两者配合，才能让数据质量真正落地。