数据契约基础：什么是数据契约、核心要素、数据契约与Schema的关系

好，咱们直接进入正题。数据契约这个概念，说白了就是数据提供方和数据消费方之间的一份"君子协议"。我在做多云数据同步项目时，最头疼的不是技术选型，而是两边团队对数据格式的理解总对不上。后来我意识到，缺的就是这么一份契约。

什么是数据契约

数据契约不是文档，也不是API规范。它是一组可验证、可执行的约定。你想想看，传统做法是写个Wiki页面，说"订单表有三个字段"，然后消费方自己去读。但人读总会出错，对吧？

数据契约把这种约定代码化了。它明确告诉双方：

• 数据长什么样（Schema）
• 数据怎么来（来源）
• 数据怎么用（语义约束）
• 数据什么时候变（演进规则）

我习惯把数据契约比作微服务之间的API契约。只不过API契约管的是接口，数据契约管的是数据本身。在云原生环境里，数据跨Kafka、S3、数据库流动，没有契约，你根本不知道数据在哪一步被"污染"了。

数据契约的核心要素

我在项目中落地过几十份数据契约，总结下来，一份完整的数据契约必须包含以下五个要素：

要素	说明	我踩过的坑
Schema定义	字段名、类型、是否必填、默认值	字段类型用string存时间戳，消费方解析时直接崩了
语义约束	字段的业务含义、取值范围、枚举值	status字段"1"代表"已支付"还是"待支付"，两边理解反了
数据来源	数据由哪个系统产生、经过哪些中间件	同一个order_id，订单系统和支付系统定义不一样
演进规则	字段新增/废弃/变更的流程和兼容性策略	直接删字段，下游ETL任务全挂了
SLA承诺	数据延迟、可用性、一致性级别	说好秒级延迟，结果数据晚了半小时，报表全错

嗯，这里要注意。很多团队只关注Schema定义，忽略了语义约束。我曾经接手过一个项目，两个团队用同一个字段名"amount"，一个存的是"分"，一个存的是"元"。数据合到一起，金额差了100倍。这就是没有语义约束的后果。

数据契约与Schema的关系

很多人把数据契约和Schema划等号。其实不对。Schema是数据契约的一部分，但不是全部。

我画个图帮你理解：

从图上你能看出来，Schema是数据契约的骨架，但光有骨架活不了。语义约束是血肉，数据来源是血脉，演进规则是生长机制，SLA是健康指标。

我举个例子。假设你定义了一个订单Schema：

{
  "order_id": "string",
  "amount": "number",
  "status": "string",
  "created_at": "string"
}

这个Schema本身没问题。但加上数据契约后，它变成：

{
  "schema": {
    "order_id": {"type": "string", "required": true, "description": "订单唯一标识，UUID格式"},
    "amount": {"type": "number", "required": true, "description": "订单金额，单位：分"},
    "status": {"type": "string", "enum": ["pending", "paid", "cancelled"], "description": "订单状态"},
    "created_at": {"type": "string", "format": "date-time", "description": "创建时间，ISO 8601格式"}
  },
  "semantics": {
    "source_system": "order_service",
    "data_domain": "交易域",
    "field_mappings": {
      "status": {"pending": "待支付", "paid": "已支付", "cancelled": "已取消"}
    }
  },
  "evolution": {
    "compatibility": "backward",
    "deprecation_policy": "字段废弃后保留90天"
  },
  "sla": {
    "latency": "5秒",
    "availability": "99.9%"
  }
}

你看，加了契约之后，消费方不需要再去问"amount单位是什么"、"status有哪些值"。契约里写得清清楚楚。

数据契约的典型应用场景

数据契约不是理论概念，它在实际项目中能解决很多具体问题。我列几个常见场景：

• 跨团队数据共享：A团队产出的数据，B团队消费。契约就是双方的"翻译器"。
• 多云数据同步：数据在AWS、Azure、阿里云之间流转，契约保证两边Schema一致。
• 实时数据管道：Kafka Topic的Schema演进，契约保证生产者和消费者兼容。
• 数据湖治理：写入数据湖的数据必须符合契约，否则拒绝写入。

说白了，数据契约就是数据领域的"接口文档"。只不过它比接口文档更严格、更可执行、更贴近业务。