Iceberg数据湖为什么快和可靠性、并行写

1. Performance性能

本节主要讲述Iceberg为什么查询数据很快

Iceberg查询一个Snapshot的数据，先获取一个manifest list，再通过manifest list获取manifest files，最后通过manifest files获取data files。其中manifest list和manifest file储存的数据有：

• manifest list：包含哪几个manifest file，和每个manifest file对应数据的分区字段的分区范围 + data files和delete files的数量
  所以如果查询的数据不在该分区范围，则不会读取该manifest file
• manifest file：包含有哪几个data file，和每个data file对应数据的分区信息 + 每个data file对应数据的每列统计信息(如一列的值数量、空值数量、数值上界和下界) + 每个data file对应数据的汇总信息
  所以如果查询的数据不在该分区范围，或这一列不位于上界和下界之间等等，则不会读取该data file

2. Reliability可靠性

Iceberg每一次write或delete操作都会产生一个新的Snapshot，新的Snapshot的manifest list，和上一个Snapshot的manifest list，会共用很多manifest file，所以也会共用很多data file

HDFS上的metadata/version-hint.text文件指向最新的metadata/vN.metadata.json文件，该json文件中有最新的current-snapshot-id。而Iceberg的commit操作对metadata/version-hint.text的修改是原子性的，这能保证一个表metadata和data的更新是原子性的，从而保证了serializable isolation。同时还有下面的好处：

1. 可靠的read：能读取到一致性的Snapshot，而不是读write产生锁。同时write也不会对read产生锁
2. O(1) RPCs to plan：一个job计划，只需要请求一个Snapshot，所以只需要O(1) RPC calls
3. Distributed计划：manifest file和data file的过滤、谓词下推能分布式的进行

2.1 并行写

Iceberg使用乐观并行机制，来实现并行写。每一个writer都假设没有其它writer在操作，对表的write进行原子性的commit。如果一个writer因为其它writer已经commit过而失败，会在最新的表状态下，进行commit重试

commit重试的成本：通过structuring changes，可以进行多次重试，避免昂贵的重试操作。比如向表添加数据，会添加data files，也会向表添加新的manifest file，当commit失败后重试，不用重新创建data files和manifest file(但是需要重新创建manifest list)，再次进行commit即可

验证commit是否可以重试：commit重试分为验证和执行两步，先验证是否符合commit条件，如何符合则执行commit，不符合则失败。比如合并file_a.avro和file_b.avro，如果commit重试检验两个文件存在，则可以执行commit，如果其中一个文件被其它操作删除，则失败

2.2 Compatibility兼容性

通过避免file listing和rename operations，Iceberg可以兼容许多储存系统