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

一、数据契约基础：什么是数据契约、数据契约的组成要素、数据契约的价值

数据契约，说白了就是数据生产者和消费者之间的一份书面约定。

我刚开始做数据治理那会儿，团队里经常出现这样的场景：业务方跑过来问「昨天的日活怎么少了 20 万？」，数据团队排查半天，发现是上游埋点改了字段名但没通知下游。嗯，这种问题其实很常见。

数据契约要解决的核心问题就是——让数据的「供应」和「消费」变得可预期、可信任。它像一份 API 接口文档，但比 API 文档更严格。API 文档只告诉你接口长什么样，数据契约还告诉你：数据什么时候到、数据质量要达到什么标准、出了问题谁负责。

一句话总结：数据契约 = 数据结构约定 + 质量承诺 + 变更通知机制。

你想想看，如果没有契约，数据链路就像一条没有红绿灯的马路——谁都可以随时改、随时停，撞车是迟早的事。

我在项目中落地数据契约时，一般把它拆成五个核心要素。少了任何一个，契约都可能变成一纸空文。

要素	说明	我踩过的坑
数据结构	字段名、类型、长度、枚举值、是否可空	曾经有个字段叫「status」，上游从 int 改成 string，下游直接报错
质量指标	完整性、准确性、及时性、唯一性等阈值	约定「及时性」但没写具体分钟数，结果双方理解差了 2 小时
SLA 承诺	数据产出时间、可用性、响应时间	没写 SLA 的契约，出问题后扯皮了三天
变更流程	变更通知方式、审批流程、灰度周期	有一次变更只发了邮件，下游没看到，直接导致报表全红
责任矩阵	谁生产、谁消费、谁运维、谁兜底	最容易被忽略，但出事时最有用

这里我想特别强调一下变更流程。数据契约不是签完就锁死的，业务在变，数据也在变。契约要能「优雅地」变更，而不是「暴力地」中断。

我的习惯：每次变更至少提前 3 个工作日通知下游，并附带一个「兼容期」——旧字段和新字段同时存在 7 天，给下游留足迁移时间。

数据契约到底值不值得做？我直接说结论：对于超过 10 个数据源、5 个以上消费方的团队，不做数据契约就是在给自己埋雷。

它的价值主要体现在三个层面：

我记得有一次，一个核心指标「DAU」突然跌了 30%。业务方直接找到 CEO 汇报，说产品出大问题了。结果查下来，是上游一个埋点字段从「user_id」改成了「uid」，下游没适配。如果当时有数据契约，这种问题根本不会发生。

数据契约通过自动化校验，能在数据发布之前就发现结构变化。说白了，就是把问题扼杀在摇篮里。

没有契约的时候，数据团队 60% 的时间花在「沟通」上——确认字段含义、排查数据异常、对齐变更计划。有了契约，这些信息都写死了，双方按约定执行就行。

我见过一个团队，引入数据契约后，数据问题的平均排查时间从 4 小时降到了 30 分钟。为什么？因为契约里写清楚了「谁的数据、什么格式、什么时候到」，排查范围一下子缩小了。

这一点是咱们这门课的核心。数据契约是指标治理的「地基」。

你想想看，如果连原始数据的定义都不统一，上层指标怎么可能对齐？数据契约把每个字段的业务含义、计算口径、来源系统都固定下来，指标治理才有了「可信的数据源」。

注意：数据契约不是万能的。它解决的是「数据链路」问题，解决不了「业务定义」问题。业务口径的争议，还是得靠业务方坐下来谈。

下面这张图，是我在项目中总结的数据契约核心逻辑。它展示了数据从生产到消费的完整链路，以及契约在其中扮演的角色。

从这张图你能看到：数据契约不是孤立存在的，它连接了生产者和消费者，中间还有一层自动化校验引擎。校验引擎会实时检查数据是否满足契约约定，不满足就告警甚至阻断。

我曾经在一个项目中，把校验引擎和 CI/CD 流水线集成在一起。每次数据变更，自动跑一遍契约校验。如果校验不通过，流水线直接失败，变更根本发布不出去。效果非常好，上线后数据事故减少了 80%。

不是所有场景都需要数据契约。我建议你对照下面这个清单，如果命中 3 条以上，就该认真考虑了：

我的建议：不要一开始就追求「全量契约」。先挑 3-5 个核心链路试点，跑通流程、看到效果，再逐步推广。步子迈太大，容易扯着。