数据契约的核心要素：五根支柱撑起数据质量

数据契约不是一张纸，也不是一个文档。它是一套可执行、可验证的约定。我把它拆成五个核心要素，缺一不可。你想想看，少了任何一个，这个契约就变成了空壳。

这五个要素分别是：数据生产者、数据消费者、数据Schema、服务水平协议(SLA)、数据质量约束。它们之间的关系，就像一座房子的地基、承重墙、屋顶、门窗和电路——各司其职，又互相支撑。

核心观点：数据契约的本质，是在生产者和消费者之间建立一份可量化的、自动化的“数据服务协议”。五个要素缺一不可，否则契约就会退化成一张废纸。

2.1 数据生产者：谁在“制造”数据？

数据生产者，就是数据的源头。它可能是一个微服务、一个数据库、一个IoT设备，甚至是一个人工录入的Excel表格。我个人习惯把生产者分为两类：系统生产者和人工生产者。

  • 系统生产者：比如订单服务、用户服务、日志采集器。它们的数据是自动生成的，格式相对稳定。
  • 人工生产者：比如运营人员填写的配置表、客服录入的工单。这类数据容易出错，需要更严格的约束。

我在项目中遇到过一件事：一个数据团队花了三个月搭建实时数仓，结果发现上游的订单服务突然改了字段类型，把订单金额从 decimal(10,2) 改成了 string。下游所有报表全部报错。为什么？因为没有契约约束生产者。生产者觉得“我改个字段怎么了”，消费者却崩了。

我的建议：在数据契约中，生产者必须承诺“不改Schema”或“变更前通知”。这不是技术问题，是治理问题。

2.2 数据消费者：谁在用数据？

数据消费者，就是数据的下游使用者。它可能是另一个微服务、一个BI报表、一个机器学习模型，或者一个外部合作伙伴。

消费者的需求千差万别。有的要实时数据，有的要离线数据；有的要全量数据，有的只要增量。如果不把消费者写进契约，生产者就不知道“为谁服务”，质量约束也就无从谈起。

我记得有一次，一个数据团队给业务部门提供“用户活跃度”数据。生产者每天凌晨跑批，数据早上8点就绪。但业务部门是实时看板，要求数据延迟不超过5分钟。结果呢？业务部门天天投诉数据不准，技术团队觉得“我明明按时跑了啊”。

说白了，这就是契约里没写清楚消费者的SLA要求。

避坑指南：我曾经见过一个项目，消费者有20多个，但契约里只写了“数据可用”。结果每个消费者对“可用”的理解都不一样——有人要秒级，有人要小时级。最后全乱套了。所以，每个消费者都要单独列出来，写清楚它的具体需求。

2.3 数据Schema：数据的“身份证”

数据Schema，就是数据的结构定义。它告诉双方：数据长什么样？有哪些字段？每个字段是什么类型？

一个完整的Schema应该包含：

  • 字段名：比如 order_id、user_name
  • 数据类型：比如 string、int、decimal
  • 是否必填：比如 nullable: false
  • 默认值：比如 default: 0
  • 枚举值：比如 enum: ['active', 'inactive']
  • 字段描述：比如“订单创建时间，格式为ISO8601”

我建议用Avro或Protobuf来定义Schema。它们支持向前兼容和向后兼容，能自动检测Schema变更。举个例子：

{
  "type": "record",
  "name": "Order",
  "fields": [
    {"name": "order_id", "type": "string"},
    {"name": "amount", "type": "double"},
    {"name": "status", "type": {"type": "enum", "symbols": ["pending", "paid", "cancelled"]}},
    {"name": "created_at", "type": "long", "logicalType": "timestamp-millis"}
  ]
}

你看，这个Schema把每个字段都定义得清清楚楚。生产者必须按这个格式输出，消费者也按这个格式解析。谁也别耍赖。

关键点：Schema是契约的“语法层”。没有它，生产者和消费者就是鸡同鸭讲。

2.4 服务水平协议(SLA)：数据服务的“承诺书”

SLA是数据契约中最“硬”的部分。它定义了数据服务的质量指标，比如：

SLA指标 说明 常见阈值
数据延迟 数据从产生到可用的时间 实时：<5秒；离线：T+1
数据可用性 数据服务正常运行的时间比例 99.9%
数据新鲜度 数据是否是最新版本 不超过30分钟
数据完整性 数据是否完整，无缺失 99.99%
数据一致性 跨系统数据是否一致 最终一致，偏差<0.1%

我在项目中遇到过最典型的SLA问题：数据延迟。生产者说“我每天凌晨2点跑完”，消费者说“我早上8点要用”。看起来没问题，对吧？但实际跑起来，生产者经常因为资源争抢跑到凌晨4点。消费者8点一看，数据还是昨天的。这就是SLA没写清楚“如果延迟了怎么办”。

我的建议：SLA里一定要写“违约条款”。比如：延迟超过1小时，生产者需要发告警；延迟超过4小时，自动触发补偿机制。没有惩罚的SLA，就是一张空头支票。

2.5 数据质量约束：数据的“体检标准”

数据质量约束，是契约里最细、最繁琐的部分。它定义了数据必须满足的质量规则。我把它分为四类：

  1. 完整性约束：比如“订单金额不能为空”、“用户手机号必须11位”。
  2. 准确性约束：比如“订单金额必须大于0”、“年龄必须在0-150之间”。
  3. 一致性约束：比如“订单状态必须与支付状态匹配”、“用户ID必须在用户表中存在”。
  4. 唯一性约束：比如“订单ID不能重复”、“用户邮箱不能重复”。

举个例子，一个电商系统的数据质量约束可能长这样：

{
  "quality_rules": [
    {"rule": "order_id IS NOT NULL", "severity": "critical"},
    {"rule": "amount > 0", "severity": "critical"},
    {"rule": "status IN ('pending', 'paid', 'cancelled')", "severity": "high"},
    {"rule": "created_at <= NOW()", "severity": "medium"},
    {"rule": "user_id IN (SELECT id FROM users)", "severity": "high"}
  ]
}

这些约束不是写给人看的，是写给自动化工具执行的。每次数据流转，工具都会自动校验这些规则。一旦违反，要么拒绝数据，要么发告警。

避坑指南：我曾经见过一个团队，写了200多条质量约束，结果每条都设成“critical”级别。最后告警满天飞，运维团队直接躺平了。所以，约束一定要分等级：critical的必须阻断，high的告警，medium的记录日志。别搞一刀切。

2.6 五要素的关系：一张图看懂

下面这张图展示了五个核心要素之间的关系。你可以看到，生产者产出数据，消费者消费数据，Schema定义数据格式，SLA约定服务水平，质量约束保证数据质量。它们环环相扣，缺一不可。

数据契约五要素关系图 数据契约五要素关系图 数据契约 数据生产者 数据消费者 数据Schema 服务水平协议(SLA) 数据质量约束 产出数据 消费数据 定义格式 约定服务 保证质量 五要素环环相扣：生产者产出数据 → Schema定义格式 → 质量约束保证数据 → SLA约定服务 → 消费者使用数据

2.7 小结：五要素缺一不可

数据契约的五个核心要素，就像一辆车的五个轮子（嗯，我知道车只有四个轮子，但备胎也很重要）。少了任何一个，这辆车就跑不稳。

  • 生产者和消费者是契约的“人”的部分，明确谁对谁负责。
  • Schema是契约的“语法”部分，让双方说同一种语言。
  • SLA是契约的“承诺”部分，量化服务水平。
  • 质量约束是契约的“底线”部分，保证数据不出格。

我个人习惯在项目启动时，先花一周时间把这五个要素梳理清楚。别急着写代码，先把契约写好。代码可以重构，契约一旦定下来，改起来就麻烦了。你想想看，是不是这个道理？

← 上一章 📖 返回目录 下一章 →