GROUP BY多列必然触发Shuffle但不必然溢出；溢出主因是数据分布不均、spark.sql.shuffle.partitions配置过小或NULL值集中，需通过采样、显式repartition、调整分区数及NULL处理来优化。
GROUP BY 多列天然触发 Shuffle，但溢出不是必然结果
Spark SQL 执行 GROUP BY a, b, c 时一定会发生 Shuffle，因为必须把相同 (a,b,c) 组合的数据拉到同一 partition 才能聚合。但 Shuffle 溢出（Spill）只在特定条件下出现：内存缓冲区撑不住、磁盘写入跟不上、或单个 partition 数据量远超均值。溢出不是多列本身导致的，而是多列组合加剧了数据分布不均或分区数配置失当。
多列组合放大键空间稀疏性，容易隐式生成巨量空 partition
当 GROUP BY 的列中存在高基数字段（如 user_id）+ 低基数字段（如 status），组合后 key 总数可能爆炸式增长，但实际非空组合占比极低。Spark 默认按 hash 分区，会为所有潜在 key 分配 slot，大量 partition 实际为空或仅含几条记录，而少数 hot key 对应的 partition 却塞满数据 —— 这直接导致个别 task 内存爆掉、频繁 Spill 到磁盘。
- 典型表现：
Shuffle write: 120GB，但Spill (disk): 45GB，且 Web UI 显示某几个 reducer task 耗时是其他 task 的 10 倍以上 - 检查手段：用
df.groupBy("a", "b", "c").count().rdd.getNumPartitions看实际产出 partition 数，再对比spark.sql.shuffle.partitions设置值 - 规避方式：先对高频组合做采样统计，确认 key 分布；必要时改用
repartition(col("a"), col("b"))显式控制分区逻辑，而非依赖默认 hash
spark.sql.shuffle.partitions 配置不当是溢出主因
默认值 200 在多列聚合场景下极易失效。例如 10TB 数据跑 GROUP BY user_id, date, region，若仍用 200 分区，平均每个 partition 要处理 50GB 数据，远超安全阈值（建议单 partition ≤200MB）。这时即使 key 分布均匀，也会因单 partition 数据量过大引发 Spill。
- 调优公式：目标分区数 ≈ 总 shuffle 输入数据量（字节）/ 200MB
- 实操命令：
spark.conf.set("spark.sql.shuffle.partitions", "1000")，注意该值需与集群 executor 数量和内存匹配，避免创建过多小 task - 副作用提醒：盲目调大可能增加 task 调度开销，尤其当总数据量不足 10GB 时，设成 1000 反而更慢
NULL 值参与多列分组会强制归集到同一 partition
Spark 对 NULL 值的 hash 处理是统一的（例如全映射到 partition 0），当多列中任意一列含大量 NULL，比如 GROUP BY product_id, category, supplier_id 中 supplier_id IS NULL 占 30%，这些记录全被塞进同一个 partition，极易触发该 task 的 Spill 和 OOM。
- 验证方法：执行
df.filter(col("product_id").isNull() | col("category").isNull() | col("supplier_id").isNull()).count() - 修复路径：提前用
COALESCE替换，如GROUP BY COALESCE(product_id, -1), COALESCE(category, 'UNKNOWN') - 替代方案：若业务允许，用子查询过滤掉含
NULL的行，比填充更彻底
Shuffle spill 日志背后，可能是某三个字段交叉产生的长尾 key，既难采样定位，又不能简单丢弃。这时候绕过 SQL 直接用 RDD 的 combineByKey + 自定义分区器，反而比调参更可控。 
