一、数据契约概述：什么是数据契约、为什么需要数据契约、数据契约与API契约的区别
大家好，我是这次课程的主讲。在数据领域摸爬滚打了十几年，我见过太多因为数据“打架”导致的线上事故。今天咱们聊的数据契约，就是解决这些问题的关键钥匙。
1.1 什么是数据契约
说白了，数据契约就是数据生产方和消费方之间的一份书面约定。它明确规定了：数据长什么样、什么时候到、质量怎么保证、出了问题谁负责。
我习惯把它比作“数据界的合同”。你想想看，两个团队合作，如果没有合同约束，全靠口头承诺，那迟早要出乱子。
数据契约的核心三要素：
- Schema（模式）：字段名、类型、是否必填、取值范围
- SLA（服务等级协议）：数据延迟多久算正常、可用性要达到多少
- 质量规则：空值率上限、唯一性约束、数据新鲜度
举个例子，订单系统要同步数据给BI报表团队。契约里会写清楚：order_id是字符串类型，不能为空；create_time是时间戳，延迟不能超过5分钟；amount是decimal(10,2)，必须大于0。
// 一个简单的数据契约示例（YAML格式）
data_contract:
dataset: order_events
version: "1.0.0"
owner: order_engineering
schema:
fields:
- name: order_id
type: string
required: true
description: "订单唯一标识"
- name: create_time
type: timestamp
required: true
description: "订单创建时间"
- name: amount
type: decimal(10,2)
required: true
constraints:
- min: 0
description: "订单金额"
sla:
max_latency: "5 minutes"
availability: "99.9%"
quality_rules:
- rule: "order_id 唯一性"
severity: critical
- rule: "amount 非负"
severity: warning
1.2 为什么需要数据契约
我在项目中遇到过太多次“数据对不上”的惨案。有一次，数据管道改了字段类型，从int变成了string，下游报表直接崩了三天。原因很简单——没有契约。
为什么需要数据契约？我总结了三个最核心的原因：
- 防止“悄悄变更”：生产方改了数据结构，消费方完全不知情。契约就是一道防火墙，任何变更都必须先过契约这一关。
- 明确责任边界：数据出问题了，是生产方没按约定产出，还是消费方理解错了？契约写得清清楚楚，谁也别甩锅。
- 提升协作效率：新同事加入，不用再挨个问“这个字段是什么意思”。看契约就行了，文档即代码，代码即文档。
我的经验之谈：数据契约最好在项目启动时就定义，而不是等出了问题再补。我曾经在一个大促项目里，因为前期没定契约，上线前三天还在扯皮字段定义，那叫一个焦头烂额。
你想想看，如果没有契约，数据生产方和消费方就像在玩“传话游戏”。生产方说“我发了”，消费方说“我没收到”，或者“收到的数据不对”。这种沟通成本，真的太高了。
1.3 数据契约与API契约的区别
很多人会问：数据契约和API契约到底有啥区别？嗯，这个问题问得好。我刚开始接触时也混淆过。
简单来说：API契约管的是“请求-响应”，数据契约管的是“数据本身”。
| 对比维度 | API契约 | 数据契约 |
|---|---|---|
| 核心关注点 | 接口行为（请求/响应） | 数据内容（Schema/质量） |
| 典型协议 | OpenAPI, gRPC, GraphQL | Avro, Protobuf, JSON Schema |
| 变更方式 | 版本化接口，向后兼容 | Schema演进，兼容性检查 |
| 消费方式 | 实时调用（同步/异步） | 批量/流式订阅（异步为主） |
| 质量保障 | 响应状态码、超时 | 数据完整性、时效性、准确性 |
| 典型场景 | 微服务间RPC调用 | 数据仓库、数据湖、实时管道 |
举个例子你就明白了：
- API契约：你调用
GET /orders/{id}，返回200和订单JSON。它关心的是“你传什么参数，我返回什么结果”。 - 数据契约：你订阅
order_events主题，数据契约告诉你每条消息的字段结构、延迟要求、空值率上限。它关心的是“数据本身是否可靠”。
注意：两者不是替代关系，而是互补关系。API契约保证接口调用的正确性，数据契约保证数据流转的可靠性。在数据密集型系统里，两者缺一不可。
我曾经在一个实时数仓项目里，同时用了API契约（管理数据接入层的REST接口）和数据契约（管理Kafka Topic的Schema和质量）。前者保证了“接口能调通”，后者保证了“数据能信任”。少了任何一个，系统都跑不稳。
本章知识体系总览
下面这张图，帮你快速理清本章的核心脉络：
这张图把本章的三个核心知识点串起来了。从中心节点“数据契约”出发，左边是“是什么”，中间是“为什么”，右边是“和谁对比”。每个分支又往下展开具体内容，方便你对照学习。