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

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

大家好，我是老赵。今天咱们聊聊数据契约。

说实话，我做了十几年数据安全，见过太多因为数据问题撕逼的场面。业务方说数据不准，数据方说业务方乱用，两边吵得不可开交。后来我发现，很多问题的根源就一个——没有约定。

数据契约，说白了就是给数据上下游之间签一份「君子协议」。你生产数据，我消费数据，咱们提前说好：数据长什么样、多久更新一次、出问题了谁负责。就这么简单。

1.1 什么是数据契约

数据契约（Data Contract）是一份正式的技术约定。它定义了数据提供方和数据消费方之间的接口规范。

我习惯把它类比成API契约。你调用一个API，得知道入参出参、响应格式、超时时间对吧？数据契约干的是同样的事——只不过对象换成了数据集。

数据契约 = 数据接口的「合同」

它明确记录了：谁生产数据、谁消费数据、数据长什么样、质量要求是什么、出了问题怎么处理。

举个例子。你负责用户画像表，下游推荐团队要用。没有契约的时候，你改了字段名，他们跑崩了，你才知道。有了契约，你改之前得通知他们，他们得确认，改完还得一起验证。

嗯，这里要注意：数据契约不是文档，是可执行的技术规范。它应该能自动校验、自动告警、自动生成代码。我见过很多团队把契约写成了Word文档，那没用，没人看。

1.2 为什么需要数据契约

这个问题我问过很多团队。答案五花八门，但核心痛点就三个。

跨团队协作混乱：数据提供方改了Schema，消费方毫不知情。我曾经遇到一个案例，数据团队把字段类型从int改成了string，下游十几个任务全部报错，修复花了两天。
数据质量没人兜底：数据延迟了、缺失了、错了，谁负责？没有契约，就是互相甩锅。提供方说「我按时产出了」，消费方说「数据不对」，最后找领导拍桌子。
安全合规风险高：敏感数据被谁用了？用在哪里？没有契约，你根本不知道。等审计找上门，才发现数据已经泄露半年了。

我的经验：数据契约最大的价值不是技术，而是「降低沟通成本」。有了契约，两边不用反复确认，一切按约定执行。出问题看契约，改东西走流程，清爽。

你想想看，一个中型公司，数据链路少说几十条，多则上千条。没有契约，每条链路都是黑盒。数据安全？不存在的。

1.3 数据契约的核心三要素

数据契约包含很多内容，但最核心的就三个：Schema、SLA、语义。我管它叫「铁三角」，缺一个都不行。

要素	定义	核心问题
Schema	数据的结构定义	数据长什么样？字段名、类型、约束是什么？
SLA	服务质量协议	数据多久更新一次？延迟多少算违规？
语义	数据的业务含义	这个字段代表什么？怎么算的？谁定义的？

1.3.1 Schema：数据的「骨架」

Schema定义了数据的物理结构。包括字段名、数据类型、是否为空、主键、外键、分区字段等等。

我建议用Avro、Protobuf或JSON Schema来定义。别用Excel，别用Word，别用Markdown。为什么？因为这些格式没法自动校验。

{
  "namespace": "com.company.user",
  "type": "record",
  "name": "UserProfile",
  "fields": [
    {"name": "user_id", "type": "string", "doc": "用户唯一标识"},
    {"name": "age", "type": "int", "doc": "用户年龄"},
    {"name": "email", "type": ["null", "string"], "default": null, "doc": "邮箱地址"}
  ]
}

你看，这个Schema明确说了：user_id是字符串，不能为空；age是整数；email可以为空。下游拿到这个，就知道怎么解析数据。

避坑指南：我曾经见过一个团队，Schema里写了字段名，但没写类型。结果上游改了类型，下游解析报错，查了两天才发现。记住：字段类型必须显式声明，别偷懒。

1.3.2 SLA：数据的「承诺」

SLA定义了数据提供方对质量的承诺。常见的SLA指标包括：

时效性：数据多久更新一次？T+1还是实时？
完整性：数据行数不能低于多少？字段不能为空的比例？
准确性：数据偏差允许多少？比如金额字段误差不超过0.01%
可用性：数据服务可用时间？99.9%还是99.99%？

我习惯把SLA写成这样：

SLA:
  freshness: 1h          # 数据延迟不超过1小时
  completeness: 99.5%    # 行数完整度不低于99.5%
  accuracy: 99.9%        # 关键字段准确率不低于99.9%
  availability: 99.95%   # 数据服务可用率不低于99.95%

嗯，这里要注意：SLA不是越高越好。你定99.999%的可用性，成本翻十倍，业务不一定需要。我建议按业务等级分级：核心交易数据SLA高，日志分析数据SLA低，合理分配成本。

1.3.3 语义：数据的「灵魂」

语义是最容易被忽略的，但也是最重要的。它回答了三个问题：

这个字段是什么意思？比如「活跃用户」是指7天内有登录，还是30天内有交易？
这个值是怎么算的？比如「订单金额」是含税还是不含税？
谁负责定义？业务方还是数据方？

我见过最离谱的事：两个团队都用「用户数」这个字段，一个算的是注册用户，一个算的是活跃用户。结果汇报给老板，数据对不上，老板拍桌子。

我的做法：每个关键字段都加一个「业务定义」字段，写明计算逻辑、数据来源、更新频率。最好再配一个「负责人」字段，出问题直接找人。

说白了，语义就是消除歧义。数据是客观的，但人对数据的理解是主观的。契约把主观理解统一起来，大家用同一套语言说话。

1.4 数据契约的整体框架

为了让你更直观地理解，我画了一张图。它展示了数据契约在数据链路中的位置，以及三要素之间的关系。

这张图你看懂了吗？数据提供方和消费方之间，通过数据契约建立连接。契约里包含Schema、SLA、语义三要素，缺一不可。没有契约，两边就是盲打；有了契约，一切有据可依。

1.5 小结

好了，这一章的内容就这些。总结一下：

数据契约是数据上下游之间的技术约定，解决协作混乱、质量无保障、安全风险三大问题。
核心三要素：Schema（结构）、SLA（质量）、语义（含义），一个都不能少。
契约要可执行、可校验、可自动化，别写成文档吃灰。