key 分布不均匀 业务数据本身的欠缺性 建表设计方法不对 有些 SQL 难免会有一下数据倾斜不可避免 表现的形式： 任务完成进度卡死在99%，或者进度完成度在100%但是查看任务监控，发现还是有少量（1个或几个）reduce 子任务未完成。因为其处理的数据量和其他 reduce 差异过大。单一reduce 的记录数与平均记录数差异过大，通常可能达到3倍甚至更多。 最长时长远大于平均时长。
解决方案： 参数调整： hive.map.aggr=true： Map 端部分聚合，相当于 Combiner hive.groupby.skewindata=true： 有数据倾斜的时候进行负载均衡，当选项设定为 true，生成的查询计划会有两个 MR Job。
第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。
2：参数调节： 如何 Join： 关于驱动表的选取，选用 join key 分布最均匀的表作为驱动表 做好列裁剪和 filter 操作，以达到两表做 join 的时候，数据量相对变小的效果 大小表 Join： 使用 map join 让小的维度表（1000条以下的记录条数） 先进内存。在 map 端完成 reduce. 大表 Join 大表： 把空值的 key 变成一个字符串加上随机数，把倾斜的数据分到不同的 reduce 上，由于 null值关联不上，处理后并不影响最终结果 count distinct 大量相同特殊值 count distinct 时，将值为空的情况单独处理，如果是计算 count distinct，可以不用处理，直接过滤，在最后结果中加1。
如果还有其他计算，需要进行 group by，可以先将值为空的记录单独处理，再和其他计算结果进行 union。 group by 维度过小： 采用 sum() group by 的方式来替换 count(distinct) 完成计算。 特殊情况特殊处理： 在业务逻辑优化效果的不大情况下，有些时候是可以将倾斜的数据单独拿出来处理。最后 union 回去。 如果确认业务需要这样倾斜的逻辑，考虑以下的优化方案： 总结：
1、对于 join，在判断小表不大于1 G 的情况下，使用 map join
2、对于 group by 或 distinct，设定 hive.groupby.skewindata=true
3、尽量使用上述的 SQL 语句调节进行优化
