📚 课程目录第1章数据契约基础

1. 数据契约基础：什么是数据契约、三大核心要素与传统数据字典的区别

好，咱们直接进入正题。数据契约这个概念，这几年在数据治理圈子里越来越热。但我发现很多人把它理解成了「一份文档」或者「一个接口规范」。说实话，这种理解有点窄了。

我个人习惯把数据契约看作一种「承诺」——数据生产者和数据消费者之间，白纸黑字写下来的承诺。你生产什么数据，我消费什么数据，双方都得认账。

1.1 什么是数据契约

先别急着背定义。咱们想想实际场景：

你是一个数据平台工程师，负责维护用户行为日志。业务方天天找你：「这个字段啥意思？」「昨天那个字段怎么没了？」「数据延迟了半小时你咋不说？」

嗯，这种混乱我经历过太多次了。数据契约就是为了解决这类问题而生的。

数据契约，说白了就是数据生产方和数据消费方之间的一份正式协议。它约定了：

数据长什么样（Schema）
数据质量和服务水平怎么样（SLA）
数据代表什么业务含义（语义）

你想想看，如果每个数据接口都有一份这样的契约，上下游之间的扯皮是不是能少一大半？

核心观点：数据契约不是文档，是承诺。承诺需要被验证、被监控、被强制执行。

1.2 数据契约的三大核心要素

数据契约到底包含什么？我把它拆成三个维度：Schema、SLA、语义。缺一个，这个契约就不完整。

1.2.1 Schema — 数据的「骨架」

Schema 定义了数据的结构。字段名、字段类型、是否必填、取值范围……这些都是 Schema 的事。

举个例子，一个用户订单数据的 Schema 可能是这样的：

{
  "order_id":    {"type": "string", "required": true,  "pattern": "^ORD\\d{12}$"},
  "user_id":     {"type": "string", "required": true},
  "amount":      {"type": "number", "required": true,  "min": 0.01},
  "status":      {"type": "string", "required": true,  "enum": ["pending", "paid", "cancelled"]},
  "created_at":  {"type": "string", "required": true,  "format": "date-time"}
}

我在项目中遇到过一种情况：业务方说「这个字段是必填的」，结果生产方偷偷改成可选了。下游消费端直接报空指针。你说冤不冤？有了 Schema 契约，这种变更必须双方确认，谁也别想偷偷改。

我的建议：Schema 定义越细越好。别只写个「string」，把格式、枚举值、正则表达式都写清楚。越模糊的契约，越容易出问题。

1.2.2 SLA — 数据的「承诺书」

光有 Schema 还不够。数据什么时候到？延迟多久算异常？数据质量不达标怎么办？这些都得写进 SLA。

SLA 通常包含：

时效性：数据多久更新一次？T+1？实时？
可用性：接口或表的可用率是多少？99.9%？
完整性：数据缺失率不能超过多少？
准确性：关键字段的准确率要求？
响应时间：查询接口的 P99 延迟？

我曾经踩过一个坑：数据管道凌晨 3 点跑完，下游分析师每天早上 9 点看报表。本来相安无事。结果有一次管道出了故障，数据到下午 2 点才到位。分析师上午开会用的全是昨天的旧数据，决策全错了。

后来我们加了 SLA 监控：如果数据在早上 8 点前没到位，自动告警。这就是 SLA 的价值——把「模糊的期望」变成「可量化的承诺」。

注意：SLA 不是越严越好。定得太严，生产方做不到；定得太松，消费方不满意。双方得坐下来谈，找到一个平衡点。我见过最离谱的 SLA 是「数据延迟不超过 1 秒」，结果生产方根本做不到，契约成了一纸空文。

1.2.3 语义 — 数据的「灵魂」

Schema 告诉你字段叫什么，SLA 告诉你数据什么时候到。但「这个字段到底是什么意思？」——这是语义要解决的问题。

举个例子：

user_id 是注册用户 ID 还是设备 ID？
amount 是含税金额还是不含税金额？
status = "active" 是指用户最近 7 天有登录，还是指账户未被禁用？

你看，同一个字段名，不同团队的理解可能完全不同。语义就是要把这些「潜规则」摆到台面上。

语义定义通常包括：

业务定义：这个字段在业务上代表什么
计算逻辑：如果是衍生字段，怎么算出来的
数据来源：原始数据从哪里来
枚举值说明：每个值的业务含义

我个人习惯在数据契约里加一个「语义字典」附件。每个字段都写上业务定义和计算逻辑。虽然写的时候麻烦点，但后期排查问题的时候，能省下大量沟通成本。

1.3 数据契约与传统数据字典的区别

很多人问：数据契约和数据字典有啥区别？不都是描述数据的吗？

嗯，这个问题问得好。我直接做个对比：

对比维度	传统数据字典	数据契约
本质	静态的「说明书」	动态的「承诺书」
更新方式	人工维护，容易滞后	代码驱动，自动同步
约束力	仅供参考，没人强制执行	有验证机制，违反会告警
覆盖范围	主要是 Schema 描述	Schema + SLA + 语义
变更管理	改了就改了，下游可能不知道	变更需双方确认，版本化管理
使用场景	数据查询、文档查阅	数据生产、消费、监控、治理

说白了，传统数据字典是「告诉你数据长什么样」，数据契约是「承诺数据必须长什么样，并且我保证它一直长这样」。

我在很多公司看到过这种情况：数据字典建了一大堆，但没人看，也没人维护。字段改了，字典还是旧的。最后字典成了摆设。

数据契约不一样。它跟代码走在一起，Schema 变了，契约自动更新；SLA 不达标，自动告警。它是活的，不是死的。

一句话总结：数据字典是「过去时」，描述数据曾经是什么样；数据契约是「将来时」，承诺数据应该是什么样。

1.4 数据契约的核心逻辑框架

为了让你更直观地理解数据契约在整个数据治理中的位置，我画了一张图：

这张图展示了数据契约的完整生命周期。生产者发布契约，消费者订阅契约，中间有验证引擎实时校验，不达标就告警。这是一个闭环，不是一次性的文档交付。