1. Catalog集群概述
1.1 什么是Catalog集群
Catalog集群是数据湖/数据仓库体系中的元数据与索引中心层，负责统一管理表结构、分区、文件路径、统计信息以及辅助查询加速的索引数据。在存算分离架构下，Catalog集群独立于计算引擎部署，为上层查询引擎（如Trino、Spark、Hive）提供一致的元数据视图和高效的索引服务。
核心定位：Catalog集群不是存储原始数据的系统，而是存储“数据的数据”——即元数据与索引。它决定了查询引擎能否快速定位目标数据，是数据湖性能的关键瓶颈之一。
1.2 核心组件
Catalog集群由三个核心组件构成，各组件职责明确，协同工作：
| 组件 | 职责 | 典型实现 | 容量敏感指标 |
|---|---|---|---|
| 元数据存储 | 持久化表Schema、分区信息、文件列表、事务日志 | Hive Metastore (MySQL/PostgreSQL)、AWS Glue、HBase | 存储容量、QPS、事务吞吐量 |
| 索引服务 | 构建和维护二级索引、布隆过滤器、位图索引，加速数据过滤 | Apache Hudi索引、自研索引引擎、Elasticsearch | 索引存储量、构建延迟、查询命中率 |
| 查询引擎 | 解析SQL、生成执行计划、通过元数据和索引下推优化数据扫描 | Trino Coordinator、Spark Driver、Presto | 并发连接数、计划生成耗时、缓存命中率 |
1.3 典型部署架构
Catalog集群通常采用分层解耦的部署模式，各组件可独立扩缩容。以下为最常见的三节点部署架构：
1.4 部署模式对比
根据业务规模和容灾要求，Catalog集群可选择以下部署模式：
| 部署模式 | 节点数 | 适用场景 | 容量评估要点 |
|---|---|---|---|
| 单节点 | 1 | 开发测试、小规模数据湖（表数 < 1000） | 单机内存/磁盘上限，无高可用 |
| 主备模式 | 2 | 中小规模生产环境（表数 1000~5000） | 主节点容量 + 备节点同步延迟 |
| 三节点集群 | 3 | 大规模生产环境（表数 > 5000，高并发） | 各组件独立扩缩容，需评估网络带宽 |
| 多活/跨地域 | ≥4 | 全球化部署、异地容灾 | 跨地域延迟、数据一致性、成本 |
容量水位评估前置条件：在开始评估Catalog集群容量水位之前，必须明确当前集群的部署模式、各组件版本以及业务峰值QPS。不同部署模式下，同一组件的容量瓶颈表现差异巨大，例如单节点模式下元数据存储的CPU使用率超过80%即视为高水位，而三节点集群可容忍至90%以上。
1.5 组件间交互流程
一次典型查询的Catalog交互流程如下：
- 查询接入：查询引擎（如Trino Coordinator）接收SQL请求。
- 元数据获取：查询引擎向元数据存储请求表Schema、分区列表、文件路径。
- 索引下推：查询引擎根据过滤条件向索引服务请求匹配的文件列表（如布隆过滤器过滤掉不包含目标值的文件）。
- 计划生成：查询引擎结合元数据与索引结果，生成最优扫描计划。
- 数据扫描：查询引擎将计划下发至Worker节点，直接扫描分布式存储层中的目标文件。
容量水位关键观察点：步骤2和步骤3的响应时间直接决定了查询延迟。当元数据存储或索引服务的QPS接近上限时，查询引擎会出现大量等待，表现为“元数据超时”或“索引查询失败”。这是升级前必须重点评估的容量指标。