Apache Iceberg详解

一、产生背景

1.众多计算引擎难以适配

在使用不同的引擎进行大数据计算时，需要将数据根据计算引擎进行适配。这是一个相当棘手的问题，需要一个介于上层计算引擎和底层存储格式之间的一个中间层。这个中间层不是数据存储的方式，只是定义了数据的元数据组织方式，并向计算引擎提供统一的类似传统数据库中"表"的语义。它的底层仍然是Parquet、ORC等存储格式。

2.数据组织方式的掣肘

从Hadoop诞生至今，数据的存储格式经历了几代的发展，而数据组织方式的发展却相当缓慢。

Hive提出了分区的概念，利用某几个column作为分区值来组织数据，能够有效地过滤掉无需读取的数据，这种分区在物理存储上反映出来的就是按照文件夹进行分区（组织）数据。利用文件夹来组织与HDFS的文件系统结构有天然的亲和性，这一方式也一直被沿用下来。

随着大数据和云计算的结合，越来越多的底层存储系统从HDFS这样的分布式文件系统换成了云上的对象存储系统，而这种利用文件夹来组织数据的方式在对象存储上遇到了极大的挑战：

1. 利用对象存储来模拟文件系统从而提供文件夹遍历的方式非常低效，而传统的分区计算中又大量地依赖遍历操作。

2. 基于文件、文件夹的rename来保证原子性的语义在某些对象存储上是有问题的（如S3)。同时有的对象存储对于rename的实现有巨大的开销。

3.元数据的存取问题

集中式的元数据服务能够更好地管理整个数仓的元数据信息，但也带来了几个问题：

1. 元数据和数据的分离式存储容易造成不一致性。比如在HDFS上对数据进行了某些删除、改动，但是metastore并不能感知到数据的变化从而造成两边的不一致。

2. 集中式的元数据管理对于大规模的企业级应用容易形成单点瓶颈。所以的元数据都需要通过metastore来存取，极易造成metastore的压力，从而极大地延长query plan的时间。

基于此，Netflix开发了Iceberg

二、Iceberg定义

Iceberg是一个通用的表格式（数据组织格式），它可以适配Presto，Spark等引擎，提供高性能的读写和元数据管理功能。是介于计算引擎（Flink , Spark）和存储格式（ORC，Parqurt，Avro）中间的数据组织格式，通过特定的方式将数据和元数据组织起来。

在文件Format（parquet/avro/orc等）之上实现Table语义：

ACID语义

支持定义和变更Schema

支持Hidden Partition和Partition变更

历史版本回溯

借助partition和columns统计信息实现分区裁剪

不绑定任何存储引擎，可拓展到HDFS/S3/OSS等

容许多个writer并发写入,乐观锁机制解决冲突

三、Iceberg术语

• data files（数据文件）:

数据文件是Apache Iceberg表真实存储数据的文件，一般是在表的数据存储目录的data目录下；Iceberg每次更新会产生多个数据文件(data files)。

• Snapshot（表快照）：

快照代表一张表在某个时刻的状态。每个快照里面会列出表在某个时刻的所有 data files 列表。data files是存储在不同的manifest files里面，manifest files是存储在一个Manifest list文件里面，而一个Manifest list文件代表一个快照。

• Manifest list（清单列表）：

manifest list是一个元数据文件，它列出构建表快照（Snapshot）的清单（Manifest file）。这个元数据文件中存储的是Manifest file列表，每个Manifest file占据一行。每行中存储了Manifest file的路径、其存储的数据文件（data files）的分区范围，增加了几个数据文件、删除了几个数据文件等信息，这些信息可以用来在查询时提供过滤，加快速度。

• Manifest file（清单文件）：