实战业务场景，频繁的rewrite、mergeInto等产生大量新的replace/overwrite snapshot，会导致iceberg表的实际存储数据大量冗余，进而导致iceberg表实际磁盘存储占用急速膨胀，需要根据实际业务场景进行历史snapshot的expire操作

---

数据冗余现象

描述：

由于生产环境要求亚秒至分钟级别的数据实效性，同时要满足下游 亚秒级 ad-hoc查询与多维分析，所以需要进行频繁的小文件rewrite操作，从而导致单表的实际存储急速膨胀

---

数据冗余分析

从示意图中，可以看出

• commit1、commit2是正常的数据写入操作，产生snapshot1、snapshot2、共写入了6个datafile，23K数据，当前表数据23K，磁盘占用23K，冗余比：0
• commit3进行了一次rewrite操作，新产生一个snapshot3，合并生成了两个新文件：datafile1+datafile2、datafile3+datafile4，新增12K数据，当前表数据23K，磁盘占用35K，冗余比：0.52
• commit4进行了一次mergeinto操作，新产生一个snapshot4，更新生成了2个新文件：datafile1’+datafile2’、datafile7，新增11K数据，当前表数据28K，磁盘占用46K，冗余比：0.64

---

数据冗余原理

• 对于iceberg表结构而言，任何commit操作都会落地成snapshot
• 为了满足iceberg的一大核心特性：时光机（time traveling），每个snapshot下都会挂载当前表全量数据（非增量）
• 所以，所有rewrite、mergeinto操作的commit产生的snapshot会冗余存储历史的部分数据，从而导致整表存储膨胀

---

如何应对snap数据冗余膨胀？

So，我们需要根据实际业务场景进行历史snap的expire工作

Expire操作的两种模式

• 编程api模式

PS：当前（2021年2月）社区spark api的retainLast和oldThan两种策略结果与预期在一定的差异，且是单并发，执行性能不是很好，需要进行一定的二次开发，增加并发度

• Procedures模式

Stored procedures are only available when using Iceberg SQL extensions in Spark 3.x.

CALL hive_prod.system.expire_snapshots('db.sample', TIMESTAMP '2021-06-30 00:00:00.000', 100)

https://iceberg.apache.org/docs/latest/spark-procedures/#expire_snapshots

---

实战优化效果

从示意图可以看出

• 存储最高优化了接近300倍，由2P+ 缩小至 7T+
• 小文件数最高优化了3.5倍，由1100万级降低至280万级