Iceberg Catalogs
catalog是Iceberg对表进行管理（create、drop、rename等）的一个组件。目前Iceberg主要支持HiveCatalog和HadoopCatalog两种Catalog。
- HiveCatalog将当前表metadata文件路径存储在hive Metastore，这个表metadata文件是所有读写Iceberg表的入口，所以每次读写Iceberg表都需要先从hive Metastore中取出对应的表metadata文件路径，然后再解析这个Metadata文件进行接下来的操作。
- HadoopCatalog将当前表metadata文件路径记录在一个文件目录下，因此不需要连接hive Metastore。
Hive Catalog
创建一个名为hive_catalog的 iceberg catalog ，用来从 hive metastore 中加载表。
CREATE CATALOG hive_catalog WITH ( 'type'='iceberg', 'catalog-type'='hive', 'uri'='thrift://localhost:9083', 'clients'='5', 'property-version'='1', 'warehouse'='hdfs://nn:8020/warehouse/path' );
- type: 只能使用iceberg,用于 iceberg 表格式。(必须)
- catalog-type: Iceberg 当前支持hive或hadoopcatalog 类型。(必须)
- uri: Hive metastore 的 thrift URI。 (必须)
- clients: Hive metastore 客户端池大小，默认值为 2。 (可选)
- property-version: 版本号来描述属性版本。此属性可用于在属性格式发生更改时进行向后兼容。当前的属性版本是 1。(可选)
- warehouse: Hive 仓库位置, 如果既不将 hive-conf-dir 设置为指定包含 hive-site.xml 配置文件的位置，也不将正确的 hive-site.xml 添加到类路径，则用户应指定此路径。
- hive-conf-dir: 包含 Hive-site.xml 配置文件的目录的路径，该配置文件将用于提供自定义的 Hive 配置值。 如果在创建 iceberg catalog 时同时设置 hive-conf-dir 和 warehouse，那么将使用 warehouse 值覆盖 < hive-conf-dir >/hive-site.xml (或者 classpath 中的 hive 配置文件)中的 hive.metastore.warehouse.dir 的值。
Hadoop catalog
ceberg 还支持 HDFS 中基于目录的 catalog ，可以使用’catalog-type’='hadoop’进行配置：
CREATE CATALOG hadoop_catalog WITH ( 'type'='iceberg', 'catalog-type'='hadoop', 'warehouse'='hdfs://nn:8020/warehouse/path', 'property-version'='1' );
• warehouse：hdfs目录存储元数据文件和数据文件。（必须）
为什么选择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的依赖，问题并不大。
