4. Catalog 选型实战：Hive Catalog、Hadoop Catalog、REST Catalog 对比与最佳实践
Catalog 是什么？说白了，它就是 Iceberg 的「元数据中心」。你想想看，一张 Iceberg 表存在哪个路径、有哪些快照、Schema 长什么样——这些信息都得有个地方存。Catalog 就是干这个的。
选错 Catalog，后面调优会非常痛苦。我在项目中见过不少团队，一开始随便选了个 Catalog，结果到了生产环境发现性能瓶颈、权限难控、跨集群迁移困难……最后不得不重来。今天我就把三种主流 Catalog 的优缺点、适用场景、以及我个人的选型建议，一次性讲清楚。
4.1 三种 Catalog 的核心差异
先看一张对比表，快速建立整体认知：
| 特性 | Hive Catalog | Hadoop Catalog | REST Catalog |
|---|---|---|---|
| 元数据存储 | Hive Metastore (MySQL/PostgreSQL) | 文件系统 (HDFS/S3/OSS) | REST 服务后端（可自选存储） |
| 依赖组件 | Hive Metastore 服务 | 无额外服务依赖 | REST Server（如 Nessie、Polaris） |
| 多引擎支持 | Spark、Flink、Trino、Hive | Spark、Flink、Trino | 所有支持 REST 协议的引擎 |
| 跨集群访问 | 困难（依赖 Hive Metastore 网络） | 困难（依赖文件系统挂载） | 原生支持（HTTP 协议） |
| 权限控制 | 依赖 Hive 的 Ranger/Sentry | 依赖文件系统 ACL | 服务端可自定义 |
| 运维复杂度 | 中等（需维护 HMS） | 低（无额外服务） | 高（需维护 REST Server） |
4.2 Hive Catalog：最成熟，但也是「历史包袱」
Hive Catalog 是目前使用最广泛的 Iceberg Catalog。它把元数据存在 Hive Metastore（HMS）里，表结构、分区信息、快照位置都通过 HMS 的 API 来读写。
优点很明显：
- 与 Hive 生态无缝集成。如果你团队已经有 Hive 数仓，迁移成本几乎为零。
- 支持引擎最全。Spark、Flink、Trino、Hive 都能直接读写。
- 权限体系成熟。可以用 Ranger 或 Sentry 做细粒度权限控制。
但坑也不少：
- HMS 本身是单点瓶颈。我遇到过 HMS 的 QPS 被打满，导致整个集群的建表、查询都变慢。
- 跨集群访问非常麻烦。两个集群要共享同一个 HMS，网络延迟和稳定性都是问题。
- HMS 的元数据格式是 Hive 的，Iceberg 的一些高级特性（如分支、标签）无法原生表达。
适用场景：
- 已有 Hive 数仓，需要平滑迁移到 Iceberg。
- 团队对 Hive 生态依赖很深（如 HiveQL、UDF、SerDe）。
- 单集群部署，不需要跨集群共享表。
4.3 Hadoop Catalog：轻量级，但功能有限
Hadoop Catalog 是最简单的实现。它把元数据直接以文件形式存储在文件系统上（如 HDFS、S3、OSS）。每个 Iceberg 表对应一个目录，目录下有一个 metadata 文件夹，里面存着 version-hint.text 和 v1.metadata.json 等文件。
优点：
- 零依赖。不需要额外部署任何服务，只要文件系统可用就行。
- 部署极简。适合测试环境、小规模场景。
- 元数据文件可以直接查看。调试时很方便。
缺点也很致命：
- 没有事务保证。多个客户端同时写元数据时，可能产生冲突。
- 不支持多表原子操作。比如同时提交多个表的快照，Hadoop Catalog 做不到。
- 性能差。每次元数据操作都要读写文件系统，延迟比 HMS 高一个数量级。
- 权限控制弱。只能依赖文件系统的 ACL，无法做到表级、列级权限。
适用场景：
- 本地开发测试。
- 单机或小规模集群，对元数据一致性要求不高。
- 临时性的数据探索任务。
4.4 REST Catalog：未来趋势，但需要额外投入
REST Catalog 是 Iceberg 社区力推的新一代 Catalog 实现。它通过 HTTP REST API 暴露元数据操作，后端可以对接任何存储系统（如 JDBC、RocksDB、甚至内存）。
核心优势：
- 跨平台、跨语言。任何支持 HTTP 的客户端都能访问，不限于 JVM 生态。
- 原生支持 Iceberg 高级特性。分支、标签、时间旅行等操作在 REST Catalog 中都有标准 API。
- 服务端可扩展。你可以自己实现权限、审计、缓存等逻辑。
- 多集群共享。通过 REST 服务，不同集群可以访问同一套元数据。
但代价也不小：
- 需要额外部署和维护 REST Server。目前比较成熟的有 Nessie、Polaris、Tabular。
- 网络延迟。每次元数据操作都要走 HTTP 请求，延迟比本地 HMS 高。
- 生态还在完善中。部分引擎对 REST Catalog 的支持还不够稳定。
适用场景：
- 新建数据平台，没有历史包袱。
- 需要跨集群、跨地域共享元数据。
- 需要细粒度权限控制和审计。
- 团队有运维 REST 服务的能力。
4.5 选型决策流程
我整理了一个简单的决策流程，你可以照着走一遍：
- 是否有 Hive 生态依赖？——是，选 Hive Catalog；否，进入下一步。
- 是否需要跨集群访问？——是，选 REST Catalog；否，进入下一步。
- 团队是否有运维能力？——是，选 REST Catalog；否，选 Hive Catalog。
- 是否只是开发测试？——是，可以用 Hadoop Catalog 临时顶一下。
嗯，这个流程不复杂。但实际项目中，往往会有一些「灰色地带」。比如你既有 Hive 依赖，又需要跨集群访问——这时候可以考虑用 REST Catalog 包装一层，后端对接 HMS。这样既保留了 Hive 生态，又获得了 REST 的跨集群能力。
4.6 实战配置示例
最后，我给出三种 Catalog 的 Spark 配置示例，方便你直接复制使用。
Hive Catalog 配置：
spark.sql.catalog.my_catalog = org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.my_catalog.type = hive
spark.sql.catalog.my_catalog.uri = thrift://hive-metastore:9083
spark.sql.catalog.my_catalog.warehouse = hdfs://namenode:8020/user/hive/warehouseHadoop Catalog 配置：
spark.sql.catalog.my_catalog = org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.my_catalog.type = hadoop
spark.sql.catalog.my_catalog.warehouse = s3a://my-bucket/iceberg-warehouseREST Catalog 配置：
spark.sql.catalog.my_catalog = org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.my_catalog.type = rest
spark.sql.catalog.my_catalog.uri = http://rest-catalog-server:8080/iceberg
spark.sql.catalog.my_catalog.warehouse = my_warehousewarehouse 参数不是文件系统路径，而是 REST 服务端定义的仓库标识。具体值需要跟你的 REST Server 管理员确认。
好了，Catalog 选型就讲到这里。记住一句话：选型不是选最好的，而是选最适合你当前场景的。Hive Catalog 稳，Hadoop Catalog 轻，REST Catalog 活——你根据自己团队的实际情况来定。