Paimon 是什么？和 Iceberg、Hudi 有什么区别？
湖仓与 OLAP第 8 / 34 题
自测：先别看答案
试着用 1～2 分钟把这道题讲出来（说出声或写下要点），再展开对照。
面试怎么回答
Paimon 是面向流式更新设计的湖存储格式，主键表按 bucket 组织成 LSM 树，写入先落小的有序文件，再由后台 Compaction 合并，所以高频 upsert 写得快、读时按主键合并。它和 Flink 深度集成，既能流式写入，也能把表的变更以 changelog 形式流式读出，适合 CDC 入湖和流式数仓分层。Iceberg 更偏离线表格式标准和多引擎生态，Hudi 也支持主键更新但调优较复杂。选型时我会看更新频率、是否需要流式消费变更、以及查询引擎生态。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
面试里聊到湖仓，现在越来越常被追问：
Paimon 和 Iceberg、Hudi 有什么不一样？为什么实时场景会选它？
如果只回答「都是数据湖表格式」，基本接不住后面的追问。
Paimon 的核心区别在于：它从设计之初就是为流式更新准备的，底层用 LSM 结构组织主键表。
先说它解决什么问题
Iceberg 最初的设计目标是让大规模离线表具备快照、Schema 演进和隐藏分区等能力，写入以批量提交为主。
在实时场景里，上游是 CDC 或 Kafka 的持续变更流，每分钟都有大量按主键的更新和删除。批量提交模型下，频繁小提交会产生大量小文件和元数据；按主键合并更新的代价也比较高。
Paimon（前身是 Flink Table Store）的思路是：把每个 bucket 组织成一棵 LSM 树，新数据先以小的有序文件写入，再由后台 Compaction 逐层合并。高频更新写得快，读取时按主键合并即可。
和 Iceberg、Hudi 怎么比
- Iceberg：强项是表格式标准化和多引擎生态，离线分析、快照管理、分区演进很成熟。主键更新依赖 MERGE INTO 或 equality delete，高频流式更新不是它的主场。
- Hudi：同样支持主键更新，有 Copy-on-Write 和 Merge-on-Read 两种表，较早被用于 CDC 入湖，但配置项多、调优复杂。
- Paimon：主键表天然基于 LSM，和 Flink 深度集成，流式写入和流式读取（直接读出 changelog）是一等公民；同时也支持 Spark 等引擎批量读写。
什么时候选 Paimon
- 上游是数据库 CDC，下游需要分钟级可查的明细或宽表。
- 需要「部分列更新」拼宽表，或者「按主键预聚合」。
- 希望湖上的表还能被下游 Flink 作业继续流式消费，构建流式数仓的分层。
如果主要是离线大表分析、多引擎共享读取，Iceberg 依然是更稳妥的通用选择。