1、数据契约是什么

说实话，我第一次听到「数据契约」这个词，脑子里蹦出来的是「又要签什么合同？」。后来真正上手做数据治理，才发现这玩意儿比合同实在多了。

数据契约，说白了就是数据生产者和数据消费者之间的一份技术约定。它明确规定了数据长什么样、什么时候到、质量怎么保证。我习惯把它理解成「数据界的 API 文档」，但比 API 文档更狠——它连数据出问题了怎么处理都写好了。

数据契约的定义

官方点的说法：数据契约是数据提供方和数据消费方之间，对数据格式、语义、时效性、质量指标达成的可验证的协议。它通常以机器可读的配置文件存在，比如 YAML、JSON 或者 Protobuf 定义。

举个例子，一个订单数据契约大概长这样：

# order_contract.yaml
dataset: order
version: 1.2.0
schema:
  - name: order_id
    type: string
    required: true
    description: "订单唯一标识"
  - name: user_id
    type: string
    required: true
  - name: amount
    type: decimal(10,2)
    required: true
    min: 0
  - name: status
    type: string
    enum: ["pending", "paid", "shipped", "cancelled"]
sla:
  max_latency: 10min
  min_records_per_hour: 1000
quality:
  - rule: "order_id 唯一"
    check: "unique"
  - rule: "amount 非负"
    check: "min >= 0"

嗯，这里要注意：契约不是写给人看的，是写给自动化测试和监控系统看的。我见过太多团队把契约写成 Word 文档，然后就没有然后了。

为什么需要数据契约

你想想看，一个中型公司每天有多少数据管道在跑？几十条？上百条？每条管道背后都有生产者和消费者。没有契约的时候，数据出问题全靠「吼」——

• 消费者：「昨天的订单表怎么少了一列？」
• 生产者：「哦，我改了字段名，忘了通知你。」
• 消费者：「……」

我在项目中遇到过最离谱的一次：业务方改了支付状态枚举值，从 paid 改成 success，下游三个报表直接崩了，修复花了整整两天。从那以后，我强制所有数据接口必须签契约。

数据契约能解决三个核心痛点：

痛点	没有契约	有契约
字段变更	改完才通知，甚至不通知	改契约先过评审，消费者确认
数据延迟	消费者自己写脚本监控	契约自带 SLA 告警
质量事故	出事了再排查	契约校验前置，提前拦截

数据契约与传统数据接口的区别

很多人问我：「这不就是 API 文档吗？」还真不是。我画了张图，你看一眼就明白了。

区别其实就三点：

1. 约定形式不同：传统接口的约定在文档里，数据契约的约定在代码里。文档会过期，代码不会。
2. 校验时机不同：传统接口上线后才发现问题，数据契约在开发阶段就能校验。我习惯在 CI/CD 里加一步「契约校验」，通不过就不让发布。
3. 变更流程不同：传统接口改字段，生产者改完通知消费者。数据契约改字段，必须先更新契约文件，消费者确认后才能改。

说白了，数据契约不是什么高深的技术，它就是把「我们之前靠默契做的事」变成「机器能理解的规则」。你想想看，默契会出问题，机器不会。