数据契约基础概念

大家好，欢迎来到《数据契约变更审批与版本管理》的第一章。今天咱们聊聊最基础的东西——数据契约到底是什么。

我接触数据治理这些年，发现一个很有意思的现象：很多团队数据问题频发，根因往往不是技术不行，而是“约定”没做好。数据契约，说白了就是一套正式的约定。它让数据提供方和使用方之间，不再靠“口头承诺”或“群里吼一声”来协作。

什么是数据契约

数据契约（Data Contract），你可以把它理解成一份数据服务的“合同”。

举个例子。你负责一个用户画像系统，每天要产出用户的年龄、性别、兴趣标签。下游的推荐团队、广告团队都依赖这些数据。如果没有契约，哪天你改了字段名、调整了更新频率，下游直接报错——这就是典型的“数据事故”。

数据契约就是用来避免这种事的。它明确记录了：谁生产数据、谁消费数据、数据长什么样、质量要求是什么、出了问题谁负责。

数据契约的组成要素

一个完整的数据契约，通常包含四个核心部分。我习惯把它们称为“四件套”。

要素	说明	常见内容
生产者	数据的提供方，负责数据的生成与发布	团队名称、系统名称、负责人、联系方式
消费者	数据的使用方，订阅并消费数据	团队名称、使用场景、消费方式（API/消息/文件）
Schema	数据的结构定义，包括字段名、类型、约束	字段列表、数据类型、是否必填、枚举值范围
SLA	服务水平协议，约定数据的质量与交付标准	数据延迟、可用性、准确性、异常处理机制

1. 生产者

生产者就是“谁造的数据”。我个人习惯在契约里明确写清楚：哪个系统、哪个团队、哪个接口。光写个“数据组”太模糊了，要具体到“用户画像平台-数据工程组-张三”。

我在项目中遇到过，一个 Kafka Topic 被三个团队同时写入，出了事互相推诿。后来我们在契约里强制要求每个 Topic 只能有一个生产者，问题才解决。

2. 消费者

消费者是“谁用数据”。这里要注意，消费者不一定是人，也可能是下游系统、微服务、ETL 任务。

我曾经见过一个团队，上线新功能时改了数据格式，结果影响了 12 个下游任务。为什么？因为他们根本不知道谁在用这些数据。数据契约里明确列出消费者，就能避免这种“误伤”。

3. Schema

Schema 是数据契约的“硬核”部分。它定义了数据长什么样。

{
  "schema_name": "user_profile",
  "version": "1.0.0",
  "fields": [
    {"name": "user_id", "type": "string", "required": true, "description": "用户唯一标识"},
    {"name": "age", "type": "integer", "required": false, "min": 0, "max": 150},
    {"name": "gender", "type": "string", "required": false, "enum": ["M", "F", "U"]},
    {"name": "tags", "type": "array", "items": {"type": "string"}, "description": "用户标签列表"}
  ]
}

嗯，这里要注意：Schema 不仅要定义字段类型，还要定义约束条件。比如年龄不能为负数、性别只能取三个值。这些约束在变更时特别重要——你想想看，如果某天你把 gender 的枚举值从三个改成两个，下游消费端可能直接报错。

4. SLA

SLA 是契约里的“软实力”。它不定义数据结构，而是定义数据质量。

• 时效性：数据多久更新一次？延迟超过多少算故障？
• 可用性：接口或 Topic 的可用性要求是多少？99.9% 还是 99.99%？
• 准确性：数据准确率要求多少？异常数据如何处理？
• 异常响应：数据出问题后，多久需要响应？多久需要修复？

数据契约的价值与意义

说了这么多，数据契约到底能带来什么好处？我总结了几点。

1. 减少数据事故

没有契约的时候，数据变更全靠“吼”。改了字段名，群里发个消息，看到了算你运气好。有了契约，变更必须走审批，消费者必须确认。事故率能降 80% 以上——这不是夸张，是我在项目里实测的数据。

2. 明确责任边界

数据出了问题，是谁的责任？生产者改了 Schema 没通知？还是消费者没及时适配？契约里写得清清楚楚，扯皮的事就少了。

3. 提升协作效率

新同事接手数据项目，不用一个个去问“这个字段是什么意思”“这个表多久更新一次”。翻一下数据契约，全都有。我习惯把契约放在统一的 Git 仓库里，所有人都能查。

4. 支撑自动化治理

数据契约是机器可读的。你可以基于契约做自动化校验、自动化测试、自动化变更审批。这是数据治理走向“平台化”的基础。

数据契约核心关系图

下面这张图展示了数据契约的核心组成与协作关系。我建议你仔细看看，理解生产者、消费者、Schema、SLA 之间的交互。

从这张图你能看到：生产者发布数据，消费者订阅数据，两者通过数据契约达成一致。Schema 和 SLA 是契约的两个核心约束维度。任何一方的变更，都会影响另一方——这就是为什么我们需要变更审批与版本管理，也是这门课后续要深入的内容。

好了，第一章就到这里。数据契约的概念其实不复杂，但它是整个数据治理体系的基石。后面的章节，我们会一步步深入，看看怎么落地、怎么管理变更、怎么处理版本冲突。