一、数据契约概念与价值
1.1 什么是数据契约
数据契约，说白了就是数据生产者和消费者之间的一份正式约定。
我习惯把它类比成「API 契约」。你想想看，微服务之间调用需要接口文档，数据流转也一样——谁产出、谁使用、字段怎么定义、质量怎么保证，这些都得白纸黑字写清楚。
具体来说，一份数据契约通常包含这几部分：
- 数据实体定义：表名、字段名、字段类型、主键、索引
- 数据质量承诺：非空率、唯一性、取值范围、时效性
- 数据生命周期：产出时间、保留周期、归档策略
- 变更通知机制：谁可以改、怎么通知、审批流程
- 消费方列表：哪些下游系统或团队依赖这份数据
核心要点：数据契约不是文档，是可执行、可验证、可追溯的约定。我在项目中见过太多「口头契约」，最后都变成了数据事故。
1.2 为什么需要数据契约
这个问题，我每次培训都会被问到。其实答案很简单——没有契约，数据就是一团乱麻。
我在一家金融公司做过咨询。当时他们的风控团队每天凌晨跑批，结果某天突然发现数据对不上了。查了三天，才发现是上游数仓团队把某个字段从 varchar(32) 改成了 varchar(64)，但没通知任何人。下游的 ETL 脚本直接报错，数据全乱了。
嗯，这就是没有数据契约的代价。
具体来说，数据契约能解决这几个痛点：
- 变更失控：数据生产者随意改字段、改口径，下游毫不知情
- 质量无保障：数据什么时候到、质量怎么样，全靠运气
- 责任推诿：出问题了，生产方说「我改了但你没问」，消费方说「你改了但你没说」
- 重复建设：每个团队各自维护一份数据字典，口径不一致
我的经验：数据契约最大的价值不是「约束」，而是建立信任。有了契约，生产方敢改，消费方敢用，两边都踏实。
1.3 数据契约在数据治理中的定位
数据治理这个筐很大，元数据管理、数据质量、数据安全、数据标准……数据契约到底放在哪？
我个人认为，数据契约是连接数据治理各领域的「枢纽」。
你看这张图就明白了：
数据契约的定位，我总结为三个关键词：
| 定位 | 说明 | 我见过的反面案例 |
|---|---|---|
| 执行层 | 把数据标准、质量规则落地成可执行的约定 | 标准文档写了 100 页，没人执行 |
| 连接层 | 打通元数据、质量、安全、生命周期各领域 | 元数据系统和质量系统各自为政 |
| 反馈层 | 消费方的问题能反向推动生产方改进 | 下游发现问题，上游半年不改 |
注意：数据契约不是银弹。它解决的是「协作」问题，解决不了「数据本身质量差」的问题。我曾经见过一个团队，数据质量一塌糊涂，却花三个月搞了一套契约系统——最后没人用。
1.4 数据契约的典型场景
说了这么多理论，我举几个实际场景，你感受一下：
- 数仓分层之间的数据流转：ODS → DWD → DWS → ADS，每一层之间都需要契约
- 业务系统到数据平台的数据同步：CRM 系统每天同步订单数据到数仓，字段、频率、质量都得约定
- 跨团队的数据共享：A 团队产出用户画像数据，B、C、D 团队消费，变更必须通知
- 实时数据管道：Kafka Topic 的 schema 变更，消费方需要提前感知
这些场景，如果没有数据契约，基本就是「谁改谁有理，谁用谁倒霉」。
一个小建议：刚开始推行数据契约时，别贪多。选一个核心链路、一个高频变更的表，先跑通流程。我见过太多团队一上来就想覆盖所有数据，结果半年了还在开会讨论模板。
1.5 数据契约与变更审批的关系
数据契约不是签完就完事了。数据是活的，字段会变、口径会调、表结构会改——变更才是常态。
所以，数据契约必须配套变更审批流程。这也是我们这门课的核心。
简单来说：
- 数据契约定义了「应该是什么样」
- 变更审批流程定义了「怎么改、谁批准、怎么通知」
没有审批流程的契约，就是一张废纸。我见过一个团队，契约写得漂漂亮亮，结果生产方改字段直接在数据库里执行了 ALTER TABLE，下游第二天才发现——契约形同虚设。
嗯，这就是为什么我们要花 30 章来讲清楚这件事。