小查询并发优化

优化原理

大多数场景下分布式执行能带来更高的性能，查询被拆分为多个 Stage 在多个节点间通过 Shuffle 交换数据。但分布式执行也额外带来：

• 网络与序列化开销：节点间数据传输涉及序列化、反序列化以及网络 RPC 调用。

• 调度协调成本：多节点协同需要 Coordinator 做任务分发、状态收集，增加端到端延迟。

• 节点长尾风险：任一节点异常都会影响整体进度，受“木桶效应”制约。

对于小查询而言，处理的数据量极小，并行计算收益有限，上述开销反而可能远超实际计算耗时。为此，系统在识别到小查询后，会将执行计划收敛为单机计划，在单个节点上完成所有计算，从根本上消除分布式开销。

典型示例

以下查询涉及多表 Join 与多维度聚合，但由于过滤条件极具选择性，实际扫描数据量极小，是单机执行的典型受益场景。

SELECT
    s.s_store_name,
    CAST(COALESCE(SUM(CASE WHEN i.i_current_price > 100 THEN 1 ELSE 0 END), 0) AS BIGINT) AS dx_expensive_items_cnt,
    CAST(COALESCE(MIN(CASE WHEN i.i_current_price > 100 THEN DATEDIFF(CURRENT_DATE, ss.ss_sold_date_sk) END), -99) AS BIGINT) AS dx_expensive_items_diff_days_min,
    CAST(COALESCE(COUNT(DISTINCT CASE WHEN i.i_current_price > 100 THEN i.i_category END), 0) AS BIGINT) AS dx_expensive_items_categories,
    CAST(COALESCE(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 BIGINT) AS dx_expensive_items_14d_cnt,
    CAST(COALESCE(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 BIGINT) AS dx_expensive_items_30d_cnt,
    CAST(COALESCE(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 BIGINT) AS dx_expensive_items_60d_cnt,
    CAST(COALESCE(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 BIGINT) 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
JOIN store s ON ss.ss_store_sk = s.s_store_sk
WHERE c.c_customer_sk = 10001
GROUP BY
    s.s_store_name,
    c.c_customer_sk
LIMIT 1;

优化前：查询被切分为 6 个 Stage 分布式执行。

优化后：仅包含 1 个 Stage 单机执行，无数据 Shuffle。

实测效果

基于 96 ACU 集群规格，在不同并发下对比开关单机执行计划的性能表现：

原理

独立执行队列让小查询绕开了常规的资源配额管控，但若不加以控制，大量小查询同时涌入同一节点可能造成资源争抢，甚至导致节点过载。

为此，系统在 Coordinator 侧为每个计算节点维护一套轻量的资源配额机制，专门用于管控小查询的执行负载。每条小查询在调度前需先向目标节点申请配额，若当前所有节点均无空闲配额，调度请求将短暂等待后重试，同时 Executor Control Service 会基于查询队列深度做扩缩容决策。更多信息，请参见Auto-Scaling弹性策略。

每个节点的配额上限并非固定不变，系统基于节点当前的查询延迟与吞吐水平动态调整：

• 异常熔断保护：节点过载或持续异常时触发熔断，降低配额上限并暂停调度，恢复后重新接入。

• 慢节点自动降级：节点响应延迟显著高于集群平均水平时，降低配额上限并将流量调度至健康节点。

• 稳态探测：稳定节点试探性提升配额上限，在确保执行性能不劣化的前提下最大化资源利用。

• 弹性收缩：流量降低时自动收缩配额至安全水位，避免突发流量导致节点瞬间过载。

配额上限的调节范围有明确的上下边界，防止在极端情况下过度收紧或放开。整个过程完全自动，无需人工干预，每次调节后会有一段冷静期。

实测效果

基于 96 ACU 规格，关闭单机执行计划策略以充分模拟资源争抢场景，测试SQL如单机执行计划章节所示，在不同并发下对比开关自适应限流的集群性能表现：

• 无限流：性能呈先升后降趋势，高并发引发节点过载，导致延迟飙升且吞吐量断崖式下跌。

• 自适应限流：性能持续上升并企稳，通过动态调控成功抵御压力，在高负载下仍保持高吞吐，端到端延迟线性增长主要是排队带来的额外开销。