📚 课程目录第3章数据契约与Schema Registry

数据契约与 Schema Registry：Avro/Protobuf Schema 定义、兼容性检查与版本管理

好，我们进入第三章。前面聊了数据契约是什么，为什么流批一体需要它。这一章，咱们得落地了。

说白了，数据契约在技术层面最直接的体现，就是 Schema。你定义了数据结构，生产端按这个结构写，消费端按这个结构读。但问题来了——数据是会变的。今天加个字段，明天改个类型，后天废弃一个属性。如果没有一套机制来管理这些变化，流批一体就是一句空话。

嗯，这就是 Schema Registry 的用武之地。它不只是一个存 Schema 的地方，更是数据契约的「公证人」。

Avro 与 Protobuf：两种主流 Schema 定义方式

先说说 Schema 本身怎么定义。目前业界用得最多的，就是 Avro 和 Protobuf。我个人习惯在 Kafka 生态里用 Avro，在微服务 gRPC 场景用 Protobuf。但这不是的，你完全可以反过来用。

Avro Schema 示例

Avro 用 JSON 定义 Schema，可读性不错。来看一个用户事件的例子：

{
  "type": "record",
  "name": "UserEvent",
  "namespace": "com.example.analytics",
  "fields": [
    { "name": "userId", "type": "string" },
    { "name": "eventType", "type": "string" },
    { "name": "timestamp", "type": "long" },
    { "name": "properties", "type": { "type": "map", "values": "string" }, "default": {} }
  ]
}

注意那个 default 字段。我在项目中吃过亏——早期定义 Schema 时没给 properties 设默认值，结果下游消费老版本的代码读到新数据直接崩了。后来我养成了习惯：所有可能新增的字段，都设一个合理的默认值。

Protobuf Schema 示例

Protobuf 用 .proto 文件定义，更紧凑：

syntax = "proto3";

package com.example.analytics;

message UserEvent {
  string user_id = 1;
  string event_type = 2;
  int64 timestamp = 3;
  map<string, string> properties = 4;
}

Protobuf 的字段编号（=1, =2, =3...）不是随便写的。它直接影响序列化效率和兼容性。你想想看，一旦某个编号被用了，就不能再改，否则老版本解析会出问题。

核心区别：Avro 依赖 Schema 本身做序列化，读写双方必须协商好 Schema；Protobuf 把 Schema 信息编译进代码，字段编号是兼容性的关键。流批一体场景下，我个人更倾向 Avro，因为它的 Schema 可以独立于代码演进，更适合数据湖和 Kafka 这种多消费者场景。

Schema 兼容性检查：为什么需要它？

好，Schema 定义好了。但数据契约不是一成不变的。业务需求变了，你得加字段。这时候问题来了——新 Schema 和老 Schema 能共存吗？

这就是兼容性检查要干的事。Schema Registry 会帮你判断：新 Schema 能不能安全替换老 Schema，而不会让正在运行的生产者和消费者出问题。

兼容性类型主要有这么几种：

兼容性类型	含义	典型场景
BACKWARD	新 Schema 可以读老 Schema 写的数据	消费者先升级，生产者后升级
FORWARD	老 Schema 可以读新 Schema 写的数据	生产者先升级，消费者后升级
FULL	同时满足 BACKWARD 和 FORWARD	生产者和消费者独立升级，互不影响
NONE	不检查兼容性	开发环境、一次性任务

我曾经在一个实时数仓项目里，默认用了 BACKWARD 兼容性。结果有一次业务方急着上线新功能，先改了生产者代码，加了两个必填字段。消费者还没升级，读到新数据直接反序列化失败。那次事故让我记住了：兼容性策略不是随便选的，它决定了你的升级顺序。

我的建议：流批一体场景下，优先用 FULL 兼容性。虽然限制多一些，但生产者和消费者可以各自独立升级，不用协调发布时间窗口。代价就是新增字段必须带默认值，不能加必填字段。

Schema 版本管理：数据契约的演进史

有了兼容性检查，我们还需要版本管理。每次 Schema 变更，Registry 都会生成一个新版本号。这样，每条数据都携带了 Schema 版本信息，消费者可以明确知道：这条数据是用哪个版本的契约写的。

版本管理的核心流程是这样的：

生产者提交新 Schema 到 Registry
Registry 检查与当前最新版本的兼容性
通过则创建新版本，返回版本 ID
生产者序列化数据时，带上版本 ID
消费者根据版本 ID 获取对应 Schema，反序列化

这个流程里，第 2 步是关键。我见过不少团队，Schema 变更从来不检查兼容性，直接往 Registry 里塞。结果就是——数据还在，但没人能读懂了。数据契约变成了数据「气」约，一碰就散。

注意：版本号是单调递增的，不能回退。如果你发现新 Schema 有问题，正确的做法是提交一个修复版本，而不是删除旧版本。删除操作会破坏历史数据的可读性，这在流批一体中是灾难性的。

整体架构：Schema Registry 在流批一体中的位置

说了这么多，咱们用一张图把整个体系串起来。下面这张 SVG 展示了 Schema Registry 如何作为数据契约的核心枢纽，连接生产者和消费者：

这张图其实揭示了一个关键点：Schema Registry 不参与数据传输。它只负责管理契约，数据本身走 Kafka 或数据湖。生产者和消费者通过 Registry 协商好「怎么读」，然后各自处理「读什么」。

实战中的避坑指南

最后，分享几个我在实际项目中踩过的坑：

别把 Schema Registry 当数据库用：它只存 Schema 元数据，不存业务数据。有人试图用它存配置信息，结果版本一多，查询性能直线下降。
兼容性策略要团队共识：我曾经在一个项目里，不同团队用了不同的兼容性策略，结果跨团队数据交换时频繁出问题。后来统一成 FULL，世界清净了。
版本清理要谨慎：老版本 Schema 可能被历史数据引用。删了版本，历史数据就变成「死数据」。我建议保留所有版本，只在必要时做归档。
测试兼容性检查逻辑：不要完全信任 Registry 的默认行为。写几个单元测试，模拟 Schema 变更场景，确保检查逻辑符合你的预期。

嗯，这一章的内容就到这里。Schema Registry 是数据契约的「守门人」，把 Schema 定义、兼容性检查和版本管理做好，流批一体的数据质量就有了基本保障。