云原生数据仓库AnalyticDB：Auto-Scaling资源组测评

Multi-Cluster类型

• 适用场景：Multi-Cluster类型的资源组支持根据资源组的负载以Cluster为最小单位自动进行资源扩缩，满足资源组内部的资源隔离和高并发场景。主要适用于Interactive类型查询，且单查询资源量不超过一个Cluster资源量的场景。在业务高峰期，以Cluster为单位自动拉起一批计算节点，提升整体的计算资源量来适配业务压力，避免性能受损。在业务低峰期，以Cluster为单位自动缩容计算节点，减少整体计算资源量节约成本。

• 计费规则：具体参考计费规则。

Job类型

• 适用场景：Job类型资源组支持为查询临时拉起计算资源，查询结束立即释放计算资源。以BSP方式执行查询，响应时间较慢，通常在秒级或分钟级，具体拉起的资源量大小取决于运行的任务大小。主要适用于对时延不敏感、消耗资源量大的非实时性任务。

• 计费规则：具体参考计费规则。

Auto-Scaling类型

• 适用场景：Auto-Scaling类型资源组支持实时感知资源组负载，并以节点为单位动态扩缩计算资源，单条查询最大可使用的资源量与设置的资源组资源量上限相同，并且拉起的计算节点可以先后在多个查询之间共享。Auto-Scaling类型资源组以查询为单位进行资源隔离，避免查询之间相互干扰，减少查询的性能抖动。适用于业务负载中既有对时延敏感的Interactive类型查询，也有消耗资源量大的Batch类型查询的场景。

• 计费规则：具体参考计费规则。

资源组对比总览

实时查询—BI查询性能

BI查询是数据仓库中最常见的固定负载类型，一般是通过BI工具（如Tableau、PowerBI、QuickBI等）执行的预定义报表和仪表板查询。这类查询具有明确的业务模式：SQL逻辑固定、执行频率高（定时刷新或高频访问）、结果集规模可控，主要用于日常业务监控、经营日报/周报、KPI仪表板等场景。BI查询对数据库的核心诉求是稳定的并发处理能力和可预测的响应延迟，既要保证早高峰多人同时刷新时不卡顿，又要确保固定报表按时产出，同时对负载隔离有一定要求（避免大查询影响核心报表体验）。

以1T数据规模的TPCH数据集模拟BI查询的业务负载，在不同并发数下，Auto-Scaling资源组和Multi-Cluster资源组的性能表现对比如下。

测试结论：Auto-Scaling在所有并发下的查询成功率都是100%，而Multi-Cluster会存在查询失败的情况，甚至在30并发时失败率高达50%+。除去30并发下Multi-Cluster近似不可用外，观察总RT的测试结果，随着并发上升，Auto-Scaling的总RT是近似线性增长的，而Multi-Cluster的性能有严重的退化。

以上测试结果反映了Auto-Scaling以查询作为资源隔离粒度的优势，即使并发数增加，各个查询之间也不会相互干扰，既保证了集群的可用性，又保证了查询的性能。

实时查询—即席查询性能

即席查询（Ad-Hoc）是数据仓库中典型的探索性负载类型，指由数据分析师或业务人员临时发起的非固定模式查询。这类查询具有高度的不确定性：SQL逻辑不固定（常为手写或动态生成）、查询复杂度高（多表关联、嵌套子查询、复杂聚合）、不同的查询执行耗时波动大，主要用于数据探索分析、问题排查归因、临时取数等场景。Ad-Hoc查询对数据库的核心诉求是复杂查询处理能力、并发能力，并且操作主要以人工为主，所以对响应速度的要求也比较高。

根据TPC数据集，选取如下用于测试的SQL语句：

• 轻量Ad-Hoc：基于TPC数据集构造了一组耗时约为5s的查询，包括：多表Join取明细、按维度聚合统计（GROUP BY + SUM/COUNT）、窗口函数排名（RANK）、星型模型多维聚合、聚合排序Top-N。整体偏向“快速浏览与汇总”的轻量级分析。

  点击查看查询SQL

  [
    {
      "sql": "SELECT c.c_name, o.o_orderdate, l.l_quantity FROM customer c JOIN orders o ON c.c_custkey = o.o_custkey JOIN lineitem l ON o.o_orderkey = l.l_orderkey LIMIT 100",
      "databaseName": "tpch_100g_iceberg",
      "description": "CONCURRENCY_ADHOC_1",
      "weight": 1.0,
      "queryType": "ADHOC"
    },
    {
      "sql": "SELECT p.p_brand, COUNT(*), SUM(l.l_extendedprice) FROM part p JOIN lineitem l ON p.p_partkey = l.l_partkey GROUP BY p.p_brand LIMIT 100",
      "databaseName": "tpch_100g_iceberg",
      "description": "CONCURRENCY_ADHOC_2",
      "weight": 1.0,
      "queryType": "ADHOC"
    },
    {
      "sql": "SELECT p_partkey, p_name, p_retailprice, RANK() OVER (ORDER BY p_retailprice DESC) as price_rank FROM part LIMIT 100",
      "databaseName": "tpch_100g_iceberg",
      "description": "CONCURRENCY_ADHOC_3",
      "weight": 1.0,
      "queryType": "ADHOC"
    },
    {
      "sql": "SELECT d.d_year, i.i_category, s.s_state, SUM(ss_sales_price) FROM store_sales ss JOIN date_dim d ON ss.ss_sold_date_sk = d.d_date_sk JOIN item i ON ss.ss_item_sk = i.i_item_sk JOIN store s ON ss.ss_store_sk = s.s_store_sk GROUP BY d.d_year, i.i_category, s.s_state LIMIT 100",
      "databaseName": "tpcds_100g_iceberg",
      "description": "CONCURRENCY_ADHOC_4",
      "weight": 1.0,
      "queryType": "ADHOC"
    },
    {
      "sql": "SELECT i.i_brand, COUNT(*), SUM(ss_sales_price), AVG(ss_sales_price) FROM store_sales ss JOIN item i ON ss.ss_item_sk = i.i_item_sk GROUP BY i.i_brand ORDER BY SUM(ss_sales_price) DESC LIMIT 50",
      "databaseName": "tpcds_100g_iceberg",
      "description": "CONCURRENCY_ADHOC_5",
      "weight": 1.0,
      "queryType": "ADHOC"
    }
  ]

• 复杂Ad-Hoc：基于TPC数据集构造了一组耗时约为10s的查询，包括：Semi-Join半连接过滤（EXISTS子查询）、窗口函数分组对比（AVG OVER PARTITION BY）、CTE分阶段计算+Top-N回查、星型模型多维聚合、CASE条件分层+COUNT DISTINCT去重。整体偏向“深度探索与分群”的重量级分析。

  点击查看查询SQL

  [
    {
      "sql": "SELECT * FROM supplier s WHERE EXISTS (SELECT 1 FROM lineitem l WHERE l.l_suppkey = s.s_suppkey) LIMIT 100",
      "databaseName": "tpch_1t_iceberg",
      "description": "CONCURRENCY_ADHOC_1",
      "weight": 1.0,
      "queryType": "ADHOC"
    },
    {
      "sql": "SELECT o_custkey, o_totalprice, AVG(o_totalprice) OVER (PARTITION BY o_custkey) as customer_avg FROM orders LIMIT 100",
      "databaseName": "tpch_1t_iceberg",
      "description": "CONCURRENCY_ADHOC_2",
      "weight": 1.0,
      "queryType": "ADHOC"
    },
    {
      "sql": "WITH top_customers AS (SELECT c_custkey, SUM(o_totalprice) as total_spent FROM customer c JOIN orders o ON c.c_custkey = o.o_custkey GROUP BY c_custkey ORDER BY total_spent DESC LIMIT 10) SELECT tc.c_custkey, tc.total_spent, c.c_name, c.c_mktsegment FROM top_customers tc JOIN customer c ON tc.c_custkey = c.c_custkey LIMIT 100",
      "databaseName": "tpch_1t_iceberg",
      "description": "CONCURRENCY_ADHOC_3",
      "weight": 1.0,
      "queryType": "ADHOC"
    },
    {
      "sql": "SELECT d.d_year, i.i_category, s.s_state, SUM(ss_sales_price) FROM store_sales ss JOIN date_dim d ON ss.ss_sold_date_sk = d.d_date_sk JOIN item i ON ss.ss_item_sk = i.i_item_sk JOIN store s ON ss.ss_store_sk = s.s_store_sk GROUP BY d.d_year, i.i_category, s.s_state LIMIT 100",
      "databaseName": "tpcds_1t_iceberg",
      "description": "CONCURRENCY_ADHOC_4",
      "weight": 1.0,
      "queryType": "ADHOC"
    },
    {
      "sql": "SELECT CASE WHEN SUM(ss_sales_price) > 10000 THEN 'High Value' WHEN SUM(ss_sales_price) > 1000 THEN 'Medium Value' ELSE 'Low Value' END as customer_segment, COUNT(DISTINCT c.c_customer_sk) FROM store_sales ss JOIN customer c ON ss.ss_customer_sk = c.c_customer_sk GROUP BY c.c_customer_sk LIMIT 100",
      "databaseName": "tpcds_1t_iceberg",
      "description": "CONCURRENCY_ADHOC_5",
      "weight": 1.0,
      "queryType": "ADHOC"
    }
  ]

分别针对2组Ad-Hoc查询，在10/20/50/100并发压力下，分别压测5分钟，Auto-Scaling和Multi-Cluster资源组的性能表现如下。

测试结论：在这项测试中，最直观的结果就是Auto-Scaling在多并发下的可用性明显优于Multi-Cluster。50并发开始，Multi-Cluster在5分钟内无法完成任意一个轻量Ad-Hoc查询。对于复杂的Ad-Hoc查询，Multi-Cluster在20并发开始就无法正常处理。再从QPS的角度观察，Auto-Scaling在不同并发下，QPS基本维持稳定。这再次证明了Auto-Scaling对于查询间的资源隔离处理得很好。

实时查询—小查询性能

小查询是业务场景中最频繁的一类查询，这类查询消耗资源量少，并且对延迟和吞吐十分敏感。基于TPC数据集，构造了2类具有代表性的小查询：1）分布键点查；2）复杂小查询。

复杂小查询是指通过高选择性过滤条件精确定位少量行，但后续计算逻辑复杂，包含多表关联、多维聚合统计分析。这类查询用于模拟线上典型的用户级实时画像分析场景。

-- 示例1：用户级实时画像分析
SELECT
  SUM(
    CASE WHEN p.p_brand = 'Brand#12' THEN l.l_extendedprice ELSE 0 END
  ) AS brand12_sales,
  AVG(
    CASE WHEN p.p_brand = 'Brand#23' THEN l.l_extendedprice ELSE NULL END
  ) AS brand23_avg_price,
  SUM(
    CASE WHEN p.p_brand = 'Brand#34' THEN l.l_quantity ELSE 0 END
  ) AS brand34_quantity,
  AVG(
    CASE WHEN p.p_brand = 'Brand#45' THEN l.l_quantity ELSE NULL END
  ) AS brand45_avg_quantity,
  SUM(
    CASE WHEN p.p_brand = 'Brand#51' THEN l.l_extendedprice ELSE 0 END
  ) AS brand51_sales,
  AVG(
    CASE WHEN p.p_brand = 'Brand#13' THEN l.l_extendedprice ELSE NULL END
  ) AS brand13_avg_price,
  SUM(
    CASE WHEN p.p_brand = 'Brand#24' THEN l.l_quantity ELSE 0 END
  ) AS brand24_quantity,
  AVG(
    CASE WHEN p.p_brand = 'Brand#35' THEN l.l_quantity ELSE NULL END
  ) AS brand35_avg_quantity,
  SUM(
    CASE WHEN p.p_brand = 'Brand#41' THEN l.l_extendedprice ELSE 0 END
  ) AS brand41_sales,
  AVG(
    CASE WHEN p.p_brand = 'Brand#52' THEN l.l_extendedprice ELSE NULL END
  ) AS brand52_avg_price,
  SUM(
    CASE WHEN p.p_brand = 'Brand#14' THEN l.l_quantity ELSE 0 END
  ) AS brand14_quantity,
  AVG(
    CASE WHEN p.p_brand = 'Brand#25' THEN l.l_quantity ELSE NULL END
  ) AS brand25_avg_quantity,
  SUM(
    CASE WHEN p.p_brand = 'Brand#31' THEN l.l_extendedprice ELSE 0 END
  ) AS brand31_sales,
  AVG(
    CASE WHEN p.p_brand = 'Brand#42' THEN l.l_extendedprice ELSE NULL END
  ) AS brand42_avg_price,
  SUM(
    CASE WHEN p.p_brand = 'Brand#53' THEN l.l_quantity ELSE 0 END
  ) AS brand53_quantity
FROM
  orders o
  JOIN lineitem l ON o.o_orderkey = l.l_orderkey
  JOIN part p ON l.l_partkey = p.p_partkey
WHERE
  o.o_custkey = 135889;

-- 示例2：多维度聚合统计
SELECT
    CAST(IFNULL(SUM(CASE WHEN i.i_current_price > 100 THEN 1 ELSE 0 END), 0) AS int) AS dx_expensive_items_cnt,
    CAST(IFNULL(MIN(CASE WHEN i.i_current_price > 100 THEN DATEDIFF(CURRENT_DATE, ss.ss_sold_date_sk) END), -99) AS int) AS dx_expensive_items_diff_days_min,
    CAST(IFNULL(COUNT(DISTINCT CASE WHEN i.i_current_price > 100 THEN i.i_category END), 0) AS int) AS dx_expensive_items_categories,
    CAST(IFNULL(SUM(CASE WHEN i.i_current_price > 100 AND DATEDIFF(CURRENT_DATE, ss.ss_sold_date_sk) < 14 THEN ss.ss_sales_price ELSE 0 END), 0) AS int) AS dx_expensive_items_14d_cnt,
    CAST(IFNULL(SUM(CASE WHEN i.i_current_price > 100 AND DATEDIFF(CURRENT_DATE, ss.ss_sold_date_sk) < 30 THEN ss.ss_sales_price ELSE 0 END), 0) AS int) AS dx_expensive_items_30d_cnt,
    CAST(IFNULL(SUM(CASE WHEN i.i_current_price > 100 AND DATEDIFF(CURRENT_DATE, ss.ss_sold_date_sk) < 60 THEN ss.ss_sales_price ELSE 0 END), 0) AS int) AS dx_expensive_items_60d_cnt,
    CAST(IFNULL(SUM(CASE WHEN i.i_current_price > 100 AND DATEDIFF(CURRENT_DATE, ss.ss_sold_date_sk) < 90 THEN ss.ss_sales_price ELSE 0 END), 0) AS int) AS dx_expensive_items_90d_cnt,
    c.c_customer_sk AS dx_expensive_group_rptid
FROM store_sales ss
JOIN item i ON ss.ss_item_sk = i.i_item_sk
JOIN customer c ON ss.ss_customer_sk = c.c_customer_sk
WHERE c.c_customer_sk = 10001
GROUP BY c.c_customer_sk
LIMIT 1;

以下是2种小查询负载在不同并发下分别使用Auto-Scaling和Multi-Cluster资源组的测评结果。

测试结论：在分布键点查场景下，Auto-Scaling性能略差于Multi-Cluster，而在复杂小查询场景下，Auto-Scaling在高并发时表现出明显的优势。

离线查询性能

离线查询是数据仓库中面向批量数据处理的负载类型，通常用于T+1报表、数据仓库分层加工、历史数据归档、大规模数据分析等非实时场景。这类查询具有明确的任务边界：TB~PB级数据量、小时级的执行时长、逻辑复杂（多表Join、窗口函数、聚合计算）、对延迟不敏感但对稳定性要求高。

以10T数据规模的TPC数据集模拟离线查询，对比Auto-Scaling和Job资源组的性能表现。

测试结论：TPCH 10T开箱测试中，Auto-Scaling整体性能相对于Job提升了443.44%，并且Auto-Scaling的成功率是100%，而Job成功率只有59%。在TPCDS 10T开箱中，Auto-Scaling整体性能相对于Job提升了355.17%，成功率方面也是Auto-Scaling全都成功，而Job成功率是92%。所以，在离线查询场景下，Auto-Scaling无论是查询性能还是稳定性都显著优于Job。

能力矩阵总览

下表汇总了三种资源组在各评估维度上的表现：

测评结论汇总

核心结论

• Auto-Scaling在实时查询场景全面对标Multi-Cluster：在BI查询、Ad-Hoc查询、复杂小查询等高并发场景下，Auto-Scaling凭借查询粒度的资源隔离能力，表现出更优的并发稳定性和查询成功率。Multi-Cluster在高并发下查询失败率显著上升，而Auto-Scaling始终保持100%成功率。

• Auto-Scaling在离线查询场景对标Job：在离线查询场景下，Auto-Scaling无论从查询性能角度还是从查询稳定性角度，相比于Job都具有压倒性的优势。

• Auto-Scaling的核心优势：

  • 查询级资源隔离：以查询为单位进行资源分配和隔离，避免查询间相互干扰，高并发下性能稳定。

  • 完全按需付费：相比Multi-Cluster至少需要支付1个Cluster的费用，Auto-Scaling按实际使用量计费。

  • 节点级弹性伸缩：相比Multi-Cluster的Cluster级扩缩容，Auto-Scaling以节点为单位，弹性更细粒度。

  • 一套资源覆盖多场景：同时支持Interactive和Batch查询，无需维护多套资源组。

• 选型建议：推荐Auto-Scaling，混合负载场景（同时有实时+离线查询）、高并发实时查询场景、成本敏感场景。