数据契约核心要素：数据提供方与消费方、SLA定义、数据质量承诺、版本管理

上一章我们聊了数据契约是什么，以及它为什么在资产运营里这么重要。这一章，咱们把契约拆开看看——它到底长什么样？里面都写了什么？

我个人习惯把数据契约比作一份「数据服务合同」。合同嘛，总得有甲方乙方、服务标准、违约责任、版本号这些。数据契约也一样，核心要素就四个：参与方、SLA、质量承诺、版本管理。少了任何一个，这契约就是一张废纸。

2.1 数据提供方与消费方：谁对谁负责？

先搞清楚谁在「卖」数据，谁在「买」数据。这听起来简单，但我在项目中遇到过不少糊涂账——一个团队既生产数据又消费数据，最后出了问题互相甩锅。

数据提供方，说白了就是数据源头。可能是业务系统、外部接口、或者某个数据中台的表。提供方的责任很明确：按约定生产数据，保证数据能拿到、能看懂。

数据消费方，就是下游用数据的人。可能是数据分析师、算法工程师、或者另一个业务系统。消费方的义务是：按约定使用数据，发现问题及时反馈。

嗯，这里要注意——一个团队可以同时扮演两个角色。比如数据中台，对上游业务系统来说是消费方，对下游报表系统来说又是提供方。所以契约里必须写清楚：在这个契约里，你是谁？

角色	核心职责	常见问题
数据提供方	按时产出数据、保证数据格式正确、响应消费方问题	数据延迟、字段变更不通知、数据质量差
数据消费方	按约定使用数据、及时反馈异常、遵守使用限制	滥用数据、不反馈问题、私自修改数据用途

2.2 SLA定义：数据服务不能「随缘」

SLA（Service Level Agreement）是数据契约的「硬条款」。它定义了数据服务应该达到什么水平。没有SLA，数据提供方可以说「我尽力了」，消费方可以说「你不行」——最后全是扯皮。

我一般把SLA拆成三个维度：

• 可用性：数据接口或表在什么时间范围内必须可用？比如「99.9%的时间可查询」。
• 时效性：数据多久更新一次？比如「T+1 早上8点前完成」。
• 响应时间：查询或调用接口的延迟上限？比如「单次查询不超过3秒」。

举个例子。我曾经帮一个金融团队写契约，他们的风控系统需要实时数据。SLA里写的是：「数据延迟不超过5秒，可用性99.99%，单次查询响应时间小于200毫秒」。你看，这就很清晰——达不到就是违约。

2.3 数据质量承诺：数据「能用」的标准是什么？

SLA管的是「服务」，数据质量承诺管的是「内容」。数据到了，但全是空值、乱码、重复记录——这算不算履约？当然不算。

数据质量承诺通常包含这几个维度：

• 完整性：关键字段不能为空。比如用户ID、交易金额。
• 准确性：数据值必须在合理范围内。比如年龄不能是负数。
• 一致性：同一份数据在不同系统里应该对得上。
• 唯一性：没有重复记录，主键唯一。

我习惯在契约里用一张表来定义质量规则：

质量维度	规则描述	阈值	违约处理
完整性	user_id 字段空值率	< 0.1%	提供方24小时内修复
准确性	交易金额在0-100万之间	100%	异常数据标记并重跑
一致性	与源系统对账差异率	< 0.01%	双方联合排查

你想想看，如果没有这些承诺，消费方拿到数据后还得自己清洗一遍——那要数据契约干嘛？

2.4 版本管理：数据契约也会「升级」

数据契约不是签完就锁进柜子里的。业务在变，数据在变，契约也得跟着变。但怎么变？谁说了算？这就是版本管理要解决的问题。

我建议每个数据契约都带上版本号，格式可以这样：v1.0.0。主版本号代表重大变更（比如数据结构改了），次版本号代表小调整（比如新增一个字段），补丁号代表修复（比如修正描述错误）。

版本变更的流程也很重要：

1. 提出变更：任何一方都可以发起变更请求。
2. 评估影响：变更会影响哪些下游？需要多少迁移时间？
3. 协商确认：双方签字确认新版本。
4. 灰度发布：先小范围验证，再全量切换。
5. 旧版下线：给消费方留足缓冲期，再停掉旧版本。

好了，这四个要素构成了数据契约的骨架。提供方和消费方是「人」，SLA是「标准」，质量承诺是「底线」，版本管理是「进化机制」。缺一个，契约就跑不起来。

下面这张图可以帮你快速回顾这四个要素的关系：