一、引言
很多团队使用 StarRocks 的第一诉求是“把数据导进来，然后查得快”。这条路径很自然：通过 Routine Load、Stream Load、Broker Load、INSERT INTO 或 Flink Connector 把实时或离线数据写入 StarRocks 内部表，再依赖列式存储、向量化执行、MPP 并行、物化视图、分区分桶和索引能力支撑低延迟 OLAP。
但现实的数据架构通常没有这么干净。实时明细可能在 Kafka 或 StarRocks，离线大宽表可能在 Hive，增量湖表可能在 Iceberg 或 Hudi，业务维表在 MySQL 或 PostgreSQL，日志检索在 Elasticsearch。于是一个分析问题往往跨越多个系统：
一个典型分析问题：
“看过去 90 天用户行为趋势，
关联实时会员状态，
再按最近一次订单和风控标签分层。”
数据可能分散在：
StarRocks 内部表 -> 实时聚合、服务化指标
Iceberg / Hive -> 历史明细、离线宽表
MySQL / PostgreSQL -> 业务维表、配置表
Elasticsearch -> 日志、搜索型标签
如果每次跨源分析都先搬数据，工程链路会变长：同步任务、临时表、数据校验、权限对齐、口径解释都会带来成本。External Catalog 的意义在于，它把“是否搬数据”从默认动作变成架构选择：能直接查的先直接查，频繁且高价值的再缓存、物化或导入。
二、External Catalog 是什么
StarRocks 中有两类 Catalog：default_catalog管理 StarRocks 内部数据；External Catalog 用于访问外部数据源。每个 StarRocks 集群只有一个内部 Catalog，名称为 default_catalog；External Catalog 则通过外部 Metastore 让 StarRocks 直接访问外部数据源，并支持跨 Catalog 查询。
可以把 Catalog 理解为 StarRocks 的“数据命名空间 + 元数据连接器”。它解决三个核心问题：
| 问题 | Catalog 的作用 |
|---|---|
| 数据在哪里 | 通过 Catalog 名称定位内部表或外部系统 |
| 表结构怎么来 | 从 StarRocks 内部元数据或外部 Metastore 获取 |
| 查询怎么执行 | FE 基于元数据生成计划，BE/CN 并行扫描内部或外部数据 |
查询外部数据时，FE 访问外部数据源的 Metastore 获取元数据并生成执行计划；计划下发后，BE 或 CN 并行扫描外部数据、执行计算并返回结果。External Catalog 不是简单的 SQL 代理，而是把外部数据纳入 StarRocks 的分布式执行框架。
三、External Catalog 支持哪些源
StarRocks External Catalog 覆盖 Hive、Iceberg、Hudi、Delta Lake、JDBC、Elasticsearch、Paimon、Unified Catalog 等类型，其中 Elasticsearch Catalog 和 Paimon Catalog 从 v3.1 起支持，Unified Catalog 从 v3.2 起支持。JDBC Catalog 从 v3.0 起支持 MySQL 和 PostgreSQL，Oracle 和 SQL Server 分别在后续 3.2.9、3.3.1 版本加入支持，ClickHouse 以实验能力从 v3.3.0 起出现。
| Catalog 类型 | 典型数据源 | 适合场景 | 注意点 |
|---|---|---|---|
| Hive Catalog | Hive 表、HMS 元数据 | 离线数仓、历史明细、归档数据分析 | 依赖 Metastore、文件格式和存储可访问性 |
| Iceberg Catalog | Iceberg 湖表 | 湖仓表、快照表、增量数据分析 | 表版本、删除文件支持与 StarRocks 版本有关 |
| Hudi Catalog | Hudi 表 | 增量湖表、近实时湖仓 | 读性能与文件布局、Compaction 状态有关 |
| Delta Lake Catalog | Delta 表 | Delta 湖表查询 | 需核对具体版本和能力边界 |
| Paimon Catalog | Paimon 表 | 流批一体湖仓表 | 部分场景可能涉及 JNI 或格式限制 |
| JDBC Catalog | MySQL、PostgreSQL、Oracle、SQL Server 等 | 维表、配置表、小规模业务库关联 | 不适合大规模事实表扫描 |
| Elasticsearch Catalog | Elasticsearch 索引 | 搜索标签、日志索引联查 | 查询语义与 ES 映射、谓词下推能力有关 |
| Unified Catalog | Hive、Iceberg、Hudi、Delta Lake、Paimon、Kudu 等 | 同一 Metastore/Storage 下多湖表格式统一访问 | 官方标注为 Beta，且一个 Unified Catalog 只支持单一存储系统和单一 Metastore 服务 |
Unified Catalog 从 v3.2 起提供，用于把 Hive、Iceberg、Hudi、Delta Lake、Kudu 等数据源作为统一数据源处理，并可直接查询 Hive、Iceberg、Hudi、Delta Lake、Paimon、Kudu 数据而无需手工建表。 但它有明确限制：一个 Unified Catalog 只支持接入一个存储系统和一个 Metastore 服务，因此它更适合同一湖仓底座下的多格式统一访问，而不是任意异构源大拼盘。
Catalog 类型与定位
StarRocks SQL
|
+---------------+----------------+
| |
default_catalog external catalogs
StarRocks 内部表 外部数据源入口
| |
| +---------------+----------------+
| | | |
OLAP Table Lake Catalog JDBC Catalog ES Catalog
实时聚合 Hive/Iceberg MySQL/PG/... Elasticsearch
明细服务 Hudi/Paimon 维表/配置表 日志/标签
高并发查询 Delta/Kudu 小表关联 检索型分析
四、外表和 Catalog 的关系
StarRocks 早期也支持 External Table，即通过CREATE EXTERNAL TABLE在 StarRocks 中创建一张映射外部数据源的表。官方已明确提示：External Table 功能除少数边角场景外不再推荐，未来可能废弃；一般场景建议使用 External Catalog 管理和查询外部数据源。
| 维度 | External Table | External Catalog |
|---|---|---|
| 抽象层级 | 表级映射 | Catalog 级数据源接入 |
| 元数据管理 | 在 StarRocks 中建外表并维护表映射 | 连接外部 Metastore，按库表发现 |
| 推荐程度 | 官方已不推荐一般场景使用 | 官方推荐用于 Hive、Iceberg、Hudi、JDBC 等外部数据查询 |
| 典型问题 | 表多时建表和维护成本高 | 更适合统一命名空间和跨源查询 |
| 适用边界 | 少量历史兼容或特殊场景 | 当前主要路线 |
五、联邦查询怎么发生
联邦查询的核心是“三段式命名”：catalog.database.table，跨 Catalog 联邦查询时，可以用catalog_name.database_name或catalog_name.database_name.table_name指定要查询的数据。
-- 当前在 default_catalog.olap_db 下，查询 Hive Catalog 中的表
SELECT *
FROM hive_catalog.hive_db.hive_table;
-- 当前在 hive_catalog.hive_db 下，查询 StarRocks 内部表
SELECT *
FROM default_catalog.olap_db.olap_table;
-- 内部表与外部表 Join
SELECT *
FROM hive_catalog.hive_db.hive_table h
JOIN default_catalog.olap_db.olap_table o
ON h.id = o.id;
从执行视角看，联邦查询不是把所有数据先复制到一个地方，而是在同一个 SQL 计划中组合不同 Scan 节点。StarRocks 的 FE 负责解析 Catalog、获取元数据、生成分布式计划；BE/CN 负责并行扫描 StarRocks 内部 Tablet 或外部文件/远端数据，并完成过滤、Join、聚合等算子。
这个能力让 StarRocks 可以成为统一分析入口，但它也要求理解每类数据源的代价模型。湖表扫描可能受文件数量、对象存储延迟、分区裁剪影响；JDBC Catalog 可能受远端数据库连接数、网络延迟、谓词下推和返回数据量影响；内部表则更适合高并发、低延迟、频繁访问的服务化查询。
六、性能优化
1.Data Cache
External Catalog 查询外部文件时，远端 I/O 经常是性能瓶颈。Data Cache 会把远程存储中的数据按块加载到本地缓存，减少对象存储读取和本地磁盘写入压力；从 v3.4.0 起，StarRocks 对 External Catalog 查询和存算分离集群云原生表使用统一 Data Cache 实例。
Data Cache 适合重复访问相同分区、相同列、相同时间窗口的场景，例如 BI 看板、日常报表、固定分析路径。它缓存的是数据块，不是计算结果，因此对复杂 Join 和聚合的 CPU 代价帮助有限。
Data Cache 工作理解
第一次查询：
BE/CN -> 远端对象存储/HDFS -> 读取数据块 -> 写入本地缓存 -> 返回结果
后续命中：
BE/CN -> 本地 Data Cache -> 返回数据块 -> 继续计算
适合：
相同热点分区反复查
相同报表周期性查
湖表冷启动后需要稳定延迟
不适合单独解决：
大 Join 计算代价
跨源网络延迟
远端 JDBC 大表扫描
2.异步物化视图
对于频繁执行、计算复杂、聚合或 Join 代价高的外部数据查询，只靠 Data Cache 往往不够。StarRocks 异步物化视图能够保存一个或多个基表的预计算结果，并通过查询改写复用这些结果；异步物化视图的基表可以来自 default_catalog、External Catalog、已有物化视图和视图。
在数据湖加速场景中，StarRocks 支持基于 Hive、Iceberg、Hudi、JDBC、Paimon 等 External Catalog 创建异步物化视图，并适用于数据湖报表透明加速、实时数据关联历史数据、快速构建指标层等场景。 但也要注意限制：外部表物化视图不支持由基表数据变化自动触发刷新，只支持异步固定间隔刷新和手动刷新，且外部 Catalog 基表与物化视图之间不保证严格一致性。
External Catalog + Async MV
外部湖表 / JDBC 表 / 内部实时表
|
| 复杂 Join / Agg / Rollup
v
+-----------------------------+
| StarRocks Async MV |
| - 预计算结果 |
| - 本地存储 |
| - 查询改写 |
| - 定时或手动刷新 |
+-----------------------------+
|
v
BI / API 继续查原 SQL，命中时自动加速
3.导入内部表
当一类查询对时延、并发、稳定性和资源隔离要求很高时，最稳的方案仍然是把数据导入 StarRocks 内部表。External Table 最初设计是帮助加载数据到 StarRocks，而不是作为常规高效查询外部系统的方式；更高性能的方案通常是把数据加载到 StarRocks。
因此，统一分析不是“所有数据都不入仓”，而是把数据移动变成有依据的决策：
查询治理决策树
某张外部表被查询
|
+-----------+-----------+
| |
低频探索 高频稳定
| |
直接 External Catalog 是否计算复杂？
|
+-----------+-----------+
| |
不复杂 复杂
| |
Data Cache 优先 Async MV / 内部表
|
延迟仍不满足？
|
导入内部表
七、统一分析的架构落地
External Catalog 真正落地时，不应只问“能不能查”，而应问“哪些数据直接查，哪些数据缓存，哪些数据物化，哪些数据导入内部表”。一个较稳妥的分层方式如下：
统一分析落地分层
+--------------------------------------------------+
| BI / Notebook / Ad-hoc SQL / Metric API |
+---------------------------+----------------------+
|
v
+--------------------------------------------------+
| StarRocks SQL 统一入口 |
| - default_catalog 内部表 |
| - external catalogs 外部数据源 |
| - cross-catalog federated query |
+------------+----------------+--------------------+
| |
v v
+--------------------+ +-------------------------+
| 加速层 | | 外部数据层 |
| - Async MV | | Hive / Iceberg / Hudi |
| - Data Cache | | Delta / Paimon / JDBC |
| - Native Table | | Elasticsearch / Kudu |
+--------------------+ +-------------------------+
|
v
+--------------------------------------------------+
| 治理层：权限、血缘、元数据刷新、资源隔离、成本监控 |
+--------------------------------------------------+
可以把数据分成四类处理：
| 数据类型 | 推荐路径 | 原因 |
|---|---|---|
| 高频指标、Dashboard 核心看板 | 导入 StarRocks 内部表或异步物化视图 | 追求低延迟和高并发 |
| 中频湖仓明细分析 | External Catalog + Data Cache | 减少搬运，保留可接受性能 |
| 低频探索性查询 | 直接 External Catalog 查询 | 降低建模和同步成本 |
| 小规模维表、配置表 | JDBC Catalog 联查，或定期同步内部表 | 直接联查方便，但大表扫描风险高 |
八、踩坑实践
| 坑点 | 表现 | 建议 |
|---|---|---|
| 把 External Catalog 当内部表用 | 大量远端扫描，延迟不稳定 | 高频查询导入内部表或建异步物化视图 |
| JDBC Catalog 扫大表 | 远端业务库压力升高，查询慢 | 只联查小维表，大表同步或分批加工 |
| 忽略元数据刷新 | 新分区查不到，Schema 不一致 | 数据发布后执行 REFRESH EXTERNAL TABLE 或配置刷新策略 |
| 只看功能不看版本 | SQL 写法正确但能力不可用 | 按 StarRocks 版本核对 Catalog、格式、MV 支持矩阵 |
| 误用 External Table | 新架构仍大量建外表 | 一般场景改用 External Catalog |
| 物化视图一致性预期过高 | 外部表更新后 MV 未同步 | 使用固定刷新或手动刷新，并对外说明数据延迟 |
| Unified Catalog 误解为任意统一 | 多套 Metastore/Storage 接不进同一 Catalog | 一个 Unified Catalog 只支持单一存储系统和单一 Metastore |
