1. 数据契约概述
大家好，我是老张。做数据架构十几年了，踩过的坑比写过的代码还多。今天咱们聊一个很实在的话题——数据契约。
你可能听过微服务之间的契约测试，也可能在数据仓库里见过"数据血缘"这个词。但数据契约到底是什么？它跟成本归因有什么关系？别急，我慢慢讲。
1.1 什么是数据契约
说白了，数据契约就是数据生产者和消费者之间的一份"君子协定"。它约定了数据长什么样、什么时候到、质量怎么保证。
举个例子。你负责一个订单系统的数据管道，下游是BI报表团队。他们需要每天凌晨2点前拿到昨天的订单明细，字段包括订单ID、用户ID、金额、状态，而且金额不能为负。
这份约定，就是数据契约。
数据契约的核心要素：
- Schema契约：字段名、类型、是否必填、取值范围
- SLA契约：数据到达时间、更新频率、延迟容忍度
- 质量契约：完整性、准确性、一致性、时效性
- 语义契约：业务含义、计算口径、枚举值定义
我在项目中遇到过最典型的反例——没有数据契约。数据生产者随便改了个字段类型，下游报表直接崩了。排查了三天，最后发现是上游把"金额"从decimal改成了string。你说冤不冤？
所以，数据契约不是可有可无的文档，它是数据链路稳定的基石。
1.2 数据契约的核心价值
你可能会问：搞这么正式干嘛？我们团队小，口头沟通不行吗？
嗯，这里要注意。口头沟通在10个表以内还行，到了100个表、1000个任务，你试试？
数据契约的价值，我总结为四点：
| 价值维度 | 具体说明 | 我见过的真实收益 |
|---|---|---|
| 减少沟通成本 | 生产者和消费者不用反复确认字段含义 | 某金融客户，契约化后沟通邮件减少70% |
| 提升数据质量 | 契约即校验规则，异常数据早发现早处理 | 曾经帮一个电商团队拦截了3次错误数据推送 |
| 加速问题排查 | 谁改了什么、什么时候改的，一目了然 | 有一次线上故障，5分钟定位到是上游改了枚举值 |
| 支撑成本归因 | 数据链路清晰，成本才能算得明白 | 这是咱们这门课的核心，后面细讲 |
我的个人习惯：每接入一个新的数据源，第一件事不是写ETL代码，而是先跟上下游敲定数据契约。契约签好了，后面的事情至少省一半力气。
1.3 数据契约在成本归因中的角色
好，重点来了。数据契约怎么帮我们做成本归因？
先想一个问题：你的数据平台每个月花多少钱？
存储多少钱？计算多少钱？哪个业务线用的最多？哪个表最贵？
很多公司答不上来。为什么？因为数据链路不透明。
数据契约恰好能解决这个问题。它把数据链路中的每个环节都"契约化"了——谁生产的、谁消费的、用了多少资源、产生了多少成本。
我画了一张图，帮你理解数据契约在成本归因中的位置：
你看，数据契约处在生产者和消费者之间，它不只是"传话"的，它还承载了成本归因所需的元数据。
具体来说，数据契约在成本归因中扮演三个角色：
- 成本锚点：每个数据契约对应一条数据链路，链路成本可以精确归因到契约级别
- 成本透明化：谁消费了数据、消费了多少、产生了多少成本，契约里写得清清楚楚
- 成本优化依据：通过契约分析，发现"高成本低价值"的数据链路，推动优化
我曾经踩过的坑：有一次做成本归因，发现某个表存储成本特别高。查了半天，原来是三年前的一个离线任务还在每天全量跑，下游早就没人用了。如果当时有数据契约，这种"僵尸数据"一眼就能看出来。
1.4 数据契约的落地形态
说了这么多，数据契约长什么样？
我建议用YAML或JSON来定义，既机器可读，也人可读。给你看一个简化版：
# 数据契约示例：订单明细表
contract:
id: "ods_order_detail_v1"
version: "1.2.0"
producer:
system: "order_service"
owner: "订单团队-张三"
consumer:
- team: "BI报表组"
owner: "李四"
- team: "推荐算法组"
owner: "王五"
schema:
- name: "order_id"
type: "string"
required: true
description: "订单唯一标识"
- name: "user_id"
type: "string"
required: true
- name: "amount"
type: "decimal(10,2)"
required: true
constraint: "amount >= 0"
- name: "status"
type: "string"
required: true
enum: ["pending", "paid", "shipped", "completed", "cancelled"]
sla:
delivery_time: "02:00 UTC+8"
frequency: "daily"
max_latency: "30min"
quality:
completeness: "> 99.9%"
accuracy: "> 99.99%"
cost:
storage_per_month: "120GB"
compute_per_run: "15min * 8CU"
estimated_cost: "¥2,800/月"
小建议：契约里的cost字段可以先不填，等成本归因引擎跑起来后自动填充。我习惯在契约里预留这个字段，方便后续对接。
1.5 数据契约与数据血缘的关系
你可能会问：数据契约跟数据血缘有什么区别？
我打个比方。数据血缘像是一张地图，告诉你数据从哪来到哪去。数据契约像是路标和交通规则，告诉你每条路该怎么走、限速多少、谁负责维护。
两者相辅相成。血缘解决"是什么"的问题，契约解决"怎么做"的问题。在成本归因场景下，血缘帮你找到链路，契约帮你算清成本。
| 维度 | 数据血缘 | 数据契约 |
|---|---|---|
| 核心问题 | 数据从哪里来？到哪里去？ | 数据应该长什么样？谁负责？ |
| 表现形式 | 有向无环图（DAG） | 结构化文档（YAML/JSON） |
| 变更影响 | 被动追溯 | 主动约束（契约校验） |
| 成本归因角色 | 提供链路拓扑 | 提供成本锚点与分摊依据 |
在实际项目中，我通常把数据契约作为数据血缘的"元数据补充"。血缘告诉你表A→表B→表C，契约告诉你表A是谁的、表B的SLA是什么、表C的成本是多少。
好了，这一章的内容就到这里。数据契约不是什么高深的概念，它就是一份让数据生产者和消费者"对齐"的约定。有了它，成本归因才有了抓手。