数据湖技术概览：从 Hadoop 到 Iceberg 与 Delta Lake

大家好，我是老张。今天咱们聊聊数据湖的演进史，以及为什么这两年 Iceberg 和 Delta Lake 突然成了热门话题。

先问个问题：你现在的数据架构，是不是还在用 Hive 加 HDFS 那套？如果是，那你一定遇到过“读到的数据不完整”、“改个分区要重跑全量”这种糟心事。嗯，我当年也踩过这些坑。

数据湖的演进历史

数据湖这个概念，最早是 Hadoop 生态带起来的。说白了，就是把所有数据——结构化的、半结构化的、非结构化的——一股脑扔到 HDFS 上，想用的时候再读。

但问题很快就来了。

• 第一阶段：HDFS + Hive 时代——能存能查，但事务？不存在的。你写数据的时候别人读，读到一半可能就崩了。
• 第二阶段：Hive ACID + ORC 改进——Hive 开始支持事务，但性能差，配置复杂。我在项目中试过一次，最后放弃了。
• 第三阶段：对象存储 + Spark 时代——AWS S3、阿里云 OSS 兴起，存储计算分离成了主流。但文件列表操作慢，小文件问题严重。
• 第四阶段：湖仓一体（Lakehouse）时代——Iceberg、Delta Lake、Hudi 出现，把数据库的 ACID 事务、Schema 演进、Time Travel 带进了数据湖。

为什么需要 Iceberg 和 Delta Lake？

你想想看，传统数据湖最大的痛点是什么？

1. 数据一致性差——写了一半的任务挂了，留下的脏数据没人管。
2. Schema 变更麻烦——加一列要删表重建，或者靠 Hive 的 SerDe 硬撑。
3. 查询性能不可控——没有统计信息，Spark 只能全表扫描。
4. 缺乏版本管理——误删数据？只能从备份恢复，恢复一次半天。

Iceberg 和 Delta Lake 就是来解决这些问题的。它们不是新的存储引擎，而是在现有存储（HDFS、S3、OSS）之上加了一层“表格式”（Table Format）。

两大技术的核心定位对比

先看一张图，帮你快速建立整体认知。

这张图里，我刻意把两者的差异点列了出来。你可能会问：那到底选哪个？别急，咱们先看详细对比。

对比维度	Apache Iceberg	Delta Lake
开源背景	Netflix 捐赠给 Apache 基金会	Databricks 开源，商业公司主导
核心设计	不可变的 Manifest 文件 + 快照链	事务日志（Delta Log）+ Checkpoint
引擎支持	Spark、Flink、Trino、Hive、Presto	Spark 为主，Flink、Presto 逐步支持
Schema 演进	原生支持，无副作用	支持，但部分操作需重写文件
Time Travel	基于快照 ID 或时间戳	基于版本号或时间戳
分区演进	支持隐藏分区，分区可动态变更	分区变更需重写历史数据
小文件合并	通过 Spark 或 Flink 作业手动/自动合并	OPTIMIZE 命令 + Auto Compaction

我的个人经验总结

做了这么多年数据架构，我最大的感受是：没有银弹。

Iceberg 的优势在于开放和灵活。它不绑定任何计算引擎，你可以在同一个表上跑 Spark 做批处理、Flink 做流处理、Trino 做即席查询。而且它的隐藏分区设计非常巧妙——你不需要手动指定分区字段，系统会自动管理。

Delta Lake 的优势在于深度优化。如果你全栈都是 Spark，Delta Lake 的 Merge、Update、Delete 性能会更好。Databricks 在 Runtime 层面做了大量优化，比如 Photon 引擎、Delta Caching 等。

所以，选型不是比谁更牛，而是看你的场景。接下来的章节，我会带你深入每个技术细节，帮你做出最适合自己的选择。