数据倾斜成因：由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点。具体为某一个reduce接收到的数据是其他reduce的n倍，导致明显的木桶效应。
症状：
1，对表做select count(1) from tb group by key，看表中是否有大量相同的key。
2，查看监控界面，任务进度长时间维持在99%(或100%)，只有少量(1个或几个)reduce子任务未完成或某几个reduce子任务是平均reduce时长的n倍；
上图的其中的一个job的reduce时间远远超出其他reduce时长，表明该reduce处理的数据远超出其他的reduce，可见此次统计发生数据倾斜。
解决方案
参数调优：
1，set hive.groupby.skewindata=true：这个参数的意思是做Reduce操作的时候，拿到的key并不是所有相同值给同一个Reduce，而是随机分发，然后Reduce做聚合，做完之后再做一轮MR，拿前面聚合过的数据再算结果。所以这个参数其实跟Hive.Map.aggr做的是类似的事情，只是拿到Reduce端来做，而且要额外启动一轮Job，所以其实不怎么推荐用，效果不明显。
2，set hive.skewjoin.key=100000：这个是join的键对应的记录条数超过这个值则会进行优化。
3，set mapred.reduce.tasks=500：增加Reducer个数，通常数据(KV数值对)Shuffle到某个Reducer是根据Key进行Hash然后对Reducer个数进行取模。
HQL语句优化：
1，小表join大表：
将小表放在join左边，减少oom的几率；
使用mapjoin，小表数据最好在1000条以内。select /*+mapjoin(a)*/ count(1) from tb_a a left outer join tb_b b on a.uid=b.uid；
2，大表join大表：
把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果。
select * from tb_a a left outer join tb_b b on (case when a.userid is null then concact('xxx', rand()) else a.userid end = b.userid);
3，不同数据类型关联产生数据倾斜，在join之前先转换数据类型：
select * from users a left outer join logs b on a.usr_id = cast(b.user_id as string);
4，count distinct优化
采用sum() group by的方式来替换count(distinct )进行计算
原语句：select a， count(distinct b) as c from tbl group by a;
改写后：select a， count(*) as c from (select distinct a， b from tbl) group by a;
另外，count distinct时，将值为空的情况单独处理，如果是计算count distinct，可以不用处理，直接过滤，在最后结果中加1。如果还有其他计算，需要进行group by，可以先将值为空的记录单独处理，再和其他计算结果进行union。
