1. Iceberg 前世今生：为什么需要 Iceberg？从 Hive 表到 Iceberg 的演进之路
1.1 故事得从 Hive 说起
做数据的人，没人不知道 Hive。我 2016 年刚入行时，Hive 就是大数据领域的「标配」。你想想看，那时候大家用 Hive 做离线数仓，跑个 T+1 报表，日子过得也挺好。
但问题来了。Hive 的表格式，说白了就是个「目录+文件」的简单映射。你在 HDFS 上建个目录，里面放一堆 Parquet 或 ORC 文件，Hive 的元数据里记一下「这个表对应哪个目录」。仅此而已。
嗯，这里要注意。这种设计在数据量小的时候没问题。一旦数据量上来，痛点就全暴露了。
1.2 Hive 表的三大痛点
我在项目中遇到过好几次这样的场景：凌晨两点，运维同事打电话说「流水表又查不到最新数据了」。为什么？因为 Hive 的元数据刷新机制太脆弱了。
痛点一：ACID 事务缺失
Hive 表不支持行级更新和删除。你想改一条数据？只能把整个分区重写一遍。我见过一个团队，为了修复一条错误记录，重跑了 3TB 的数据。说白了，这就是「为了修一扇窗户，把整栋楼拆了重建」。
痛点二：快照隔离能力为零
你在跑一个查询，别人同时在写数据。结果呢？你的查询可能读到一半的数据——前面是旧版本，后面是新版本。这种「幻读」在金融场景里是致命的。我记得有一次做对账，就因为这种不一致，排查了整整两天。
痛点三：文件膨胀与元数据瓶颈
Hive 的元数据存在 MySQL 里，一张表的分区数超过几万个，查询元数据就能卡死。更麻烦的是，小文件问题——Spark 写数据时默认每个 task 生成一个文件，一天下来可能产生几十万个小文件。NameNode 压力大，查询性能也差。
1.3 从 Hive 到 Iceberg：演进之路
那怎么解决这些问题？业界尝试过很多方案。有人用 Hive + ACID，有人用 Kudu，有人用 Delta Lake。但 Iceberg 的解法，我个人觉得最优雅。
Iceberg 的核心思路是：把表格式从「文件目录」升级为「元数据层」。它不再依赖 HDFS 目录结构来管理数据，而是用一套独立的元数据文件来追踪所有数据文件。
我画了一张图，帮你理解这个演进过程：
1.4 Iceberg 的核心设计理念
Iceberg 到底做了什么？我总结为三个关键设计：
- 快照（Snapshot）机制：每次写入生成一个新的快照，查询时指定快照 ID，就能读到那个时刻的完整数据。说白了，就是「时间旅行」。
- Manifest 清单文件：每个快照对应一组 Manifest 文件，里面记录了所有数据文件的路径、分区信息、统计信息（min/max 值等）。查询引擎不需要扫描目录，直接读 Manifest 就能知道哪些文件需要读。
- 分区演进（Partition Evolution）：Hive 的分区是写死的，改分区要重建表。Iceberg 允许你随时改分区策略，旧数据用旧分区，新数据用新分区，查询时自动合并。
一个小技巧：我个人习惯在 Iceberg 表上开启 write.metadata.delete-after-commit.enabled=true，自动清理历史元数据文件。否则时间久了，元数据目录会膨胀得很厉害。
1.5 为什么是 Iceberg 而不是其他？
你可能要问：Delta Lake 和 Hudi 也做类似的事，为什么选 Iceberg？
我个人的看法是：Iceberg 的「开放」属性太重要了。它不绑定任何计算引擎，Spark、Flink、Trino、Presto、Hive 都能用。而且它的表格式规范是 Apache 基金会标准，社区活跃度很高。
举个例子。我之前在项目中同时用了 Spark 做批处理、Flink 做流处理、Trino 做 Ad-hoc 查询。如果用 Delta Lake，Flink 的支持就不太成熟；用 Hudi，Trino 的集成又有坑。但 Iceberg 对这三个引擎的支持都很完善，省了我不少对接的功夫。
| 特性 | Hive | Iceberg |
|---|---|---|
| ACID 事务 | ❌ 不支持 | ✅ 支持（行级更新/删除） |
| 快照隔离 | ❌ 无 | ✅ 时间旅行 |
| 分区演进 | ❌ 需重建表 | ✅ 在线变更 |
| 小文件合并 | ❌ 手动处理 | ✅ 自动 Compaction |
| 引擎兼容性 | ✅ 广泛 | ✅ 更广泛（原生支持） |
| 元数据性能 | ❌ 分区数多时瓶颈 | ✅ 百万级分区无压力 |
1.6 避坑指南：从 Hive 迁移到 Iceberg 的教训
我曾经帮一个团队做 Hive 到 Iceberg 的迁移。他们有个 10TB 的日志表，直接用了 ALTER TABLE ... CONVERT TO ICEBERG 命令。结果呢？跑了 6 个小时还没跑完，最后发现是文件数量太多（300 多万个小文件），转换过程卡在了元数据生成上。
注意：迁移前一定要先做小文件合并。建议先用 INSERT OVERWRITE 把数据重写一遍，控制文件大小在 256MB~1GB 之间。否则 Iceberg 的 Manifest 文件会变得非常庞大，影响查询性能。
另一个坑是分区策略。Hive 表的分区字段通常是日期（如 dt=2024-01-01），但 Iceberg 推荐使用 days(timestamp) 这种隐藏分区。如果你直接转换，旧分区还在，但新写入的数据会按新策略分区。查询时 Iceberg 会自动处理，但如果你用 Hive 引擎查，可能会出问题。
1.7 小结
Iceberg 的出现，说白了就是「Hive 表格式已经撑不住了」。数据量大了、实时性要求高了、需要事务了，Hive 的短板就全暴露了。Iceberg 用一套元数据层解决了这些问题，而且做得足够开放。
嗯，这一章先讲到这里。后面的章节，我会带你深入 Iceberg 的存储格式、文件布局、Compaction 策略、查询优化等实战内容。准备好了吗？