FileIO 是 Iceberg 库和底层存储之间的主要接口,与 Hive 等组件不同的是,Iceberg 不引用目录,它追踪了表在文件级别的完整状态,通过 FileIO 可以从最顶层的元数据直达底层存储。

二、设计

2.1. 云原生 I/O 架构

Iceberg 之所以可以利用像 FileIO 这样的简洁接口,是因为所有的位置信息在元数据结构中都是显式的、不可变的和绝对的。Iceberg 不引用目录,它从文件级别跟踪了表的完整状态。因此,从元数据层次结构的最顶层,可以直达任何存储位置,而无需进行 $File\ Listing$ 操作。同样,提交动作是向元数据树添加一个完全可访问且不需要重命名操作的新分支。

Iceberg 和 Hudi 最大区别:

Hudi 本身是要强化 Hadoop 的能力,而 Iceberg 是要绕开 Hadoop 拥抱云。

在文件级别跟踪数据还允许 Iceberg 完全抽象物理布局。分区信息以文件级别存储在元数据中,因此物理位置完全独立于逻辑结构。这种分离机制可以通过底层数据的转换支持隐藏分区。
元数据操作在计划和提交阶段执行,其中读取和写入元数据文件(metadata file)、清单列表(manifest list) 和 清单(manifest)等文件。在 Iceberg 库中,这些操作完全通过 FileIO API 进行。在某些情况下,这些文件是由 workers 读取的(例如,元数据表的分布式处理),但为了简化描述,我们暂时忽略这些差异,因为所有元数据都流经 FileIO 之手。
数据操作与计算引擎在任务处理期间读取和写入数据的位置有关。任务使用 FileIO 接口来读取和写入底层数据文件。在提交过程中收集这些文件的位置并将其添加到表元数据中。值得注意的是,并不是所有的读写操作都需要经过这条路径,因此引擎可以自定义它们与数据交互的方式。最终,读取位置由核心 Iceberg 库提供,输出位置被收集以重新提交回表中。

三、实现

Iceberg 有多个 FileIO 实现,但从广义上讲,它们可以分为两类: HadoopFileIO 和原生 FileIO 实现。

3.1. HadoopFileIO

HadoopFileIO 在任何现有的 Hadoop 文件系统实现(HDFS、S3 等)和 Iceberg 的 FileIO API 之间提供了一个适配器层。这意味着任何具有 Hadoop 文件系统实现的存储系统都可以与 Iceberg 一起使用。

3.2. 原生 FileIO

3.2.1. OSSFileIO