数据倾斜本质是数据分布不均导致部分task负载过重，典型表现为任务卡在99%、executor处理量差异数十倍、CPU利用率“旱涝不均”；需通过Spark UI监控、数据采样和日志识别定位，优先分离空值/兜底值而非盲目加盐，并结合广播小表、两阶段聚合等方案协同优化。
直接加盐（salting）不是万能解法，尤其当倾斜由业务兜底值（如 user_id = 0、product_id = -1）或空值引发时，盲目加盐反而会放大 Shuffle 量、引入非确定性、甚至导致结果错误。
先确认是不是真倾斜，别被“慢”骗了
数据倾斜和单纯性能差是两回事：前者表现为绝大多数 Task 已完成，仅 1–2 个卡在 99%；后者是所有 Task 都慢。关键看 Spark UI 的 Input Size 分布或 MaxCompute Logview 中 Fuxi Instance 的 Latency 偏离度。如果最大任务耗时是中位数的 5 倍以上，再查倾斜。
- 跑一次
SELECT key, COUNT(*) FROM big_table GROUP BY key ORDER BY COUNT(*) DESC LIMIT 20，看前几条是否占总量 60%+ - 检查维度表里有没有
user_id IN (0, -999)这类人工兜底值——它们常被事实表高频引用 - 用
DESCRIBE FORMATTED table_name看TotalSize，小表行数少但 STRING 列多，序列化后可能超 2GB，根本播不了
空值和兜底值优先走分离处理
空值和固定兜底值是确定性热点，加随机盐反而让原本可预测的逻辑变不可控。更稳的做法是拆开处理：
- 把空值或兜底值单独拎出来：
WHERE key IS NULL OR key IN (0, -999) - 非空/非兜底部分走正常 JOIN
- 对空值部分做
CROSS JOIN或补默认值（需评估记录量，避免笛卡尔积爆炸） - 最后用
UNION ALL合并，不走去重逻辑，保结果正确性
热点 key 加盐必须满足三个硬条件
加盐有效 ≠ 加了就有效。生产环境常见失败原因是 salt 函数不一致、分区没重设、或盐值范围不合理：
- 大表和小表的 salt 逻辑必须完全一致：比如都用
hash(key) % 10，不能一个用RAND()、一个用hash——RAND()每次执行结果不同，JOIN 不上 - 盐值数量建议 5–20：太小（如 2）仍倾斜；太大（如 100）会让总 Shuffle 数据翻倍，得不偿失
- 加盐后必须显式重分区，比如 Spark SQL 加
/*+ REPARTITION(100) */，否则引擎仍按原 key 分区，盐白加 - 别忘了验证结果：加盐前后
COUNT(*)和关键聚合值必须一致
小表够小就直接广播，绕过 Shuffle
如果维表真实大小（TotalSize）在 100MB 以内，MapJoin 是最轻量、最稳的解法——它压根不走 Reduce，自然不存在倾斜。
- Hive 开启自动 MapJoin：
SET hive.auto.convert.join = true，并调高阈值：SET hive.mapjoin.smalltable.filesize = 104857600（100MB） - Spark SQL 用
BROADCASThint：SELECT /*+ BROADCAST(dim_table) */ ... FROM fact JOIN dim_table - 注意：广播的是序列化后大小，不是行数；STRING 列多的小表容易“看着小、实际大”
真正难处理的从来不是技术方案本身，而是业务语义约束——比如你不能改兜底值、不能丢空值、不能接受 CROSS JOIN 的不确定性。这时候加盐或分离都只是权衡，不是银弹。动手前，先搞清哪些 key 必须保留、哪些聚合口径不能动、哪些任务失败是可容忍的。
