Delta Lake、Iceberg、Hudi选哪个？——不同场景下怎么选型？

-- Databricks Runtime独有功能
-- AUTO OPTIMIZE：自动合并小文件、优化Z-Ordering
SET spark.databricks.delta.autoOptimize.optimizeWrite = true;
SET spark.databricks.delta.autoOptimize.autoCompact = true;
 
-- Delta Live Tables：声明式ETL（Databricks独有）
CREATE LIVE TABLE fact_orders
AS SELECT * FROM source_orders;

推荐理由：

1. Iceberg的设计目标就是'多引擎兼容'——不仅支持Spark，还原生支持Flink、Trino、Presto、Hive

2. Netflix、Apple、Airbnb等大厂都在用，社区活跃，问题容易找到解决方案

3. Partition Evolution功能独特——可以'不重写数据就调整分区策略'

-- Iceberg在Trino中的使用（完全兼容）
SELECT * FROM iceberg_catalog.sales.orders
WHERE order_date >= DATE '2024-01-01';
 
-- Iceberg在Flink中的使用（完全兼容）
INSERT INTO iceberg_catalog.sales.orders
SELECT * FROM kafka_orders;
 
-- Iceberg在Spark中的使用（完全兼容）
MERGE INTO iceberg_catalog.sales.orders target
USING updates source ON target.order_id = source.order_id
WHEN MATCHED THEN UPDATE *;

典型案例：Netflix用Iceberg作为'统一表格式'——Spark批处理、Flink实时、Trino即席查询都访问同一张Iceberg表。如果用Delta Lake，Trino和Flink的支持都不如Iceberg成熟。

适用场景：多引擎环境、需要Flink+Trino、不想被单一生态绑定

不适用场景：纯Databricks环境、需要Databricks独有功能（如Delta Live Tables）

场景3：CDC实时入湖 → 选Hudi

场景特征：需要从数据库CDC（Change Data Capture）实时同步数据到数据湖，要求'秒级延迟'。

推荐理由：

1. Hudi的设计目标就是'流批一体'——原生支持增量查询、增量ETL、CDC入湖

2. Merge-on-Read模式——实时写入是Append（快），查询时Merge（稍慢），适合'频繁更新'的场景

3. Hudi对'删除标记'的支持最完善——Copy-on-Write和Merge-on-Read双模式，兼顾性能和成本

// Hudi的DeltaStreamer：CDC实时入湖
hoodie.Streamer
  --source-class org.apache.hudi.utilities.sources.MySQLSource,
  --source-ordering-field timestamp,
  --table-type MERGE_ON_READ,
  --op UPSERT
 
// 效果：MySQL的Binlog实时写入Hudi表，
// 延迟约5-10秒（相比Delta Lake的分钟级流）

典型案例：Uber用Hudi做'实时欺诈检测'——司机行为数据实时写入Hudi，Flink实时查询检测异常。如果用Delta Lake，需要用Structured Streaming微批（延迟约1分钟），无法满足'秒级检测'的需求。

适用场景：CDC实时入湖、流批一体、需要秒级延迟

不适用场景：纯批量ETL、不需要实时能力、团队不熟悉流式计算

性能对比：MERGE INTO基准测试

我在出海硬件品牌做过一次性能对比：对同一张500GB的表，执行MERGE INTO（更新10万行）。结果如下：

数据湖格式	MERGE INTO耗时	文件重写数量	存储开销
Delta Lake（Z-Ordering）	12分钟	约50个文件（12%）	约60GB新文件
Iceberg（Sort Order）	15分钟	约50个文件（12%）	约60GB新文件
Hudi（MoR）	8分钟	约20个文件（5%）	约25个日志文件（500MB）
Hive（全量重写）	180分钟	全部4000个文件	500GB新文件

关键发现：

- Delta Lake和Iceberg的性能接近，Delta Lake略快（因为Z-Ordering的优化更好）

- Hudi的Merge-on-Read模式最快，因为只写日志文件，不重写Parquet

- 相比Hive全量重写，数据湖格式有10-15倍的性能提升

成本对比：存储和计算

选型时不仅要考虑性能，还要考虑总成本。

维度	Delta Lake	Apache Iceberg	Apache Hudi
存储格式	Parquet + JSON日志	Parquet + Avro Manifest	Parquet + 日志文件
日志开销	小（每个提交一个JSON）	中（多层Manifest）	大（MoR的日志文件）
小文件问题	AUTO OPTIMIZE自动合并	手动Rewrite Files	手动Compaction
计算成本	低（优化的文件布局）	中（类似Delta Lake）	高（MoR查询时Merge）
运维成本	低（Databricks自动化）	中（手动优化）	高（手动Compaction）

我的经验：在出海硬件品牌，我们评估了'存储+计算+运维'的总成本。Delta Lake的AUTO OPTIMIZE减少了约70%的运维工作量（不需要手动合并小文件）。如果用Iceberg或Hudi，需要专门的工程师定期运行Compaction/Rewrite，人力成本更高。

面试高频追问

追问一：可以在同一集群混用三种格式吗？

技术上可以，但不推荐。我在某短剧出海公司早期试过混用——核心表用Delta Lake，实时表用Hudi，临时表用Iceberg。结果遇到很多问题：

- 元数据管理混乱：三个格式的元数据分别存储，没有统一的Catalog

- 性能调优困难：每个格式的优化技巧不同，团队学习成本高

- 跨格式Join困难：Delta Lake表和Hudi表Join时，优化器无法做统一优化

-- 不推荐：混用三种格式
SELECT *
FROM delta_catalog.sales.orders a
JOIN hudi_catalog.sales.customers b ON a.customer_id = b.customer_id;
 
-- 问题：Spark无法优化跨格式的Join，
-- 因为Delta Lake和Hudi的文件统计信息格式不同
 
-- 推荐：统一格式（如全用Iceberg）
SELECT *
FROM iceberg_catalog.sales.orders a
JOIN iceberg_catalog.sales.customers b ON a.customer_id = b.customer_id;

我的建议：除非有明确的'技术隔离需求'（如'实时表用Hudi、离线表用Delta Lake，物理隔离'），否则统一用一种格式。如果必须混用，用'统一的Catalog（如Hive Metastore或Glue Catalog）'管理所有表，至少在元数据层面统一。

追问二：从Hive迁移到数据湖，Delta Lake和Iceberg哪个更容易？

答案是：迁移成本类似，但'后续维护成本'不同。从Hive迁移的步骤：

-- 第一步：转换现有Parquet文件为Delta Lake（秒级）
CONVERT TO DELTA hive_catalog.sales.orders;
 
-- 或转换为Iceberg（需要重写元数据，分钟级）
ALTER TABLE hive_catalog.sales.orders
SET TBLPROPERTIES ('table_type' = 'ICEBERG');

Delta Lake的CONVERT TO DELTA是'秒级操作'——只创建事务日志，不重写数据。Iceberg的转换需要'注册表到Iceberg Catalog'，时间稍长但也在分钟级。

但'后续维护成本'差异大：Delta Lake有AUTO OPTIMIZE，基本免维护；Iceberg需要手动运行Rewrite Files。如果团队没有专门的'数据湖管理员'，Delta Lake更省心。

追问三：如果未来要切换格式，怎么办？

这是个'避免厂商锁定'的问题。答案是：可以用'XTable'项目（前称Delta-Iceberg-Hudi互转工具）在三种格式间转换。

# XTable：Delta Lake ↔ Iceberg ↔ Hudi 互转
# Delta Lake转Iceberg
delta-to-iceberg --source delta_catalog.sales.orders \
                --target iceberg_catalog.sales.orders
 
# Iceberg转Hudi
iceberg-to-hudi --source iceberg_catalog.sales.orders \
               --target hudi_catalog.sales.orders
 
# ⚠️ 注意：转换需要重写数据，耗时较长

XTable的原理是'读取源格式的数据文件，写入目标格式的元数据'。因为三者都是'Parquet + 事务层'，数据文件（Parquet）可以复用，只需重写事务日志。

我在出海硬件品牌没有实践过跨格式转换，因为我们的技术栈（Spark + Delta Lake）很稳定。但了解XTable的好处是：'未来如果需要切换，成本可控'，这在选型时是一个'风险对冲'。

实战踩坑：Delta Lake的Databricks绑定

2023年我在某短剧出海公司遇到过这个问题。我们早期选了Delta Lake（因为用Spark），但后来业务部门要求'用Flink实时入湖'。我们发现Delta Lake对Flink的支持不完善——没有官方的Flink Connector，只能用第三方库（如delta-flink），功能和稳定性都不如Iceberg。

-- 问题：Delta Lake没有官方Flink支持
-- 只能用第三方库（如delta-flink）
<dependency>
  <groupId>io.github.materiiapps</groupId>
  <artifactId>delta-flink</artifactId>
  <version>0.1.0</version>  <!-- 第三方库，版本落后 -->
</dependency>
 
// 结果：Flink写入Delta Lake时，经常遇到
// '事务日志冲突'、'Schema不兼容'等问题

解决方案：我们最终把'实时表'迁移到Iceberg，'离线表'保持Delta Lake。但这样又回到了'混用格式'的问题，团队需要维护两套工具链。

经验教训：选型时要考虑'未来1-2年的技术演进'。如果确定会'引入Flink'，一开始就选Iceberg；如果确定'纯Spark'，Delta Lake更优。不要因为'Delta Lake热'就盲目选择，要结合实际技术栈。

总结

数据湖选型的核心是'匹配技术栈和场景'。Databricks → Delta Lake，多引擎 → Iceberg，CDC实时 → Hudi。Delta Lake的Databricks集成最好，Iceberg的多引擎兼容最强，Hudi的流式能力最强。选型时要考虑'当前技术栈、未来演进方向、团队熟悉度、总成本（存储+计算+运维）'。面试时能说清楚'三种格式的区别、什么场景选哪个、有什么坑'，这道题就稳了。

下一篇聊一个很多人头疼的问题：小文件太多，查询特别慢？——OPTIMIZE和Z-Ordering怎么优化数据布局？

你们生产环境用Delta Lake还是Iceberg？有没有混用多种格式的经历？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长

数据湖 面试通关手册

第6-10篇：性能与优化

Wood聊大数据

9年大数据老兵，聊技术、聊职场、聊成长