【详述】问题详细描述
【背景】3.3.19 etl加工过程中会阻塞在某个project和exchange，看上去是pipeline没有调度 be的日志搜queryId没有异常信息。有完整的profile，chunk_size设的比较低只有128，调大到1024的时候可以成功跑完，可能是因为chunk_size的大小导致的吗？
【业务影响】
【是否存算分离】
【StarRocks版本】3.3.19
【集群规模】3fe 3be
【附件】
您遇到的查询阻塞问题，根源在于 极其低效的 SQL 写法 与 不合理的 chunk_size 参数设置 共同作用导致的性能雪崩。
UNION ALL 组合了多个独立的子查询，每个子查询都从头完整地扫描了一遍大型 Hive 表 ads_fg_product_metric_month_info_f 。这种模式导致了数十次的重复数据读取，产生了海量的中间数据。这些中间数据在进行窗口函数计算时需要排序，其体量远超内存上限，因此触发了大规模的磁盘溢出（Spill），这是导致查询耗时近30分钟的核心原因。chunk_size 设置不当 您将 chunk_size 设置为极小的 128 ，这是导致查询“卡死”在 PROJECT 和 EXCHANGE 算子的直接原因。过小的 chunk_size 会：chunk 使其性能严重退化，尤其是在执行复杂的 CASE WHEN 表达式时。EXCHANGE 算子需要发送海量的小数据包，网络协议开销远大于实际数据传输，造成了数据流阻塞。总结来说，低效的 SQL 创造了一个极其消耗资源的执行计划，而过小的 chunk_size 则彻底摧毁了 StarRocks 执行引擎的处理能力，两者叠加导致了最终的性能问题。
chunk_size 参数立即将 chunk_size 参数从 128 恢复至 StarRocks 的默认值 4096 ，或者直接删除该参数设置。 这是解决当前执行阻塞、让查询能够稳定运行的最快方法。
SET chunk_size = 128 的设置。为了从根本上解决性能问题，实现数量级的性能提升，并降低资源消耗，您必须重构 SQL。核心思想是： “一次读取，多次使用” 。
WITH 子句) 将对 ads_fg_product_metric_month_info_f 的扫描提取出来，后续所有 UNION ALL 的分支都从这个 CTE 中读取数据。同时，将多个用于计算不同百分位的子查询合并为一个。-- 步骤1: 使用 CTE 将源表读取一次
WITH base_product_data AS (
SELECT
sale_gmv, sale_count, avg_price,
category_name1, category_name2, category_name3, category_name4,
yuce_market_category_id, month_date
FROM lake.saas_hq_datalake.ads_fg_product_metric_month_info_f
WHERE category_name1 IS NOT NULL OR category_name2 IS NOT NULL OR category_name3 IS NOT NULL OR category_name4 IS NOT NULL
),
-- 步骤2: 为每个 category_level 创建一个计算逻辑块，从 CTE 读取数据
category_level_1 AS (
SELECT
DATE_FORMAT(t.month_date, '%Y-%m-%d') AS stat_date,
'1' AS category_level,
t.category_name1 AS category_name,
-- ... 其他字段
-- 步骤3: 在一个子查询内完成所有百分位计算，避免多次 JOIN
MIN(CASE WHEN cum_ratio >= 0.25 THEN avg_price END) as cutoff_25,
MIN(CASE WHEN cum_ratio >= 0.50 THEN avg_price END) as cutoff_50,
-- ...
FROM (
SELECT *,
SUM(sale_count) OVER (PARTITION BY category_name1, month_date ORDER BY avg_price) /
SUM(sale_count) OVER (PARTITION BY category_name1, month_date) AS cum_ratio
FROM base_product_data
WHERE category_name1 IS NOT NULL
) t
GROUP BY t.month_date, t.category_name1 -- ...
),
category_level_2 AS (
-- 类似上面的逻辑，但处理 category_name2
SELECT ... FROM base_product_data WHERE category_name2 IS NOT NULL ...
)
-- ... 其他 category_level 的逻辑
-- 步骤4: 最后将所有处理好的结果 UNION ALL
SELECT ... FROM category_level_1
UNION ALL
SELECT ... FROM category_level_2
-- ...
完成以上两步优化后，您可以预期：