4. 元数据管理：Catalog 是什么？Hive Metastore、Hadoop、REST 三种 Catalog 怎么选？
聊到 Iceberg，很多人第一反应是「表格式」。没错，它确实是。但真正让 Iceberg 跑起来的，是它背后的元数据管理——也就是 Catalog。
说白了，Catalog 就是 Iceberg 的「通讯录」。它记录了哪个表存在、表有哪些版本、数据文件在哪。没有它，Iceberg 就是个空壳子。
我刚开始接触 Iceberg 时，也踩过 Catalog 的坑。当时选型没想清楚，上线后才发现性能瓶颈。嗯，今天我们就把这三种 Catalog 掰开揉碎讲清楚。
4.1 Catalog 的核心职责
先搞清楚 Catalog 到底管什么。它主要做三件事：
- 表注册与发现：记录表名、表路径、表 Schema。查询引擎通过 Catalog 找到表。
- 元数据指针管理：每个 Iceberg 表都有一个当前元数据文件指针。Catalog 负责维护这个指针的原子性更新。
- 多版本控制：Iceberg 的每次写入都会生成新的元数据文件。Catalog 要保证并发写入时指针不冲突。
一句话总结：Catalog 是 Iceberg 表的「注册中心」+「版本管理器」。没有它，Spark、Flink、Trino 根本找不到表在哪。
4.2 三种 Catalog 的对比
目前主流的有三种：Hive Metastore、Hadoop、REST。我一个个说。
4.2.1 Hive Metastore Catalog
这是最传统的方式。它把 Iceberg 表的元数据信息存储在 Hive Metastore 的表中。每次查询时，引擎先去 Hive Metastore 拿到元数据文件路径，再读取 Iceberg 的元数据。
优点：
- 兼容性好。Spark、Hive、Flink 都原生支持。
- 部署简单。如果你已经有 Hive 集群，直接复用。
缺点：
- 性能瓶颈。Hive Metastore 本身是单点服务，高并发时容易成为瓶颈。
- 功能受限。只支持基本的表操作，不支持 Namespace 管理、权限控制等高级功能。
我的经验：如果你团队规模不大，查询并发不高，Hive Metastore 是最省事的方案。我曾经在一个 10 人数据团队里用过，半年没出过问题。
4.2.2 Hadoop Catalog
这个更轻量。它直接把元数据信息存储在文件系统上（HDFS、S3、OSS）。每个表对应一个目录，目录下有个 .metadata 文件夹，里面放着元数据文件。
优点：
- 无中心化服务。不依赖任何外部系统，只要文件系统可用就行。
- 适合测试和开发环境。快速搭建，用完就删。
缺点：
- 不支持并发写入。多个引擎同时写同一个表时，元数据指针会冲突。
- 没有事务保证。文件系统本身不支持原子性操作。
注意：Hadoop Catalog 只适合单机测试或低并发场景。生产环境千万别用。我曾经见过有人用它做线上服务，结果并发写入时表直接坏了。
4.2.3 REST Catalog
这是 Iceberg 社区推荐的方式。它定义了一套 RESTful API，任何语言都可以实现。元数据服务独立部署，通过 HTTP 接口与引擎交互。
优点：
- 高性能。可以水平扩展，支持高并发。
- 功能丰富。支持 Namespace、权限控制、审计日志等。
- 跨语言。Java、Python、Go 都能对接。
缺点：
- 需要额外部署服务。增加了运维成本。
- 网络延迟。每次元数据操作都要走 HTTP 请求。
我的建议：新项目直接上 REST Catalog。虽然初期部署麻烦点，但后期扩展性、稳定性都好很多。我现在的团队全部用 REST Catalog，配合 Trino 查询，延迟控制在 10ms 以内。
4.3 三种 Catalog 的选型对比表
| 维度 | Hive Metastore | Hadoop | REST |
|---|---|---|---|
| 部署复杂度 | 低（复用 Hive） | 极低（文件系统） | 中（独立服务） |
| 并发能力 | 中（单点瓶颈） | 低（无事务） | 高（可水平扩展） |
| 功能丰富度 | 低 | 极低 | 高 |
| 适用场景 | 中小团队、已有 Hive | 测试、开发 | 生产环境、大规模 |
| 推荐指数 | ⭐⭐⭐ | ⭐ | ⭐⭐⭐⭐⭐ |
4.4 核心架构图
下面这张图展示了三种 Catalog 在 Iceberg 架构中的位置。你可以看到，Catalog 是连接查询引擎和元数据文件的桥梁。
4.5 选型建议
你可能会问：「那我到底该选哪个？」
我的建议很简单：
- 如果你是新项目：直接上 REST Catalog。别犹豫。虽然初期部署麻烦点，但后期省心很多。
- 如果你已有 Hive 集群：可以先从 Hive Metastore 开始，等业务量上来后再迁移到 REST Catalog。
- 如果你只是做测试：Hadoop Catalog 够用了。用完就删，不占资源。
避坑指南：我曾经在一个项目里用 Hive Metastore 做生产，结果并发查询一上来，Hive Metastore 直接挂了。后来换成 REST Catalog，配合缓存，性能提升了 5 倍。所以，别在并发场景下用 Hive Metastore。
4.6 配置示例
最后，给个配置示例。你可以在 Spark 或 Flink 中这样配置 Catalog：
-- Hive Metastore 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://metastore-host:9083
-- Hadoop Catalog
spark.sql.catalog.my_catalog = org.apache.iceberg.spark.SparkCatalog
spark.sql.catalog.my_catalog.type = hadoop
spark.sql.catalog.my_catalog.warehouse = s3://my-bucket/warehouse
-- REST 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://catalog-service:8080/iceberg
嗯，Catalog 就讲到这里。记住一句话：选型看场景，生产用 REST。下次我们聊聊 Iceberg 的元数据文件结构，看看它到底是怎么做到「快照隔离」和「时间旅行」的。