Apache Iceberg 概述

Apache Iceberg概述

在这里插入图片描述

一、what is Apache Iceberg？

为了解决数据存储和计算引擎之间的适配的问题，Netflix开发了Iceberg，2018年11月16日进入Apache孵化器，2020 年5月19日从孵化器毕业，成为Apache的顶级项目。
在这里插入图片描述

Apache Iceberg is an open table format for huge analytic datasets.Apache Iceberg 是一种适用于大型分析数据集的开放表格式。

表格式（Table Format）可以理解为元数据以及数据文件的一种组织方式，处于计算框架（Flink，Spark…）之下，数据文件之上。

在这里插入图片描述

A good way to define a table format is a way to organize a dataset’s files to present them as a single “table”.
在这里插入图片描述

Iceberg 使用高性能表格式将表添加到计算引擎中，包括 Spark、Trino、PrestoDB、Flink、Hive 和 Impala，其工作方式与 SQL 表类似。

二、Apache Iceberg核心特性

2.1 数据存储、计算引擎插件化（解耦）

Apache Iceberg 作为一种开放的表格式，允许用户灵活地选择数据存储和计算引擎。

在这里插入图片描述

它与具体的存储解决方案（如 HDFS、Amazon S3）和计算引擎（如 Apache Spark、Apache Flink）解耦，使得用户能够根据需求随时调整架构。
例如，在一个数据分析平台中，用户可以将数据存储在 Amazon S3 中，并使用 Apache Spark 来进行批量分析，同时也能接入 Apache Flink 进行实时流处理，无需更改数据格式。

2.2 实时流批一体

Iceberg 支持同时处理流数据和批数据，提供统一的读写接口。
可以在同一个数据管道中混合处理实时流数据（如 IoT 设备产生的数据）和历史批数据（如日志文件）。
例如，一个电商平台可以使用 Iceberg 接收实时的交易数据流，并同时执行对历史订单数据的分析，以生成实时销售报告和库存监控，简化 ETL 过程，减少数据延迟。

2.3 数据表演化（Table Evolution）

Apache Iceberg 提供了一种高效的方式来进行表级别的模式演进，使得用户能够灵活地修改表的结构而不需要耗费大量时间和资源。
这种模式演进通过简单的 SQL 操作实现，避免了繁琐的数据迁移和重写过程。

低代价的操作：在 Iceberg 中，模式演进几乎不需要重写数据。当用户需要对表的结构进行修改（如添加、删除列或更改列的数据类型）时，只需执行相应的 SQL 命令，Iceberg 会在后台自动处理相关的元数据更新，而不需要将现有数据读取出来再写入。
无缝集成：与传统的 Hive 表相比，Iceberg 允许用户在不影响现有查询的情况下进行修改。例如，用户可以在保留原有数据的基础上，逐步演进到新的数据模型。

假设一个在线零售平台的订单表最初按天分区：

CREATE TABLE orders (order_id BIGINT,customer_id BIGINT,order_date DATE,amount DECIMAL(10, 2)
) PARTITIONED BY (order_date);

如果业务需求发生变化，需要将表的分区方式改为按小时分区。在传统的 Hive 中，这通常需要创建新表并将数据插入其中：

创建新表：

CREATE TABLE orders_hourly (order_id BIGINT,customer_id BIGINT,order_date DATE,order_hour INT,amount DECIMAL(10, 2)
) PARTITIONED BY (order_date, order_hour);//按小时分区

将旧表数据迁移到新表：

INSERT INTO orders_hourly
SELECT order_id, customer_id, order_date, HOUR(order_date) as order_hour, amount
FROM orders;

然后重命名新表以替换旧表，这可能影响其他依赖于旧表的查询。

而在 Iceberg 中，用户只需执行以下 SQL 操作：

ALTER TABLE orders ADD COLUMN order_hour INT;
ALTER TABLE orders SET PARTITIONED BY (order_date, order_hour);

Iceberg 会在不影响现有数据的情况下处理分区的变更，原有的数据仍然可以通过新的查询访问。这样，整个演进过程变得简单、快速且高效，大大降低了操作复杂性和风险。

数据架构的演进变得灵活和高效，企业可以更快速地响应业务需求的变化，保持数据模型的现代化。这种无缝的演进能力是许多企业在进行数据管理和分析时所期望的。

2.4 模式演化（Schema Evolution）

Iceberg 的模式演化设计提供了一种灵活、安全的方式来管理表结构，确保在修改表时不会影响现有数据或引入潜在的错误。

在这里插入图片描述

ADD：通过增加新列，用户可以轻松扩展表的结构，例如添加新特性而不干扰现有数据。
DROP：移除不再需要的列，确保数据模型的整洁，且不影响其他列的内容。
RENAME：重命名列有助于提升可读性或反映业务变化，Iceberg 保证其他列的数据不会受到影响。
UPDATE：对复杂结构的基本类型进行扩展，如从 tinyint 更新为 int，支持更大的数据范围，而无需重写数据。
REORDER：改变列的排列顺序，使数据结构更符合用户需求，同时保持数据完整性。

在这里插入图片描述
Iceberg 使用唯一ID来定位列，从而避免因名称重复或位置依赖引发的问题，这一设计增强了模式演化的灵活性和可靠性。

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

2.5 分区演化（Partition Evolution）

Iceberg可以在一个已存在的表上直接修改，因为Iceberg的查询流程并不和分区信息直接关联。
当我们改变一个表的分区策略时，对应修改分区之前的数据不会改变, 依然会采用老的分区策略，新的数据会采用新的分区策略。
也就是说同一个表会有两种分区策略，旧数据采用旧分区策略，新数据采用新新分区策略, 在元数据里两个分区策略相互独立，不重合。

在这里插入图片描述

booking_table表2008年按月分区，进入2009年后改为按天分区，这两中分区策略共存于该表中。
借助Iceberg的隐藏分区（Hidden Partition），在写SQL 查询的时候，不需要在SQL中特别指定分区过滤条件，Iceberg会自动分区，过滤掉不需要的数据。
Iceberg分区演化操作同样是一个元数据操作, 不会重写数据文件。

表 sales，初始的分区策略是按年份（year）进行分区：

id
amount
date (包含年份信息)

初始分区策略：

year 分区
- 数据分区示例：
  - 2021
  - 2022
  - 2023

初始数据加载：
- 数据按 year 分区存储在表中。
- 例如，2022年的销售数据存储在 year=2022 的目录下。
修改分区策略：
- 假设将分区策略改为按月（year/month）进行分区。
- 新的分区策略会将数据细分为每个月。
- 现在表结构将会有两个分区策略。
- 2021年、2022年、2023年的旧数据仍然采用老的分区策略，即按 year 分区。
- 这些数据会保留在原有的分区结构中，例如：
  - year=2021
  - year=2022
  - year=2023
- 新加载的数据将会使用新的分区策略，即按 year/month 进行分区。
- 例如，2023年4月的新数据将存储在：
  - year=2023/month=04 的目录下。