在介绍如何使用Iceberg之前，先简单地介绍一下Iceberg catalog的概念。catalog是Iceberg对表进行管理（create、drop、rename等）的一个组件。目前Iceberg主要支持HiveCatalog和HadoopCatalog两种Catalog。其中HiveCatalog将当前表metadata文件路径存储在Metastore，这个表metadata文件是所有读写Iceberg表的入口，所以每次读写Iceberg表都需要先从Metastore中取出对应的表metadata文件路径，然后再解析这个Metadata文件进行接下来的操作。而HadoopCatalog将当前表metadata文件路径记录在一个文件目录下，因此不需要连接Metastore。

在下述案例中，笔者会分别使用HiveCatalog和HadoopCatalog创建Iceberg表并进行读写操作，再结合案例在下一篇文章中介绍两者的不同之处。

在Iceberg官方下载页面（http://iceberg.apache.org/releases/）下载Iceberg Spark runtime Jar。目前社区已经发布了两个版本：apache-iceberg-0.7.0-incubating和0.8.0-incubating，建议下载最新的0.8.0版本。这里需要注意的是，Iceberg在使用上就是一个Jar包，这个Jar包可以放在Spark的Jars目录下，然后就可以使用Spark创建Iceberg表、将数据导入Iceberg表中以及从Iceberg表中查询。另外需要注意的一点是，目前Iceberg仅支持Spark 2.4版本。

我们先将下载的iceberg-spark-runtime-0.8.0-incubating.jar放到spark的classpath下，然后启动spark-shell：

1.使用Spark创建Iceberg表

使用HiveCatalog创建Iceberg表之前需要先在Hive中创建对应的数据库，否则执行建表语句的话会报错。下面是完整的建表语句：

建好表后可以在hive查询到创建的表：

2.使用Spark导入数据到Iceberg表

 iceberg表建好之后，就可以使用spark将数据导入Iceberg表中。下面是完整的示例：

3.使用Spark查询Iceberg表

基于HadoopCatalog的用法与HiveCatalog基本相同，主要的区别在于建表的时候稍有不同，如下所示：

​​​​​​​

导入和查询的时候也有一点区别：

1.HiveCatalog

其中data目录下存储数据文件，metadata目录下存储元数据文件。

2.metadata目录

其中00001-62ade8ab-c1cf-40d3-bc21-fd5027bc3a55.metadata.json中存储表的schema、partition spec以及当前snapshot manifests文件路径。snap-6771375506965563160-1-bb641961-162a-49a8-b567-885430d4e799.avro存储manifest文件路径。bb641961-162a-49a8-b567-885430d4e799-m0.avro记录本次提交的文件以及文件级别元数据。

3.data目录

4.HadoopCatalog

Hadoopcatalog与Hivecatalog的的data目录完全相同，metadata目录下文件稍有不同，HadoopCatalog管理的metadata目录如下所示：

说明该表的最新snapshot_id是2，即对应的snapshot元数据文件是v2.metadata.json，解析v2.metadata.json可以获取到该表当前最新snapshot对应的schema、partition spec、父snapshot以及该snapshot对应的manifestList文件路径等，因此version-hint.text是HadoopCatalog获取当前snapshot版本的入口。

阅读到这里，读者可能就会问了，HiveCatalog的metadata目录下并没有version-hint.text文件，那它获取当前snapshot版本的入口在哪里呢？它的入口在Metastore中的schema里面，读者可以在HiveCatalog建表schema中的TBPROPERTIES中有个key是"metadata_location"，对应的value就是当前最新的snapshot文件。因此，有两点需要说明：

HiveCatalog创建的表，每次提交写入文件生成新的snapshot后都需要更新Metastore中的metadata_location字段。

HiveCatalog和HadoopCatalog不能混用。即使用HiveCatalog创建的表，再使用HadoopCatalog是不能正常加载的，反之亦然。

上面说到Iceberg目前支持两种Catalog，而且两种Catalog相互不兼容。那这里有两个问题：

社区是出于什么考虑实现两种不兼容的Catalog？

因为两者不兼容，必须选择其一作为系统唯一的Catalog，那是选择HiveCatalog还是HadoopCatalog，为什么？

先回答第一个问题。社区是出于什么考虑实现两种不兼容的Catalog？

在回答这个问题之前，首先回顾一下上一篇文章中介绍到的基于HadoopCatalog，Iceberg实现数据写入提交的ACID机制，最终的结论是使用了乐观锁机制和HDFS rename的原子性一起保障写入提交的ACID。如果某些文件系统比如S3不支持rename的原子性呢？那就需要另外一种机制保障写入提交的ACID，HiveCatalog就是另一种不依赖文件系统支持，但是可以提供ACID支持的方案，它在每次提交的时候都更新MySQL中同一行记录，这样的更新MySQL本身是可以保证ACID的。这就是社区为什么会支持两种不兼容Catalog的本质原因。

再来回答第二个问题。HadoopCatalog依赖于HDFS提供的rename原子性语义，而HiveCatalog不依赖于任何文件系统的rename原子性语义支持，因此基于HiveCatalog的表不仅可以支持HDFS，而且可以支持s3、oss等其他文件系统。但是HadoopCatalog可以认为只支持HDFS表，比较难以迁移到其他文件系统。但是HadoopCatalog写入提交的过程只依赖HDFS，不和Metastore/MySQL交互，而HiveCatalog每次提交都需要和Metastore/MySQL交互，可以认为是强依赖于Metastore，如果Metastore有异常，基于HiveCatalog的Iceberg表的写入和查询会有问题。相反，HadoopCatalog并不依赖于Metastore，即使Metastore有异常，也不影响Iceberg表的写入和查询。

考虑到我们目前主要还是依赖HDFS，同时不想强依赖于Metastore，所以我们选择HadoopCatalog作为我们系统唯一的Catalog。即使有一天，想要把HDFS上的表迁移到S3上去，也是可以办到的，大家想想，无论是HadoopCatalog还是HiveCatalog，数据文件和元数据文件本身都是相同的，只是标记当前最新的snapshot的入口不一样，那只需要简单的手动变换一下入口就可以实现Catalog的切换，切换到HiveCatalog上之后，就可以摆脱HDFS的依赖，问题并不大。

上一篇介绍Iceberg的文章中讲到了Iceberg写入数据文件提交snapshot的时候会依次生成manifest文件、manifestList文件以及snapshot文件，那这些元数据文件中都存放什么记录呢？如果使用HiveCatalog创建的表，可以直接使用spark读出相关元数据记录。如果是HadoopCatalog创建的表，暂时不能直接使用spark读出相关信息，但是也可以使用文件解析器解析出相关元数据文件内容。

下文基于HiveCatalog建表模式介绍Iceberg相关元数据：

本文基于上一篇介绍Iceberg入门的文章，介绍了如何使用Iceberg进行简单的创建表、往表中写数据、查询表数据以及表中元数据。同时也介绍了HadoopCatalog和HiveCatalog的不同以及我们选择HadoopCatalog的一些想法。