Flink、Iceberg和Hive的Catalog比较研究

所谓Catalog即数据目录，简单讲，Catalog是企业用于管理数据资产的方式，Catalog借助元数据来管理数据，包括数据收集、组织、访问、发现和治理。可见，Catalog在数据资产管理中处于核心位置。元数据本身内容非常丰富，包括技术元数据、业务元数据和操作元数据，本文仅仅研究大数据计算存储框架本身的技术元数据，比如数据库、数据表、分区、视图、函数等。限于篇幅，参与比较的计算存储框架为Flink、Iceberg和Hive，比较维度为Catalog的定义、Catalog的实现和生态拓展几个方面。

Catalog接口定义

1 Flink Catalog

从Flink Catalog的接口定义来看，Flink Catalog提供了基本的数据库、数据表、函数、视图、分区的增删改查基本操作。

2 Iceberg Catalog

从Iceberg Catalog的接口定义来看，Iceberg Catalog提供了基本的表创建、表替换、表删除、表改名和表加载、查询等操作。在对外接口参数中，Iceberg使用TableIdentifier来标识一个表，TableIdentifier内部又包含一个Namespace。在Iceberg中，一个表的完整标识组成为： TableIdentifier=Namespace+table，其中Namespace是一个字符串数组，支持多层级的表修饰，第0层为table，第1层为database。

3 Hive Catalog

Hive Catalog在3.x版本以前没有Catalog 的概念，此后的版本中才勉强在Metastore中加上了一张表，专门存储Catalog，从Hive Catalog的类定义中可见，声明是相当简单的：

private String name; // required private

String description; // optional private

String locationUri; // required

其中locationUri指定了Catalog所属的数据存储路径，该属性必填。

小结

通过Catalog定义来看，Flink Catalog功能相对完善，Iceberg Catalog跟Flink Catalog相比，没有明确的对数据库相关的操作，而且也没有像Flink Catalog那样明确的表的全名称（如用database.table来标识一个表）修饰概念，而是将表的标识概念泛化。相比Flink、Iceberg的 Catalog，Hive Catalog显得”后知后觉“，因为Hive早期设计是基于database和table两级命名来实现，也没有考虑到当前蓬勃发展的联邦查询场景。

Catalog实现

1 Flink Catalog

Flink Catalog的实现有两种：Hive Catalog和Memory Catalog。两者都继承抽象的AbstractCatalog，区别是前者借助HMS来管理元数据，后者基于内存管理，Flink Job停止之后，这些数据会丢失，需要重建。

2 Iceberg Catalog

Iceberg Catalog的实现类有4种，Hive Catalog、Hadoop Catalog、CacheCatalog和JDBC Catalog。它们都继承抽象类BaseMetastoreCatalog。Hive Catalog将表的元数据信息存储在Hive Metastore，为了兼容HMS，Namespace必须包含table和database。

Hadoop Catalog将表的元数据信息存储在Hadoop之上，因为Hadoop支持存算分离，因此底层的数据文件可以是HDFS或者是S3这样的对象系统，对Hadoop Catalog来讲，定位一个表的位置，只需要提供表的路径即可，因为表的元信息都存储在文件中，比如TableIdentifier为[“test_table”,“test_db”,“test_nm1”,“test_nm2”]的表全路径为:

对Hadoop Catalog来讲，Namespace可以只有一层，即table 名称即可，它并不关心数据库的概念，只关心表的位置，但在实际应用中，为了规范管理表，建议使用规范的组织方式，具体如何组织，要看企业的行为习惯，目前没有最佳实践。

需要提醒一点的是，Hadoop Catalog构建在文件系统之上，一些文件系统不支持的操作，Catalog也无法实现，