shuffle hash join因数据倾斜卡死，是因右表某key占80%行数导致单reducer oom或卡在99%；需通过spark ui确认shufflehashjoin节点及task指标偏斜；应对方式：①强制广播（broadcast hint）；②倾斜key单独打标重分布；③调高shuffle分区数。
为什么Shuffle Hash JOIN会因倾斜卡死
Spark SQL默认在join时若右表小（spark.sql.autoBroadcastJoinThreshold默认10MB），会走BroadcastHashJoin；否则走ShuffleHashJoin。但一旦右表实际数据分布不均（比如某个join key占了80%行数），ShuffleHashJoin就会把所有匹配该key的记录全拉到同一个reducer，造成单task处理量爆炸——不是慢，是直接OOM或卡在99%不动。
先确认是不是真由Shuffle Hash JOIN引发的倾斜
别一上来就改代码。打开Spark UI → 对应stage → 点开“DAG Visualization”看物理计划，确认是否出现ShuffleHashJoin节点；再点开该stage的task列表，观察：Shuffle Read Size列是否存在一个task远超其他（比如2GB vs 其他20MB）、Executor CPU Time是否严重偏斜、GC Time是否飙升。如果这些指标都集中在一个executor上，基本可锁定是ShuffleHashJoin的key倾斜。
三种实操有效的应对方式
按优先级和落地成本排序：
- 强制转
BroadcastHashJoin：如果右表逻辑上确实小（比如维表），但因统计不准或null值过多被误判为大表，手动加hint：SELECT /*+ BROADCAST(t2) */ * FROM t1 JOIN t2 ON t1.id = t2.id。注意：必须确保t2序列化后不超过spark.sql.autoBroadcastJoinThreshold，否则会fallback回shuffle且不报错，反而更难排查。 - 对倾斜key单独处理：先用
SELECT id, COUNT(*) FROM t2 GROUP BY id ORDER BY COUNT(*) DESC LIMIT 5找出高频key（如id = 0或NULL），然后拆成两路：
– 主路：过滤掉这些key，走正常ShuffleHashJoin；
– 倾斜路：对t1和t2中这些key的数据分别map打上随机前缀（如CONCAT(id, '_', FLOOR(RAND() * 10))），join后再GROUP BY去前缀聚合。这个方案能均摊压力，但需业务允许key变形。 - 调高shuffle并行度治标：设置
spark.sql.shuffle.partitions=1000（默认200）。它不能解决“一个key数据太多”的本质问题，但能让每个reducer分到更少的key桶，降低单task内存峰值。适用于倾斜程度轻（最大key占比
容易被忽略的细节
很多团队试了随机前缀还倾斜，是因为没处理null——NULL在ShuffleHashJoin中会被统一哈希到同一个partition，比任何业务key都顽固。必须显式过滤或COALESCE(id, 'null_' || FLOOR(RAND()*100))。另外，ShuffleHashJoin在Spark 3.0+已逐渐被SortMergeJoin替代，如果你用的是较新版本，检查是否启用了spark.sql.join.preferSortMergeJoin=true，它对倾斜更友好（虽慢但稳）。
