SR不只查内部表：External Catalog、联邦查询与统一分析

一、引言

很多团队使用 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