1. 数据契约基础：什么是数据契约、核心要素与治理定位

各位同学好，我是老周。今天咱们开始聊数据契约。

先问大家一个问题：你在数据团队里，有没有遇到过这种情况——

• 上游改了字段类型，下游报表直接崩了
• 流任务和批任务对同一字段的语义理解不一样
• 数据仓库里一堆表，没人说得清哪个字段是权威来源

这些坑，我全踩过。而且不止一次。

后来我发现，很多问题的根源不是技术不行，而是数据生产者和消费者之间没有一份明确的"合同"。这就是数据契约要解决的事。

1.1 什么是数据契约

数据契约，说白了就是数据提供方和数据使用方之间的一份书面约定。

它跟咱们现实中的合同很像。合同里写清楚：谁负责什么、交付什么、质量标准是什么、出了问题谁担责。数据契约也一样。

我个人的理解更直白一些：数据契约就是让数据"说话算话"。你承诺输出什么格式、什么质量的数据，下游就可以放心地基于这个承诺做开发。一旦承诺被打破，契约机制能及时发现问题，甚至自动阻断。

举个例子。你开发了一个实时订单流，下游的实时大屏依赖它。如果某天订单流里突然多了一个字段，或者某个字段类型从 string 变成了 int，下游大屏可能直接报错。有了数据契约，这种变更会被契约校验拦截，或者至少提前通知下游。

嗯，这里要注意：数据契约不是文档，不是 Wiki 页面，不是邮件沟通。它是可执行、可验证、可自动化的规范。

1.2 数据契约的核心要素

我在项目中落地数据契约时，一般会关注以下六个核心要素。少了哪个，契约都可能变成一纸空文。

核心要素	说明	我踩过的坑
Schema 定义	字段名称、类型、是否必填、默认值、枚举值范围	曾经有个字段叫 user_id，上游是 int，下游当 string 用，数据对不上查了三天
语义约定	字段的业务含义、度量单位、取值逻辑	金额字段有的用"分"，有的用"元"，聚合结果差100倍
质量约束	非空率、唯一性、取值范围、数据延迟上限	实时流延迟超过5分钟，下游风控模型直接误判
时效性承诺	数据产出时间、更新频率、最大延迟	批任务承诺每天8点产出，结果经常拖到10点
兼容性规则	字段变更策略（新增/废弃/修改）的兼容性等级	上游直接删字段，下游任务全部报错
SLA 与责任人	数据可用性目标、响应时间、升级路径	出了问题找不到人，群里@所有人没人回

这六个要素，缺一不可。Schema 定义是基础，语义约定是灵魂，质量约束是底线，时效性承诺是信任，兼容性规则是保障，SLA 与责任人是兜底。

1.3 数据契约在数据治理中的定位

聊完基础，咱们看看数据契约在整个数据治理体系里到底扮演什么角色。

数据治理这件事，说起来很大：数据标准、数据质量、数据安全、元数据管理、数据生命周期……但落到实际，很多团队做治理就是"写文档、定规范、然后没人看"。你想想看，是不是这样？

数据契约不一样。它是把治理要求"嵌入"到数据流转的每一个环节。不是靠人自觉遵守，而是靠机制自动执行。

我画了一张图，帮你理解数据契约在治理体系中的位置：

从这张图你能看到，数据契约处于治理能力层和数据流转层之间。它不是一个独立的治理工具，而是一个"翻译器"和"执行器"。

• 对上：承接数据标准、质量规则、安全策略等治理要求
• 对下：约束数据生产、传输、存储、消费的全流程

说白了，数据契约就是把治理"做活"的关键。没有契约，治理就是挂在墙上的制度；有了契约，治理才能嵌入到代码和流水线里。

1.4 为什么流批一体场景更需要数据契约

聊到这里，你可能想问：数据契约听起来不错，但跟流批一体有什么关系？

关系大了。

流批一体的核心挑战是什么？是同一份数据，既走实时流，又走离线批，两套管道对数据的理解必须一致。否则就会出现：

• 实时看板显示订单量 100 万，离线报表显示 95 万，老板问你对不上
• 实时特征和离线特征分布不一致，模型训练和推理效果天差地别
• 流任务和批任务对同一个字段的解析逻辑不同，数据对不齐

这些问题的根源，就是没有一份统一的契约来约束流和批两套管道。

数据契约在流批一体中的价值，我总结为三点：

1. 统一语义：流和批共用同一份 Schema 和语义定义，保证"同一个字段，同一种理解"
2. 质量对齐：流和批的数据质量约束一致，避免"流快但不准，批准但太慢"的尴尬
3. 变更协同：上游 Schema 变更时，流和批两套管道都能被契约机制感知，不会出现"批改了流没改"的情况