Spark读写Delta Lake/Iceberg——数据湖和Spark怎么配合？
先说结论
Delta Lake和Iceberg的核心价值是：给数据湖加上了ACID事务 + MERGE INTO + 时间旅行 + Schema演进。它们解决的是传统数据湖的“可靠性问题”——写到一半失败了怎么办、怎么做更新删除、怎么回滚。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
数据湖（Data Lake）是这两年大数据领域最热的话题。Delta Lake和Iceberg都是基于Parquet的表格式，给Parquet加了事务能力。我在出海硬件公司全量用Delta Lake，在Databricks上的体验非常好。今天把数据湖和Spark的关系和实战经验讲清楚。
为什么需要数据湖格式？
传统的Hive表（Parquet/ORC文件）有三个缺陷：
① 没有事务： 写入到一半失败了，会留下部分文件（脏数据）。
② 不支持UPDATE/DELETE： Parquet是只追加的，要更新一条数据只能全量重写整个分区。
③ 没有时间旅行： 不能查看“昨天这张表是什么样子的”。
Delta Lake和Iceberg对比
| 维度 | Delta Lake | Apache Iceberg |
|---|---|---|
| 起源 | Databricks开发 | Netflix开发 |
| 底层格式 | Parquet + JSON事务日志 | Parquet + Avro元数据 |
| Spark支持 | 原生（Databricks最优） | 原生支持 |
| 引擎兼容性 | 主要Spark | Spark/Flink/Trino/Presto/Hive全部 |
| MERGE INTO | 支持（性能优秀） | 支持 |
| Z-Ordering | 支持（OPTIMIZE命令） | 支持（Sort Order） |
| 时间旅行 | DESCRIBE HISTORY + VERSION | CALL快照管理 |
简单说：Databricks生态选Delta Lake，多引擎生态选Iceberg。
实战：MERGE INTO替代全量重写
这是Delta Lake对我工作影响最大的功能。以前用Hive做缓慢变化维，要写复杂的“全量Join + UNION + OVERWRITE”逻辑。现在一条MERGE INTO搞定：
-- Delta Lake的MERGE INTO：既更新既插入
MERGE INTO dim_user t
USING user_update s ON t.user_id = s.user_id
WHEN MATCHED THEN UPDATE SET t.email = s.email, t.updated_at = s.updated_at
WHEN NOT MATCHED THEN INSERT *;
-- 以前的Hive写法需要20+行SQL，现在只要4行我在出海硬件公司把所有维度表的更新逻辑仏UNION改成MERGE INTO，代码量减少70%，而且性能更好——因为MERGE INTO只重写变更的文件，不需要全量重写整个分区。
总结
数据湖格式解决了传统数据湖的事务、更新删除、时间旅行问题。Databricks选Delta Lake，多引擎选Iceberg。MERGE INTO是最实用的功能。面试时能说清楚“为什么需要数据湖格式”和“MERGE INTO的实战价值”，就很有深度。
下一篇聊Spark作业跑到一半Checkpoint失败了——Spark的容错机制怎么工作的？
你们生产环境用的Delta Lake还是Iceberg？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长