Catalogs

Introduce multi-catalog

Catalog 是一个包含了数据库，表，视图， 索引，用户和 UDF 等一系列信息的元数据空间，catalog 可以被简单理解为 table 和 database 的上一级 namespace。在实践中，一般将 catalog 指向特定类型的数据源实例或集群，在 Flink、Spark 和 Trino 中，可以通过 multi-catalog 功能来支持跨数据源的 SQL，如：

SELECT c.ID, c.NAME, c.AGE, o.AMOUNT
FROM MYSQL.ONLINE.CUSTOMERS c JOIN HIVE.OFFLINE.ORDERS o
ON (c.ID = o.CUSTOMER_ID)

过去数据湖围绕 HMS 来管理元数据，遗憾的是 HMS 不支持 multi-catalog，导致引擎在数据湖上的功能存在一定限制，比如有些用户希望用 spark 通过指定 catalog 名称在不同 Hive 集群之间做联邦计算，需要用户在上层重构一套 Hive catalog plugin。其次，数据湖格式正在从 Hive 单极走向 Iceberg，Delta 以及 Hudi 多家争鸣的格局，新型的数据湖 format 对公有云更加友好，也会促进数据湖上云的进程，在这些背景下，需要一套面向 multi-catalog 的管理系统帮助用户治理不同环境，不同 format 的数据湖。

用户可以在 Arctic 中为不同环境，不同集群以及不同的 table format 创建 catalog，再利用 Flink、Spark、Trino 的 multi-catalog 功能实现多集群、多格式的联邦计算。同时，配置在 catalog 中的属性可以被所有表和用户共享，避免了重复设置。Arctic 通过 multi-catalog 的设计，为数据平台提供元数据中心的支持。

AMS 和 HMS 协同使用时，相当于使用 HMS 作为 AMS 的存储底座，结合 native Iceberg format，用户可以在不引入任何 Arctic 依赖的情况下，使用 AMS 的 multi-catalog 管理功能。

How to use

在 Arctic v0.4 之后，引入了 catalog 管理功能，所有表的创建都在 catalog 下完成，用户可以在 catalogs 模块中创建，编辑和删除 catalog，创建 catalog 时需要配置 metastore，table format 以及环境配置信息，了解更多请参阅：Managing catalogs

注意

用户可以在 catalog properties 中配置给所有表配置参数，也可以在建表时指定 table properteis，在各个引擎执行时配置执行参数，这些参数的覆盖规则为：引擎优先于表，优先于 catalog。

在实践中，推荐按照下面的方式创建 catalog：

• 如果希望和 HMS 协同使用，Metastore 选择 Hive，format 根据需求选择 Mixed Hive 或 Iceberg
• 如果希望使用 Arctic 提供的 Mixed Iceberg format，Metastore 选择 Arctic

目前 Arctic catalog 创建时只能选择一种 table format，这主要考虑到引擎在使用 catalog 时会解析成特定的数据源，一对一的形式是符合直觉的，另一方面，直接使用 HMS 时可以突破这个限制，比如 Iceberg 社区提供的 SessionCatalog 实现，未来 Arctic 会考虑为用户提供更加灵活的管理方式。

Future work

AMS 未来会围绕两个目标提升元数据中心的价值：

• 扩展数据源 — 除数据湖之外，消息队列，数据库，数据仓库都可以作为 catalog 托管的对象，通过元数据中心和计算引擎基于 SQL 的联邦计算，为 DataOps、DataFabric 等数据平台提供基础设施方案
• catalog 自动感知 — 在 spark、flink 等计算引擎里能够自动感知到 catalog 的创建和变更，做到一次配置，永久扩展