一、数据契约基础：什么是数据契约、为什么需要数据契约、数据契约的核心要素

1.1 什么是数据契约？说白了就是“数据界的接口规范”

我先问个问题：你做过微服务开发吧？服务之间调用要定义接口，要约定入参、出参、超时时间。那数据流转呢？

我见过太多团队，数据生产者随便改个字段类型，下游消费方直接崩了。数据契约，就是给数据流转也定一套接口规范。

用一句话概括：数据契约是数据生产方和消费方之间，关于数据格式、语义、质量、时效性的书面约定。

它不是什么新概念。早在SOA时代就有服务契约，数据契约只是把这个思路搬到了数据层面。但实时特征场景下，它的重要性被放大了十倍。

举个例子。你在做实时推荐特征，需要用户最近5分钟的点击行为。数据契约会写明：

• 字段：user_id（string）、item_id（string）、click_time（timestamp）、page_type（int）
• 延迟：从事件发生到数据就绪，不超过30秒（P99）
• 质量：user_id 非空率 ≥ 99.9%，click_time 不能是未来时间
• 可用性：每天 99.5% 的时间可消费

嗯，这就是一份典型的数据契约。它把“模糊的信任”变成了“可量化的承诺”。

1.2 为什么需要数据契约？我踩过的坑告诉你答案

说实话，我早年做实时数仓时，根本不知道什么叫数据契约。结果呢？

第一个坑：字段改了，没人通知

我记得有一次，上游把 order_status 从 int 改成了 string，没发任何公告。下游的实时特征计算任务直接抛异常，线上推荐效果掉了一大截。排查了整整三个小时，才发现是字段类型变了。

第二个坑：数据延迟了，消费方还在傻等

实时特征对时效性敏感。上游 Kafka 集群挂了，数据延迟了 10 分钟，下游的实时规则引擎还在用旧数据做决策。结果呢？误判了一堆用户行为，运营活动效果惨不忍睹。

第三个坑：数据质量没人兜底

我曾经接手过一个实时特征项目，user_id 字段偶尔会出现空值。下游模型训练时直接报错，但没人知道这个空值是谁产生的、什么时候产生的、该谁修。

这三个坑，本质上都是同一个问题：数据生产方和消费方之间没有明确的契约。

数据契约能解决什么？我列一下：

痛点	没有契约的后果	有契约的解法
字段变更	下游任务崩溃，排查耗时	契约版本管理，变更前通知所有订阅方
数据延迟	实时决策基于过期数据	契约约定 SLA，超时自动告警/降级
数据质量	脏数据污染下游，无人认领	契约定义质量指标，自动校验+责任到人
依赖混乱	不知道谁在用我的数据	契约注册中心，消费方必须订阅

1.3 数据契约的核心要素：一张图讲清楚

一份完整的数据契约，至少包含五个要素。我习惯把它们分成“承诺层”和“治理层”。

下面我逐个拆解。

1. Schema 定义

这是最基础的部分。数据长什么样？字段名、数据类型、是否必填、默认值、枚举范围。实时特征场景下，我建议用 Avro 或 Protobuf 做 Schema 定义，天然支持兼容性检查。

// 一个实时用户行为特征的 Schema 示例（Avro 格式）
{
  "type": "record",
  "name": "UserClickFeature",
  "fields": [
    {"name": "user_id", "type": "string", "doc": "用户ID，不能为空"},
    {"name": "item_id", "type": "string", "doc": "物品ID"},
    {"name": "click_time", "type": "long", "doc": "点击时间戳（毫秒）"},
    {"name": "page_type", "type": "int", "default": 0, "doc": "页面类型：0-首页，1-详情页，2-搜索页"},
    {"name": "duration_ms", "type": "int", "default": 0, "doc": "停留时长（毫秒）"}
  ]
}

2. SLA 承诺

实时特征最敏感的就是延迟。SLA 里要写明：

• 延迟：从事件发生到数据可消费，P99 不超过多少秒
• 可用性：数据链路全年可用时间占比（比如 99.9%）
• 吞吐量：每秒能处理多少条事件

3. 质量约束

数据质量不是“尽量好”，而是“可量化”。常见的质量约束包括：

• 非空率：关键字段（如 user_id）非空率 ≥ 99.9%
• 唯一性：主键不能重复
• 值域：枚举值必须在合法范围内
• 时序：时间戳不能是未来时间，不能乱序超过 N 秒

4. 生命周期管理

数据契约不是写一次就完事了。它需要版本管理。我习惯的做法：

• 每个契约有唯一 ID 和版本号
• 变更必须走审批流程，通知所有订阅方
• 废弃的契约要有下线计划，给消费方缓冲期

5. 治理与合规

最后，谁对这个契约负责？谁审批变更？谁监控 SLA 达标情况？这些都要写清楚。我建议每个契约至少指定一个“数据 Owner”和一个“技术 Owner”。

1.4 一个完整的契约长什么样？

我把上面五个要素拼起来，给你看一份完整的实时特征数据契约模板：

要素	内容示例
契约名称	实时用户点击行为特征 v1.2
数据生产方	用户行为采集团队（Owner: 张三）
数据消费方	实时推荐团队（Owner: 李四）
Schema	Avro 格式，7 个字段，详见 Schema 仓库
SLA	P99 延迟 ≤ 30s，可用性 ≥ 99.5%，吞吐量 ≥ 10w/s
质量约束	user_id 非空率 ≥ 99.9%，click_time 不能为未来时间
生命周期	版本 v1.2，变更需提前 3 个工作日通知
治理规则	每周 SLA 达标报告，连续 3 天不达标触发升级

嗯，看到这里你应该明白了。数据契约不是什么高深的理论，它就是一套“把话说清楚、把责任划明白”的规则。但就是这套规则，能帮你省掉无数个排查问题的深夜。