📚 课程目录第1章数据契约入门

1. 数据契约入门：什么是数据契约、为什么需要数据契约、数据契约与传统数据治理的区别

大家好，我是老赵。做数据治理这行十几年了，踩过的坑比走过的路还多。今天咱们聊聊数据契约——这个听起来有点新鲜，但实际解决了我很多头疼问题的东西。

先问个问题：你有没有遇到过这种情况？数据仓库里一张表，昨天跑任务还好好的，今天突然就挂了。查了半天，发现上游业务系统改了字段类型，从 varchar 改成了 int，没人通知你。嗯，我遇到过，还不止一次。

数据契约，说白了就是给数据上下游之间签一份「君子协议」。你生产什么数据、什么格式、什么时效、什么质量，白纸黑字写清楚。谁违反了，谁负责。

1.1 什么是数据契约

数据契约（Data Contract）是一组明确的、可验证的约定，定义了数据生产者（Producer）和数据消费者（Consumer）之间的交互规则。

我个人习惯把它拆成三个核心要素：

结构契约：字段名、类型、长度、是否为空、主外键关系
质量契约：完整性、准确性、一致性、时效性、唯一性
服务契约：数据更新频率、可用性SLA、异常处理机制

举个例子，你开发一个订单系统，下游的数据分析团队需要每天凌晨2点拿到前一天的订单明细。数据契约里就会写明：

{
  "contract_id": "ORD_001",
  "producer": "订单系统",
  "consumer": "数据分析平台",
  "schema": {
    "order_id": "string(32) NOT NULL",
    "user_id": "string(16) NOT NULL",
    "amount": "decimal(10,2) NOT NULL",
    "status": "enum('pending','paid','cancelled')",
    "create_time": "datetime NOT NULL"
  },
  "quality": {
    "completeness": "> 99.5%",
    "accuracy": "订单金额误差 < 0.01元",
    "timeliness": "T+1 02:00前送达"
  },
  "sla": {
    "availability": "99.9%",
    "retry_policy": "失败后每30分钟重试，最多3次"
  }
}

你看，这份契约把「谁该做什么」写得清清楚楚。下游不用猜，上游不用躲。

核心观点：数据契约不是文档，是可执行的代码。它应该能被自动化工具解析、验证、告警。

1.2 为什么需要数据契约

说实话，没有数据契约的时候，我们是怎么过的？靠群吼，靠邮件通知，靠「老张你帮我看看这个表怎么变了」。这种模式在数据量小、团队少的时候还能凑合。一旦规模上来，就是灾难。

我经历过一个真实案例：某电商平台大促期间，数据管道突然断裂，BI报表全白。查了6个小时，发现是上游一个开发改了字段长度，从varchar(50)改成了varchar(20)，下游ETL直接报错。那个开发说「我以为没人用这个字段」——你看，这就是没有契约的后果。

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

变更失控：上游改了什么，下游不知道。契约强制变更必须通知、评审、验证。
责任不清：数据出问题，是生产方的问题还是消费方的问题？契约里写明了SLA和质量指标，谁违规谁背锅。
信任缺失：下游不敢用上游的数据，因为不知道数据什么时候会变。契约给了双方一个「可信任的承诺」。

避坑指南：我曾经在一个项目里，把数据契约写成了50页的Word文档，结果没人看。后来我改成YAML文件，集成到CI/CD流水线里，每次变更自动校验。效果天差地别。记住：契约要「活」在系统里，不是「死」在文档里。

1.3 数据契约 vs 传统数据治理

很多人问我：数据契约跟传统的数据治理有什么区别？是不是换了个马甲？

我的回答是：不是换马甲，是换思路。

传统数据治理，说白了是「自上而下」的管控。数据治理委员会定标准、发文、培训、考核。流程长、见效慢，而且容易变成「为了治理而治理」。我见过不少公司，数据治理搞了两年，元数据平台建了，数据字典写了，但业务该乱还是乱。

数据契约是「自下而上」的协作。它不要求你一开始就建一套完美的治理体系，而是从数据生产者和消费者之间的具体交互入手，把治理规则嵌入到日常开发流程里。

我整理了一张对比表，你看完就明白了：

维度	传统数据治理	数据契约
驱动方式	自上而下，管理层推动	自下而上，开发团队自发
核心载体	制度文档、标准规范	可执行的契约文件（YAML/JSON）
变更管理	审批流程，周期长	自动化校验，实时反馈
责任归属	模糊，容易扯皮	明确，契约即责任
落地速度	慢，需要全公司统一	快，可以从一个接口、一张表开始
技术依赖	低，主要靠人	高，需要工具链支撑

说白了，传统数据治理像「立法」，数据契约像「签合同」。立法需要人大开会，签合同两个人就能搞定。但合同的法律效力，一点不比法律弱。

注意：数据契约不是要取代传统数据治理。恰恰相反，它是传统治理在技术层面的「落地抓手」。没有契约，治理标准就是空中楼阁；没有治理框架，契约就是一盘散沙。

1.4 数据契约的核心流程

理解了概念，咱们看看数据契约在实际中怎么跑。我画了一张流程图，帮你理清脉络：

流程其实不复杂：

定义契约：生产者和消费者一起敲定字段、质量、SLA
发布契约：把契约注册到契约中心，版本化管理
数据生产：上游按契约生产数据
契约校验：自动化工具检查数据是否合规，不合规就告警
消费使用：下游放心消费，出了问题按契约追责

这里有个关键点：校验失败要能阻断。我见过很多团队，契约写得好好的，但校验失败了只是发个邮件，该跑还是跑。那契约就形同虚设。真正有效的做法是：校验失败，数据管道直接中断，直到问题修复。

我的经验：刚开始推行数据契约时，别追求完美。先选一个高频、痛点明显的接口或表，签一份简单的契约，跑通流程。有了成功案例，其他团队自然会跟上来。我当年就是从一张订单表开始的，三个月后全公司20多个核心数据流都签了契约。

1.5 小结

数据契约不是什么高深的理论，它就是数据团队之间的一份「君子协议」。但它比君子协议强的地方在于：可执行、可验证、可追责。

传统数据治理解决的是「该怎么做」的问题，数据契约解决的是「谁来做、做到什么程度、做不好怎么办」的问题。两者结合，才是数据质量的完整解法。

嗯，这一章就到这里。记住一句话：没有契约的数据，就像没有护栏的桥——你敢走，我不敢。