第1章 Iceberg简介

本文主要是介绍第1章 Iceberg简介，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.1 概述

Iceberg是一个面向大型分析数据集的开放表格格式。它为多种计算引擎，如Spark、Trino、PrestoDB、Flink、Hive和Impala，增加了表格功能，使用一种高性能的表格格式，其工作方式就像一个SQL表一样。

在生产环境中，Iceberg被用于管理单个表格，这些表格可包含数十PB（千兆字节）的数据，即使是这样巨大的表格也能在没有分布式SQL引擎的情况下读取。它扫描规划速度快，读取表格或查找文件不需要分布式SQL引擎。同时，Iceberg使用表元数据，通过分区和列级统计信息来剪枝数据文件，实现高级过滤。

Iceberg旨在解决最终一致性云对象存储中的正确性问题，并适用于任何云存储。在HDFS中，它通过避免listing和重命名操作来减少NN（名称节点）拥塞。此外，Iceberg保证了可序列化隔离，表格变更是原子性的，读取者永远不会看到部分或未提交的变更。多个并发写入者使用乐观并发控制，并会重试以确保当写入操作冲突时兼容的更新能够成功。

总的来说，Iceberg为大型分析数据集提供了高效、可靠和灵活的数据管理解决方案，满足了各种复杂的分析需求。如需更多关于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）

Iceberg支持下面几种模式演化：

ADD：向表或者嵌套结构增加新列
Drop：从表中或者嵌套结构中移除一列
Rename：重命名表中或者嵌套结构中的一列
Update：将复杂结构(struct, map<key, value>, list)中的基本类型扩展类型长度, 比如tinyint修改成int.
Reorder：改变列或者嵌套结构中字段的排列顺序

Iceberg保证模式演化（Schema Evolution）是没有副作用的独立操作流程, 一个元数据操作, 不会涉及到重写数据文件的过程。具体的如下:

增加列时候，不会从另外一个列中读取已存在的的数据
删除列或者嵌套结构中字段的时候，不会改变任何其他列的值
更新列或者嵌套结构中字段的时候，不会改变任何其他列的值
改变列列或者嵌套结构中字段顺序的时候，不会改变相关联的值

在表中Iceberg 使用唯一ID来定位每一列的信息。新增一个列的时候,会新分配给它一个唯一ID, 并且绝对不会使用已经被使用的ID。

使用名称或者位置信息来定位列的, 都会存在一些问题, 比如使用名称的话,名称可能会重复, 使用位置的话, 不能修改顺序并且废弃的字段也不能删除。

总结为

数据写入与读取：Iceberg支持实时和批量数据的写入和读取，这使得它能够高效地处理大规模数据集。
计算引擎支持：Iceberg为多种计算引擎，包括Spark和Flink，提供了表格功能，使得这些引擎能够更方便地处理和分析数据。
事务ACID支持：Iceberg支持ACID事务，这确保了数据的一致性和可靠性。在事务中，多个操作（如插入、更新和删除）都是原子性的，要么全部成功，要么全部失败。
底层存储与文件格式：Iceberg不绑定任何特定的底层存储，它支持Parquet、ORC和Avro等格式，这些格式都是列式存储的，提供了高效的压缩和查询性能。
分区与元数据：Iceberg支持隐藏分区和分区变更，这使得业务可以根据需要进行数据分区策略。同时，它使用元数据来描述表的结构和分区信息，这些元数据包括表的schema、分区列、文件列表等，并存储在独立的存储系统中。
数据查询与版本控制：Iceberg支持快照数据的重复查询，并具备版本回滚功能，这为用户提供了数据查询的灵活性和数据管理的安全性。

1.2.5 分区演化（Partition Evolution）

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的表分区可以被修改,而且不和涉及到数据迁移。