一、数据契约概述：什么是数据契约

先问大家一个问题：你们团队里，数据提供方和数据消费方之间，有没有吵过架？

我猜大概率有。数据生产者说「我给了啊」，消费者说「你给的根本不能用」。这种扯皮，我见过太多次了。

数据契约，说白了就是给数据协作立个规矩。它是一份正式的、可执行的约定，明确告诉双方：谁生产数据、谁消费数据、数据长什么样、质量怎么保证。

我在项目中遇到过最典型的情况：业务部门要一份用户画像数据，数据团队给了，但字段名对不上、更新频率不一致、空值率超标。业务说「这数据没法用」，数据团队说「你又没说要什么格式」。嗯，这就是没有数据契约的后果。

1.1 数据契约的三大核心要素

数据契约不是一张纸，它包含三个必须明确的要素。缺一个，契约就不完整。

要素	角色/内容	关键问题
生产者	数据的提供方，负责生成、维护、发布数据	谁负责？数据从哪里来？更新机制是什么？
消费者	数据的使用方，负责消费、处理、应用数据	谁在用？用在哪里？对数据有什么要求？
SLA	服务水平协议，定义质量、时效、可用性等指标	数据多久更新一次？允许的延迟是多少？空值率上限？

你想想看，如果这三个要素都明确了，数据协作还会乱吗？

生产者：不只是「谁产生的」

生产者不只是一个团队名。它要回答：数据从哪里来？是实时采集还是离线计算？数据模型是谁维护的？变更流程是什么？

我曾经帮一家电商公司梳理数据资产，发现同一个「订单金额」字段，三个系统各有一套计算逻辑。生产者是谁？没人说得清。这就是典型的「数据孤儿」问题。

消费者：不只是「谁在用」

消费者同样需要明确。谁在用这个数据？用在什么场景？是实时交易还是离线报表？对数据质量有什么容忍度？

我记得有一次，数据团队把实时接口的延迟从秒级降到了毫秒级，结果消费方的系统反而崩溃了——因为消费方是按秒级延迟设计的，数据来得太快，缓冲区溢出了。你看，消费者没有说清楚自己的需求，生产者做了「过度优化」，反而出了问题。

SLA：数据契约的「硬约束」

SLA 是数据契约里最容易被忽视、也最容易引发争议的部分。它包含但不限于：

• 时效性：数据多久更新一次？允许的最大延迟是多少？
• 完整性：字段空值率上限？记录数是否完整？
• 准确性：数据与源系统的偏差范围？
• 可用性：接口可用性百分比？故障恢复时间？
• 一致性：跨系统数据是否一致？如何校验？

1.2 数据契约与 API 契约的区别

很多人会问：数据契约和 API 契约是不是一回事？

嗯，有相似之处，但本质不同。我画个图帮你理解。

区别在哪？我总结几点：

维度	数据契约	API 契约
关注点	数据本身（结构、质量、血缘）	接口行为（方法、参数、响应）
粒度	字段级、记录级	接口级、操作级
生命周期	数据从产生到消亡	接口从发布到废弃
变更影响	影响所有下游消费方	影响调用方
典型工具	Schema Registry、dbt、Great Expectations	OpenAPI、gRPC、GraphQL
验证方式	数据质量检查、Schema 校验	契约测试、集成测试

说白了，API 契约管的是「怎么调」，数据契约管的是「数据本身是什么、好不好」。两者可以共存，但解决的问题不同。

1.3 为什么数据契约是资产协作的基石

你想想看，企业里数据资产为什么难协作？

根本原因就一个：数据是流动的，但责任是静止的。生产者只管生产，消费者只管消费，中间缺了一个「连接器」。

数据契约就是那个连接器。它把生产者和消费者拉到同一张桌子上，把「模糊的期望」变成「明确的约定」。

我在一家金融公司做过一个项目，数据资产目录里登记了 2000 多张表，但实际被使用的不到 30%。为什么？因为没人知道这些表是谁生产的、质量怎么样、能不能用。后来我们给每张表都建立了数据契约，明确生产者、消费者和 SLA，使用率从 30% 提升到了 70% 以上。

嗯，这一章我们先把数据契约的概念讲清楚。后面我会带你一步步搭建完整的数据契约体系，包括怎么定义、怎么落地、怎么自动化。