apache iceberg 数据湖

理解

首先，大家要明白为什么出现了类似Iceberg这样的数据技术。
大数据领域发展至今已经经历了相当长时间的发展和探索，虽然大数据技术的出现和迭代降低了用户处理海量数据的门槛，但是有一个问题不能忽视，数据格式对不同引擎适配的对接。
这句话是什么意思呢？
我们在使用不同的引擎进行计算时，需要将数据根据引擎进行适配。这是相当棘手的问题
为此出现了一种新的解决方案：
介于上层计算引擎和底层存储格式之间的一个中间层。这个中间层不是数据存储的方式，只是定义了数据的元数据组织方式，并且向引擎层面提供统一的类似传统数据库中"表"的语义。它的底层仍然是Parquet、ORC等存储格式。
基于此，Netflix开发了Iceberg，目前已经是Apache的顶级项目。

介绍

Apache Iceberg 是一种开放的表格格式，专为巨大的 PB 级表格而设计。表格格式的功能是确定您如何管理、组织和跟踪构成表格的所有文件。您可以将其视为物理数据文件（用 Parquet 或 ORC 等编写）以及它们如何构建以形成表格之间的抽象层。
该项目最初是在 Netflix 开发的，目的是解决长期存在的 PB 级大表使用问题。它于 2018 年作为 Apache 孵化器项目开源，并于 2020 年 5 月 19 日从孵化器毕业。
Netflix用内部的一个时序数据业务的案例来说明Hive的这些问题，采用Hive时按照时间字段做partition，他们发现仅一个月会产生2688个partition和270万个数据文件。他们执行一个简单的select查询，发现仅在分区裁剪阶段就耗费数十分钟。

hive存在的问题

1、Hive的元数据依赖一个外部的MySQL和HDFS文件系统，通过MySQL找到相关的parition之后，需要为每个partition去HDFS文件系统上按照分区做目录的list操作在文件量大的情况下，这是一个非常耗时的操作
2、hive元数据分属MySQL和HDFS管理，写入操作本身的原子性难以保证。即使在开启Hive ACID情况下，仍有很多细小场景无法保证原子性。
3、Hive Metastore没有文件级别的统计信息，无法追踪到文件级别，这使得filter谓词只能下推到partition级别，而无法下推到文件级别，对上层分析性能损耗无可避免。
Iceberg通过使用持久树结构跟踪表中所有文件的完整列表来避免这种情况。对表的更改使用原子（对象/文件）级提交来更新包含所有单个数据文件位置的新元数据文件的路径
Iceberg 跟踪单个文件而不是文件夹的另一个优点是不再需要昂贵的list操作，这会在执行查询表中的数据等操作时提高性能。

iceberg数据组织

iceberg文件

1、Snapshot metadata file( /metadata/v9.metadata.json)：包含有关表的元数据，如表架构、分区规范以及清单列表的路径。
2、Manifest list(/metadata/snap-1690829998331847164-1-5655e629-c39e-4e6b-825a-dca3bf5b814a.avro)：包含与快照关联的每个清单文件的条目。每个条目都包含清单文件的路径和有关该文件的一些元数据，包括分区统计信息和数据文件计数。这些统计信息可用于避免读取操作不需要的清单。
3、Manifest file(/metadata/5655e629-c39e-4e6b-825a-dca3bf5b814a-m2.avro)：包含相关数据文件的路径列表。数据文件的每个条目都包含一些关于文件的元数据，例如每列的上限和下限，可用于在查询计划期间修剪文件。
4、Data file(/data/level=1/00000-811-f7539dc8-534e-4d29-a563-3de7f8b35c9d-00001.parquet)：物理数据文件，以 Parquet、ORC、Avro 等格式编写。

iceberg schema 修改理解

Iceberg保证更改是独立的且没有副作用。Iceberg 使用唯一 ID 来跟踪schema 中的每个字段，并将字段名称映射到 ID。这意味着您可以更改字段的名称，但 Iceberg读取底层数据仍将使用与每个字段关联的 ID。

Partition Evolution

由于Iceberg实现了隐藏分区，因此Iceberg还可以提供分区规范演变的特性。这意味着您可以在不破坏表的情况下更改分区的粒度或列。分区演变是一种元数据操作，不会重写文件，因此旧数据可以与任何新数据在表中共存。Iceberg实现了分割计划——Iceberg使用旧规范为第一组数据执行查询计划，然后使用新规范为第二组数据执行第二个查询计划，然后合并所有文件。

image.png

在上面的图表中，booking_table最初是按月(日期)进行分区的，直到partition spec更改为日(日期)的2009-01-01。旧数据保持旧分区格式，所有新数据都以新格式写入。当运行示例查询时，Iceberg为每个分区规范执行分割计划，并可以通过对日期列应用月或日转换来过滤两种spec下的分区。

Time travel

如前所述，Iceberg保留表以前快照的日志，这允许执行时间旅行查询或表回滚。iceberg为spark3.x提供了全部功能的实现
通过Spark可以访问快照日志数据:

spark.read
     .format("iceberg")
     .load("bookings.rome_hotels.snapshots")
     .show(truncate = false)

image.png

查询指定快照数据，回滚操作

spark.read
    .format("iceberg")
    .option("snapshot-id", 1624021260521L) #Using snapshot ID
    .load("bookings.rome_hotels")
spark.read
    .format("iceberg")
    .option("as-of-timestamp", "1624021260521") #Using timestamp
    .load("bookings.rome_hotels")
table.rollback()
     .toSnapshotId(1624021260521L)
     .commit();
table.rollback()
     .toSnapshotAtTime(1624021260521)
     .commit();

参考
https://iceberg.apache.org/spark-procedures/
https://medium.com/expedia-group-tech/a-short-introduction-to-apache-iceberg-d34f628b6799
https://jishuin.proginn.com/p/763bfbd3950b