过去几年，大家聊湖仓，经常会先问一个问题：
我们到底用 Iceberg、Hudi，还是 Delta？
这个问题看起来像技术选型，实际上是架构选择。
因为 Iceberg、Hudi、Delta 不是简单的“存储格式”，它们本质上是在对象存储、HDFS 或云存储之上，给大规模数据表补上数据库能力：事务、快照、并发、Schema 演进、更新删除、时间旅行、元数据管理、表维护、治理接口。
换句话说，湖仓表格式解决的是一个长期痛点：
数据湖便宜、开放、能装，但不够像数据库；
数据仓库可靠、好用、可治理，但成本和开放性经常受限制。
湖仓表格式试图把两边的优点合在一起。
但问题也来了：三个主流方案都能做 ACID，都能做时间旅行，都能支持更新删除，也都在讲开放生态。那到底怎么选？
我的建议很简单：
不要按“哪个最火”选，也不要按“谁的 PPT 最好看”选。
要按现有计算引擎、写入模式、更新需求、成本模型、治理体系和团队运维能力来选。
这篇文章我从架构师视角，把 Iceberg、Hudi、Delta 的来龙去脉、技术原理、最佳实践、商业价值和未来趋势讲透一点。
1. 为什么会有湖仓表格式？
早期数据湖的核心思路很朴素：
数据直接落到 HDFS / S3 / OSS / ADLS / GCS
文件格式用 Parquet / ORC / Avro
计算用 Spark / Hive / Presto / Flink
这个架构的优点很明显：便宜、开放、容量大、引擎多。
但它有一个致命问题：文件不是表。
Parquet 是很好的列式文件格式，但它只关心一个文件内部的数据怎么存。它不负责回答这些问题：
这张表现在有哪些文件？
一次写入是否原子成功？
读任务会不会读到一半新文件、一半旧文件？
字段改名怎么处理？
分区字段变化怎么办？
怎么删除一批数据？
怎么回滚到昨天的版本？
怎么支持多个引擎同时读写？
传统 Hive 表也能维护一些元数据，但在大规模数据湖场景下，它的事务、并发、分区演进、Schema 演进和元数据扩展能力都不够。Iceberg 最早就是为了解决 Hive 表在大规模场景下的可靠性和可维护性问题而出现的；ASF 在 2026 年的项目专访中也提到，Iceberg 最初由 Netflix 开发，用于处理大规模数据集的可靠性和不断演进的数据需求，后来在 2018 年贡献给 Apache 软件基金会。
Hudi 的出发点也类似，但重点更偏实时和增量。Uber 在自己的工程博客里提到，Hudi 是在 Uber 内部大规模数据湖场景下诞生的，目标是把 ACID、索引、增量处理这类数据库能力带进数据湖。
Delta Lake 则来自 Databricks。Databricks 官方文档也明确说，Delta Lake 是 Databricks 默认的数据格式，Databricks 最初开发了 Delta Lake 协议，并持续贡献开源项目。
所以三者的起点可以粗略理解为：
Iceberg：从大规模分析表和多引擎开放性出发
Hudi：从流式写入、Upsert、增量处理出发
Delta：从 Spark / Databricks 湖仓体验和事务可靠性出发
这三个出发点，会影响它们后面的架构哲学。
2. 先拆清楚：文件格式、表格式、Catalog 不是一回事
很多团队选湖仓时，容易把三个概念混在一起。
2.1 文件格式
文件格式负责数据文件内部怎么存。
常见的是：
Parquet
ORC
Avro
比如 Parquet 负责列式存储、压缩、编码、统计信息、谓词下推等。
2.2 表格式
表格式负责“很多文件如何组成一张表”。
Iceberg、Hudi、Delta 属于表格式。
它们关心：
哪些文件属于当前表快照？
哪些文件已经被删除？
一次写入如何提交？
Schema 怎么演进？
更新删除怎么表达？
快照怎么回滚？
并发写入怎么处理？
小文件怎么整理？
2.3 Catalog
Catalog 负责“表在哪里，以及怎么找到表的当前元数据”。
常见 Catalog 有：
Hive Metastore
AWS Glue Catalog
REST Catalog
Unity Catalog
Snowflake Catalog
BigLake / Lakehouse Catalog
自研 Catalog
Iceberg 近几年很重要的趋势就是 REST Catalog。Iceberg 官方定义了 REST-based Catalog API，用于管理表元数据和 Catalog 操作。
所以你真正选型时，不是只选：
Iceberg / Hudi / Delta
而是在选一整套组合：
对象存储 + 表格式 + Catalog + 计算引擎 + 治理平台 + 运维体系
这也是为什么同样是 Iceberg，不同公司落地效果差别很大。
3. Iceberg：更像“开放多引擎时代的分析表标准”
Iceberg 的核心定位是：大规模分析表的开放表格式。
Iceberg 官方对自己的描述是：它是面向巨大分析表的高性能格式，把 SQL 表的可靠性和简单性带到大数据里，同时让 Spark、Trino、Flink、Presto、Hive、Impala 等引擎可以安全地同时使用同一批表。
3.1 Iceberg 的核心机制
Iceberg 的关键是快照和元数据树。
一个 Iceberg 表大概由这些东西组成：
Table Metadata
-> Snapshot
-> Manifest List
-> Manifest File
-> Data File / Delete File
每次提交都会产生新的元数据文件和新的快照指针。读任务看到的是某个一致性快照，而不是直接扫描目录里的所有文件。
这解决了数据湖里非常经典的问题：
目录里有一堆文件，不知道哪些是当前有效文件；
写入过程中读任务可能读到半成品；
文件删除、追加、覆盖没有事务边界；
多个任务并发写容易互相覆盖。
Iceberg 通过快照让读写变得更像数据库表。
3.2 Iceberg 的优势
Iceberg 最大的优势是开放生态和多引擎支持。
如果你的公司不是单一 Spark 或单一 Databricks，而是同时有：
Spark
Flink
Trino
Presto
Athena
Snowflake
BigQuery
Databricks
Doris / StarRocks
那 Iceberg 很容易成为候选方案。
云厂商也明显在往 Iceberg 靠。AWS S3 Tables 是 fully managed Apache Iceberg tables，官方说它会自动处理数据湖和湖仓表管理的运维负担，并支持 Spark、Trino、Athena、Redshift 等 Iceberg 兼容引擎。
Google BigQuery 的 Apache Iceberg managed tables 也强调，它们用开放 Iceberg 表格式，在客户自有存储桶里存数据，同时支持和开源及第三方计算引擎共享同一份数据。
Snowflake 也支持 Apache Iceberg tables，并提供 Snowflake-managed 和 external catalog 等模式。
从行业趋势看，Iceberg 已经不只是一个开源表格式，而是逐渐成为云厂商和多引擎生态之间的“共同语言”。
3.3 Iceberg 的技术亮点
Iceberg 有几个非常适合企业级湖仓的能力。
第一是隐藏分区。
传统 Hive 分区经常要求用户理解分区字段，比如：
dt = 2026-05-08
hour = 10
Iceberg 支持隐藏分区，用户查询时不需要显式理解底层分区设计，也能让引擎利用分区裁剪。Databricks 的 Iceberg 文档也把 schema evolution、time travel、hidden partitioning 列为 Iceberg 的关键能力。
第二是分区演进。
业务早期可能按天分区，后来数据量上来后要按小时分区。传统 Hive 分区变更会非常痛苦，而 Iceberg 可以在同一张表里维护不同历史阶段的分区规范。
第三是 Schema 演进。
Iceberg 用字段 ID 管理 Schema 演进，比单纯依赖字段名或位置更安全。
第四是行级更新删除。
Iceberg v2 增加了 row-level updates and deletes，可以通过 delete files 表达对不可变数据文件里的行级删除；Iceberg spec 也明确说明 v2 增加了 row-level deletes，v3 又加入 deletion vectors。
第五是分支和标签。
Iceberg 支持 branches 和 tags，它们是指向快照的命名引用，并拥有独立生命周期。这个能力特别适合审计、回溯、数据验证和 Write-Audit-Publish 流程。
3.4 Iceberg 的短板
Iceberg 不是没有问题。
它的弱点主要在几个方面。
第一，更新写入和流式 Upsert 的体验不一定是最轻的。
如果你是大量 CDC、频繁更新、分钟级增量消费，Iceberg 能做，但不一定是最天然的方案。
第二，Catalog 选择很关键。
Iceberg 的开放性很强，但也意味着 Catalog、权限、锁、元数据维护、压缩、清理都需要设计好。用得好是开放标准，用不好就是组件拼装。
第三，不同引擎支持特性不完全一致。
比如某些引擎支持 Iceberg 表读取，但对 row-level delete、MERGE、branching、v2/v3 特性的支持可能不完整。选型时一定不能只看“支持 Iceberg”，要看支持到什么程度。
4. Hudi：更像“把数据库更新能力搬到数据湖”
Hudi 的核心定位是：支持高效 Upsert、Delete、增量处理和近实时数据湖。
Hudi 官方文档说，Hudi 把表、事务、高效 upserts/deletes、高级索引、数据摄取服务、聚簇和压缩等数据库能力带到数据湖，同时支持开放文件格式。
如果你的场景是：
CDC 入湖
订单状态频繁更新
用户画像不断修正
近实时数据同步
需要增量消费变化数据
那 Hudi 会非常值得认真评估。
4.1 Hudi 的核心机制
Hudi 的核心概念是 Timeline。
Hudi 会把每一次表操作记录为一个 instant，比如：
commit
deltacommit
compaction
clean
rollback
savepoint
Hudi 的并发控制文档里提到，它通过把 commits 原子发布到 timeline 来保证 atomic writes，并且每个 commit 都带有 instant time。
这套 timeline 机制让 Hudi 很擅长回答：
从某个时间点之后有哪些记录发生变化？
这次写入是不是成功提交了？
上一次 commit 是什么？
哪些文件需要 compaction？
哪些旧文件可以 clean？
4.2 Hudi 的两种表类型：COW 和 MOR
Hudi 有两种核心表类型。
第一种是 Copy-on-Write，简称 COW。
更新时重写 Parquet 文件
读性能好
写放大较高
适合读多写少、批量更新
第二种是 Merge-on-Read，简称 MOR。
新变化先写入 delta log
读时合并 base file + log file
写入更快
读时可能有 merge 成本
需要 compaction
适合高频写入、近实时入湖
Hudi 官方文档明确说，MOR 是 COW 的超集，会把 incoming upserts 写到 row-based delta log，再在查询时把 delta log 和最新 base file 合并，以平衡读写放大，并支持近实时数据。
4.3 Hudi 的优势
Hudi 最大的优势是写入和增量。
Hudi 官方文档说，incremental queries 可以获取某个 commit time 之后变化的最新记录，适合用来构建增量数据管道，而且相比批处理扫描只处理变化记录，效率可以大幅提升。
Hudi 也支持 CDC 查询，可以输出某个时间范围内插入、更新、删除的变化记录，甚至包含 before/after images 和操作类型。
这对数据平台非常有价值。
很多公司做湖仓时，真正痛苦的不是全量分析，而是：
如何把 MySQL / Kafka / Binlog 的变化高效同步进湖？
如何避免每天全量重刷大表？
如何把上游变化继续增量传给下游？
如何支持准实时用户画像和指标？
Hudi 在这些场景上的设计是非常直接的。
4.4 Hudi 的索引能力
Hudi 从设计上就很重视索引。
Hudi 的索引文档说，索引是辅助数据结构，用来快速定位记录，避免读取不必要的数据；由于 Hudi 针对 mutable change streams 做了优化，索引从一开始就是 Hudi 设计的重要组成部分。
Hudi 还有 metadata table。官方文档提到，Hudi 维护一个 scalable metadata table，里面有 files、column stats 等索引；索引子系统依赖 metadata table，从而提升定位记录和数据跳过能力。
Hudi 1.1.1 还引入 table version 9 和 index versioning，并支持 partitioned record index，用于在超大分区数据集里加速查找。
这说明 Hudi 的方向是越来越像“数据湖上的存储引擎”，而不只是一个表格式。
4.5 Hudi 的短板
Hudi 的短板也很明显。
第一，运维复杂度更高。
MOR、compaction、cleaning、clustering、metadata table、index，这些能力很强，但也意味着要维护更多表服务。
第二，多引擎生态相比 Iceberg 的“标准感”略弱。
Hudi 支持 Spark、Flink、Trino、Presto、Hive 等，但业界很多云厂商和开放湖仓互操作场景，默认会优先围绕 Iceberg 展开。
第三，读性能和写性能之间需要持续调参。
MOR 表如果 compaction 没做好，读性能可能下降；COW 表写放大又可能偏高。
所以 Hudi 很适合写入复杂、增量诉求强的团队，但它要求团队懂表服务和运维。
5. Delta Lake：更像“Spark/Databricks 体系里的湖仓事务层”
Delta Lake 的核心定位是：在数据湖之上提供 ACID 事务、可扩展元数据、流批一体和可靠数据管理。
Delta Lake 官方文档说，它是一个开源项目，可以在 S3、ADLS、GCS、HDFS 等现有数据湖之上构建 Lakehouse，并提供 ACID transactions、scalable metadata handling、streaming and batch unification。
如果你是 Databricks 或 Spark 重度用户，Delta 往往是最顺手的方案。
5.1 Delta 的核心机制
Delta 的核心是 transaction log。
每个 Delta 表下面都有一个：
_delta_log
里面记录每次提交的 JSON / checkpoint 元数据。
读任务通过 transaction log 得到当前版本的有效文件集合，而不是直接扫描目录。
Delta 通过 optimistic concurrency control 提供写入事务保证。官方文档说明，Delta Lake 在读写之间提供 ACID transaction guarantees；多个 writer 可以同时修改表，读者看到一致快照。
5.2 Delta 的优势
Delta 最大的优势是 Spark / Databricks 体验成熟。
常见能力包括：
ACID
MERGE / UPDATE / DELETE
Time Travel
Schema Enforcement
Schema Evolution
Streaming Source / Sink
Change Data Feed
OPTIMIZE
ZORDER
Liquid Clustering
Deletion Vectors
Column Mapping
UniForm
Delta 官方文档说，Delta Lake 提供 schema enforcement、time travel、upserts and deletes 等能力，其中 upserts/deletes 支持 MERGE、UPDATE、DELETE，可用于 CDC、SCD 等场景。
Delta Lake 的 batch 文档也说明，Delta 支持 Spark 大多数读写 API，并且从 3.0 开始支持 Spark DataSourceV2 和 Catalog API 集成。
5.3 Liquid Clustering 和 Deletion Vectors
Delta 近几年一个很重要的方向是优化数据布局和更新删除成本。
Liquid clustering 允许在 Delta 表上启用 CLUSTER BY，并通过 OPTIMIZE 增量聚簇数据；官方文档也说明，它不兼容传统 partitioning 或 ZORDER，一旦启用会开启 Clustering 和 DomainMetadata 表特性。
Delta 的 deletion vectors 则用于减少删除或更新时的数据重写成本。虽然用户最终感知的是 UPDATE / DELETE / MERGE 更快，但架构上本质是在行级删除表达和文件重写之间做权衡。
5.4 UniForm：Delta 在开放格式上的回应
Delta 过去常被认为更偏 Databricks/Spark 生态。为了提升开放互操作，Delta 推出了 UniForm。
Delta 官方文档说，Delta Universal Format 允许用 Iceberg 和 Hudi 客户端读取 Delta 表；它利用三种格式都由 Parquet 数据文件和元数据层组成的事实，异步生成 Iceberg 元数据，从而让 Iceberg 客户端像读 Iceberg 表一样读取 Delta 表。
Delta 官网也强调，Delta Lake 支持 Spark、PrestoDB、Flink、Trino、Hive、Snowflake、BigQuery、Athena、Redshift、Databricks、Azure Fabric 等引擎，并且通过 UniForm 让 Iceberg 和 Hudi 客户端读取 Delta 表。
这说明 Delta 也在往开放湖仓方向走。
5.5 Delta 的短板
Delta 的主要短板在于生态重心。
如果你的公司已经深度使用 Databricks，那 Delta 很顺。但如果你的计算生态是 Trino、Flink、Snowflake、BigQuery、Athena、Doris 混合，而且不希望被某个平台强绑定，Iceberg 的标准化优势可能更明显。
另外，Delta 的很多高级能力在 Databricks 平台内体验最好，开源 Delta 与商业平台能力之间存在体验差异。这不是说不能用，而是选型时要看清楚你用的是哪个版本、哪个 runtime、哪个 catalog 和哪个 connector。
6. 三者对比：不要看宣传，要看工作负载
下面这张表是架构选型时真正应该看的。
| 维度 | Iceberg | Hudi | Delta |
|---|---|---|---|
| 核心强项 | 开放多引擎、分析表、Catalog 标准化 | Upsert、CDC、增量处理、近实时写入 | Spark/Databricks 体验、事务、流批一体 |
| 典型场景 | 多引擎查询、云湖仓、开放数据平台 | CDC 入湖、用户画像、订单状态更新、近实时数仓 | Databricks/Spark 湖仓、交互式分析、稳定事务表 |
| 更新删除 | v2 delete files，v3 deletion vectors | COW / MOR，索引和表服务强 | MERGE/UPDATE/DELETE，Deletion Vectors |
| 流式写入 | 支持，但不是唯一核心卖点 | 非常强，设计上重视增量流 | Spark Structured Streaming 体验好 |
| 多引擎互操作 | 很强 | 中等偏强 | 通过 UniForm 增强 |
| 运维复杂度 | 中等，取决于 Catalog 和维护策略 | 较高，尤其 MOR + compaction + index | Databricks 内较低，自建中等 |
| 治理能力 | 强依赖 Catalog / 云平台 / 外部治理 | Hudi metadata table 和索引强 | Unity Catalog 体系内强 |
| 最适合团队 | 多计算引擎、开放标准优先 | 写入复杂、CDC/Upsert 重 | Databricks/Spark 优先 |
一句话概括：
多引擎开放湖仓：优先看 Iceberg
高频 Upsert / CDC / 增量处理：优先看 Hudi
Databricks / Spark 体系：优先看 Delta
但这只是第一层判断，不能机械套用。
7. 选型第一原则：先看现有计算引擎
你不能脱离计算引擎选表格式。
7.1 如果你是 Databricks 优先
如果公司已经重度使用 Databricks，Delta 通常是默认选择。
Databricks 文档明确说，Delta Lake 是 Databricks 所有操作的默认格式，除非特别指定，Databricks 上的表都是 Delta 表。
这时候硬上 Iceberg 或 Hudi，除非有非常明确的多引擎开放诉求，否则会增加复杂度。
7.2 如果你是 Trino / Presto / Flink / Spark 混合
如果公司同时使用 Trino、Spark、Flink、Presto、Doris、StarRocks，甚至还希望接 Snowflake、BigQuery，那 Iceberg 更值得优先评估。
因为 Iceberg 的定位就是让多个引擎安全使用同一张表。
7.3 如果你是 Flink + CDC 入湖优先
如果你的架构是：
MySQL Binlog / Kafka
-> Flink
-> 湖仓表
-> 下游增量消费
那 Hudi 会很强。
Hudi 的 Flink Quick Start 也明确强调 Flink-Hudi 集成，并说明 Flink 为 Hudi 带来 streaming 能力。Hudi 1.1.x 支持 Flink 1.17 到 2.0.x。
8. 选型第二原则：看写入模式
写入模式决定表格式。
8.1 Append-only
如果数据主要是追加写，比如日志、点击流、埋点、指标明细：
insert append
很少 update/delete
主要做批量查询
Iceberg、Delta、Hudi 都能做。
这类场景不需要过度纠结表格式，重点反而是：
文件大小
分区策略
小文件治理
查询引擎兼容
Catalog 统一
成本控制
8.2 Batch MERGE
如果是每天批量同步维表、订单状态、用户属性：
每天 / 每小时 merge 一批数据
有 update/delete
但频率不是特别高
Delta 和 Iceberg 都比较适合，Hudi COW 也可以。
如果你在 Spark/Databricks 里做大量 MERGE，Delta 的体验会非常顺。
如果你要多引擎共享，Iceberg 更有吸引力。
8.3 高频 Upsert / CDC
如果是持续 CDC：
秒级 / 分钟级写入
主键更新
乱序到达
删除事件
下游还要增量消费
Hudi 往往更贴合。
Hudi 原生就围绕 record key、timeline、incremental query、CDC、index 来设计。
8.4 大规模 Delete
如果你有大量隐私删除、GDPR 删除、用户注销、数据修正：
delete from table where user_id in (...)
要重点评估每种格式的删除实现。
Iceberg v2 有 delete files，v3 有 deletion vectors；Delta 有 deletion vectors；Hudi 有 COW/MOR 和索引体系。不同方式会影响写放大、读放大和维护成本。
9. 选型第三原则：看更新需求，不要只看“能不能 UPDATE”
很多产品都会说自己支持 UPDATE / DELETE / MERGE。
但架构师不能只问“能不能做”，要问：
怎么做？
更新 1 万行要改多少文件？
读的时候要合并多少 delete 文件或 log 文件？
Compaction 多久做一次？
小文件如何治理？
失败了怎么回滚？
并发写会不会冲突？
大体上有几种实现思路。
9.1 Copy-on-Write
更新时重写数据文件。
优点：
读性能好
查询简单
数据文件干净
缺点：
写放大高
频繁更新成本高
适合：
批量更新
读多写少
对查询性能敏感
9.2 Merge-on-Read
更新先写增量日志，查询时或压缩时合并。
优点：
写入快
适合高频更新
近实时友好
缺点：
读时可能有 merge 成本
需要 compaction
运维复杂度高
适合：
CDC
实时入湖
高频 upsert
Hudi MOR 就是典型代表。
9.3 Delete Files / Deletion Vectors
不立刻重写原文件，而是用额外结构记录哪些行被删除。
优点：
减少更新删除时的文件重写
提高 DML 性能
缺点：
读时需要应用删除信息
需要后续优化整理
不同引擎支持程度可能不同
Iceberg 和 Delta 都在这个方向演进。
所以“支持更新删除”只是开始，真正要看的是读写放大和维护成本。
10. 选型第四原则：看成本
湖仓选型里，成本不是只看存储价格。
更准确地说，要看：
存储成本
计算成本
扫描成本
小文件成本
元数据读取成本
Compaction 成本
失败重跑成本
运维人力成本
10.1 小文件成本
流式写入很容易产生小文件。
小文件会带来：
查询慢
元数据膨胀
对象存储 LIST/GET 成本上升
调度变慢
Compaction 频繁
Delta 的 OPTIMIZE 可以做 bin-packing，把小文件合并为更大的文件；官方文档也说明，Delta 可以通过 coalescing small files into larger ones 来提升查询速度。
Hudi 有 compaction、clustering、cleaning 等 table services。
Iceberg 也需要做 rewrite data files、expire snapshots、remove orphan files 等维护。
10.2 读放大与写放大
COW 是写放大更高，读更简单。
MOR 是写更轻，读可能更重。
Delete files / deletion vectors 是减少写放大，但增加读时处理成本。
架构师要按业务场景权衡：
报表查询为主：读性能优先
CDC 入湖为主：写性能优先
交互分析为主：读延迟优先
隐私删除为主：删除成本优先
10.3 运维成本
Hudi 的能力很强，但表服务复杂度也更高。
Iceberg 开放性强，但 Catalog 和多引擎兼容要维护。
Delta 在 Databricks 内部运维成本低，但如果自建开源 Delta，要自己处理更多组件差异。
所以成本评估不能只看云账单，还要看团队维护能力。
11. 选型第五原则：看治理能力
湖仓不是把数据放进对象存储就完了。
生产级湖仓必须考虑：
权限
审计
血缘
数据质量
数据合同
Schema 演进
敏感字段
Catalog
版本管理
生命周期
11.1 Iceberg 的治理重点在 Catalog
Iceberg 的 Catalog 非常关键。
REST Catalog 的意义不只是“能找到表”，而是让 Catalog 成为多引擎统一访问表元数据的标准接口。Snowflake 也支持配置 Iceberg REST catalog integration，用来访问符合开源 Iceberg REST OpenAPI 规范的远程 Catalog。
如果你走 Iceberg 路线，Catalog 就是治理入口。
你需要考虑：
谁能创建表？
谁能提交快照？
谁能删除快照？
权限如何同步？
血缘怎么采集？
多引擎如何一致？
11.2 Hudi 的治理重点在表服务和元数据表
Hudi 的 metadata table、indexes、timeline，让它在表内部管理很多状态。
这对写入、增量和索引很有价值，但治理体系要能看懂这些状态。
比如：
哪个 instant 成功了？
Compaction 是否积压？
Clean 是否误删？
Metadata table 是否健康？
Index 是否和数据一致？
11.3 Delta 的治理重点在平台生态
Delta 在 Databricks / Unity Catalog 体系里治理能力很强。
Unity Catalog 能把表、权限、血缘、审计、共享、AI 数据治理统一起来。但如果你离开 Databricks 平台，治理能力就取决于你怎么组合开源组件和外部平台。
12. 一个实用决策树
如果你不想看太多表格，可以按这个决策树来。
最重要的是，不要追求“理论最优”。
企业选型要追求“组织可落地”。
13. 最佳实践一：先做 POC，不要靠文档选型
湖仓表格式必须用真实数据做 POC。
我建议 POC 至少覆盖这些测试。
1. 追加写入 1 天数据
2. 批量 MERGE 一批数据
3. CDC 连续写入 24 小时
4. 删除一批用户数据
5. 查询最近 7 天数据
6. 查询历史快照
7. Schema 增加字段
8. 字段改名或删除
9. 并发两个任务写同一张表
10. 模拟任务失败和重跑
11. 做 compaction / optimize
12. 接入 BI 查询
13. 接入权限和血缘
14. 测试下游引擎兼容性
要重点看这些指标：
写入吞吐
查询延迟
MERGE 成本
小文件数量
元数据大小
Compaction 耗时
失败恢复
引擎兼容
运维复杂度
如果只拿官方 demo 跑一个 insert，然后就决定全公司上某个格式，后面大概率会踩坑。
14. 最佳实践二：表格式尽量统一，但不要宗教化
统一表格式有好处：
减少学习成本
统一治理
统一运维
统一血缘
统一数据开发规范
但不要宗教化。
有些公司可以这样做：
Bronze 层用 Hudi 接 CDC
Silver / Gold 层用 Iceberg 做多引擎分析
Databricks 内部实验数据用 Delta
也可以这样：
全平台 Iceberg
高频 CDC 表单独 Hudi
或者：
Databricks 内全 Delta
对外通过 UniForm 暴露 Iceberg 读取能力
关键不是“只能用一个”，而是要保证：
主路径清晰
治理能覆盖
血缘不断裂
成本可控
团队能维护
如果混用格式但没有统一 Catalog、血缘和权限，那会变成灾难。
15. 最佳实践三：分层决定表类型
湖仓通常会分层：
Bronze / ODS：原始或准原始数据
Silver / DWD：清洗标准化明细
Gold / DWS / ADS：指标、数据集市、业务消费
不同层的表格式策略可以不一样。
Bronze 层
Bronze 层关注写入和保真。
建议：
保留原始字段
控制 Schema 演进
支持 CDC
支持回放
不要过度清洗
如果是 CDC 重，Hudi 会适合。
如果是 Kafka append-only，Iceberg/Delta 也都没问题。
Silver 层
Silver 层关注标准化和复用。
建议：
统一主键
统一时间字段
统一枚举值
统一数据质量规则
支持增量加工
这里 Iceberg、Delta、Hudi 都可以，但要看你的计算引擎和更新模式。
Gold 层
Gold 层关注查询性能和业务稳定。
建议：
读性能优先
口径稳定
文件大小合理
分区/聚簇合理
快照保留策略清楚
如果是 BI 多引擎查询，Iceberg 很适合。
如果是在 Databricks 内做 BI 和 ML，Delta 很适合。
如果是 Hudi MOR，要确保 compaction 后读性能稳定。
16. 最佳实践四：分区不要拍脑袋
湖仓性能很大程度取决于数据布局。
错误的分区会导致：
小文件爆炸
查询扫描过多
更新成本过高
分区倾斜
历史分区难维护
常见建议：
时间字段是常见分区候选
不要用高基数字段直接分区
不要为了一个低频查询设计全局分区
分区字段要和查询过滤条件匹配
更新频繁的表要小心分区变动
Iceberg 的 hidden partitioning 和 partition evolution 能缓解传统 Hive 分区的问题。
Delta 的 liquid clustering 则提供了另一种数据布局思路，特别适合不想被传统分区锁死的场景。官方文档也建议，如果从 Hive-style partitioning 或 Z-order 转过来，可以考虑把原分区列或 ZORDER 列作为 clustering columns。
Hudi 则需要结合 record key、precombine field、partition path、index 类型一起设计。
17. 最佳实践五：表维护必须产品化
湖仓表不是写完就完了。
生产级表必须有维护任务：
小文件合并
Compaction
Clustering
Snapshot 过期
旧文件清理
孤儿文件清理
Metadata 清理
统计信息刷新
索引维护
这些任务如果靠人肉跑，很快会失控。
建议做成平台能力：
按表级别配置维护策略
按数据量触发维护
按文件数量触发维护
按延迟 SLA 触发维护
自动记录维护结果
异常自动报警
尤其是 Hudi MOR 表，compaction 和 cleaning 策略要非常清楚。
Iceberg 表要管理 snapshot retention 和 orphan files。
Delta 表要管理 VACUUM、OPTIMIZE、ZORDER / liquid clustering。
18. 最佳实践六：Schema 演进要进 CI/CD
湖仓表支持 Schema 演进，不等于可以随便改 Schema。
生产环境最危险的操作包括：
删除字段
字段改名
字段类型变更
主键语义变化
分区字段变化
字段含义变化但名字不变
建议所有 Schema 变更走流程：
提交变更
自动做影响分析
检查下游血缘
检查数据合同
检查 BI 报表
检查 AI 特征
Owner 审批
灰度发布
Delta column mapping 可以让列改名和删除不必重写底层 Parquet 文件，但官方也提醒，启用 column mapping 会升级 Delta table protocol，且协议升级不可逆。
这类能力很强，但更需要治理。
19. 最佳实践七：Catalog 不要后补
很多团队一开始只关心表格式，Catalog 随便选一个。
后面才发现：
表找不到
权限管不住
血缘采不到
多引擎不一致
表迁移困难
跨云访问复杂
Catalog 应该在第一天就设计。
你需要明确：
表命名规范
库命名规范
环境隔离
权限模型
多引擎接入方式
元数据同步策略
审计日志
Catalog 高可用
Catalog 迁移方案
Iceberg REST Catalog 的趋势说明，Catalog 正在从“元数据存储”变成“湖仓控制面”。
Google Cloud 的 Lakehouse for Apache Iceberg 也强调，Iceberg tables 通过 Lakehouse Iceberg REST catalog 管理，并支持 BigQuery、Google managed Spark、Spark、Trino、Flink 等引擎互操作。
20. 最佳实践八：不要忽略 Time Travel 和快照保留成本
时间旅行很好用。
可以：
回滚错误数据
审计历史版本
复现模型训练数据
对账历史报表
排查数据事故
但快照保留不是免费的。
保留太短：
出了问题无法回滚
审计不够
历史复现困难
保留太长：
旧文件无法清理
存储成本上升
元数据膨胀
建议按数据域配置：
核心财务表：保留更久
普通日志表：短保留
AI 训练数据：按实验周期保留
高频更新表：更关注旧文件清理
不要全公司一个策略。
21. 最佳实践九：治理平台要能读懂表格式
湖仓治理不能只停留在 Hive Metastore。
要接入：
表快照
Schema 版本
字段变更
读写任务
Compaction 任务
数据质量结果
权限策略
血缘关系
你用 Iceberg，就要能识别 Iceberg metadata、snapshot、manifest。
你用 Hudi，就要能识别 timeline、commit、metadata table、index。
你用 Delta，就要能识别 transaction log、version、commit operation。
否则治理平台看到的只是表名和字段，真正的湖仓状态它看不见。
22. 对行业的影响：开放表格式正在重塑数据平台
Iceberg、Hudi、Delta 的竞争，本质上不是三种格式之间的竞争，而是数据平台控制权的竞争。
过去企业数据平台的核心控制点在数据库或数仓。
现在越来越多控制点转移到：
开放表格式
对象存储
Catalog
治理平台
多引擎计算
这带来几个变化。
22.1 数据从“平台内资产”变成“开放资产”
以前你把数据放进某个数仓，数据基本被这个数仓锁住。
现在如果数据以开放表格式存储在客户自己的对象存储里，就可以被多个引擎访问。
这会改变采购模式。
企业可以更灵活地组合：
一个引擎做 ETL
一个引擎做 BI
一个引擎做 AI
一个引擎做流处理
22.2 云厂商开始抢 Catalog 和托管表服务
AWS S3 Tables、Google BigQuery Iceberg managed tables、Snowflake Iceberg tables，都说明云厂商已经不满足于只提供对象存储或计算引擎，而是在争夺湖仓表的管理层。
AWS 官方称 S3 Tables 是带内置 Iceberg 支持的 table buckets，专门为表设计，并且相对 self-managed tables 提供更高 TPS 和更好查询吞吐。
这说明表格式本身会越来越“基础设施化”。
22.3 数据仓库和数据湖边界变模糊
传统上：
湖：便宜、开放、灵活
仓：可靠、治理、性能
湖仓表格式让两者边界变模糊。
当数据湖也有 ACID、快照、更新删除、Catalog、治理、数据布局优化后，它就越来越像一个开放的分布式数据库。
23. 商业价值：为什么企业愿意为湖仓表格式买单？
这件事不是技术洁癖，而是能带来真实商业价值。
23.1 降低重复存储成本
过去很多公司有多份数据：
一份在数据湖
一份在数仓
一份在 BI 集市
一份在 AI 平台
开放表格式的目标是让一份数据被多个引擎消费。
这能减少复制、同步和对账成本。
23.2 降低平台锁定风险
如果数据是开放格式，企业更容易切换或组合计算引擎。
这对大公司尤其重要，因为它们不希望核心数据资产被单一厂商锁死。
23.3 提高数据新鲜度
Hudi 这类方案通过增量写入和增量查询，可以减少全量重算，提高数据新鲜度。
对风控、运营、推荐、实时画像来说，数据新鲜度就是业务价值。
23.4 提升治理和审计能力
快照、时间旅行、Schema 版本、血缘、事务日志，让数据平台更容易审计。
这对金融、医疗、政务、跨境数据尤其重要。
23.5 支撑 AI 数据底座
AI 时代，企业需要可追溯、可治理、可复现的数据。
比如：
训练数据用的是哪个快照？
特征表来自哪些上游？
RAG 知识库对应哪个版本？
数据质量是否达标？
敏感数据有没有被模型使用？
没有湖仓表格式和 Catalog，AI 数据治理会非常困难。
24. 未来趋势一：Iceberg 会继续吃下开放湖仓生态
从云厂商动作看，Iceberg 的势能非常强。
AWS、Google、Snowflake、Databricks 都已经以不同方式支持 Iceberg。AWS S3 Tables 和 Google Lakehouse for Apache Iceberg 这类产品，基本是在把 Iceberg 变成云原生湖仓基础设施。
未来 Iceberg 的关键不只是表格式本身，而是：
REST Catalog
多引擎一致性
V3 spec
deletion vectors
branch / tag
跨云互操作
治理集成
Iceberg 官方 release 页面显示，Iceberg 1.10.1 在 2025 年 12 月发布，1.10.0 在 2025 年 9 月发布，项目仍在快速迭代。
25. 未来趋势二：Hudi 会继续向“数据湖数据库”演进
Hudi 不是只想做一个开放表格式，它更像是在对象存储上做数据库存储引擎。
Hudi 1.1 的发布博客提到，1.1 引入 pluggable table format framework，可以把 Hudi 的存储引擎能力扩展到 Iceberg、Delta 等其他表格式，并强调多格式读写兼容。
这代表一个趋势：
表格式之间不只是竞争，也会互相吸收。
Hudi 的方向会继续强化：
索引
增量
CDC
表服务
多格式支持
低延迟写入
26. 未来趋势三：Delta 会继续强化 Databricks 内体验，同时补开放互操作
Delta 在 Databricks 内的体验仍然会非常强。
同时，UniForm 说明 Delta 也意识到开放互操作的重要性。Databricks 文档也提供了让 Iceberg clients 读取 Delta tables 的能力，并说明该能力之前叫 Delta Lake Universal Format。
未来 Delta 的核心方向大概率是：
更强的 Databricks 原生优化
更好的 AI / ML 集成
更强治理能力
通过 UniForm 连接开放生态
27. 未来趋势四：多格式互操作会成为刚需，但别过早迷信
未来企业很可能会有多种表格式共存。
所以 UniForm、Hudi pluggable table format、Iceberg REST Catalog、跨格式读取会越来越重要。
但我要提醒一句：
多格式互操作可以缓解迁移和生态问题，但不要把它当作主写入链路的万能药。
原因很简单：
读取兼容不等于写入兼容
元数据转换不等于语义完全一致
高级特性可能不兼容
不同引擎对同一特性的支持不同
比如 deletion vectors、branching、liquid clustering、record index、CDC 这些高级能力，很难做到跨格式完全等价。
所以生产选型还是要先确定主格式，再考虑互操作。
28. 未来趋势五：湖仓表格式会和 AI 平台深度绑定
AI 对数据底座提出了更高要求。
AI 不是只需要更多数据，而是需要：
可信数据
可追溯数据
可复现数据
可治理数据
可授权数据
可回滚数据
湖仓表格式刚好提供这些基础能力。
比如：
Time Travel：复现实验数据
Snapshot：锁定训练数据版本
Schema Evolution：支持特征演进
Lineage：追踪模型输入
Catalog：管理权限和语义
ACID：保证数据一致性
未来企业 AI 平台如果没有稳定的湖仓表格式，很多治理问题会非常难处理。
29. 我的最终建议
如果你是架构师，我建议你这样做选型。
29.1 先定主路线
不要一开始就三种都上。
优先选一个主表格式：
Databricks/Spark 主导：Delta
多引擎开放主导：Iceberg
CDC/Upsert 主导：Hudi
29.2 再定 Catalog
Catalog 比你想象中重要。
Iceberg 要认真选 REST Catalog / Glue / Snowflake / BigLake / 自研。
Delta 要看 Unity Catalog 或外部治理集成。
Hudi 要看 Hive sync、DataHub sync、metadata table、metaserver 等能力。
29.3 然后做真实 POC
不要用 toy data。
用真实数据、真实写入、真实查询、真实下游、真实成本跑一轮。
29.4 最后才是推广
推广前要准备好：
建表规范
分区规范
Schema 演进规范
Compaction 策略
Snapshot 保留策略
权限规范
血缘规范
故障回滚方案
成本监控
否则上湖仓只是把旧问题换个地方放。
30. 总结：湖仓选型不是选格式，而是选数据平台的未来控制面
Iceberg、Hudi、Delta 都是优秀技术，但它们不是同一种答案。
Iceberg 的关键词是：
开放
多引擎
Catalog
分析表
云湖仓标准
Hudi 的关键词是：
Upsert
CDC
增量
索引
近实时
表服务
Delta 的关键词是：
Spark
Databricks
ACID
流批一体
事务日志
平台体验
所以最终选型不要问：
哪个最好？
要问：
我的计算引擎是什么？
我的写入模式是什么？
我的更新删除频率多高？
我的数据要给哪些引擎用？
我的团队能不能维护表服务？
我的治理体系接得住吗？
我的云成本模型是什么？
我的 AI 和数据产品未来怎么用这些数据？
如果这些问题都回答清楚，选择其实就不难。
我的个人判断是：
如果你要做面向未来的开放湖仓，Iceberg 是非常强的默认候选；
如果你要解决高频更新和 CDC 入湖，Hudi 依然很有竞争力；
如果你已经在 Databricks/Spark 体系内，Delta 是最高效、最顺手的选择。
真正成熟的平台，最后比拼的不是格式名字，而是 Catalog、治理、运维、成本和数据产品化能力。
湖仓的本质不是“湖 + 仓”的营销词，而是把开放存储变成可治理、可交易、可演进、可服务的数据基础设施。
Iceberg、Hudi、Delta 只是入口。真正的难点，是你能不能把它们变成公司级数据平台的稳定底座。
