源头治理与数据契约
数据质量的根因常在源头：字段缺失、枚举新增不通知、更新时间不稳定，都会让下游反复救火。数据契约（data contract）把约定显式化——字段类型与非空约束、枚举取值集合、唯一性、可接受的更新时效（SLA）、负责人，并在入库前做自动校验，把问题挡在入口。同时把上游的结构与口径变更纳入通知与评审流程，避免下游在报表出错后才发现字段被改。契约只有在自动校验时才真正有效。
基本信息
| 契约内容 | schema 约束、枚举集合、唯一性、更新时效 SLA、负责人 |
|---|---|
| 入口校验 | 接入时自动校验结构与取值约束，失败即告警 |
| 变更通知 | DDL 与口径调整走评审并同步下游 |
| 责任共担 | 契约双方共同维护，违约有记录 |
| 常见载体 | YAML 或 JSON 描述文件，纳入版本管理 |
典型使用场景
- 新数据源接入前，先约定字段与更新时效，再开发加工逻辑
- 上游系统改字段前，通过契约评审评估下游影响
- 每日入口校验：源端结构与取值不符合契约时立即告警
- SLA 管理：约定最晚产出时间，超时自动通知上游值班
- 跨团队协作：把口头约定固化成可校验的文件，减少扯皮
数据契约示意
数据契约示意
# 数据契约示例（简化）
table: ods_orders
owner: trade-system
schema:
order_id: {type: bigint, nullable: false, unique: true}
amount: {type: decimal(12,2), nullable: false, min: 0}
status: {type: string, enum: [PAID, REFUND, CLOSED]}
freshness:
sla: "T+1 06:00" # 最晚产出时间，超时告警
timezone: "Asia/Shanghai"
# 变更流程：修改契约需走评审，评审通过后同步下游负责人契约条款与检查方式
| 条款 | 含义 | 检查方式 | 违反后果 |
|---|---|---|---|
| 字段约束 | 类型、非空、唯一 | 接入脚本校验 | 加工失败或主键重复 |
| 枚举集合 | 状态等取值白名单 | 取值越界计数 | 状态字段出现未知值 |
| 更新时效 | 最晚产出时间 | 新鲜度监控比对 | 下游产出整体延后 |
| 变更通知 | 结构调整需评审 | 变更记录与评审单 | 下游被动发现并返工 |
契约要自动化才有效：靠文档与口头约定，几个月后就会和实际实现脱节，出现问题双方各执一词。
上游改字段不通知，下游往往在报表出错后才发现：把变更通知纳入上游的发布检查项，比事后追责更有用。
契约条款不宜一次写几十条：先覆盖最影响下游的字段与时效（金额、主键、状态、产出时间），落地后再逐步补充。