Paimon 是如何做到支持强 Schema Evolution 的？

知识点图片

在 Apache Paimon 的官方文档（基于 master 分支）中，Paimon 被定位为一个流批统一的湖仓存储格式。它能够实现强大的、无副作用的 强 Schema Evolution（模式演进），其底层设计和实现机制主要依赖于以下几个核心技术要点：

传统的 Hive 表在进行 Schema 演进（如重命名列或改变列顺序）时容易发生数据错乱，因为它们依赖列名或列的物理位置（索引）进行映射。

Paimon 引入了类似 Apache Iceberg 的 Field ID 机制：

Schema 文件格式：Paimon 的 Schema 信息以 JSON 格式持久化在磁盘上（路径为 schema/schema-0, schema-1 等）。
唯一 ID 绑定：每个字段（DataField）在创建时都会分配一个自动递增且唯一的 id。
highestFieldId 跟踪：Schema 文件中记录了当前最大的 highestFieldId。后续不论是新增列、删除列还是重命名列，新字段都会分配全新的 ID，而已有字段的 ID 永远保持不变。
读时解析（Schema Projection）：在读取底层的物理文件（如 Parquet、ORC）时，Paimon 的底层 Reader 完全通过 Field ID 匹配数据列，而非依赖列名或物理位置。
- 重命名列：仅需在元数据 JSON 中修改 name，由于底层的 Field ID 未变，Reader 依然能精准读到旧文件中的数据。
- 删除列：元数据中移除该 Field ID，读取时直接忽略该列。
- 新增列：旧文件中不存在该 Field ID，读取时自动补 NULL。

Schema 版本控制：每次发生 Schema 变更（如 ALTER TABLE）都会生成一个新的 Schema JSON 文件（例如从 schema-0 升级为 schema-1）。
Snapshot 的 Schema 关联：Paimon 中的每一次数据提交（Snapshot）都会显式关联生成它时的 Schema 版本号。
不重写历史物理文件：因为旧的数据文件仍然依赖其写入时的 Schema 版本进行解析，Paimon 禁止直接删除旧的 Schema 文件。当读取历史 Snapshot 时，Paimon 依靠元数据中的 Schema 历史确保“时间旅行（Time Travel）”和版本回滚的正确性。

在流式数据集成（CDC）中，上游源表（如 MySQL、Kafka）可能会随时发生 Schema 变更。

无重启流式同步：Paimon 支持在不重启 Flink / Spark 流作业的前提下，实时将上游新增的列同步到 Paimon 表中。
自动 Schema 合并（Schema Merging）：通过开启 write.merge-schema 配置，Paimon 在写入数据时如果发现输入数据的 Schema 与当前表不一致，会自动将两者的 Schema 进行合并，并生成最新的 Schema 版本投入运行。
类型拓宽支持（Type Promotion）：支持数据类型的安全晋升（例如 INT -> BIGINT，BIGINT -> DECIMAL 等），旧物理文件在读取时会自动转换为新类型。

针对无主键的追加表（Append Table），Paimon 在较新版本中引入了革命性的 Data Evolution 模式：

传统痛点：在传统数据湖中，如果为已有数据回填（Backfill）新添加的列，必须将历史的所有物理文件全部重写，I/O 开销极大。
Paimon 解决方案：通过在建表时开启 row-tracking.enabled = true 和 data-evolution.enabled = true：
1. 当需要回填新列的数据或更新局部列时，Paimon 不会重写原有的历史数据文件。
2. 它会将新列的数据写入到独立的列文件中。
3. 在读取期间，Paimon 会利用 Row ID（行跟踪）将原始物理文件与新列的独立物理文件进行读时智能合并（Merge-on-Read）。
4. 这种方式既避免了频繁重写文件的巨大 I/O 消耗，又保障了读路径上的高性能。

Apache Paimon 依托于 Field ID 的映射设计、多版本元数据管理、CDC 引擎的实时 Schema 合并以及针对追加表的 Data Evolution 物理隔离合并机制，在流批两端都实现了极其强韧且对生产无污染的 Schema 演进能力。

播面