数据契约生命周期：从定义到废弃

数据契约不是写一份文档就完事了。它有自己的生命轨迹。

我见过太多团队把契约当成「一次性交付物」——定义完、发布完，就扔进 wiki 吃灰。结果呢？半年后数据对不上了，没人知道哪个版本在生效，变更全靠口头通知。说白了，契约没活起来。

这一章，我们就把数据契约的完整生命周期走一遍。六个阶段：定义、发布、发现、绑定、变更、废弃。每个阶段都有它的关键动作和常见坑。

2.1 六个阶段，一个闭环

先看整体框架。我习惯用一张图来理解这六个阶段的关系：

嗯，这张图值得多看两眼。你会发现：变更这个阶段有两条出路——要么走向废弃，要么触发重新定义。我在项目中遇到过不少团队，一遇到变更就直接废弃旧契约、创建新契约，结果历史版本全丢了，审计的时候根本说不清。

2.2 每个阶段，逐个拆解

① 定义：契约的「出生证明」

定义阶段做什么？说白了，就是把数据提供方和消费方之间的约定写清楚。包括：

• 数据实体：表名、字段名、字段类型、主键、外键
• 数据质量：非空率、唯一性、取值范围、时效性
• 服务承诺：SLA、响应时间、可用性
• 安全约束：脱敏规则、访问权限、数据分类

② 发布：让契约「可被发现」

定义完了，得让其他人能看到。发布不是发一封邮件就完事，而是要把契约注册到契约中心（一个集中管理平台）。

发布时至少包含：

发布项	说明	示例
契约ID	全局唯一标识	DC-2024-00123
版本号	语义化版本	v1.0.0
生效时间	契约开始生效的时间点	2024-06-01 00:00:00
发布状态	草稿/已发布/已废弃	已发布
变更摘要	本次变更的简要说明	初始版本

③ 发现：消费方「找到」契约

发布之后，消费方怎么知道有这份契约？这就是发现阶段要解决的问题。

我建议做两件事：

1. 主动推送：通过消息队列或 webhook，通知相关方有新契约发布
2. 被动检索：提供搜索界面或 API，让消费方按数据域、数据实体、标签等维度查找契约

④ 绑定：消费方「接入」数据

绑定是消费方根据契约内容，实际接入数据的过程。这个阶段，消费方会：

• 根据契约中的字段定义，创建数据管道或数据模型
• 根据质量承诺，设置数据校验规则
• 根据 SLA，配置监控告警

绑定完成后，消费方应该向契约中心注册绑定关系。这样，当契约发生变更时，提供方才能知道哪些消费方会受影响。

⑤ 变更：契约的「版本迭代」

变更是整个生命周期里最复杂的阶段。为什么？因为变更可能影响多个消费方。

变更类型通常分三种：

变更类型	示例	影响范围
兼容性变更	新增字段（非必填）	小，消费方无需改动
非兼容性变更	删除字段、修改字段类型	大，消费方必须改动
元数据变更	修改字段描述、标签	无，仅信息更新

变更必须走审批流程。我后面会专门用一章来讲变更审批的细节，这里先记住一个原则：非兼容性变更必须通知所有已绑定的消费方，并给出缓冲期。

⑥ 废弃：契约的「终点」

当数据不再被需要，或者被新契约替代时，旧契约就应该被废弃。

废弃不是删除。废弃后的契约应该：

• 标记为「已废弃」状态，但保留历史版本
• 通知所有已绑定的消费方
• 设置废弃生效时间，给消费方留出迁移窗口

2.3 数据契约在数据治理中的定位

聊完生命周期，我们得回答一个根本问题：数据契约在数据治理里到底扮演什么角色？

我个人理解，数据契约是数据治理的「执行层」工具。它把治理策略翻译成了可落地、可验证的约定。

看这张定位图就清楚了：

数据治理通常分三层：

• 战略层：定方向、定政策。比如「所有个人隐私数据必须脱敏」
• 机制层：定标准、定规则。比如「手机号脱敏规则：保留前3后4」
• 执行层：定约定、定验证。比如「数据契约中声明：phone字段使用保留前3后4脱敏」

数据契约就在执行层。它不制定标准，但它把标准绑定到了具体的数据交换场景中。

2.4 生命周期管理的关键原则

最后，总结几条我在实战中沉淀下来的原则：

1. 版本可追溯：每次变更都生成新版本，旧版本不能覆盖或删除
2. 变更可通知：非兼容性变更必须通知所有绑定方，并给出至少 7 天缓冲期
3. 废弃可审计：废弃的契约保留完整历史，包括变更记录和审批记录
4. 绑定可查询：随时能查到「谁在用哪个版本的哪个契约」