Spark SQL DataFrame分组求均值、中位数任务未完成问题排查咨询

嘿，这种1TB级数据下GroupBy卡壳的情况我碰过好多次，大概率和键值倾斜脱不了干系，但咱们得一步步排查，不能上来就下定论。下面是我常用的排查思路和解决办法：

第一步：先确认是不是键值倾斜搞的鬼 #

这是大数据集GroupBy卡壳最常见的原因，你可以通过这几个方式验证：

• 扒Spark UI的Stage页面：看每个Task的输入数据量，如果某个Task处理的数据是其他Task的几十上百倍（比如别人都处理1GB，它干50GB），那基本实锤是键倾斜了。
• 先跑个轻量统计：用SELECT group_key, COUNT(*) as cnt FROM your_table GROUP BY group_key ORDER BY cnt DESC LIMIT 20;查下分组大小，如果前几个键的count占了总数据的30%以上，那就是倾斜的源头。
• 看Task日志：卡住的Task如果长时间卡在某个阶段，或者报出内存溢出（OOM）的错误，也能侧面印证是倾斜导致的资源过载。

第二步：排除其他可能的卡壳原因 #

如果确认不是键倾斜，那得看看这些地方：

• 资源配置太抠门：1TB的数据，要是Executor内存只给个2G、核数只开1个，肯定跑不动。检查下spark.executor.memory、spark.executor.cores、spark.driver.memory这些参数是不是设置得太小了，适当往上调。
• 数据格式拖后腿：如果原始数据是CSV、JSON这种非列式存储，读取和处理的开销会大很多，换成Parquet或ORC格式（带Snappy压缩）能大幅提升性能。
• Shuffle配置不合理：Shuffle阶段内存不够会频繁溢写磁盘，速度直接崩。可以调大spark.shuffle.memoryFraction（比如设成0.4），或者增加spark.shuffle.io.maxRetries避免网络波动导致的重试失败。
• 中位数计算的坑：精确中位数的计算开销比均值大得多，尤其是大分组。如果你用的是精确计算，赶紧换成近似的percentile_approx(col, 0.5)，性能能提一大截。

第三步：针对键值倾斜的解决办法 #

如果确实是键倾斜，试试这些方案：

• 拆分倾斜键：把超大的键拆成多个子键，比如给倾斜键加个0-9的随机后缀，分成10组计算后再合并。示例SQL：

  WITH temp AS (
    SELECT 
      CASE WHEN group_key IN ('超大键1', '超大键2') THEN CONCAT(group_key, '_', FLOOR(RAND()*10)) ELSE group_key END AS new_group_key,
      value
    FROM your_table
  )
  SELECT 
    CASE WHEN new_group_key LIKE '超大键%_%' THEN SPLIT(new_group_key, '_')[0] ELSE new_group_key END AS group_key,
    AVG(value) AS mean,
    percentile_approx(value, 0.5) AS median
  FROM temp
  GROUP BY new_group_key
  

• 单独处理倾斜键：把倾斜键的数据单独过滤出来计算，非倾斜键正常跑，最后合并结果。这样倾斜键的计算可以单独分配更多资源，或者用更高效的逻辑。
• 加盐（Salting）通用方案：如果不知道具体哪些键倾斜，给所有键加个随机前缀（比如CONCAT(group_key, '_', FLOOR(RAND()*20))），先按新键GroupBy，再把前缀去掉二次聚合，让数据分布更均匀。
• 调大Shuffle分区数：默认的200分区对1TB数据来说太少了，把spark.sql.shuffle.partitions调到1000甚至2000，让每个Task处理的数据量更均衡。

一些额外的小Tips #

• 先过滤无效数据：如果有不需要的行（比如NULL、无效值），先过滤掉，减少处理量。
• 开启动态分区调整：打开spark.sql.adaptive.enabled=true，Spark会自动根据数据量调整Shuffle分区数，避免小分区浪费资源或大分区卡壳。
• 先拿小样本测试：用TABLESAMPLE(1 PERCENT)取1%的数据跑查询，验证逻辑的同时快速排查是否有倾斜，比直接跑全量高效多了。

内容的提问来源于stack exchange，提问作者stackoverflowuser2010