Hive 中的 shuffle 操作，本质上就是 MapReduce 任务里那个关键的“分拣”环节——数据需要重新分区并排序，才能准确送达对应的 reduce 端进行后续处理。但这一步经常遇到一个让人头疼的问题：数据倾斜。简单说，就是在 shuffle 阶段，某些 reduce 任务莫名其妙地扛走了绝大多数数据，而其他任务却几乎空闲。结果整个任务被拖得像蜗牛一样慢，集群资源也被白白浪费。要避开这个坑，业内总结了几种行之有效的方案，下面逐一拆解。
- Salting（加盐）：在 key 前面随机拼接一个前缀，原本扎堆的数据就能被打散到不同的 reduce 任务中。比如某个 key 的分布明显不均，给它加上一段随机字符串，用新的 key 进行 shuffle。等计算完成后，再把前缀去掉即可——方法简单直接，但效果显著。
- Combiner（局部聚合）：在 map 阶段之后、reduce 之前，先让 combiner 做一轮局部的“同城合并”。这样一来，真正需要传到 reduce 端的数据量会大幅减少，数据倾斜带来的影响自然也随之降低。
- 自定义 Partitioner：自己编写一个 Partitioner 类，按照数据特性将 key 均匀分配到各个 reduce 任务。目标只有一个：确保每个任务拿到的数据量基本接近——公平分配，谁也不多扛。
- 数据预处理：在数据进入 Hive 之前就先做一轮处理，比如使用聚合函数或窗口函数把数据分布调整平衡。不要等到 shuffle 阶段才手忙脚乱，从源头治理才是上策。
- 增加 Reduce 任务数量：如果数据倾斜实在无法避免，可以多开几个 reduce 任务，让集群资源得到更充分的利用。不过代价也很明显——集群负载和运行成本会相应增加。
- 优化 MapReduce 作业配置：合理设置 map 和 reduce 任务的内存大小、超时时间等参数。有时问题并不出在数据分布，而是配置不合理——调一调参数，任务就能跑得顺畅。
- 换引擎：使用 Tez 或 Spark：传统 MapReduce 的 shuffle 机制相对笨重，而 Tez 和 Spark 这类分布式计算引擎提供了更高级的抽象层和优化策略，对缓解数据倾斜有明显帮助。很多团队在实际测试中发现，换引擎比死磕参数要省力得多。
话说回来，上面这些方法并不是只能单选——根据实际场景组合使用，效果会更好。最关键的是在设计阶段就要把数据的分布特性和业务需求充分考虑进去，提前预判倾斜风险，这样才能让 Hive 查询跑得更稳、更快。
