4、Iceberg表格式核心概念：时间旅行、增量读取、行级更新与删除

好，咱们进入正题。这一章要聊的四个概念，可以说是Iceberg最硬核的底牌。时间旅行、增量读取、行级更新、行级删除——你想想看，传统Hive表能做到哪样？基本上一个都做不到。但Iceberg把它们全包了，而且做得还挺优雅。

我个人习惯把这一章当作Iceberg的「分水岭」。你搞懂了这四个东西，才算真正入了Iceberg的门。否则你只是在用Parquet文件加了个目录，跟Hive没啥区别。

4.1 时间旅行（Time Travel）

时间旅行，说白了就是你能看到表在「过去某个时刻」的样子。不是快照备份那种笨办法，而是直接查。

我在项目中遇到过最典型的场景：业务方跑完ETL发现数据算错了，问我能不能回滚到昨天跑完的状态。我说可以，一条SQL搞定。对方当时就愣住了——他们之前用Hive，回滚得靠运维从备份恢复，至少两小时。

4.1.1 快照与版本链

每次提交（commit）都会生成一个快照。快照之间通过parent-snapshot-id串联，形成版本链。你可以通过history命令查看表的变更历史：

-- 查看表的历史快照
SELECT * FROM db.table.history;

-- 输出示例
+------------------------+-------------------+---------------------+
| made_current_at        | snapshot_id       | parent_id           |
+------------------------+-------------------+---------------------+
| 2024-01-15 10:00:00    | 8745123987451238  | NULL                |
| 2024-01-15 11:30:00    | 8745123987451239  | 8745123987451238    |
| 2024-01-15 14:00:00    | 8745123987451240  | 8745123987451239    |
+------------------------+-------------------+---------------------+

嗯，这里要注意：快照ID是全局唯一的，不是自增的。parent_id为NULL表示这是第一个快照。

4.1.2 查询历史数据

两种方式可以回到过去：按快照ID查，或者按时间戳查。

-- 方式一：按快照ID
SELECT * FROM db.table
  FOR SYSTEM_VERSION AS OF 8745123987451239;

-- 方式二：按时间戳
SELECT * FROM db.table
  FOR SYSTEM_TIME AS OF '2024-01-15 11:30:00';

我曾经踩过一个坑：时间戳格式必须带时区，否则Iceberg会默认用UTC。你传个'2024-01-15 11:30:00'不带时区，查出来的结果可能跟你本地时间对不上。后来我统一要求业务方传带时区的时间戳，比如'2024-01-15 11:30:00+08:00'。

4.1.3 回滚操作

回滚不是删除快照，而是把当前指针指向旧快照。Iceberg支持两种回滚：

回滚方式	命令	说明
按快照ID回滚	CALL rollback_to_snapshot('db.table', 8745123987451239)	精确回滚到指定快照
按时间回滚	CALL rollback_to_timestamp('db.table', TIMESTAMP '2024-01-15 11:30:00')	回滚到该时间点之前的最新快照

4.2 增量读取（Incremental Read）

增量读取，说白了就是「我只拿两个快照之间变了的数据」。这在传统Hive里几乎没法做——你只能全量扫描，然后自己算diff。

Iceberg的做法很聪明：它直接对比两个快照的Manifest文件，找出新增、删除、修改的数据文件，然后只读这些文件。

4.2.1 增量查询语法

-- 查询从快照A到快照B之间的增量数据
SELECT * FROM db.table
  FOR STREAM
  BETWEEN
    '8745123987451238' AND '8745123987451240';

-- 或者按时间范围
SELECT * FROM db.table
  FOR STREAM
  BETWEEN
    TIMESTAMP '2024-01-15 10:00:00'
    AND TIMESTAMP '2024-01-15 14:00:00';

我建议你在做CDC（变更数据捕获）场景时优先用这个功能。比如你要把Iceberg的数据实时同步到Elasticsearch，每次只拉增量，效率能提升几十倍。

4.2.2 增量读取的适用场景

• CDC同步：将Iceberg表的变更实时推送到下游系统
• 增量ETL：只处理新增和修改的数据，避免全量重跑
• 审计追踪：分析某个时间窗口内的数据变更情况

4.3 行级更新与删除

行级更新和删除，这是Iceberg最让我惊艳的地方。你想想看，Parquet文件是不可变的，你怎么在不可变的文件上做更新？Iceberg的答案是：写时合并（Copy-on-Write）和读时合并（Merge-on-Read）。

4.3.1 两种实现模式

模式	写入方式	读取方式	适用场景
Copy-on-Write（COW）	重写整个数据文件	直接读取，无额外开销	写少读多，对查询性能敏感
Merge-on-Read（MOR）	写入增量文件（delete file）	读取时合并基础文件和增量文件	写多读少，对写入延迟敏感

我在项目中遇到过这样的选择困境：业务方要求秒级写入，但查询也要快。最后我折中了一下——白天用MOR模式保证写入性能，凌晨跑一个compaction任务把增量文件合并成基础文件，这样白天查询时虽然要读增量文件，但数据量不大，性能还能接受。

4.3.2 行级更新示例

-- 更新操作
UPDATE db.table
  SET status = 'completed', update_time = current_timestamp()
  WHERE order_id = 10086;

-- 在COW模式下，这条SQL会：
-- 1. 找到包含order_id=10086的数据文件
-- 2. 读取该文件，修改对应行
-- 3. 写入新的数据文件
-- 4. 更新Manifest，指向新文件

4.3.3 行级删除示例

-- 删除操作
DELETE FROM db.table
  WHERE order_date < '2024-01-01';

-- 在MOR模式下，这条SQL会：
-- 1. 生成一个delete file，记录所有被删除行的路径和位置
-- 2. 查询时，跳过这些被标记为删除的行

4.4 核心概念关系图

下面这张图展示了时间旅行、增量读取、行级更新与删除之间的关系。我画这张图的时候，特意把Metadata层放在中间——因为所有功能都依赖它。

4.5 实践建议与避坑

最后，我总结几条实战经验，都是真金白银换来的：

1. 时间旅行别滥用：保留太多快照会占用Metadata存储。我一般设置保留最近7天的快照，超过的自动清理。
2. 增量读取要确认范围：两个快照之间如果发生了compaction，增量数据可能会包含重复行。建议先做一次小范围测试。
3. 行级更新选模式：COW适合小表或低频更新，MOR适合大表高频更新。没有的好坏，看你的读写比。
4. 定期做compaction：MOR模式下delete file和增量文件会越来越多，建议每天凌晨做一次合并。