1、数据契约基础：数据契约的定义、核心要素与传统数据接口的区别

各位同学，咱们今天聊一个我这些年越来越觉得重要的东西——数据契约。

先说说我自己的经历。几年前我在一家金融科技公司带数据团队，那时候我们每天最头疼的事就是数据对不上。业务系统说“我凌晨两点已经把报表推过去了”，数据仓库说“我没收到啊”。两边扯皮，最后查日志发现是字段类型变了——生产系统偷偷把金额字段从 decimal(18,2) 改成了 varchar。嗯，这种坑，踩过一次就忘不了。

后来我意识到，数据交互这件事，不能靠“信任”，得靠“契约”。

什么是数据契约？

数据契约，说白了就是数据生产者和消费者之间的一份正式协议。它约定了数据怎么生产、怎么传输、长什么样、质量多高。

你想想看，我们做软件工程有 API 契约，做微服务有接口规范。数据为什么不能有契约？

我个人习惯把数据契约定义为：一种可验证、可执行的数据交互约定，它明确了数据在生产者与消费者之间的交付标准。

数据契约的四个核心要素

一个完整的数据契约，我建议至少包含这四个东西：

要素	说明	我踩过的坑
生产者	谁生产数据？哪个系统、哪个服务、哪个表？	曾经有个系统换了数据源，没人通知下游，挂了三天
消费者	谁消费数据？哪些应用、哪些报表、哪些模型？	消费者列表不全，改字段时漏通知，线上事故
Schema	数据结构定义：字段名、类型、长度、约束、默认值	字段类型从 int 改成 bigint，下游解析直接报错
SLA	服务质量承诺：时效性、可用性、完整性、准确性	约定 T+1 的数据，生产系统拖到 T+2 才给，没人追责

这四个要素缺一不可。生产者不明确，出了问题找不到人。消费者不明确，改了字段都不知道影响谁。Schema 不明确，数据格式天天变。SLA 不明确，质量好坏全凭运气。

Schema：数据契约的“语法书”

Schema 这块我想多说两句。它不只是字段列表，它定义了数据的“语法”。

举个例子，一个订单数据的 Schema 可能长这样：

{
  "order_id": {
    "type": "string",
    "required": true,
    "pattern": "^ORD\\d{12}$"
  },
  "amount": {
    "type": "decimal",
    "precision": 18,
    "scale": 2,
    "min": 0
  },
  "status": {
    "type": "enum",
    "values": ["pending", "paid", "cancelled"]
  },
  "created_at": {
    "type": "datetime",
    "format": "yyyy-MM-dd HH:mm:ss"
  }
}

你看，每个字段都有明确的约束。order_id 必须是 ORD 开头加 12 位数字。amount 不能是负数。status 只能是那三个值。

我曾经遇到过一个项目，生产系统把 status 字段偷偷加了个 "refunded" 值，下游的枚举解析直接崩了。如果有 Schema 校验，这种问题根本不会发生。

SLA：数据契约的“法律条款”

SLA 是数据契约里最容易被人忽略的部分。很多人觉得“数据能传过来就行了”，但传过来和传好是两码事。

一个典型的数据 SLA 包含：

• 时效性：数据多久更新一次？T+1？实时？
• 可用性：数据接口的可用率是多少？99.9%？99.99%？
• 完整性：数据不能丢，丢失率不能超过多少？
• 准确性：数据正确率要求？允许的误差范围？

数据契约 vs 传统数据接口

很多人问我：“数据契约不就是接口文档吗？”

还真不是。我列个对比表你就明白了：

维度	传统数据接口	数据契约
关注点	数据传输方式	数据交付质量
内容	接口地址、参数、返回格式	Schema、SLA、生产者、消费者
可执行性	通常只是文档	可被工具自动验证
变更管理	口头通知或邮件	版本化、兼容性检查
责任划分	模糊	明确生产者与消费者责任
质量保障	靠人工检查	自动化质量门禁

传统数据接口关注的是“怎么传”，数据契约关注的是“传什么、传多好”。

你想想看，传统接口文档里会写“这个字段不能为空”吗？会写“数据必须在 5 分钟内到达”吗？不会。但数据契约会。

数据契约的核心价值

说了这么多，数据契约到底能解决什么问题？

• 减少扯皮：出了问题，契约上写得清清楚楚，谁的责任一目了然
• 提升质量：Schema 校验和 SLA 监控让数据质量可量化、可追踪
• 加速协作：生产者和消费者基于契约并行开发，不用等对方
• 降低风险：变更时自动检查兼容性，避免线上事故

本章知识体系

下面这张图帮你梳理数据契约的核心逻辑：

这张图把数据契约的四个核心要素和核心价值串起来了。中心是数据契约，四个角分别是生产者、消费者、Schema 和 SLA。底部对比了传统接口和数据契约的区别。

好了，这一章就到这里。数据契约的概念其实不难，难的是怎么落地。后面的章节我会一步步带你走完整个落地过程。