Schema 演化的适用场景

DDIA 第 4 章的主线是Schema 演化——当数据结构变化时新旧代码如何共存。它关注的是向后兼容新代码读旧数据和向前兼容旧代码读新数据。但 Schema 演化并不是所有数据系统的核心问题。它的优先级取决于系统形态数据生产者和消费者是否解耦、升级节奏是否可控、数据是否长期存活、是否存在在线 RPC 或消息管道。本文梳理 Schema 演化的适用边界并说明为什么在某些数据管道中Avro 和 Protobuf 并非重点。一、Schema 演化解决的核心问题Schema 演化要解决的是在无法全量同步升级的前提下让数据格式的变化不破坏系统间的通信。它成立的前提通常包括数据生产者和消费者是解耦的升级节奏无法统一。新旧代码会在系统中长期共存。数据会长期存储新代码必须能读旧数据。编码层需要向前/向后兼容以支持滚动升级和异构客户端。在分布式系统中滚动升级是常态。服务端逐节点替换新旧版本代码和新旧数据格式会同时存在。移动端 App、IoT 设备、第三方客户端更无法强制同步升级。跨团队共享消息格式时协调所有团队同时发布、测试和回滚的成本极高。历史数据写入数据库、Kafka、数据湖后也不会因为代码升级自动变成新格式。DDIA 用data outlives code概括这一事实。这些场景才是 Schema 演化的主战场。二、典型适用场景场景说明分布式滚动升级新旧代码同时运行无法瞬间全量切换异构客户端移动端、IoT、第三方客户端升级节奏不可控跨团队数据契约多个服务依赖同一消息格式需要 Schema Registry 解耦部署历史数据长期存储新代码需要读取旧格式数据向后兼容是必须在线 RPC 与消息管道gRPC、Kafka 等场景要求紧凑编码、强类型和版本兼容在这些场景中Avro、Protobuf、Schema Registry、兼容性规则都是需要认真处理的问题。三、低优先级或不适用场景反过来如果系统具备以下特征Schema 演化的优先级会明显降低场景说明单机、封闭、可全量升级所有代码和数据可以一起切换不需要新旧共存数据是中间产物批量跑完即结束不需要长期兼容批量分析格式统一控制数据格式变化时重新生成数据集即可无在线 RPC、无 Kafka 管道不需要 Protobuf 的紧凑传输也不需要 Avro 的 Schema 演化核心矛盾是查询与训练效率重点在列式存储、谓词下推、压缩、分片和训练读取速度此时编码层兼容性不是主要矛盾。该关注的是数据如何组织、存储和读取而不是新旧代码如何通过编码格式长期共存。四、案例分析大模型训练数据管道一个典型的大模型训练数据管道如下海量 JSONL → MapReduce 清洗/去重/过滤 → Doris/Quickwit/Parquet → 训练时读取拆开看各环节原始落地JSONL。可读、通用、追加友好适合从多种来源抽取数据。批处理MapReduce。输入输出可用 JSONL 或 Parquet中间 shuffle 由 Hadoop 自身序列化不依赖 Avro/Protobuf。查询与检索Doris 负责 OLAP 聚合Quickwit 负责全文检索。它们有各自的导入格式和索引结构。训练读取Parquet Arrow或 WebDataset。列式存储、列投影、谓词下推更适合大规模训练。在这些环节中数据格式变化通常由同一数据团队控制。字段变更后重新生成数据集即可。历史数据兼容靠数据集版本化而不是靠编码格式的向前/向后兼容。系统没有 Kafka 实时管道没有 gRPC 在线服务也没有多团队独立升级的契约问题。因此Avro 的优势——Schema 演化成熟、与 Hadoop/Kafka 深度集成——在此类场景中并不突出Protobuf 的优势——小体积、低延迟、强类型 RPC——也不是主战场。Hadoop 原生对 Protobuf 支持较弱集成成本较高。Avro 和 Protobuf 解决的是编码层互操作问题而大模型训练数据管道主要解决的是数据管道和训练数据服务问题。五、该关注的重点对于以批量训练数据为主的系统更值得投入的方向包括JSONL 落地规范控制分片大小、压缩格式、字段命名和类型一致性避免字段重命名和类型歧义。JSONL 转 Parquet/Arrow列式存储支持列投影、谓词下推和统计信息适合反复扫描和训练读取。训练数据加载Parquet PyArrow / Hugging FacedatasetsIterableDataset流式读取多模态场景可使用 WebDataset。Doris/Quickwit 定位Doris 用于聚合、统计和元数据查询Quickwit 用于全文检索、筛选和采样。训练数据仍应从 Parquet/WebDataset 读取。按需引入 Avro/Protobuf如果未来引入 Kafka 实时管道或 gRPC 特征服务再认真处理 Avro/Protobuf 的 Schema 演化和兼容性规则。六、结论Schema 演化是一个有明确适用边界的问题。它适合分布式滚动升级、异构客户端、跨团队数据契约、历史数据长期存活、在线 RPC 与消息管道。它不适合或优先级较低的场景包括单机全量升级、数据用完即弃、批量分析由单一团队控制格式、无在线服务通信、核心矛盾是查询和训练效率。对于以海量 JSONL、MapReduce、Doris、Quickwit 和大模型训练读取为主的系统Schema 演化通常不是核心问题Avro 和 Protobuf 的优先级也较低。技术选型应匹配场景而不是追求格式的“高级”标签。理解 Schema 演化的适用边界有助于把精力放在真正影响系统效率的环节上。