返回
产品动态

Doris Catalog 已上线!性能提升 200x ,全面优于 JDBC Catalog,跨集群查询迈入高性能分析时代

SelectDB 技术团队· 2025/12/25
Keywords:

“统一”是 Apache Doris 长期以来秉持的设计理念之一。在这一理念指引下,构建完善的 Catalog 生态是实现异构数据源统一查询分析的关键。目前,Doris 已支持 Iceberg、Paimon、Hudi 等数据湖 Catalog,以及 JDBC Catalog,用户无需迁移数据,即可对不同数据湖和传统数据库进行联邦查询分析。

本文聚焦 Doris 多集群间的查询分析。实现跨 Doris 集群的分析通查需要通过 JDBC Catalog,但该方式存在明显短板,比如协议开销较大、无法复用 Doris 查询优化策略、查询性能受限等等。同时,随着生产环境中多 Doris 集群部署愈加普遍,跨集群的数据联动分析需求也日益增长。在这种情况下,JDBC Catalog 很难满足用户的性能要求。

为此,Apache Doris 4.0.2 版本推出重磅特性:Doris Catalog。该功能专为跨 Doris 集群联邦分析设计,支持通过 Arrow Flight 和虚拟集群两种模式,进行更高效、更贴合原生优化的跨集群查询

特此说明:Doris Catalog 当前为实验性特,欢迎大家体验并反馈,我们将持续优化

Doris Catalog vs. JDBC Catalog

JDBC Catalog 主要借助 MySQL 兼容的 JDBC 协议访问其他 Doris 集群数据。由前文可知,该方式在跨集群大数据量交互时性能受限,难以满足联邦分析高吞吐与低延迟的性能要求。不同于 JDBC Catalog 的交互方式, Doris Catalog 通过 Arrow Flight 或虚拟集群这两种方式,能够直接、高效的访问其他 Doris 集群,进行多集群联邦分析。

01 功能对比

那么,与 JDBC Catalog 相比,Doris Catalog 到底具备哪些能力优势呢?

01 功能对比.png

02 性能对比

为了更直观地展示二者在实际查询中的表现,我们基于跨集群的 TPC-DS 查询场景,对比了 Doris Catalog(两种连接模式) 与 JDBC Catalog 的执行性能。以下是测试结果概要:

02 性能对比.png

结果显示,在涉及聚合、Join 等复杂查询场景下,Doris Catalog 相比 JDBC Catalog 展现出不同程度的性能优势。其中,在单表聚合查询场景下优势尤为突出:Doris Catalog(虚拟集群)的查询耗时仅为 0.21 秒,相较于 JDBC Catalog,速度提升超过 200 倍

具体测试如下

  1. 在单表简单查询(直接查询远端集群)模式下:Doris Catalog 与 JDBC Catalog 基本持平。
SELECT
    ss_sold_date_sk,
    ss_store_sk,
    ss_item_sk,
    ss_ticket_number,
    ss_quantity,
    ss_sales_price,
    ss_ext_sales_price,
    ss_net_profit
FROM jdbc_mode.tpcds100.store_sales
WHERE ss_sold_date_sk = 2450816
  AND ss_store_sk = 10
  AND ss_quantity BETWEEN 1 AND 3
LIMIT 100;

02 性能对比-1.png

  1. 在单表聚合查询(直接查询远端集群)模式下:Doris Catalog 两种模式均优于 JDBC Catalog,Doris Catalog(虚拟集群)的查询耗时仅为 0.21 秒,相较于 JDBC Catalog,速度提升超过 200 倍
SELECT
    ss_sold_date_sk,
    ss_store_sk,
    SUM(ss_ext_sales_price) AS total_sales,
    SUM(ss_net_profit)      AS total_profit,
    COUNT(*)                AS txn_cnt
FROM tpcds100.store_sales
WHERE ss_sold_date_sk BETWEEN 2450816 AND 2451179
GROUP BY
    ss_sold_date_sk,
    ss_store_sk
ORDER BY
    ss_sold_date_sk,
    ss_store_sk
LIMIT 100;

02 性能对比-2.png

  1. 在多表关联查询(两个大表分别存储在本地和远端集群,进行关联查询)模式下:Doris Catalog 两种模式均优于 JDBC Catalog,相较于 JDBC Catalog,速度提升约 42%
SELECT count(ss_item_sk), count(store_sales_amt), count(catalog_sales_amt) FROM
(
SELECT
    ss.ss_item_sk as ss_item_sk,
    SUM(ss.ss_ext_sales_price) AS store_sales_amt,
    SUM(cs.cs_ext_sales_price) AS catalog_sales_amt
FROM internal.tpcds100.store_sales ss
JOIN external.tpcds100.catalog_sales cs
    ON ss.ss_item_sk = cs.cs_item_sk
WHERE ss.ss_sold_date_sk BETWEEN 2450815 AND 2451079
  AND cs.cs_sold_date_sk BETWEEN 2450815 AND 2451079
GROUP BY ss.ss_item_sk) x;

02 性能对比-3.png

03 方案选择

由上可知,不同的查询场景中,需要选择适合的的访问模式,以获取最佳的查询性能:

  • 对于复杂 Join/Agg 查询或依赖 Doris 内表优化特性时,优先选择 Doris Catalog 虚拟集群模式
  • 对于简单单表查询、UNION 查询、远端集群规模大且无需复杂 Join 优化或 Doris 集群版本不一致,优先选择 Doris Catalog Arrow Flight 模式

Doris Catalog 核心设计

Doris Catalog 本质是跨集群访问的“中间代理”,核心职责包括

  • 元数据同步:通过 HTTP 协议从远端 Doris 集群 FE 拉取表结构、分区、副本、 Tablet 位置等元数据;
  • 执行计划生成:根据访问模式,将用户查询转换为适配远端集群的执行计划;
  • 数据路由与传输:协调本地 BE 与远端 BE 进行数据传输,支持并行拉取与分片处理;
  • 结果聚合:将远端返回的数据聚合后,返回给用户或上层应用。

Doris Catalog 支持 Arrow Flight 和 虚拟集群两种访问模式。在了解具体实现之前,先了解两种模式的区别

 Doris Catalog 核心设计.png

01 Arrow Flight 模式

01 Arrow Flight 模式.png

该模式的工作流程如下(假设本地集群为 ClusterA,远端集群为 ClusterB):

  • 查询规划:ClusterA 的 FE 节点先进行完整的查询规划,针对存储在 ClusterB 中的表,生成 RemoteDorisScanNode节点。RemoteDorisScanNode 会生成一条应用谓词下推规则后的单表查询 SQL,通过 HTTP 协议向 ClusterB 的 FE 节点发送并执行这条 Arrow Flight SQL。
  • 查询计划执行:ClusterA 的 FE 节点将物理执行计划发送给 ClusterA 的 BE 节点,并告知 BE 节点 Arrow Flight 的数据流获取位置。
  • 数据查询与传输:ClusterA 的 BE 节点的 Scan Node 通过 Arrow Flight 协议直接从 ClusterB 的 BE 节点获取 Arrow Flight SQL 的执行结果。然后在 ClusterA 中执行 Join、Agg 等其他算子,并返回最终结果。

02 虚拟集群模式

02 虚拟集群模式.png

该模式的工作流程如下(假设本地集群为 ClusterA,远端集群为 ClusterB):

  • 元数据同步:ClusterA 的 FE 节点通过 HTTP 协议同步 ClusterB 中完整的元数据,包括表结构、分区、副本、Tablet 位置等。
  • 查询规划:ClusterA 的 FE 节点将 ClusterB 的 BE 节点视为“虚拟 BE”,生成全局统一的执行计划(与单集群查询逻辑一致)。
  • 查询计划执行:执行计划会将 ClusterA 与 ClusterB 的 BE 节点视作一个统一 BE 集群,并在其上执行查询计划。因此,各类算子会同时在 ClusterA 和 ClusterB 的 BE 节点中执行。
  • 数据查询与传输:ClusterA 与 ClusterB 的 BE 节点间使用内部通信协议进行数据交互。

实战演示:10 分钟完成跨集群订单履约率分析

回归到实际使用中,Doris Catalog 可有效支撑以下五大核心业务场景,精准解决跨集群分析痛点:

  1. 多业务集群联合分析:如在电商场景中,交易集群存储订单数据、物流集群存储履约数据,通过 Doris Catalog 直接关联计算“订单履约率”“物流时效”等核心指标,无需跨集群数据同步。

  2. 地域分布式集群全局统计:如零售企业在多地域部署 Doris 集群,通过 Doris Catalog 一站式汇总各区域销售数据,实时计算全国总销售额、区域占比、用户活跃度等全局指标。

  3. 实时数据跨集群关联查询:如用户行为分析场景中,通过 Doris Catalog 实时关联用户实时行为集群(点击、浏览等)与长期用户画像集群,支撑个性化推荐、精准营销等实时决策场景。

  4. 跨地域超大规划集群分治:不同地域的分公司采用相同的业务模式部署和使用 Doris 集群。母公司通过 Doris Catalog 完成对全地域多集群的集中访问,实现超大规模业务数据管理。

  5. 跨集群数据迁移验证与对比分析:新旧集群迁移过程中,通过 Doris Catalog 直接对比两端数据一致性,无需导出导入工具,简化迁移验证流程,降低数据丢失风险。

接下来,我们以常见场景 1:多业务集群联合分析为例,实战演示如何在 10 分钟完成跨集群订单履约率分析

1、背景介绍 现有两个 Doris 集群,需跨集群关联计算核心业务指标:

  • 本地集群(Trading-Cluster):存储订单基础数据,库表为 trading_db.order_info(订单表);
  • 远端集群(Logistics-Cluster):存储物流履约数据,库表为 logistics_db.delivery_info(履约表);
  • 业务需求:计算近 7 天各订单类型的履约率(已履约订单数/总订单数),支撑运营决策。

2、表结构定义

  • 本地订单表 trading_db.order_info
    • CREATE TABLE trading_db.order_info (
          order_id STRING COMMENT '订单ID',
          order_type STRING COMMENT '订单类型:实物订单/虚拟订单',
          create_time DATETIME COMMENT '创建时间',
          amount DECIMAL(10,2) COMMENT '订单金额'
      ) ENGINE=OLAP
      DUPLICATE KEY(order_id)
      PARTITION BY RANGE(create_time) (
          PARTITION p202511 VALUES [('2025-11-01 00:00:00'), ('2025-12-01 00:00:00'))
      )
      DISTRIBUTED BY HASH(order_id) BUCKETS 10;
      
  • 远端履约表 logistics_db.delivery_info
    • CREATE TABLE logistics_db.delivery_info (
          order_id STRING COMMENT '订单ID',
          delivery_status TINYINT COMMENT '履约状态:1-已履约,0-未履约',
          delivery_time DATETIME COMMENT '履约时间'
      ) ENGINE=OLAP
      DUPLICATE KEY(order_id)
      PARTITION BY RANGE(delivery_time) (
          PARTITION p202511 VALUES [('2025-11-01 00:00:00'), ('2025-12-01 00:00:00'))
      )
      DISTRIBUTED BY HASH(order_id) BUCKETS 10;
      

3、数据准备 向两张表分别插入测试数据(本地表 100 万行订单数据,远端表 80 万行履约数据),确保订单 ID 存在关联关系。 4、配置 Doris Catalog 在本地 Doris 集群执行以下 SQL,创建连接远端物流集群的 Catalog(虚拟集群模式):

-- 创建Doris Catalog,启用虚拟集群模式(复用内表优化)
CREATE CATALOG IF NOT EXISTS logistics_ctl PROPERTIES (
    'type' = 'doris', -- 固定类型
    'fe_http_hosts' = 'http://logistics-fe1:8030,http://logistics-fe2:8030', -- 远端FE HTTP地址
    'fe_arrow_hosts' = 'logistics-fe1:8040,http://logistics-fe2:8040', -- 远端FE Arrow Flight地址
    'fe_thrift_hosts' = 'logistics-fe1:9020,http://logistics-fe2:9020', -- 远端FE Thrift地址
    'use_arrow_flight' = 'false', -- false=虚拟集群模式,true=Arrow Flight模式
    'user' = 'doris_admin', -- 远端集群登录用户
    'password' = 'Doris@123456', -- 远端集群登录密码
    'compatible' = 'false', -- 集群版本接近(4.0.3 vs 4.0.2),无需兼容
    'query_timeout_sec' = '30' -- 延长查询超时时间(默认15秒)
);

5、跨集群查询

  • 切换 Catalog 后查询
    • -- 切换到远端物流集群的Catalog
      SWITCH logistics_ctl;
      -- 使用本地订单库
      USE trading_db;
      -- 关联本地订单表与远端履约表,计算履约率
      SELECT 
          o.order_type,
          COUNT(DISTINCT o.order_id) AS total_orders,
          COUNT(DISTINCT CASE WHEN d.delivery_status = 1 THEN o.order_id END) AS delivered_orders,
          ROUND(COUNT(DISTINCT CASE WHEN d.delivery_status = 1 THEN o.order_id END) / COUNT(DISTINCT o.order_id), 4) * 100 AS delivery_rate
      FROM internal.trading_db.order_info o
      JOIN delivery_info d ON o.order_id = d.order_id
      WHERE o.create_time >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
      GROUP BY o.order_type
      ORDER BY delivery_rate DESC;
      
  • 全限定名查询
    • SELECT 
          o.order_type,
          COUNT(DISTINCT o.order_id) AS total_orders,
          COUNT(DISTINCT CASE WHEN d.delivery_status = 1 THEN o.order_id END) AS delivered_orders,
          ROUND(COUNT(DISTINCT CASE WHEN d.delivery_status = 1 THEN o.order_id END) / COUNT(DISTINCT o.order_id), 4) * 100 AS delivery_rate
      FROM internal.trading_db.order_info o
      JOIN logistics_ctl.logistics_db.delivery_info d ON o.order_id = d.order_id
      WHERE o.create_time >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
      GROUP BY o.order_type
      ORDER BY delivery_rate DESC;
      

6、查询结果与优化验证

  1. 执行结果示例 实战演示.png
  2. 优化特性验证
    • 执行 EXPLAIN 查看执行计划,可发现:
    • 虚拟集群模式下,执行计划中远端表扫描节点为 VOlapScanNode(与本地表一致),说明复用了 Doris 内表扫描优化;
    • Join 操作中自动启用 Runtime Filter,减少远端数据传输量。

总结与展望

Doris Catalog 的推出,补齐了 Doris 跨集群联邦查询的性能短板。在此特别感谢社区同学的 Chen768959 和 HonestManXin 贡献,帮助延续了 Doris Catalog 生态“无需迁移、一站式分析”的核心优势,让多 Doris 集群从“数据孤岛”变为“互联一体”。

作为实验性特性,Doris Catalog 后续将持续迭代优化:

  • 增强 Arrow Flight 模式,使其能够访问任意支持标准 Arrow Flight 协议的数据源。
  • 降低虚拟集群模式 FE 内存开销,优化元数据存储和同步策略;
  • 支持存算分离部署的 Doris 集群(虚拟集群模式)
  • 新增更多监控指标,方便排查跨集群查询故障。

更多信息,请访问 Doris 官网文档:

https://doris.apache.org/zh-CN/docs/4.x/lakehouse/catalogs/doris-catalog