Apache Paimon（原名 Flink Table Store）是专为 流批一体 设计的下一代数据湖存储格式。它不仅仅是一个文件格式，更是一个完整的 Streaming Data Lake Platform。
与 Iceberg、Hudi、Delta Lake 等主流湖格式相比，Paimon 的核心差异化在于：原生为 Flink 设计、深度优化高吞吐实时更新、支持毫秒级流式读取。以下从核心概念、架构原理、关键特性及选型对比四个维度详细拆解。
一、 核心概念体系
1. Catalog（元数据目录）
Paimon 的元数据管理层，负责管理数据库、表、分区、Schema 演进等信息。
- Filesystem Catalog：默认模式，元数据直接存储在 HDFS/S3/OSS 的文件系统中，无需外部依赖，适合轻量级或测试场景。
- Hive Metastore Catalog：复用现有 Hive HMS，实现与 Spark、Presto、Trino 等引擎的无缝互通，生产环境推荐。
- JDBC Catalog：将元数据存入 MySQL/PostgreSQL，适合对元数据查询性能要求高或需要事务性元数据管理的场景。
⚠️ 注意：Catalog 的选择决定了多引擎兼容性和运维复杂度。生产环境强烈建议使用 Hive 或 JDBC Catalog，避免 Filesystem Catalog 在并发写入时的元数据冲突风险。
2. Table Types（表类型）
Paimon 根据主键和数据更新语义，将表分为三类，这是理解其行为的关键：
| 表类型 | 主键 | 更新机制 | 适用场景 | 核心特点 |
|---|---|---|---|---|
| Append-Only | 无 | 仅追加 | 日志、事件流、ODS 层 | 写入吞吐最高，支持流读，类似 Kafka+Parquet |
| Primary Key (LSM) | 有 | LSM-Tree + Compaction | CDC 入湖、维表、DWD/DWS | 支持 Upsert/Delete，点查快，状态可持久化 |
| Partial Update | 有 | 按字段合并 | 多流 Join、宽表拼接 | 不同流更新同一行的不同列，自动合并 |
- LSM Tree 结构：PK 表的底层存储基于 LSM-Tree（Log-Structured Merge-Tree），而非传统的 B+Tree 或纯列存。这使得 Paimon 在高并发写入时保持 O(1) 复杂度，但读取时需经过多层 Merge，因此 Compaction 策略至关重要。
- Changelog Produce ：PK 表可配置
changelog-producer参数（none/input/lookup/full-compaction），决定下游流读时能否获取完整的 +I/-U/+U/-D 变更链。这对 Flink 流式 ETL 的正确性至关重要。
3. Snapshot & Tag & Branch（版本管理三件套）
Paimon 实现了类 Git 的数据版本控制：
- Snapshot：每次 Commit 生成的不可变快照，包含该时刻所有数据文件的引用。支持 Time Travel 查询和历史回滚。
- Tag：指向特定 Snapshot 的命名指针，不会随过期清理而删除。用于标记重要业务节点（如"双11零点数据"）、跨作业对齐消费位点。
- Branch：从某个 Tag 创建的独立数据分支，拥有独立的 Snapshot 序列。支持数据隔离开发、A/B 测试、Schema 验证，不影响主干数据。
4. Bucket（数据分桶）
PK 表的数据组织单元，直接影响并行度和查询性能：
- Fixed Bucket ：建表时指定固定桶数（如
bucket=16）。数据按主键 Hash 分配到桶，每个桶对应一个 Writer。优点 ：查询稳定；缺点：扩容需重写数据。 - Dynamic Bucket ：设置
bucket=-1，系统根据数据量自动扩缩桶数。优点 ：弹性伸缩，避免小文件；缺点：流读时可能因桶分裂导致短暂乱序。 - Unaware Bucket：Append-Only 表默认模式，无桶概念，Writer 自由写入，由 Compaction 整理文件。
二、 核心架构原理
1. 写入路径
#mermaid-svg-uaaB4oqOCplgp8n2{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-uaaB4oqOCplgp8n2 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-uaaB4oqOCplgp8n2 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-uaaB4oqOCplgp8n2 .error-icon{fill:#552222;}#mermaid-svg-uaaB4oqOCplgp8n2 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-uaaB4oqOCplgp8n2 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-uaaB4oqOCplgp8n2 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-uaaB4oqOCplgp8n2 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-uaaB4oqOCplgp8n2 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-uaaB4oqOCplgp8n2 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-uaaB4oqOCplgp8n2 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-uaaB4oqOCplgp8n2 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-uaaB4oqOCplgp8n2 .marker.cross{stroke:#333333;}#mermaid-svg-uaaB4oqOCplgp8n2 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-uaaB4oqOCplgp8n2 p{margin:0;}#mermaid-svg-uaaB4oqOCplgp8n2 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-uaaB4oqOCplgp8n2 .cluster-label text{fill:#333;}#mermaid-svg-uaaB4oqOCplgp8n2 .cluster-label span{color:#333;}#mermaid-svg-uaaB4oqOCplgp8n2 .cluster-label span p{background-color:transparent;}#mermaid-svg-uaaB4oqOCplgp8n2 .label text,#mermaid-svg-uaaB4oqOCplgp8n2 span{fill:#333;color:#333;}#mermaid-svg-uaaB4oqOCplgp8n2 .node rect,#mermaid-svg-uaaB4oqOCplgp8n2 .node circle,#mermaid-svg-uaaB4oqOCplgp8n2 .node ellipse,#mermaid-svg-uaaB4oqOCplgp8n2 .node polygon,#mermaid-svg-uaaB4oqOCplgp8n2 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-uaaB4oqOCplgp8n2 .rough-node .label text,#mermaid-svg-uaaB4oqOCplgp8n2 .node .label text,#mermaid-svg-uaaB4oqOCplgp8n2 .image-shape .label,#mermaid-svg-uaaB4oqOCplgp8n2 .icon-shape .label{text-anchor:middle;}#mermaid-svg-uaaB4oqOCplgp8n2 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-uaaB4oqOCplgp8n2 .rough-node .label,#mermaid-svg-uaaB4oqOCplgp8n2 .node .label,#mermaid-svg-uaaB4oqOCplgp8n2 .image-shape .label,#mermaid-svg-uaaB4oqOCplgp8n2 .icon-shape .label{text-align:center;}#mermaid-svg-uaaB4oqOCplgp8n2 .node.clickable{cursor:pointer;}#mermaid-svg-uaaB4oqOCplgp8n2 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-uaaB4oqOCplgp8n2 .arrowheadPath{fill:#333333;}#mermaid-svg-uaaB4oqOCplgp8n2 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-uaaB4oqOCplgp8n2 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-uaaB4oqOCplgp8n2 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-uaaB4oqOCplgp8n2 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-uaaB4oqOCplgp8n2 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-uaaB4oqOCplgp8n2 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-uaaB4oqOCplgp8n2 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-uaaB4oqOCplgp8n2 .cluster text{fill:#333;}#mermaid-svg-uaaB4oqOCplgp8n2 .cluster span{color:#333;}#mermaid-svg-uaaB4oqOCplgp8n2 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-uaaB4oqOCplgp8n2 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-uaaB4oqOCplgp8n2 rect.text{fill:none;stroke-width:0;}#mermaid-svg-uaaB4oqOCplgp8n2 .icon-shape,#mermaid-svg-uaaB4oqOCplgp8n2 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-uaaB4oqOCplgp8n2 .icon-shape p,#mermaid-svg-uaaB4oqOCplgp8n2 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-uaaB4oqOCplgp8n2 .icon-shape .label rect,#mermaid-svg-uaaB4oqOCplgp8n2 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-uaaB4oqOCplgp8n2 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-uaaB4oqOCplgp8n2 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-uaaB4oqOCplgp8n2 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} Buffer
Flush
Commit
Merge
Flink Writer
Memory Table
Data Files + Changelog
Snapshot
Compaction Task
- 数据先写入内存 Buffer，达到阈值后 Flush 为有序的 Data File（ORC/Parquet）。
- PK 表同时生成 Changelog File（记录变更前镜像），供下游流消费。
- Commit 操作原子性地更新 Snapshot 文件，保证 ACID。
- Compaction 异步执行，合并小文件、应用 Delete 标记、生成更高效的读取视图。
2. 读取路径
- Batch Read：扫描最新 Snapshot，过滤无效文件，Merge 各层 Data File 返回结果。支持谓词下推、Projection、Z-Order 索引加速。
- Streaming Read ：
- Append-Only 表：直接增量消费新增 Data File。
- PK 表：根据
changelog-producer配置，消费 Changelog File 或通过 Lookup/Full-Compaction 生成变更流。
3. 与小文件的斗争
Paimon 内置多重机制缓解小文件问题：
- Writer 端：Buffer 攒批、动态桶、自适应 Flush 阈值。
- Compaction：Universal Compaction 策略，平衡写放大、读放大和空间放大。
- Snapshot Expiration：自动清理过期 Snapshot 及其关联的孤立文件。
- Orphan File Clean：定期扫描并删除未被任何 Snapshot 引用的垃圾文件。
三、 关键特性详解
1. 真正的流式 Upsert
不同于 Iceberg 的 Copy-on-Write 或 Merge-on-Read 在读取时处理更新，Paimon 在写入时就通过 LSM-Tree 完成 Merge，并产出标准化 Changelog。这意味着下游 Flink 作业可以直接将其作为 Source 进行流式 ETL，无需额外去重或关联历史状态。
2. 高效的部分更新
在多流拼接宽表场景中，传统方案需维护巨大状态或使用复杂 Join。Paimon 的 Partial Update 表允许不同流只更新部分字段，系统在 Compaction 时自动合并。配合 sequence.field 解决乱序覆盖问题，大幅简化 ETL 逻辑。
3. Schema Evolution
支持添加列、删除列、重命名列、修改列类型（有限制）。Schema 变更记录在 Snapshot 中，历史数据读取时自动适配新 Schema，无需重写数据。
4. 与 Flink 的深度集成
- CDC 直写：支持 MySQL/PG/Oracle CDC 一键入湖，自动同步 Schema 变更。
- Lookup Join：PK 表可作为 Flink SQL 的维表，利用本地缓存 + Bloom Filter 实现高性能点查。
- Temporal Join：支持基于时间版本的关联查询。
- Flink Checkpoint 对齐：写入与 Flink CP 绑定，保证端到端 Exactly-Once。
四、 Paimon vs 其他湖格式选型参考
| 维度 | Apache Paimon | Apache Iceberg | Apache Hudi | Delta Lake |
|---|---|---|---|---|
| 核心定位 | 流批一体存储，Flink 优先 | 通用分析型湖格式，多引擎均衡 | 近实时数据湖，Upsert 强 | Spark 生态深度绑定 |
| 实时更新 | ⭐⭐⭐⭐⭐ (LSM + Changelog) | ⭐⭐⭐ (MoR/COW) | ⭐⭐⭐⭐ (MOR/COW) | ⭐⭐⭐ (Delta Log) |
| 流读能力 | ⭐⭐⭐⭐⭐ (原生 Changelog) | ⭐⭐⭐ (Incremental Scan) | ⭐⭐⭐⭐ (CDC Stream) | ⭐⭐ (CDF) |
| Flink 集成 | ⭐⭐⭐⭐⭐ (原生) | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| Spark 集成 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Trino/Presto | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 小文件治理 | 内置完善 | 依赖外部 Rewrite | 内置 Clustering | 内置 Optimize |
| 最佳场景 | Flink 为主、高频更新、流式 ETL | 多引擎分析、离线数仓替代 | 近实时报表、CDC 入湖 | Spark 为主、ML/AI 场景 |
💡 实践建议与避坑指南
- 不要盲目选 PK 表：如果数据只有追加没有更新，务必用 Append-Only 表。PK 表的 LSM 结构带来额外 Compaction 开销和读取 Merge 成本。
- 合理设置 Changelog Producer ：
- 下游仅需最新值 →
none（最省资源） - 上游是 CDC 且保留完整变更 →
input（零额外开销） - 需要完整变更但上游不完整 →
lookup（牺牲写入换读取） - 极端要求一致性 →
full-compaction（最重，慎用）
- 下游仅需最新值 →
- Compaction 必须独立 ：生产环境中，切勿将 Compaction 与写入作业耦合。应启动独立的 Dedicated Compaction Job，避免 Compaction 抖动影响写入延迟和 Checkpoint 稳定性。
- 监控先行：部署 Paimon Metrics Reporter，重点关注：Snapshot Commit Duration、Compaction Pending Tasks、Small File Count、Changelog Generate Rate。这些是健康度的生命线。
- 版本选择：Paimon 迭代极快，0.6→0.8→1.0 差异巨大。生产环境建议使用最新稳定版（截至2026年5月，推荐 1.x 系列），并仔细阅读 Upgrade Guide，避免不兼容升级导致数据不可读。
总结 ：Paimon 不是"又一个湖格式"，而是为流式数据仓库而生的存储引擎。如果你的技术栈以 Flink 为核心，且面临高频更新、流式 ETL、实时数仓等挑战，Paimon 是当前最优解。但若以离线分析为主、多引擎混合查询为重，Iceberg 仍是更稳妥的选择。选型永远服务于业务，而非技术潮流。