一对多JOIN倾斜源于“一”侧高频key（如user_id=-1）与“多”侧大量记录匹配，导致Shuffle阶段数据集中；验证需统计JOIN键频次并检查兜底值，加盐须双表一致且显式重分区，AQE可自动处理倾斜但不解决Map端问题，NULL和空字符串等语义污染数据是隐性主因。
确认是不是一对多导致的JOIN倾斜
一对多本身不等于倾斜，但当“一”侧出现高频key（比如 user_id = -1、region = '北京'、product_id IS NULL），而“多”侧大量记录匹配它时，就会在Shuffle阶段把所有匹配行压到少数几个Task上。典型现象是：Spark UI里某个Task的 Input Size 是其他Task的5–100倍，或MaxCompute Logview中某Fuxi Instance的 Latency 明显偏离均值。
验证方法很直接：
- 对JOIN键做频次统计：
SELECT key, COUNT(*) FROM big_table GROUP BY key ORDER BY COUNT(*) DESC LIMIT 20 - 检查是否存在兜底值：
SELECT COUNT(*) FROM table WHERE key IN (0, -1, -999, 'null', '') - 别只看行数——用
DESCRIBE FORMATTED table_name看TotalSize字段，STRING列多的小表可能序列化后超2GB，根本播不了
加盐（Salting）必须同时作用于两张表
加盐不是给大表单方面“打散”，而是让大表和小表对同一组热点key使用完全一致的salt逻辑，否则JOIN不上。核心错误就是只改一边、或两边salt函数不一致（比如一边用 RAND()，一边用 hash(key) % 5）。
推荐写法（以Spark SQL为例）：
SELECT /*+ REPARTITION(50) */ user_id, SUM(amount) AS total
FROM (
SELECT
CASE WHEN user_id IN (0, -1, -999)
THEN CONCAT(CAST(user_id AS STRING), '_', CAST(hash(user_id) % 5 AS STRING))
ELSE CAST(user_id AS STRING)
END AS user_id,
amount
FROM ods_user_events
) t1
JOIN (
SELECT
CASE WHEN user_id IN (0, -1, -999)
THEN CONCAT(CAST(user_id AS STRING), '_', CAST(hash(user_id) % 5 AS STRING))
ELSE CAST(user_id AS STRING)
END AS user_id,
user_name
FROM dim_user_info
) t2 ON t1.user_id = t2.user_id;
注意点：
-
hash(user_id) % 5比FLOOR(RAND() * 5)更可靠——RAND()在Spark中每次调用结果不同，无法保证两张表salt一致 - 盐值个数选5–20之间试；太小仍会倾斜，太大徒增Shuffle量
- 加盐后必须显式重分区，如
/*+ REPARTITION(50) */，否则Spark可能沿用原key分区策略
用自适应执行（Adaptive Query Execution）自动拆分倾斜Partition
如果你用的是Spark 3.2+ 或支持AQE的引擎（如MaxCompute 6.0+），开启自适应倾斜Join比手写加盐更省事，尤其适合不知道具体哪些key倾斜、或倾斜key频繁变动的场景。
关键配置项（需在SQL作业设置中添加）：
spark.sql.adaptive.enabled=truespark.sql.adaptive.skewedJoin.enabled=true-
spark.sql.adaptive.skewedPartitionMaxSplits=10（默认5，最大10，按需调高）
原理是：AQE运行时检测到某个Partition的大小超过平均值的N倍（由 skewedPartitionThresholdInBytes 控制，默认25MB），就自动把它拆成多个子Partition，再分别JOIN。不需要提前知道热点key，也不用改SQL逻辑。
但要注意：AQE只对Shuffle阶段有效，如果倾斜发生在Map端（比如小表太大播不出去），它无能为力。
一对多倾斜时，千万别忽略NULL值和空字符串
很多倾斜不是业务key本身造成的，而是ETL清洗不到位，把缺失值统一转成 'null' 字符串、或空字符串 ''，结果千万条记录全挤在一个key下。这类问题往往藏得深，因为 WHERE key IS NULL 查不到它们。
排查和处理建议：
- 查空值分布：
SELECT key, COUNT(*) FROM t GROUP BY key HAVING key IN ('', 'null', 'NULL', 'None') OR key IS NULL - 清洗阶段就隔离处理：
COALESCE(key, CONCAT('UNKNOWN_', FLOOR(RAND() * 10)))，而不是简单转成固定字符串 - JOIN前先过滤掉无效key：
WHERE key NOT IN ('', 'null', 'NULL')，但要确认业务是否允许丢弃
真正难处理的从来不是已知的高频key，而是那些被当成“正常值”混进来的语义污染数据——它们不会出现在Top N统计里，却能把整个作业拖垮。
