一、引言随着实时数仓架构从 Lambda 向 Lakehouse 演进数据湖表格式Table Format成为架构选型的核心决策点。Apache Hudi、Apache Iceberg 和 Apache Paimon 是当前最主流的三个开源方案它们各自从不同的业务场景出发在 ACID 事务、增量处理、流批一体等维度形成了差异化的技术路线。本文将从架构设计、核心机制、适用场景三个层面进行深入对比并结合实时工程实践给出选型建议。二、Apache Hudi 架构Hudi 的核心设计围绕Timeline时间线和Index索引两大机制展开。┌──────────────────────────────────────────────────────────┐ │ Hudi 表架构 │ ├──────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Timeline (元数据时间线) │ │ │ │ [commit1] - [commit2] - [deltacommit3] - ...│ │ │ └─────────────────────────────────────────────────┘ │ │ │ │ │ ┌─────────────┼─────────────┐ │ │ ▼ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ File Group │ │ File Group │ │ File Group │ │ │ │ ┌──────────┐ │ │ ┌──────────┐ │ │ ┌──────────┐ │ │ │ │ │Base File │ │ │ │Base File │ │ │ │Base File │ │ │ │ │ │(Parquet) │ │ │ │(Parquet) │ │ │ │(Parquet) │ │ │ │ │ ├──────────┤ │ │ ├──────────┤ │ │ └──────────┘ │ │ │ │ │Log File 1│ │ │ │Log File 1│ │ │ (COW表) │ │ │ │ │Log File 2│ │ │ └──────────┘ │ │ │ │ │ │ └──────────┘ │ │ (MOR表) │ │ │ │ │ │ (MOR表) │ │ │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Index (记录到文件的映射) │ │ │ │ Record Key - File Group ID │ │ │ │ 类型: Bloom / Simple / HBase / Bucket │ │ │ └─────────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────┘Timeline 机制每次写入操作commit/deltacommit/compaction/clean 等在 Timeline 上记录一个 instant包含时间戳 动作类型 状态requested/inflight/completed这是 Hudi 实现 ACID 和增量查询的基础。索引机制Hudi 通过索引将 Record Key 映射到 File Group实现高效 Upsert。Bloom Filter Index默认索引基于文件级别 Bloom Filter适合大数据量场景。Bucket Index基于 Hash 分桶确定性路由Flink 写入推荐使用。Record-level Index基于 HFile 的全局索引提升 Upsert 效率。Copy-on-Write (COW)Merge-on-Read (MOR)写入方式每次写入重写整个文件追加写入 Log 文件读取性能高直接读 Parquet需合并 Base Log写入延迟较高较低适用场景读多写少写多读少、近实时场景三、Apache Iceberg 架构Iceberg 的核心设计围绕三层元数据树展开实现了计算引擎与存储的完全解耦。┌──────────────────────────────────────────────────────────┐ │ Iceberg 元数据架构 │ ├──────────────────────────────────────────────────────────┤ │ │ │ ┌────────────────────────┐ │ │ │ Catalog │ (记录当前 metadata 指针) │ │ │ table - metadata ptr │ │ │ └───────────┬────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────────────────┐ │ │ │ Metadata File (.json)│ (Schema/Partition/Snapshot) │ │ │ ┌──────────────────┐ │ │ │ │ │ Snapshot List │ │ │ │ │ │ snap-1 - mlist-1 │ │ │ │ │ │ snap-2 - mlist-2 │ │ │ │ │ └──────────────────┘ │ │ │ └───────────┬────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────────────────┐ │ │ │ Manifest List (.avro) │ (本次快照包含哪些 manifest) │ │ │ manifest-1.avro │ │ │ │ manifest-2.avro │ │ │ └───────────┬────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────────────────┐ │ │ │ Manifest File (.avro) │ (数据文件列表 统计信息) │ │ │ >四、Apache Paimon 架构Paimon 的核心设计基于LSM Tree存储结构原生支持流式写入与 Changelog 生产。┌──────────────────────────────────────────────────────────────┐ │ Paimon 表架构 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ Table │ │ ├── Partition (可选) │ │ │ ├── Bucket 0 │ │ │ │ └── LSM Tree │ │ │ │ ├── Level 0: [sorted-run] [sorted-run] │ │ │ │ ├── Level 1: [sorted-run] │ │ │ │ ├── Level 2: [sorted-run] │ │ │ │ └── ... │ │ │ ├── Bucket 1 │ │ │ │ └── LSM Tree │ │ │ └── ... │ │ └── ... │ │ │ │ ┌───────────────────────────────────────────────────┐ │ │ │ Snapshot 管理 │ │ │ │ snapshot-1 - manifest-list - manifests - files│ │ │ │ snapshot-2 - ... │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────┐ │ │ │ Changelog 生产 │ │ │ │ I / -U / U / -D (完整 CDC 语义) │ │ │ └───────────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘LSM Tree 存储数据先写入内存MemTableflush 到 Level 0 形成 sorted-run后台 Compaction 逐层合并。这种结构天然适合高频写入。Merge EnginePrimary Key Table 支持多种合并策略Merge Engine行为适用场景deduplicate保留最新记录去重入湖partial-update多流字段级合并宽表拼接aggregation聚合计算sum/max/min等预聚合first-row保留首条记录去重保留最早Changelog 生产Paimon 可在 Compaction 时生成完整的 changelogI/-U/U/-D下游 Flink 作业可直接消费无需依赖 Kafka 作为中间层。流式读取支持 Streaming ReadFlink 作业可持续消费表的增量变更实现湖上流处理。五、核心特性对比1.特性矩阵特性维度HudiIcebergPaimonACID 事务✅ 基于 Timeline✅ 基于 Snapshot✅ 基于 SnapshotUpsert 能力✅ 索引驱动高效✅ Merge-on-Read / COW✅ LSM Tree 原生支持增量查询✅ 增量 Pull 模型✅ Incremental Scan✅ Streaming ReadTime Travel✅✅✅Schema Evolution✅✅最完善✅Partition Evolution❌✅独有优势❌Hidden Partitioning❌✅❌Changelog 生产⚠️ CDC 格式需额外配置❌ 需外部工具✅ 原生支持流式 Sink✅ Flink/Spark✅ Flink/Spark✅ Flink 原生最优流式 Source⚠️ 支持但非核心路径⚠️ 支持但有限制✅ 原生 Streaming Read存储结构File Group (BaseLog)扁平数据文件LSM Tree小文件治理Clustering CompactionCompaction RewriteCompaction自动引擎兼容性Spark/Flink/Hive/Presto/TrinoSpark/Flink/Trino/Presto/Dremio/StarRocks 等Flink最佳/Spark/Hive/Trino2.写入流程对比┌─────────────── 写入流程对比 ──────────────────────────────┐ │ │ │ 【Hudi COW】 │ │ Record → Index Lookup → 定位 File Group → 读取原文件 │ │ → 合并 → 写入新 Base File → 更新 Timeline │ │ │ │ 【Hudi MOR】 │ │ Record → Index Lookup → 定位 File Group → 追加 Log File │ │ → 更新 Timeline (后台异步 Compaction 合并到 Base File) │ │ │ │ 【Iceberg COW】 │ │ Record → 写入新 Data File → 生成新 Manifest │ │ → 生成新 Manifest List → 生成新 Snapshot → 原子提交 │ │ │ │ 【Iceberg MOR (v2)】 │ │ Delete → 写入 Delete File (position/equality) │ │ → 读取时合并 Data File Delete File │ │ │ │ 【Paimon Primary Key Table】 │ │ Record → Hash 到 Bucket → 写入 MemTable │ │ → Flush 到 Level 0 → 后台 Compaction 合并各层 │ │ → 生成 Changelog → 更新 Snapshot │ │ │ └───────────────────────────────────────────────────────────┘3.读取流程对比快照读增量读流式读Hudi读取最新 commit 的文件MOR 需 merge指定 beginTime/endTime 范围Flink Source 持续拉取Iceberg读取指定 Snapshot 对应的文件对比两个 Snapshot 的差异文件Flink Source 监控新 SnapshotPaimon读取最新 Snapshot读取两个 Snapshot 间的 changelogFlink Source 持续消费 changelog六、场景选型建议┌────────────────────────────────────────────────────────────────┐ │ 场景匹配推荐 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ CDC 增量入湖 (MySQL/PG binlog → 湖) │ │ ├── 推荐: Hudi ★★★ (索引驱动 Upsert, 成熟的 CDC 生态) │ │ ├── 可选: Paimon ★★☆ (LSM 天然适合高频写入) │ │ └── 一般: Iceberg ★★☆ (v2 支持但 Upsert 效率相对偏弱) │ │ │ │ 实时流式数仓 (Flink 流处理链路) │ │ ├── 推荐: Paimon ★★★ (原生 Changelog, 流读写最优) │ │ ├── 可选: Hudi ★★☆ (MOR Flink 可用) │ │ └── 一般: Iceberg ★★☆ (Flink 集成持续改进中) │ │ │ │ 大规模批处理分析 (多引擎 Ad-hoc 查询) │ │ ├── 推荐: Iceberg ★★★ (引擎无关, 元数据管理强) │ │ ├── 可选: Hudi ★★☆ (COW 表读取性能好) │ │ └── 一般: Paimon ★★☆ (非 Flink 引擎支持在追赶中) │ │ │ │ 多流拼接宽表 (多数据源字段级合并) │ │ ├── 推荐: Paimon ★★★ (partial-update merge engine) │ │ ├── 可选: Hudi ★★☆ (Payload 自定义合并) │ │ └── 一般: Iceberg ★☆☆ (需应用层处理) │ │ │ │ 数据湖上的维表 Join │ │ ├── 推荐: Paimon ★★★ (原生 Lookup Join 优化) │ │ ├── 可选: Hudi ★★☆ (支持但配置复杂) │ │ └── 一般: Iceberg ★★☆ (需额外缓存机制) │ │ │ └────────────────────────────────────────────────────────────────┘