Schema 定义与类型：强类型、弱类型、AVRO、Protobuf、JSON Schema

聊到数据契约，第一个绕不开的话题就是 Schema。说白了，Schema 就是数据的「说明书」。没有它，生产者和消费者之间全靠默契，早晚要出乱子。

我在项目中见过太多次这种场景：上游改了字段类型，下游直接崩了。双方一查，发现压根没有统一的 Schema 定义。嗯，这就是我们今天要解决的问题。

强类型 Schema vs 弱类型 Schema

先搞清楚这两个概念。你想想看，强类型 Schema 就像签了合同——字段是什么类型、能不能为空、取值范围是多少，全都写得明明白白。一旦违反，编译期就报错，绝不手软。

弱类型 Schema 就随意多了。字段可以动态增减，类型可以隐式转换。灵活是灵活，但坑也多。

特性	强类型 Schema	弱类型 Schema
类型检查	编译期严格校验	运行时动态推断
字段约束	必须明确定义	可动态增减
性能	序列化/反序列化快	解析开销较大
兼容性	需显式管理版本	天然向后兼容
典型代表	AVRO、Protobuf、Thrift	JSON、XML、YAML

AVRO：大数据生态的宠儿

AVRO 是 Apache 旗下的序列化框架，在 Hadoop 生态里用得特别多。它的特点是 Schema 和数据一起存储，自描述能力强。

来看一个 AVRO Schema 的例子：

{
  "type": "record",
  "name": "User",
  "namespace": "com.example",
  "fields": [
    {"name": "id", "type": "int"},
    {"name": "name", "type": "string"},
    {"name": "email", "type": ["null", "string"], "default": null},
    {"name": "age", "type": "int", "default": 0}
  ]
}

注意看 email 字段，它的类型是 ["null", "string"]。这是 AVRO 的联合类型写法，表示这个字段可以为 null。我个人的习惯是，所有可空字段都显式声明 default 值，避免消费者读到 null 时不知所措。

Protobuf：高性能的二进制协议

Protobuf 是 Google 家的，性能比 AVRO 还要好。它的核心优势是生成的代码体积小、序列化速度快，特别适合微服务之间的 RPC 调用。

同样的 User 对象，用 Protobuf 定义是这样的：

syntax = "proto3";

package com.example;

message User {
  int32 id = 1;
  string name = 2;
  optional string email = 3;
  int32 age = 4;
}

每个字段后面的数字是 field number，在二进制编码中代替字段名。这就是 Protobuf 体积小的秘密——传输时只传编号，不传名字。

我记得有一次帮团队优化接口，把 JSON 换成 Protobuf，数据体积直接降了 70%。但要注意，Protobuf 的 Schema 必须提前编译成代码，不像 AVRO 那样可以动态解析。所以如果你的数据消费者是动态语言，Protobuf 用起来会有点别扭。

JSON Schema：灵活但需要自律

JSON Schema 是弱类型 Schema 的代表，但它通过约束定义实现了「半强类型」的效果。它不改变 JSON 的灵活性，只是给 JSON 加了一套校验规则。

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "id": {"type": "integer"},
    "name": {"type": "string"},
    "email": {"type": "string", "format": "email"},
    "age": {"type": "integer", "minimum": 0, "maximum": 150}
  },
  "required": ["id", "name"]
}

JSON Schema 的优势是生态好，几乎所有语言都有对应的校验库。但它的缺点也很明显——校验是运行时的，不是编译期的。你写错了字段名，只有跑到那行代码才会报错。

我个人建议，JSON Schema 适合用在 API 网关、数据导入导出这类场景。核心链路还是用 AVRO 或 Protobuf 更稳妥。

三种 Schema 的对比与选型

直接上对比表，方便你快速决策：

维度	AVRO	Protobuf	JSON Schema
序列化格式	二进制	二进制	文本 (JSON)
Schema 存储	与数据一起	独立文件	独立文件
动态解析	支持	不支持	支持
性能	高	极高	低
版本演化	严格但清晰	灵活但复杂	无内置机制
最佳场景	数据管道、Kafka	微服务 RPC	API、配置文件

知识体系总览

下面这张图帮你理清本章的核心脉络：

这张图把 Schema 的三种类型、对应的具体技术、以及各自的核心特性串在了一起。你可以把它当作选型时的参考地图。