Skip to content

Latest commit

 

History

History
57 lines (41 loc) · 3.73 KB

File metadata and controls

57 lines (41 loc) · 3.73 KB
name metaframe-data-contract
category api
description 数据契约 | API & Integration

数据契约

英文名: Data Contract
分类: 数据架构
作者: Andrew Jones
复杂度: intermediate
成熟度: emerging
AI 相关: ✅ 是

简介

数据生产者和消费者之间的正式、版本化协议,规定模式、质量期望、SLA和所有权,将数据视为具有明确接口保证的产品。

核心概念

  • 模式契约:数据集结构(列、类型、可空性、主键)的版本化、机器可读规范,作为数据生产者与消费者之间的API契约
  • 质量契约:明确的、可衡量的数据质量义务,包括新鲜度SLA(如数据不得超过4小时)、完整性(如user_id空值率 < 0.1%)和有效性规则
  • 生产者所有权模型:数据生产者团队——而非消费者——负责创作、版本化和保证契约的原则,将责任向上游转移
  • 数据语义版本控制:将MAJOR.MINOR.PATCH约定应用于数据模式,其中MAJOR变更(删除列、类型变更)触发强制性消费者迁移工作流

使用步骤

  1. 使用机器可读格式(YAML或JSON)定义契约模式,指定数据集名称、所有者、版本、列定义、数据类型、可空性和主键约束
  2. 编码质量条款:新鲜度SLA(最大允许数据年龄)、完整性阈值(每列最低非空百分比)、有效性规则(值范围、正则表达式模式、引用完整性)
  3. 为契约建立语义版本控制(破坏性变更用MAJOR,增量变更用MINOR),并发布到对所有消费团队可见的契约注册表
  4. 在生产者的管道CI/CD中实施契约验证,使模式和质量规则违规在坏数据到达消费者之前阻止部署
  5. 通过自动化数据质量检查在运行时监控契约合规性,并发布契约健康仪表板,使消费者在构建依赖系统之前能够评估数据可靠性

适用场景

['当数据消费者(ML团队、分析、下游服务)反复因上游生产者团队的无声模式变更或数据质量回归而中断时', '当实施数据网格架构时,领域团队发布数据产品并需要明确的接口契约以将生产者与消费者解耦', '当监管要求(SOX、GDPR)要求有文档化的数据来源和质量保证,可以独立于生产团队进行审计时', '当数据事件(损坏的仪表板、错误的模型预测、失败的报告)的成本足够高,值得通过正式的生产者责任制进行预防性投资时']

最佳实践

✅ 推荐做法

  • 以机器可读格式(YAML/JSON)编写契约,与生产者的管道代码一起存储在git中,使契约变更经过与代码变更相同的审查流程
  • 在生产者的CI/CD管道中将契约作为部署前关卡强制执行,因为部署后的契约违规已经是下游事件
  • 使用语义版本控制,并在破坏性模式变更落地前至少提前一个迭代发布破坏性变更通知,给消费者留出适应时间
  • 从影响最大的数据集(那些为最多下游消费者或监管报告提供数据的数据集)开始,逐步扩展契约覆盖范围

❌ 避免做法

  • 不要将数据契约视为脱离执行的文档工件;未经验证的契约只是一个会随时间偏离现实的注释
  • 不要要求消费者代表生产者创作契约,因为生产者拥有的契约与责任一致;消费者创作的契约会产生所有权歧义
  • 不要对所有数据集应用统一的质量阈值;高流量生产数据集比内部实验表需要更严格的SLA
  • 不要在契约违规发生时阻止所有消费者访问数据集;实施分层通知系统,在生产者调查时告警消费者

Sources: SDFrame (Software Design) MetaFrame: 🔌 API & Integration / API 与集成