1.1 概述
为了解决数据存储和计算引擎之间的适配的问题，Netflix开发了Iceberg，2018年11月16日进入Apache孵化器，2020 年5月19日从孵化器毕业，成为Apache的顶级项目。
Iceberg是一个面向海量数据分析场景的开放表格式（Table Format）。表格式（Table Format）可以理解为元数据以及数据文件的一种组织方式，处于计算框架（Flink，Spark…）之下，数据文件之上。

Iceberg 是大型分析型数据集上的一个开放式表格式。通过该表格式，将下层的存储介质（HDFS、S3、OSS等）、文件格式（Parquet、Avro、ORC等）与上层计算引擎（Flink、Spark、Presto、Hive等）进行解耦，如下图所示

  
计算与存储的解耦给我们带来了更多的灵活性，在计算引擎上有了更多的选择，可以根据实际的需求选择不同的计算引擎。通过表格式屏蔽了下层的存储细节，对上层引擎呈现的都只是一张 Iceberg 表。

1.2 特性
1.2.1 数据存储、计算引擎插件化
Iceberg提供一个开放通用的表格式（Table Format）实现方案，不和特定的数据存储、计算引擎绑定。目前大数据领域的常见数据存储（HDFS、S3…），计算引擎（Flink、Spark…）都可以接入Iceberg。
在生产环境中，可选择不同的组件搭使用。甚至可以不通过计算引擎，直接读取存在文件系统上的数据。

1.2.2 实时流批一体
Iceberg上游组件将数据写入完成后，下游组件及时可读，可查询。可以满足实时场景.并且Iceberg同时提供了流/批读接口、流/批写接口。可以在同一个流程里, 同时处理流数据和批数据，大大简化了ETL链路。

1.2.3 数据表演化（Table Evolution）
Iceberg可以通过SQL的方式进行表级别模式演进。进行这些操作的时候，代价极低。 不存在读出数据重新写入或者迁移数据这种费时费力的操作。比如在常用的Hive中，如果我们需要把一个按天分区的表，改成按小时分区。此时，不能再原表之上直接修改，只能新建一个按小时分区的表，然后再把数据Insert到新的小时分区表。而且，即使我们通过Rename的命令把新表的名字改为原表，使用原表的上次层应用, 也可能由于分区字段修改，导致需要修改 SQL，这样花费的经历是非常繁琐的。

1.2.4 模式演化（Schema Evolution）（重点）
提起一张表（table format），最先强调的是表是具有 Schema的。 Iceberg 表是有 Schema 强制约束的。与 Hive 表不同，写入 Iceberg 表的数据必须经过 Schema 的校验，这样就解决了 Hive 表文件内容和 Schema 不匹配导致的下游消费异常的问题。

Iceberg支持下面几种模式演化：
ADD：向表或者嵌套结构增加新列
Drop：从表中或者嵌套结构中移除一列
Rename：重命名表中或者嵌套结构中的一列
Update：将复杂结构(struct, map<key, value>, list)中的基本类型扩展类型长度, 比如tinyint修改成int.
Reorder：改变列或者嵌套结构中字段的排列顺序
Iceberg保证模式演化（Schema Evolution）是没有副作用的独立操作流程, 一个元数据操作, 不会涉及到重写数据文件的过程。具体的如下:
增加列时候，不会从另外一个列中读取已存在的的数据
删除列或者嵌套结构中字段的时候，不会改变任何其他列的值
更新列或者嵌套结构中字段的时候，不会改变任何其他列的值
改变列列或者嵌套结构中字段顺序的时候，不会改变相关联的值
在表中Iceberg 使用唯一ID来定位每一列的信息。新增一个列的时候,会新分配给它一个唯一ID, 并且绝对不会使用已经被使用的ID。
使用名称或者位置信息来定位列的, 都会存在一些问题, 比如使用名称的话,名称可能会重复, 使用位置的话, 不能修改顺序并且废弃的字段也不能删除。
1.2.5 分区演化（Partition Evolution）（重点）
与 Hive 表类似，Iceberg 也可以进行分区来获取更快的查询。但与 Hive 不同的地方时 Iceberg 支持隐式分区。
在 Hive 中，分区需要显示指定为表中的一个字段，并且要求在写入和读取时需要明确的指定写入和读取的分区。

而在 Iceberg 中将分区进行隐藏，由 Iceberg 来跟踪分区与列的对应关系。在建表时用户可以指定date(event_time) 作为分区， Iceberg 会保证正确的数据总是写入正确的分区，而且在查询时不需要手动指定分区列，Iceberg 会自动根据查询条件来进行分区裁剪。

Iceberg可以在一个已存在的表上直接修改，因为Iceberg的查询流程并不和分区信息直接关联。
当我们改变一个表的分区策略时，对应修改分区之前的数据不会改变, 依然会采用老的分区策略，新的数据会采用新的分区策略，也就是说同一个表会有两种分区策略，旧数据采用旧分区策略，新数据采用新新分区策略, 在元数据里两个分区策略相互独立，不重合。
在查询数据的时候，如果存在跨分区策略的情况，则会解析成两个不同执行计划，如Iceberg官网提供图所示：

  
图中booking_table表2008年按月分区，进入2009年后改为按天分区，这两中分区策略共存于该表中。

借助Iceberg的隐藏分区（Hidden Partition），在写SQL 查询的时候，不需要在SQL中特别指定分区过滤条件，Iceberg会自动分区，过滤掉不需要的数据。

Iceberg分区演化操作同样是一个元数据操作, 不会重写数据文件。

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

1.2.7 隐藏分区（Hidden Partition）
Iceberg的分区信息并不需要人工维护, 它可以被隐藏起来. 不同其他类似Hive 的分区策略, Iceberg的分区字段/策略（通过某一个字段计算出来），可以不是表的字段和表数据存储目录也没有关系。在建表或者修改分区策略之后，新的数据会自动计算所属于的分区。在查询的时候同样不用关系表的分区是什么字段/策略，只需要关注业务逻辑，Iceberg会自动过滤不需要的分区数据。

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

1.2.8 镜像数据查询（Time Travel）
其实就是快照查询

Iceberg提供了查询表历史某一时间点数据镜像（snapshot）的能力。通过该特性可以将最新的SQL逻辑，应用到历史数据上。

1.2.9 支持事务（ACID）
Iceberg通过提供事务（ACID）的机制，使其具备了upsert的能力并且使得边写边读成为可能，从而数据可以更快的被下游组件消费。通过事务保证了下游组件只能消费已commit的数据，而不会读到部分甚至未提交的数据。

1.2.10 基于乐观锁的并发支持
Iceberg基于乐观锁提供了多个程序并发写入的能力并且保证数据线性一致。

1.2.11 文件级数据剪裁
Iceberg的元数据里面提供了每个数据文件的一些统计信息，比如最大值，最小值，Count计数等等。因此，查询SQL的过滤条件除了常规的分区，列过滤，甚至可以下推到文件级别，大大加快了查询效率。

1.2.12 事务性 (重点)
Iceberg 的一个亮点是提供了 ACID 的语义支持，通过 Snapshot 进行读写分离，提供了 Serializable isolation，且所有的操作都可以保证原子性。
相比 Hive 而言，Iceberg 提供的事务性可以隔离写入任务队分析任务的不利影响，且写入失败不会出现脏数据。

  

更加吸引人的是 Iceberg 和 Flink 的结合，通过 Flink 的 Checkpoint 机制和 Iceberg 的事务性，可以做到端到端的 Exactly once 语义。
————————————————
版权声明：本文为CSDN博主「Direction_Wind」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Direction_Wind/article/details/134083205

免责申明：

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