1. 数据契约概述
大家好，我是老赵。做数据这行十几年了，今天咱们聊聊数据契约。
你可能听过「数据契约」这个词。它不是什么新概念，但在实时数据场景下，它的价值被放大了很多倍。我最早接触它是在做实时数仓的时候，那时候数据经常对不上，业务方天天找上门。后来我才意识到——缺的就是一份契约。
什么是数据契约
数据契约，说白了就是数据生产者和消费者之间的一份「君子协定」。它明确规定了：谁生产数据、数据长什么样、什么时候到、质量怎么保证。
举个例子。你负责一个订单系统，下游的实时风控需要你的订单数据。那你们之间就得约定好：
- 订单数据通过哪个Topic发送
- 每条消息包含哪些字段
- 字段类型是什么
- 数据延迟不能超过多少秒
- 空值怎么处理
这些约定写下来，就是数据契约。
核心观点：数据契约不是文档，是可执行的约定。它应该能被自动化工具校验，而不是躺在Wiki里吃灰。
我记得有一次，一个同事问我：「这不就是接口文档吗？」我说不完全对。接口文档描述的是技术细节，数据契约更关注数据的语义、质量、时效性。它比接口文档多了一层「承诺」——我保证数据是可靠的。
为什么需要数据契约
你想想看，没有数据契约会怎样？
- 生产者改了字段类型，消费者不知道，程序直接崩了
- 生产者突然把数据延迟从1秒变成10秒，下游的实时报表全错了
- 生产者删了一个字段，消费者还在用，结果全是null
这些场景，我全遇到过。最惨的一次，因为数据契约缺失，线上事故持续了4个小时，业务损失了几十万。
数据契约能解决三个核心问题：
| 问题 | 没有契约 | 有契约 |
|---|---|---|
| 数据变更 | 生产者随意改，消费者被动挨打 | 变更前通知，双方确认后再执行 |
| 数据质量 | 出了问题才排查，耗时耗力 | 契约中定义质量规则，实时校验 |
| 责任边界 | 出了问题互相甩锅 | 契约明确责任，谁的问题谁负责 |
我的经验：数据契约最大的价值不是技术，而是「对齐预期」。它让生产者和消费者在同一个频道上说话，减少了很多不必要的沟通成本。
数据契约的核心要素
一份完整的数据契约，应该包含哪些内容？我把它总结为五个要素：
- 数据标识——数据集的唯一标识，比如Topic名、表名、API路径
- Schema定义——字段名称、类型、是否必填、默认值、取值范围
- 质量约束——完整性、准确性、时效性、一致性等指标
- 服务等级——SLA承诺，比如延迟不超过2秒、可用性99.9%
- 变更管理——变更流程、通知机制、版本控制
嗯，这里要注意。很多人只关注Schema，忽略了质量约束和服务等级。我见过一个项目，Schema定义得很详细，但数据延迟从1秒慢慢涨到30秒，下游完全不知道。这就是契约不完整的问题。
避坑指南：我曾经在一个项目中，只定义了Schema和SLA，没定义变更管理。结果生产者偷偷加了一个字段，消费者没适配，线上直接报错。从那以后，我把变更管理写进了契约模板，谁改谁负责通知。
下面这张图，展示了数据契约的核心要素和它们之间的关系：
这五个要素，缺一不可。Schema定义是基础，质量约束和服务等级是保障，变更管理是长期维护的关键。缺少任何一个，契约都可能变成一纸空文。
我习惯把数据契约比作「数据界的API文档」。但比API文档更严格——它不仅要描述接口，还要定义质量、时效、责任。说白了，它是一份可执行的承诺书。
实践建议：刚开始推行数据契约时，不要追求完美。先定义Schema和SLA，跑通流程，再逐步加入质量约束和变更管理。一步到位反而容易失败。
好了，这一章我们聊了数据契约是什么、为什么需要它、以及它的核心要素。记住一句话：数据契约不是束缚，是保护。它保护生产者不被随意追责，也保护消费者不被数据坑。