本文来源于数据从业者全栈知识库，更多体系化内容请访问知识库。
为什么数据湖格式很重要
传统数据湖的核心问题是”存储廉价但难以管理”：数据写进去就是一堆文件，没有事务保障，更新删除极其困难，还有读写一致性问题。数据湖表格式（Table Format）的出现正是为了解决这些问题——它们在对象存储（如 HDFS、S3）上构建了一层”类数据库”的管理能力。
数据湖格式解决的核心问题：
- ACID 事务：并发读写不再互相干扰
- 时间旅行（Time Travel）：查询历史版本数据
- Schema 演化：安全地增删改表结构
- 增量消费：下游可以高效地只读取变更数据
三大格式速览
| 格式 | 诞生背景 | 主导公司 | 核心定位 |
|---|---|---|---|
| Apache Hudi | 2016 年 Uber，解决大规模 Upsert 问题 | Uber、Onehouse | 流式增量处理、记录级更新 |
| Apache Iceberg | 2017 年 Netflix，解决 Hive 表格式的扩展性问题 | Netflix、Apple、Tabular | 可靠的大规模表管理、多引擎兼容 |
| Apache Paimon | 2022 年阿里巴巴（原 Flink Table Store） | 阿里巴巴、字节跳动 | 流批一体、与 Flink 深度集成 |
Delta Lake 由 Databricks 主导，与 Spark 深度绑定，在 Databricks 平台上体验最佳。本文聚焦开源中立的三大格式，Delta Lake 作为参考项目不做重点展开。
核心特性对比
功能特性矩阵
| 特性 | Hudi | Iceberg | Paimon |
|---|---|---|---|
| ACID 事务 | 支持（乐观并发控制） | 支持（乐观并发控制） | 支持（LSM-Tree 保障） |
| 时间旅行 | 支持（Timeline） | 支持（Snapshot） | 支持（Snapshot） |
| Schema 演化 | 部分支持 | 完整支持（最强） | 支持 |
| 记录级 Upsert | ★★★★★（原生设计） | ★★★（需 Merge-on-Read） | ★★★★（主键表原生支持） |
| 增量读取 | 支持（Incremental Query） | 支持（Incremental Query） | 支持（Changelog 模式） |
| 小文件合并 | 自动 Clustering | 自动 Compaction | 自动 Compaction |
| 行级删除 | 支持 | 支持（position delete） | 支持 |
| 多引擎读 | Spark/Flink/Presto/Hive | Spark/Flink/Trino/Hive（最佳） | Spark/Flink 为主 |
| 流批一体 | 部分支持 | 部分支持 | ★★★★★（核心设计目标） |
元数据与文件组织
| 维度 | Hudi | Iceberg | Paimon |
|---|---|---|---|
| 元数据存储 | Timeline（.hoodie 目录） | Manifest Files + Snapshot | Manifest Files + Snapshot |
| 文件格式 | Parquet / ORC / Avro | Parquet / ORC / Avro | Parquet / ORC |
| 表类型 | MOR（Merge on Read）/ COW（Copy on Write） | 统一格式，写时区分策略 | 主键表 / 追加表 |
| 元数据扩展性 | 中等（Timeline 文件数量多时有瓶颈） | 强（Metadata Table 优化） | 中等 |
详细维度分析
1. 设计理念
Apache Hudi
Hudi 的出发点是增量处理管道。Uber 面对的是每天数十亿条骑行记录的 Upsert 需求——既要高效写入新数据，又要能高效修改历史记录（如订单状态更新）。Hudi 的 Timeline 机制记录了表的所有操作历史，这让增量消费变得非常自然。
Hudi 提供两种表类型：
- Copy-On-Write（COW）：写入时立即合并，读取性能高，写入代价大
- Merge-On-Read（MOR）：写入快（只写 delta log），读取时合并，适合写多读少场景
Apache Iceberg
Iceberg 的出发点是可靠的大规模表格式。Netflix 遇到的问题是 Hive 的分区设计导致元数据膨胀、并发写入不安全。Iceberg 重新设计了元数据层，用 Manifest 文件树状结构管理数据文件，天然支持分区演化和隐式分区。
Iceberg 的最大优势是引擎无关性：它对 Spark、Flink、Trino、Hive、Impala 都提供了原生支持，是多引擎共享数据湖的最佳选择。
Iceberg 支持最完整的 Schema 演化操作：添加列、删除列、重命名列、修改列类型、列重新排序——这些操作都是安全的，不会导致历史数据损坏。这是 Hudi 和 Paimon 目前还不能完全匹敌的。
Apache Paimon
Paimon 脱胎于 Apache Flink 社区（原名 Flink Table Store），其核心目标是流批一体数据湖。它借鉴了 LSM-Tree（Log-Structured Merge-Tree）的数据结构，天然支持高频率的流式写入和高效的批量读取。
Paimon 与 Flink 的集成是三者中最深的：你可以用 Flink SQL 直接将 Kafka 中的 CDC 数据实时写入 Paimon 表，同时 Spark 可以对同一张表做离线分析。这正是实时数仓（Real-time Data Warehouse）的典型架构。
LSM-Tree 对写入非常友好：所有写入先到内存缓冲区（MemTable），再批量刷写到磁盘（L0 层），后台定期做 Compaction。这使 Paimon 在高并发、高频率流式写入场景下性能远超 Iceberg 和 Hudi（COW 模式）。
2. 与计算引擎的集成
| 计算引擎 | Hudi 支持 | Iceberg 支持 | Paimon 支持 |
|---|---|---|---|
| Spark | 原生，成熟 | 原生，最成熟 | 支持，Spark 3.x |
| Flink | 支持，功能略少 | 支持，功能较完整 | 深度集成，最优先支持 |
| Presto/Trino | 支持 | 支持，最佳 | 支持，仍在完善 |
| Hive | 支持（ROH） | 支持 | 支持 |
| StarRocks/Doris | 支持 | 支持，最佳 | 逐步支持 |
3. 社区活跃度与成熟度
| 维度 | Hudi | Iceberg | Paimon |
|---|---|---|---|
| 成熟度 | 高（2020 年 Apache 顶级项目） | 高（2020 年 Apache 顶级项目） | 中（2023 年 Apache 顶级项目） |
| GitHub Stars（2024） | ~5.5k | ~6.5k | ~2.5k（快速增长） |
| 主要贡献公司 | Uber、Onehouse | Netflix、Apple、Tabular | 阿里巴巴、字节跳动 |
| 商业化产品 | Onehouse Cloud | Tabular（已被 Databricks 收购） | 阿里云实时数仓 |
| 文档质量 | 较好 | 优秀 | 良好，中文文档友好 |
选型决策树
flowchart TD
A[选择数据湖格式] --> B{主要写入模式?}
B -->|高频流式写入 Flink CDC| C{团队技术栈?}
B -->|批量写入 Spark ETL| D{是否需要多引擎?}
B -->|混合模式| E[考虑 Paimon 流批一体]
C -->|Flink 为主| F[Paimon - 最佳选择]
C -->|Spark 为主| G{是否高频 Upsert?}
G -->|是，记录级更新| H[Hudi COW/MOR]
G -->|否，追加或低频更新| I[Iceberg]
D -->|是，Spark/Trino/Hive 共用| J[Iceberg - 引擎兼容最好]
D -->|否，Spark 单引擎| K{Schema 演化需求?}
K -->|频繁变更表结构| L[Iceberg - Schema 演化最强]
K -->|结构稳定| M[Hudi 或 Iceberg 均可]
国内采用情况
国内大厂在数据湖格式的选择上呈现明显的差异化：
| 公司 | 主要格式 | 典型场景 |
|---|---|---|
| 阿里巴巴 | Paimon（主推）+ Iceberg | 实时数仓、Flink CDC 数据同步 |
| 字节跳动 | Hudi（历史）→ Paimon（新项目） | 推荐系统特征、用户行为数仓 |
| 美团 | Hudi | 骑手/用户轨迹数据 |
| 滴滴 | Hudi + Iceberg | 出行数据分析 |
| 快手 | Iceberg | 视频元数据管理 |
| 腾讯 | 多格式并存 | 各业务线自选 |
2023 年后，Paimon 在国内新项目中的采用率快速上升，主要驱动力是：阿里巴巴在 Apache Flink 社区的强势推进、Paimon 对中文文档和社区的重视，以及流批一体架构在国内实时数仓场景的强需求。
选型建议总结
三句话记住选型原则：
- Flink 实时写入 + 国内团队 → 优先 Paimon
- 多引擎共享 + Schema 频繁变更 → 优先 Iceberg
- Spark 生态 + 高频 Upsert → 优先 Hudi
按团队情况推荐
情况一：全新项目，Flink 为主要写入引擎
选择 Paimon。Flink + Paimon 是当前国内实时数仓的最佳实践组合，有完整的架构参考文档。
情况二：Spark 主导的离线数仓，需要支持多查询引擎
选择 Iceberg。Iceberg 在 Spark + Trino + Hive 混用场景下的兼容性是最好的，且 Schema 演化能力最强。
情况三：已有 Hudi 生产环境
无需迁移。Hudi 在 Upsert 场景下依然是成熟可靠的选择，Onehouse 也在持续推进 Hudi 的功能演进。
三种格式之间的数据无法直接迁移，必须通过重写（re-write）实现。在已有生产数据的情况下，轻易更换格式的代价极高，请谨慎决策。
