Apache Paimon：流存储数据湖深度解析 · 专栏导览
专栏定位
Apache Paimon（前身为 Flink Table Store）是阿里巴巴团队于 2022 年贡献给 Apache 社区的流式数据湖存储引擎，2023 年成为 Apache 顶级项目。它的设计出发点与 Apache Hudi 和 Apache Iceberg 都有本质不同：
Hudi 的核心问题：如何高效地按主键 Upsert 记录？（写入侧优化） Iceberg 的核心问题：如何让多引擎一致地读写同一张表？（格式规范开放） Paimon 的核心问题：如何让数据湖支持秒级延迟的流式 Upsert？（实时性优化）
前两者在处理流式高频写入时，本质上都是”微批模拟流”——Flink 每隔几分钟触发一次 Checkpoint，生成一批文件写入数据湖，数据新鲜度维持在分钟级。Paimon 用 LSM-Tree（Log-Structured Merge-Tree） 替代了不可变 Parquet 文件的 Copy-on-Write 模型，将流式写入的延迟从分钟级压缩到秒级，同时保持 ACID 语义和可查询性。
本专栏适合：
- 在 Flink + 数据湖架构中寻求秒级数据新鲜度的实时数仓工程师
- 希望理解 LSM-Tree 如何应用于数据湖场景的架构师
- 已深入了解 Hudi 和 Iceberg，希望从第三个维度完整理解数据湖格式演进的工程师
技术版本：Apache Paimon 0.8.x / 1.0.x
专栏目录
| 篇序 | 文章标题 | 核心主题 |
|---|---|---|
| 01 | 为什么需要 Paimon——Flink 实时写湖的延迟困境与 LSM 解法 | 流式 Upsert 的分钟级延迟根因，LSM-Tree 的核心思想 |
| 02 | LSM-Tree 存储引擎——为什么用 LSM 而非 CoW 文件覆盖 | LSM-Tree 原理，MemTable、SST 文件、Compaction 层次 |
| 03 | 主键表与追加表——两种写入模型的设计逻辑 | Primary Key Table vs Append-Only Table 的场景与原理 |
| 04 | Changelog Producer——CDC 语义的流式生产与消费 | Changelog 模式，Full Compaction、Lookup Changelog |
| 05 | Lookup Join 与维表——Paimon 在流计算中的实时维表查询 | Partial Update，Lookup Join 的 Cache 机制 |
| 06 | Paimon vs Delta Lake vs Iceberg vs Hudi——流存储视角的架构总结 | 四者的完整对比，实时数仓场景的选型 |
与前两个专栏的差异定位
Hudi 专栏（已完成）：
核心叙事 = 记录级 Upsert + 增量消费（Timeline + Index）
强项 = CDC 摄入效率、增量 ETL
存储模型 = 不可变 Parquet 文件（CoW/MoR）
Iceberg 专栏（已完成）：
核心叙事 = 开放表格式 + 多引擎互操作
强项 = 元数据扩展性、分区演进、云原生生态
存储模型 = 不可变 Parquet 文件（CoW + Row-level Delete）
本专栏（Apache Paimon）：
核心叙事 = 流存储原生 + 秒级延迟写入
强项 = Flink 原生流写、实时维表、低延迟 Changelog
存储模型 = LSM-Tree（可变 + 不可变 SST 文件分层合并）← 根本差异！
推荐阅读路径
实时数仓工程师路径（快速上手 Paimon 替代 Kafka + HBase 架构）：01 → 03 → 04 → 05
架构对比路径（理解 Paimon 与 Hudi/Iceberg 的本质差异）：01 → 02 → 06
深度原理路径（完整理解 Paimon 内部机制）：01 → 02 → 03 → 04 → 05 → 06