1. 数据湖选型背景：为什么需要表格式？
大家好，我是老周。做数据平台十几年了，从 Hadoop 刚兴起那会儿就开始折腾 Hive。今天咱们聊聊一个绕不开的话题——表格式。
说白了，表格式就是给数据湖里的文件加了一层“元数据管理”。没有它，你的数据就是一堆散落的 Parquet 文件，谁也说不清里面到底有什么。
1.1 数据湖的“原罪”：文件级管理
早期数据湖，比如 Hive，本质上就是个文件系统 + 元数据映射。你写个 SQL，它去 HDFS 上扫一堆文件。听起来挺简单，对吧？
但问题来了——并发写怎么办？
我记得有一次线上事故：两个 ETL 任务同时往一个分区写数据，结果读出来的数据一半是旧的，一半是新的。业务方直接炸了。这就是典型的“读时合并”问题。
核心痛点： Hive 的 ACID 支持是后来补的，不是原生设计。它依赖 HDFS 的 rename 操作来实现事务，性能差、并发低、还容易出问题。
1.2 Hive ACID 的局限性
Hive 在 3.0 版本引入了 ACID 支持，但说实话，我用下来感觉像是“打补丁”。
- 事务隔离弱： 默认只支持快照隔离，而且并发事务多了容易死锁。
- 性能开销大： 每次写操作都要写 delta 文件，读的时候要合并，小文件越来越多。
- 不支持跨分区事务： 你想同时更新两个分区？抱歉，不行。
- 回滚困难： 一旦事务失败，清理残留文件是个噩梦。
避坑指南： 我曾经在一个项目中，因为 Hive ACID 的事务日志没及时清理，导致 NameNode 内存爆了。嗯，从那以后我再也不敢在生产环境大规模用 Hive ACID 了。
1.3 为什么需要新的表格式？
你想想看，如果有一个东西能像数据库一样管理数据湖里的文件——支持事务、支持回滚、支持时间旅行——那该多好？
这就是 Iceberg 和 Delta Lake 诞生的原因。它们不是替代 Hive，而是重新定义了数据湖的存储层。
| 特性 | Hive ACID | Iceberg / Delta Lake |
|---|---|---|
| 事务支持 | 有限（依赖 HDFS rename） | 原生 ACID（乐观并发控制） |
| 并发控制 | 悲观锁，性能差 | 乐观锁，高并发友好 |
| 时间旅行 | 不支持 | 原生支持 |
| Schema 演化 | 有限（需要重建表） | 原生支持（加列、删列、重命名） |
| 小文件管理 | 手动合并 | 自动 compaction |
1.4 Iceberg 与 Delta Lake 的诞生
这两个项目几乎是同时期出现的，但背景不同：
- Iceberg： 由 Netflix 开发，2018 年开源。他们当时用 Hive 管理 PB 级数据，被小文件问题和性能瓶颈折磨得不行。Iceberg 的设计哲学是“不依赖任何存储引擎”，纯文件级元数据管理。
- Delta Lake： 由 Databricks 开发，2019 年开源。它基于 Spark，深度集成在 Spark 生态里。Delta Lake 的卖点是“开箱即用”，你只要把 Parquet 文件转成 Delta 格式，就能享受 ACID 和版本管理。
个人经验： 我最早接触的是 Delta Lake，因为团队当时全栈 Spark。后来在另一个项目里用了 Iceberg，发现它跟 Flink 配合得更好。说白了，选哪个取决于你的技术栈。
1.5 核心逻辑：表格式如何工作？
下面这张图展示了表格式的核心架构。我画得比较简洁，但能说明问题。
说白了，表格式就是在数据文件和计算引擎之间加了一层“索引”。你查数据的时候，先查元数据，再读文件。这样就能做到原子性、一致性、隔离性。
1.6 我的选型建议
嗯，这里我直接给结论：
- 如果你的技术栈以 Spark 为主，Delta Lake 上手更快。
- 如果你的技术栈比较杂（Flink、Trino、Spark 混用），Iceberg 更通用。
- 如果你对 Hive 兼容性有执念，Iceberg 支持得更好。
- 如果你需要 实时写入，Delta Lake 的 Merge 性能更优。
一句话总结： 表格式不是银弹，但它解决了数据湖最核心的“一致性”问题。没有它，你的数据湖就是个“数据沼泽”。