📚 课程目录第3章快照与版本管理

3. 快照与版本管理

好，我们进入第三章。这一章聊的是 Iceberg 最让我着迷的特性——快照与版本管理。

说实话，我第一次接触 Iceberg 时，最震撼的就是它的快照机制。你想想看，一个表每次写入都会生成一个不可变的快照，每个快照都记录了那一时刻表的完整元数据。这意味着什么？意味着你可以随时回到过去，查看任意时间点的数据状态。

我在项目中遇到过这样一个场景：业务方跑完 ETL 后发现数据有问题，问我能不能恢复到昨天的状态。传统 Hive 表？抱歉，你得从备份恢复，耗时几小时。Iceberg？一行 SQL 搞定，秒级回滚。这就是快照隔离的力量。

快照隔离：读写不打架的秘诀

快照隔离，说白了就是每个读取操作都基于一个固定的快照版本。写入操作生成新快照，但不会影响正在读取旧快照的查询。

Iceberg 是怎么做到的？核心在于它的元数据层设计：

Manifest List：记录当前快照包含哪些 manifest 文件
Manifest：记录数据文件与分区、列的映射关系
Data Files：实际存储数据的 Parquet/ORC/Avro 文件

每次提交新数据，Iceberg 会：

写入新的数据文件（不修改旧文件）
生成新的 manifest 文件指向新数据
创建新的 manifest list 和快照元数据
原子性地更新表的当前快照指针

嗯，这里要注意：旧快照不会被删除。它们只是不再被当前指针引用，但仍然存在。这就是时间旅行的基础。

核心要点：Iceberg 的快照隔离是写时复制（Copy-on-Write）和读时合并（Merge-on-Read）的结合体。写入不阻塞读取，读取不阻塞写入。你跑你的查询，我写我的数据，互不干扰。

时间旅行：回到任意历史时刻

时间旅行是我个人最喜欢的功能。它让你能查询表在过去某个时间点的数据状态。

实现原理其实不复杂：每个快照都有一个时间戳和唯一的快照 ID。Iceberg 的元数据层维护了一个快照日志，记录了所有历史快照及其时间戳。

查询时，你可以指定：

-- 按时间戳查询
SELECT * FROM orders 
FOR SYSTEM_TIME AS OF '2024-01-15 10:00:00';

-- 按快照 ID 查询
SELECT * FROM orders 
FOR SYSTEM_VERSION AS OF 1234567890;

我曾经帮一个金融客户排查问题。他们发现某天的报表数据对不上，需要回溯到三天前的某个具体时刻。用 Iceberg 的时间旅行，我们直接查到了那个时间点的数据快照，对比后发现是上游数据源在某个时间点重复推送了数据。整个过程不到 10 分钟。

小技巧：我建议你在关键业务表上保留至少 7 天的快照历史。Iceberg 默认保留时间可以通过 write.metadata.delete-after-commit.enabled 和 write.metadata.previous-versions-max 配置。别设太短，否则时间旅行就失效了。

增量读取：只读变化的部分

增量读取，就是只读取两个快照之间发生变化的数据。这在数据同步、CDC（变更数据捕获）场景下特别有用。

原理是这样的：Iceberg 的每个快照都记录了它包含的所有数据文件。要计算两个快照之间的增量，只需要对比它们的 manifest list：

找出在快照 B 中新增的数据文件
找出在快照 B 中被删除的数据文件
找出在快照 B 中被更新的数据文件（删除旧文件 + 新增新文件）

代码示例：

-- 读取快照 1 到快照 2 之间的增量数据
SELECT * FROM orders 
FOR SYSTEM_VERSION 
BETWEEN 100 AND 200;

-- 或者按时间范围
SELECT * FROM orders 
FOR SYSTEM_TIME 
BETWEEN '2024-01-15 10:00:00' AND '2024-01-15 11:00:00';

注意：增量读取不是万能的。如果两个快照之间发生了全表重写（比如 REWRITE DATA 操作），增量读取会返回大量数据，因为所有文件都被替换了。我在项目中就踩过这个坑，当时以为增量读取只会返回少量数据，结果跑出来几 TB。后来我学乖了，先检查快照之间的文件变化量。

快照的生命周期管理

快照不会永远保留。Iceberg 提供了快照过期机制，定期清理旧快照以释放存储空间。

配置参数：

参数	说明	默认值
`write.metadata.delete-after-commit.enabled`	提交后是否删除旧元数据	false
`write.metadata.previous-versions-max`	保留的元数据版本数	100
`history.expire.max-snapshot-age-ms`	快照最大保留时间	7 天
`history.expire.min-snapshots-to-keep`	最少保留的快照数	1

手动清理快照：

CALL catalog.system.expire_snapshots(
  table => 'db.orders',
  older_than => TIMESTAMP '2024-01-01 00:00:00',
  retain_last => 5
);

我个人习惯保留最近 30 天的快照，同时至少保留 10 个快照。这样既能支持时间旅行，又不会让元数据膨胀得太厉害。

核心机制流程图

下面这张图展示了快照隔离、时间旅行和增量读取的核心流程：

实际应用场景

说了这么多原理，聊聊实际怎么用。

场景一：数据回滚

业务方发现今天的数据有问题，需要回滚到昨天。传统做法是找备份恢复，Iceberg 只需要：

CALL catalog.system.rollback_to_snapshot(
  table => 'db.orders',
  snapshot_id => 1234567890
);

秒级完成，不影响正在运行的查询。

场景二：增量 ETL

我做过一个实时数仓项目，需要每 5 分钟从 Iceberg 表读取增量数据同步到下游。用增量读取，每次只读新增和修改的数据，效率提升 10 倍以上。

场景三：数据审计

金融场景经常需要审计数据变更历史。Iceberg 的快照历史天然支持这个需求，你可以查询任意时间点的数据，对比不同版本之间的差异。

最佳实践：我建议你在设计表结构时，就规划好快照保留策略。不是所有表都需要保留 30 天快照。比如临时表保留 1 天就够了，核心业务表可以保留 30 天甚至更久。合理配置能节省大量存储成本。

好了，这一章的内容就到这里。快照隔离、时间旅行、增量读取，这三个特性是 Iceberg 区别于传统数据湖的核心竞争力。理解了它们，你就掌握了 Iceberg 版本管理的精髓。