📚 课程目录第1章 Schema Evolution 概述

1. Schema Evolution 概述：什么是 Schema Evolution？为什么需要它？常见应用场景

大家好，欢迎来到《Schema Evolution 实战指南》的第一章。

咱们开门见山。Schema Evolution，中文叫「模式演化」或「Schema 演进」。说白了，就是你的数据结构在不停变化，而你的系统得跟得上这种变化，还不能丢数据、不能崩服务。

我最早接触这个概念是在做数据仓库的时候。那时候业务方三天两头改字段，加一个、删一个、类型从 int 改成 string……搞得我焦头烂额。后来我才意识到，这不是某个人的问题，而是数据系统发展到一定规模后必然要面对的挑战。

1.1 什么是 Schema？先统一一下认知

在聊「演化」之前，得先搞清楚「Schema」是什么。

Schema 就是数据的「骨架」或「契约」。它定义了：

一条数据有哪些字段
每个字段叫什么名字
每个字段是什么类型（int、string、array、map……）
字段之间有没有嵌套关系

举个例子，一个用户信息的 Schema 可能是这样的：

{
  "name": "string",
  "age": "int",
  "email": "string"
}

嗯，很简单对吧？但现实世界的数据，远没有这么规整。

核心观点：Schema 是生产者和消费者之间的「握手协议」。协议变了，两边都得同步，否则就会出问题。

1.2 什么是 Schema Evolution？

Schema Evolution 指的是：在保证系统不中断、数据不丢失的前提下，让 Schema 能够平滑地向前演进。

它不是一个单一的技术，而是一套策略、工具和最佳实践的集合。

我个人的理解是：它解决的是「变」与「稳」之间的矛盾。业务要变，数据格式就得变；但下游的消费者（比如报表、机器学习模型、实时监控）不能因为上游改了 Schema 就挂掉。

常见的演化操作包括：

添加字段：给数据加一个新属性
删除字段：废弃一个不再使用的属性
修改字段类型：比如从 int 改成 long，或者从 string 改成 enum
重命名字段：字段改名，但语义不变
调整嵌套结构：把扁平结构改成嵌套，或者反过来

一个小建议：刚开始做 Schema Evolution 时，别想着一步到位。先保证「添加字段」这个场景能跑通，再考虑删除和修改。我见过太多团队一上来就搞大重构，结果把自己搞崩了。

1.3 为什么需要 Schema Evolution？

你可能会问：我一开始把 Schema 设计好不就行了？为什么还要演化？

问得好。但现实是：没有一成不变的业务。

业务需求在变：今天只需要用户名，明天要加手机号，后天要加会员等级。你不改 Schema，业务就做不了。
数据源在变：上游系统升级了，API 返回的字段变了。你作为下游，只能跟着变。
技术栈在变：从 JSON 换到 Avro，从 Kafka 换到 Pulsar，Schema 的承载方式也得变。
数据质量要求提高：早期可能允许字段为空，后来要求非空，再后来要加校验规则。

我记得有一次，一个实时推荐系统因为上游改了字段名但没通知下游，导致整个 pipeline 静默地写入了大量空值。等发现的时候，已经影响了三天的推荐效果。嗯，从那以后，我们团队就把 Schema Evolution 列为了基础设施级别的需求。

避坑指南：我曾经见过一个团队，因为害怕 Schema 变化，把所有字段都定义成 string。结果下游做聚合计算时，每次都要做类型转换，性能差不说，还经常因为格式不统一而出错。记住：逃避变化不是解决方案，拥抱变化才是。

1.4 常见应用场景

Schema Evolution 不是某个特定领域的专利。它在好几个场景里都是绕不开的话题。我挑三个最常见的聊聊。

1.4.1 数据湖

数据湖里存的是原始数据，通常以 Parquet、ORC、Avro 这类列式格式存储。数据湖的特点是：写一次，读多次。

问题来了：你今天写的数据是 Schema A，明天写的是 Schema B。下游在读取时，可能同时读到 A 和 B 两种格式的数据。如果没有 Schema Evolution 的支持，查询就会报错。

举个例子：

周一写入的 Parquet 文件有 3 个字段：id, name, age
周二新增了一个字段：email
周三的查询如果用了 email 字段，但周一的文件里没有，怎么办？

像 Apache Hudi、Delta Lake、Iceberg 这些数据湖框架，都内置了 Schema Evolution 的能力。它们能自动处理这种「新字段缺失」的情况，要么返回 null，要么用默认值填充。

1.4.2 流处理

流处理场景下，数据是源源不断进来的。你没法「停掉整个流」去改 Schema。

我做过一个实时风控系统，数据从 Kafka 进来，经过 Flink 做实时计算，最后写入 Elasticsearch。有一次，业务方要求在事件数据里加一个「设备指纹」字段。如果直接改 Schema，Flink 作业会反序列化失败，整个 pipeline 就断了。

解决方案是什么？用 Schema Registry + Avro。Schema Registry 里注册了新版本的 Schema，Flink 作业自动兼容新旧两种格式。老数据没有设备指纹字段，就填 null；新数据正常处理。

关键点：流处理场景下，Schema Evolution 的核心是「向前兼容」和「向后兼容」。向前兼容：新 Schema 能读老数据；向后兼容：老 Schema 能读新数据。

1.4.3 消息队列

消息队列（Kafka、Pulsar、RabbitMQ）是 Schema Evolution 的「重灾区」。因为消息队列是异步的，生产者和消费者往往不在同一个发布周期里。

你想想看：生产者升级了 Schema，但消费者可能还在跑旧版本。如果消息格式变了，消费者反序列化直接抛异常。更麻烦的是，消息队列里的数据是有「生命周期」的——有些消息可能被延迟消费，等消费者读到的时候，Schema 已经变了好几轮了。

常见的做法是：

使用 Schema Registry（Confluent Schema Registry、Apicurio Registry）统一管理 Schema
消息里带上 Schema ID，消费者根据 ID 去 Registry 拉取对应的 Schema
定义兼容性策略（BACKWARD、FORWARD、FULL 等）

我个人习惯在 Kafka 项目里强制使用 Avro + Schema Registry。虽然初期配置麻烦一点，但一旦跑起来，再也不用担心「消息反序列化失败」这种低级错误了。

1.5 核心知识体系一览

下面这张图，是我梳理的 Schema Evolution 核心知识体系。你可以把它当作整个课程的「地图」。

这张图展示了 Schema Evolution 的三大应用场景（数据湖、流处理、消息队列），以及它们依赖的核心技术和底层基础。整个课程会按照这个结构展开。

1.6 本章小结

这一章我们聊了：

Schema 是数据的契约，Schema Evolution 是让契约能平滑变化的能力
业务变化、数据源变化、技术栈变化是推动 Schema Evolution 的三大驱动力
数据湖、流处理、消息队列是三个最典型的应用场景，每个场景都有不同的挑战和解决方案