📚 课程目录第4章数据契约的构成要素

数据契约的构成要素：五根支柱

数据契约不是一张纸，也不是一个文档。它是一套可执行、可验证的规则体系。我做了这么多年数据治理，见过太多团队把契约写成「我们承诺提供高质量数据」这种空话——没用。

真正能落地的数据契约，必须包含五个核心要素。少了任何一个，契约都会变成摆设。今天我就把这五根支柱掰开揉碎了讲清楚。

数据契约五要素：数据模型定义、数据质量规则、数据SLA、数据血缘、版本管理。缺一不可。

1. 数据模型定义：契约的「语法」

数据模型定义是契约的基础。说白了，就是告诉双方：数据长什么样，每个字段是什么意思，取值范围是什么。

我见过最典型的坑：生产方说「我提供了用户信息」，消费方拿到一看，字段名对不上，类型对不上，空值处理方式也不一样。你说这契约签了有什么用？

一个完整的数据模型定义应该包含：

字段清单：字段名、数据类型、长度、精度
约束条件：主键、外键、唯一性、非空
枚举值：状态码、类型码的合法取值列表
默认值：字段为空时的处理策略

我的习惯：模型定义一定要用机器可读的格式，比如Avro、Protobuf或者JSON Schema。别用Word文档，人读得懂机器读不懂，后面自动化验证全得靠人工，累死你。

举个例子，一个简单的用户信息契约模型：

{
  "type": "record",
  "name": "UserInfo",
  "fields": [
    {"name": "user_id", "type": "string", "constraints": {"primary_key": true}},
    {"name": "user_name", "type": "string", "constraints": {"not_null": true}},
    {"name": "age", "type": "int", "constraints": {"min": 0, "max": 150}},
    {"name": "status", "type": "enum", "symbols": ["ACTIVE", "INACTIVE", "DELETED"]}
  ]
}

2. 数据质量规则：契约的「质检标准」

模型定义好了，数据也传过来了。但数据对不对？好不好？这就得靠质量规则来约束。

数据质量规则不是一句「保证数据准确」就完事了。它必须是可量化的、可自动校验的。我在项目中通常把质量规则分成四类：

质量维度	规则示例	校验方式
完整性	user_id 字段缺失率 < 0.1%	空值计数 / 总记录数
准确性	年龄字段值在 0-150 之间	范围校验
一致性	状态字段值必须在枚举列表中	枚举匹配
唯一性	user_id 重复率 = 0	去重计数

我曾经踩过的坑：一开始把质量规则定得太严，比如「所有字段缺失率必须为0」。结果生产方天天报警，消费方拿不到数据，两边互相甩锅。后来我学乖了——规则要分等级：核心字段严格，非核心字段放宽。契约是协作工具，不是武器。

3. 数据SLA：契约的「服务承诺」

SLA（Service Level Agreement）是数据契约里最容易被忽视的部分。很多人只关注数据对不对，不关注数据什么时候到、能不能用。

数据SLA通常包含三个维度：

可用性：数据接口或表的可用时间。比如「每日凌晨3点前数据必须就绪」
时效性：数据从产生到可用的延迟。比如「实时数据延迟不超过5秒」
完整性：数据覆盖范围。比如「必须包含全部活跃用户，覆盖率≥99.9%」

你想想看，消费方早上8点要跑报表，结果数据凌晨5点还没到位。这时候数据质量再好也没用——错过了业务窗口。

我建议SLA的制定遵循一个原则：可测量、可监控、可告警。每条SLA都要配上监控指标和阈值，不能含糊。

# SLA 配置示例
sla:
  table: "dwd_user_info_di"
  available_time: "2024-01-01 03:00:00"
  max_latency: "5min"
  min_completeness: 0.999
  alert_channel: "wechat"
  escalation: 
    - level: "warning"
      threshold: "延迟超过3分钟"
    - level: "critical"
      threshold: "延迟超过10分钟"

4. 数据血缘：契约的「溯源地图」

数据血缘解决的是信任问题。消费方拿到数据，想知道这数据从哪来的、经过了哪些加工、有没有被篡改过。

我遇到过最头疼的场景：一个报表指标对不上，业务方说是数据问题，数据方说是ETL问题，ETL说是上游接口问题。查了三天，发现是半年前一个字段映射改错了。要是当时有血缘记录，十分钟就能定位。

数据血缘在契约中要记录的内容：

上游来源：原始表、接口、文件
加工过程：ETL任务、转换逻辑、聚合规则
下游消费：哪些报表、模型、应用在使用这份数据
变更历史：每次修改的时间、原因、操作人

我的做法：血缘信息不要只存在人的脑子里，也不要只写在文档里。用工具自动采集，比如Atlas、DataHub或者自研的血缘解析器。每次数据流转都打上标签，出了问题一键溯源。

5. 版本管理：契约的「变更日志」

数据契约不是一成不变的。业务在变，数据在变，契约也得跟着变。但怎么变？谁来变？变了之后怎么通知？这就是版本管理要解决的问题。

版本管理的关键点：

版本号规范：语义化版本，比如 v1.0.0（主版本.次版本.修订号）
变更流程：谁可以提变更、怎么审批、怎么通知
兼容性策略：向前兼容还是向后兼容？字段新增算不算破坏性变更？
历史存档：旧版本要保留，方便回滚和审计

版本号	变更类型	变更内容	兼容性
v1.0.0	初始版本	首次发布	-
v1.1.0	新增字段	增加 email 字段	向前兼容
v2.0.0	字段类型变更	user_id 从 int 改为 string	破坏性变更

注意：版本管理最怕「偷偷改」。我曾经有个项目，生产方觉得改个字段名没什么大不了，直接改了没通知。结果消费方跑批跑了三天，最后一天全挂。从那以后我定了个铁律：任何契约变更必须走版本号+通知流程，哪怕只是改个注释。

五要素如何协同工作？

这五个要素不是孤立的。它们是一个整体：

模型定义告诉你怎么写数据
质量规则告诉你数据好不好
SLA告诉你数据什么时候到
血缘告诉你数据从哪来
版本管理告诉你数据怎么变

少了任何一个，契约都会出现盲区。我见过很多团队只做了模型定义和质量规则，觉得够了。结果一出问题，找不到根因，扯皮扯到天荒地老。

嗯，五要素讲完了。下一件事就是怎么把这些要素落地成可执行的代码和流程——那是后面章节要聊的。先把这五根支柱记牢，它们是数据契约的骨架。