1. 数据契约概述：什么是数据契约、为什么需要数据契约、数据契约的核心原则

1.1 什么是数据契约？

数据契约，说白了就是数据生产者和消费者之间的一份书面约定。

我习惯把它比作「API 的 API」。你想想看，服务之间调用有接口规范，数据在不同系统间流转，凭什么没有？

数据契约明确规定了：

• 数据长什么样（Schema）
• 数据什么时候到（SLA）
• 数据质量多高（完整性、准确性）
• 出了问题谁负责（Owner）

举个例子。我在项目中遇到过这样一个场景：业务方每天凌晨要跑报表，结果上游数据源突然改了字段类型，从 string 变成了 int。报表直接崩了。如果有数据契约，这种变更会提前通知，甚至自动拦截。

1.2 为什么需要数据契约？

这个问题我问过很多人。大部分人的第一反应是：「我们一直这么干，也没出啥大事啊。」

嗯，这话我信。但「没出大事」不代表「没问题」。

我总结了几类典型痛点：

痛点	表现	后果
字段变更无通知	上游删了字段、改了类型、加了非空约束	下游 ETL 任务失败，报表出不来
数据延迟不可控	说好凌晨 2 点到的数据，拖到早上 8 点	业务决策滞后，投诉不断
数据质量没人管	空值率突然飙升、重复记录暴增	分析结果失真，模型训练失败
责任边界模糊	出了问题互相推诿，找不到 Owner	修复周期长，信任崩塌

我曾经在一个数据平台团队待过。当时每天最怕的就是早上打开监控面板——满屏的红色告警。后来我们花了三个月，把所有核心数据链路都上了数据契约。效果立竿见影：告警量下降了 70%，而且每个告警都能直接定位到责任人。

说白了，数据契约解决的是信任问题。没有契约，数据消费方永远活在「不知道明天数据会变成什么样」的恐惧里。

1.3 数据契约的核心原则

数据契约不是拍脑袋定的。我这些年踩过不少坑，总结下来，核心原则就四条。

原则一：显式约定

所有约定必须白纸黑字写下来，不能靠口头沟通或「大家都懂」。Schema、SLA、质量阈值、变更流程，一条都不能少。

我见过最离谱的情况：两个团队靠群沟通数据变更。结果群里消息一刷屏，变更通知就漏了。显式约定，就是要让机器也能读懂。

原则二：可验证

光写下来还不够，得能自动检查。数据契约里的每一条规则，都应该能写成自动化测试用例。

举个例子：

# 数据契约验证示例
契约 = {
  "表名": "order_daily",
  "字段": ["order_id", "amount", "status"],
  "约束": {
    "order_id": "非空且唯一",
    "amount": "大于 0",
    "status": "取值于 ['pending', 'paid', 'cancelled']"
  },
  "SLA": "每日 02:00 前到达",
  "质量阈值": {
    "空值率": "< 1%",
    "重复率": "< 0.1%"
  }
}

# 每次数据发布前，自动运行验证
def validate_contract(data, contract):
    # 检查字段完整性
    # 检查约束条件
    # 检查质量阈值
    pass

原则三：变更可控

数据契约不是一成不变的。业务在发展，数据在变化。但变更必须有流程、有通知、有缓冲期。

我习惯的做法是：

1. 生产方发起变更请求
2. 系统自动通知所有消费方
3. 消费方在约定时间内确认或提出异议
4. 变更生效，旧契约归档

我曾经因为一次紧急字段变更没走流程，导致下游 12 个任务全部失败。从那以后，我再也不敢跳过变更流程了。

原则四：责任明确

每条数据、每个字段，都必须有明确的 Owner。出了问题，第一时间能找到人。

Owner 不是挂个名就完事了。他需要：

• 保证数据按时、按质交付
• 响应消费方的变更需求
• 处理数据质量问题

1.4 数据契约的核心逻辑

说了这么多，我画了一张图，帮你把数据契约的整体逻辑串起来。

这张图想表达的核心思想是：数据契约不是静态文档，而是一个「发布 → 验证 → 反馈 → 迭代」的闭环。生产方发布契约，消费方订阅契约，验证引擎自动检查，结果反馈给双方。出了问题，马上能定位到人。

1.5 什么时候该上数据契约？

我经常被问到：「我们团队才 5 个人，需要数据契约吗？」

我的回答是：看情况。

这里给一个简单的判断标准：

场景	建议
单人维护，数据只给自己用	不需要，自己心里有数就行
跨团队数据共享	强烈建议，哪怕只是简单约定
数据用于关键业务决策	必须上，出问题就是事故
数据链路超过 3 跳	必须上，否则根本查不到根因
团队快速扩张中	建议上，趁早建立规范

1.6 小结

数据契约不是什么高深的概念。它就是一份约定，让数据生产方和消费方说清楚、写明白、能验证。

核心就四点：显式约定、可验证、变更可控、责任明确。

别把它想得太复杂。从一条数据链路开始，跑起来，你就知道它有多香了。