GROUP BY 一定触发 Shuffle，因其需将相同 key 的数据拉至同一 executor 完成聚合；Spark SQL 的 groupBy.agg 默认启用 map-side 预聚合，而 groupByKey 无预聚合易 OOM；应前置过滤、投影、哈希截断，并对倾斜 key 加盐或两阶段聚合。
GROUP BY 为什么一定触发 Shuffle
Spark SQL 中的 GROUP BY 是逻辑聚合操作，底层必须把相同 key 的所有记录拉到同一个 executor 上才能完成聚合。这意味着无论数据原本在哪个 partition，只要 key 相同，就必须跨 partition 移动——这就是 Shuffle 的本质。不存在“不 shuffle 的 GROUP BY”，只有“shuffle 少不多”的差别。
用 reduceByKey / aggregateByKey 替代 groupByKey（在 DataFrame 层对应为 agg + groupBy）
很多人误以为 groupBy(...).agg(...) 和 groupByKey 是一回事，其实 Spark SQL 的 groupBy 默认已启用 map-side 预聚合（类似 reduceByKey），只要聚合函数支持部分合并（如 sum、count、avg），就会先在每个 partition 内局部计算，再 shuffle 合并结果。但如果你写的是 groupByKey().map(...) 这种 RDD 风格代码，就完全绕过了预聚合，会把所有原始数据全量 shuffle。
- ✅ 正确：
df.groupBy("user_id").agg(sum("amount"), count("*"))—— 自动预聚合，shuffle 数据量小 - ❌ 危险：
rdd.groupByKey().mapValues(it => it.sum)—— 全量 value shuffle，易 OOM - ⚠️ 注意：自定义 UDAF 若未实现
merge方法，则无法预聚合，等效于 groupByKey
提前过滤和投影，减少 shuffle 数据体积
Shuffle 的开销和传输字节数强相关。哪怕逻辑上必须 GROUP BY，也能通过前置裁剪显著降压：
- 在
GROUP BY前加filter，比如WHERE dt = '2026-10-01'，避免把历史冷数据也拉进来 shuffle - 用
select只保留分组键和聚合字段，去掉无关列（如长文本、JSON 字段），否则这些字段也会被序列化传输 - 对字符串 key 做哈希截断（如
substr(md5(user_id), 1, 8)）可减小网络传输量，但需确认业务是否允许 key 模糊
遇到数据倾斜时，别硬扛 GROUP BY
当某个 key 占比超 10%，GROUP BY 的 shuffle 就会卡在一个 task 上。此时强行优化 shuffle 参数意义不大，应改写逻辑：
- NULL key 单独处理：
UNION ALL把IS NULL和非空分支拆开聚合 - 热点 key 加盐：用
CASE WHEN user_id = 'hot_user' THEN concat('salt_', floor(rand(123) * 20), '_', user_id) ELSE user_id END，注意必须固定 seed - 两阶段聚合：第一阶段加盐分组汇总，第二阶段去盐合并，确保二次聚合只处理少量中间结果
真正难的不是写出不 shuffle 的语句，而是判断“这个 GROUP BY 是否真的不可替代”——有时候换掉它（比如改用窗口函数或预计算表）比调优更有效。
