下面列举了一些常见的导致数据倾斜的场景。
场景 1 ： 当一个大表和一个小表 join 时， 如果小表的 key 较集中，将会引起大表中的数据被分发到一个或者少数几个 Reducer 任务中，导致数据分布不均匀。
场景 2： 在 group by 时，如果分组的维度太少，维度的值分布不均匀，将导致数据分布不 均匀。
场景 3： 当大表与大表关联时，在关联的条件字段中，其中一个表的空值、 null 值过多， 将导致数据分布不均匀。
针对数据倾斜，业界一般有以下几种解决方案。
1 . 调节参数
可以通过修改 hive.map.aggr 和 hive.groupby.skewindata 参数同时配置为 true，在 Mapper 端 进行聚合操作，当发生数据倾斜时进行负载均衡。 所生成的查询计划会有两个 MR 任务。 在第 一个 MR 任务中， Mapper 阶段的输出结果集合会被随机分布到 Reducer 阶段中， 每个 Reducer 都进行部分聚合操作，并输出结果。这样处理的结果是相同的 Key 可以被分发到不同的 Reducer 中，从而达到负载均衡的目的。在第二个 MR 任务中， Mapper 根据第一个 MR 任务预处理后的 数据结果再按照 key输出给 Reducer，这个过程可以保证相同的 key被分布到同一个 Reducer 中 。 经过这两轮 MR 任务最后完成最终的聚合操作。相关的参数设置如下：
hive.map.aggr=true
hive.groupby.skewindata=true
2. 优化SOL语旬
- 使用 mapjoin：让小的维度表（建议在 20000 条记录以下〉先写入内存，并按顺序扫描 大表完成 join。这种方式比较适用于大表和小表的 join。
- 空值优化： 可以将空值的 key 变成一个字符串加上随机数，把倾斜的数据分布到不同的Reducer 中 。 也可以对空值进行单独处理，然后再和其他非空值的计算结果进行合 并。
- group by 优化： 采用 sum（）结合 group by 的方式替换 count(distinct）来完成计算。
3 特殊情况特殊处理
在业务逻辑优化效果不太好的情况下，有些时候可以将倾斜的数据单独拿出来处理，最后 再进行 union。 为了方便理解，下面列举几个业务场景来进行说明。
案例 1 ： 空值产生的数据倾斜问题。
场景：比如在日志中，通常会发生信息丢失的问题。 假如日志中的 order_id 存在丢失情况， 如果将其中的 order_id 和订单表的 order_id 关联，就会出现数据倾斜。
解决方法 1: order_id 为空值的则不参与关联，用 union all 合并数据，代码所示
解决方法 2：为空值分配一个随机值
案例总结：解决方法 2 比方法 1 的执行效率更高，不但 I/O 少了，而且作业数也少了。在解决 方法 1中 log 读取两次， job 数是 2：在解决方法 2 中 job 数是 1。这种优化适合由于无效 id （ 比 如－99、”、 null 等无效字符组合）产生的倾斜问题。 把空值的 key 变成一个字符串加上随机数， 就能把倾斜的数据分布到不同的 Reducer 中，从而解决数据倾斜问题。
案例 2：小表不小不大， 怎么用 mapjoin 解决数据倾斜问题。
使用 mapjoin 解决小表（记录数少）关联大表的数据倾斜问题。这种方法使用的频率非常高， 但是如果小表很大，大到 mapjoin 会出现 bug 或异常，这时就需要特别处理了 。 例如：
orders 表有超过 600 万条的记录，把 orders 分发到所有的 Mapper 中也有不小的开销，而且 ma阳oin 不支持这么大的表。 如果用普通的 join，又会碰到数据倾斜的问题。 那么解决方法如下代码所示
select /*+mapjoin(t)*/* from log a
left outer join (
select /*+mapjoin(c)*/b*
from ( select order_id from log group by order_id) c
join orders b
on c.order_id = d.order_id
) t
on a.order_id = t.order_id
上所述，解决数据倾斜问题就是要将 Mapper 阶段的输出数据更均匀地分布到 Reducer 中，可以通改变 job 的步骤、处理 key 值等方式来实现。数据倾斜多数是由于开发人员疏忽引 起的，问题本身并不是很复杂。
