2. Schema定义与类型：基础概念、强Schema与弱Schema、版本化策略
好，我们正式开始聊Schema。很多刚接触数据治理的同学，一听到“Schema”就觉得是DBA的事，跟我一个做业务开发的有什么关系？
其实不然。说白了，Schema就是数据的“说明书”。你想想看，两个人要合作，总得先约定好数据长什么样吧？字段叫什么、什么类型、能不能为空——这些就是Schema要管的事。
2.1 Schema基础概念
我习惯把Schema理解成“数据的契约”。它定义了数据的结构、类型和约束。举个例子，一个用户注册事件，你总得知道userId是字符串还是整数，email是不是必填。
Schema的核心三要素：
- 结构（Structure）：数据有哪些字段，字段之间的层级关系
- 类型（Type）：每个字段的数据类型（string、int、boolean等）
- 约束（Constraint）：是否必填、取值范围、默认值等
我在项目中见过最典型的反例——一个订单系统，上游突然把orderId从字符串改成了整数，下游消费端直接崩了。为什么？因为没有Schema约束，上游改得悄无声息。
来看一个最基础的Schema定义，用Avro格式举个例子：
{
"type": "record",
"name": "UserEvent",
"fields": [
{"name": "userId", "type": "string"},
{"name": "email", "type": ["null", "string"], "default": null},
{"name": "signupTime", "type": "long"}
]
}这个定义告诉所有人：userId必须是字符串，email可以为空，signupTime是时间戳。谁不按这个来，谁就是违约方。
2.2 强Schema与弱Schema
这是面试里经常被问到的问题，也是实际选型时绕不开的决策点。
| 对比维度 | 强Schema | 弱Schema |
|---|---|---|
| 定义方式 | 写入前必须预定义结构 | 写入时动态推断或无需定义 |
| 典型代表 | Avro、Protobuf、Parquet | JSON、MongoDB、Elasticsearch |
| 数据质量 | 高，写入即校验 | 低，脏数据容易混入 |
| 灵活性 | 低，改Schema需要走流程 | 高，字段可以随时增减 |
| 性能 | 高，序列化/反序列化快 | 低，解析开销大 |
强Schema：数据在写入之前，必须严格按照预定义的结构来。我参与过的一个金融风控项目，所有事件必须用Avro Schema定义好，字段类型、默认值、兼容性全部写死。好处是数据质量极高，坏处是改起来要层层审批。
弱Schema：说白了就是“先写进去再说”。JSON就是典型，你可以在同一个字段里塞字符串、数字、甚至嵌套对象。我见过一个日志系统，同一个字段昨天是字符串，今天是数组，下游解析直接报错。
我的建议：
核心业务链路用强Schema，数据质量是生命线。探索性分析或日志采集可以用弱Schema，灵活优先。但记住——弱Schema不等于没Schema，只是Schema在读取时才生效。
2.3 Schema版本化策略
数据是活的，Schema一定会变。字段要新增、类型要调整、废弃字段要删除——这些变化怎么管理？
我曾经踩过一个坑：上游在用户事件里加了一个新字段，下游消费端没更新Schema，结果反序列化直接抛异常。从那以后，我坚持所有Schema必须版本化。
2.3.1 版本化三原则
- 向前兼容（Forward Compatibility）：新版本Schema能读旧版本数据。比如新增字段时给个默认值。
- 向后兼容（Backward Compatibility）：旧版本Schema能读新版本数据。比如删除字段时确保下游不依赖它。
- 完全兼容（Full Compatibility）：新旧Schema可以互相读写。这是最理想的状态。
注意：不要轻易做破坏性变更。比如把字段类型从int改成string，或者删除一个必填字段。这种变更必须走版本升级流程，不能悄咪咪改。
2.3.2 常见的版本化策略
| 策略 | 做法 | 适用场景 |
|---|---|---|
| 线性版本 | v1 → v2 → v3，每次递增 | 小团队，变更频率低 |
| 语义化版本 | major.minor.patch（如1.2.3） | 大型系统，需要精细控制 |
| 时间戳版本 | 用日期或时间戳标识版本 | 数据湖、事件溯源场景 |
我个人比较推荐语义化版本。major版本号变化意味着不兼容变更，minor是新增字段但兼容，patch是修复或优化。这样上下游一看版本号就知道能不能直接对接。
2.3.3 Schema Registry的作用
光有版本号还不够，你得有个地方统一管理这些Schema。这就是Schema Registry干的事。
它的核心能力：
- 存储所有版本的Schema
- 校验写入的数据是否符合当前Schema
- 检查版本间的兼容性
- 提供REST API供上下游查询
Confluent Schema Registry是业界用得最多的方案，支持Avro、Protobuf、JSON Schema。我参与的一个实时数仓项目，每天几亿条事件都经过它校验，脏数据率从5%降到了0.1%以下。
2.4 本章知识体系
下面这张图把Schema的核心脉络串起来了，你可以对照着回顾一下：
嗯，这一章的内容就这些。记住一句话：没有Schema的数据是危险的，没有版本化的Schema是灾难的。后面我们会深入讲怎么用Avro、Protobuf这些工具落地，以及Schema Registry的实战配置。