一、Iceberg概念及特点
Apache Iceberg是一种用于大型数据分析场景的开放表格式（Table Format）。Iceberg使用一种类似于SQL表的高性能表格式，Iceberg格式表单表可以存储数十PB数据，适配Spark、Trino、Flink和Hive等计算引擎提供高性能的读写和元数据管理功能，Iceberg是一种数据湖解决方案。

注意：Trino就是原来的PrestoSQL，2020年12月27日，PrestoSQL项目更名为Trino，Presto分成两个分支：PrestoDB、PrestoSQL。

Iceberg非常轻量级，可以作为lib与Spark、Flink计算引擎进行集成。

Iceberg具备以下特点：

Iceberg支持实时/批量数据写入和读取，支持Spark/Flink计算引擎。
Iceberg支持事务ACID，支持添加、删除、更新数据。
不绑定任何底层存储，支持Parquet、ORC、Avro格式兼容行存储和列存储。
Iceberg支持隐藏分区和分区变更，方便业务进行数据分区策略。
Iceberg支持快照数据重复查询，具备版本回滚功能。
Iceberg扫描计划很快，读取表或者查询文件可以不需要分布式SQL引擎。
Iceberg通过表元数据来对查询进行高效过滤。
基于乐观锁的并发支持，提供多线程并发写入能力并保证数据线性一致。
二、Iceberg的数据存储格式
data files（数据文件）
数据文件是Apache Iceberg表真实存储的文件，一般是在表的数据存储目录的data目录下，如果我们的文件格式选择的是parquet，那么文件是以 ".parquet" 结尾，例如：xxxx.parquet 就是一个数据文件。

iceberg每次更新就会产生多个数据文件（data files）。

Snapshot（表快照）
快照代表一张表在某个时刻的状态。每个快照里面会列出表在某个时刻的所有data files列表。data files是存储在不同的manifest files 里面，manifest files是存储在一个Manifest list文件里面，而一个Manifest list文件代表一个快照。

Manifest list（清单列表）：
manifest list是一个元数据文件，它列出构建表快照（Snapshot）的清单（Manifest file）。这个元数据文件中存储的是Manifest file列表，每个Manifest file占据一行。每行中存储了Manifest file的路径、其存储的数据文件（data files）的分区范围，增加了几个数文件、删除了几个数据文件等信息，这些信息可以用来在查询时提供过滤，加快速度。

Manifest file（清单文件）：
Manifest file也是一个元数据文件，它列出组成快照（snapshot）的数据文件（data files）的列表信息。每行都是每个数据文件的详细描述，包括数据文件的状态、文件路径、分区信息、列级别的统计信息（比如每列的最大最小值、空值等）、文件的大小以及文件里面数据行数等信息。其中列级别的统计信息可以在扫描数据时过滤掉不必要的文件。

Manifest file是以avro格式进行存储的，以 ".avro" 后缀结尾，例如 xxxx.avro。


  

三、Iceberg的特点详述
3.1 Iceberg的分区及隐藏分区（hidden partition）
Iceberg支持分区来加快数据查询，在Iceberg中设置分区后，可以在写入数据时将相似的行分组，在查询时加快查询速度，Iceberg中可以按照年、月、日和小时粒度划分时间戳组织分区。

在Hive中也支持分区，但是想使分区能加快速度，需要在写SQL时指定对应的分区条件过滤数据，在Iceberg中写SQL查询时不需要在SQL中特别指定分区过滤条件，Iceberg会自动分区，过滤掉不需要的数据。

在Iceberg中分区信息可以被隐藏起来，Iceberg的分区字段可以通过一个字段计算出来，在建表或者修改分区策略之后，新的数据会自动计算所在数据的分区，在查询的时候同样不用关心表的分区是什么字段，只需要关注业务逻辑，Iceberg会自动过滤不需要的分区数据。

正是由于Iceberg的分区信息和表数据存储目录是独立的，使得Iceberg的表分区可以被修改，而且不会涉及到数据迁移。

3.2 Iceberg表演化（Table Evolution）
在Hive分区表中，如果把一个按照天分区的表改为按照小时分区，那么没有办法在原有表上进行修改，需要创建一个按照小时分区的表，然后把数据加载到此表中。

Iceberg支持就地表演化，可以通过SQL的方式进行表级别模式演进，例如：更改表分区布局，Iceberg进行以上操作时，代价极低，不存在读出数据重新写入或者迁移数据这种费时费力的操作。

3.3 模式演化（Schema Evolution）
Iceberg支持以下几种Schema的演化：

ADD：向表或者嵌套结构中增加新列。
Drop：从表或嵌套结构中移除列
Rename：重命名表名或嵌套结构中的列
Update：将复杂结构（Struct，Map<Key,Value>，list）中的基本类型扩展类型长度，比如：tinyint修改成int。
Reorder：改变列的顺序，也可以改变嵌套结构中字段的排序顺序。
Iceberg Schema的改变只是元数据的操作改变，不会涉及到重写数据文件。Map结构类型不支持Add和Drop字段。

Iceberg保证Schema演化是没有副作用的独立操作，不会涉及到重写数据文件，具体如下：

Iceberg实现以上的原因使用唯一的id来追踪表中的每一列，当添加一个列时，会分配新的ID，因此列对应的数据不会被错误使用。

3.4 分区演化（partition Evolution）
Iceberg分区可以在现有表中更新，因为Iceberg查询流程并不和分区信息直接关联。

当我们改变一个表的分区策略时，对应修改分区之前的数据不会改变，依然会采用老的分区策略，新的数据会采用新的分区策略，也就是说同一个表会有两种分区策略，旧数据采用就分区策略，新数据采用新分区策略，在元数据里两个分区策略相互独立，不重合。

因此，在我们写SQL进行数据查询时，如果存在跨分区策略的情况，则会解析成两个不同的执行计划，如Iceberg官网提供图所示：

  


图中booking_table表2008年按月分区，进入2009年后改为按天分区，这两种分区策略共存于该表中，得益于Iceberg的隐藏分区（Hidden Partition），针对上图中的SQL查询，不需要在SQL中特别指定分区过滤条件（是按照月还是按照天），Iceberg会自动分区，过滤掉不需要的数据。

3.5 列顺序演化（Sort Order Evolution）
Iceberg可以在一个已经存在的表上修改排序策略，修改了排序策略后，旧数据依旧采用老排序策略不变，往Iceberg里写数据的计算引擎总是会选择最新的排序策略，但是当排序的代价及其高昂的时候，就不进行排序了。

增加列时不会从另一个列中读取已存在的数据。
删除列或者嵌套结构中的字段时，不会改变任何其他列的值。
更新列或者嵌套结构中的字段时，不会改变任何其他列的值。
改变列或者嵌套结构中字段顺序的时候，不会改变相关联的值。
————————————————
版权声明：本文为CSDN博主「小枫@码」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wsq1011/article/details/128601152

免责申明：

本文系转载，版权归原作者所有，如若侵权请联系我们进行删除！