什么是Hive数据倾斜问题
- 操作：join,group by,count distinct
- 现象：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成；查看未完成的子任务，可以看到本地读写数据量积累非常大，通常超过10GB可以认定为发生数据倾斜。
- 原因：key分布不均匀
- 倾斜度衡量：平均记录数超过50w且最大记录数是超过平均记录数的4倍；最长时长比平均时长超过4分钟，且最大时长超过平均时长的2倍
Hive的典型操作时多表关联
查询
SELECT a.* FROM a JOIN b ON (a.id = b.id AND a.department = b.department)
1. 判断是否有数据倾斜
通过对表做group by key操作，取Top N，看表中是否有大量相同的Key
2.Reducer端数据倾斜
Hive查询底层是基于Hadoop的Map Reduce，如果一个Reducer要处理的数据量远多于其它Reducer要处理的数据量，那么就会产生Reducer端的数据倾斜。那么Reducer要处理的数据量是如何确定的呢？通常数据(KV数值对）Shuffle到某个Reducer是根据Key进行Hash然后对Reducer个数进行取模。那么Reducer端的优化包含三种做法
2.1 增加Reducer个数
set mapred.reduce.tasks=500; SELECT a.*,b.name FROM a JOIN b ON (a.id = b.id AND a.department = b.department);
2.2 空KEY过滤
有时join超时是因为某些key对应的数据太多，而相同key对应的数据都会发送到相同的reducer上，从而导致内存不够。此时我们应该仔细分析这些异常的key，很多情况下，这些key对应的数据是异常数据，我们需要在SQL语句中进行过滤。例如key对应的字段为空。
SELECT table_a.* , b.name FROM ( SELECT * FROM a WHERE id is not null )table_a JOIN b ON (table_a.id = b.id AND table_a.department = b.department)
2.3 空KEY转换
有时虽然某个key为空对应的数据很多，但是相应的数据不是异常数据，必须要包含在join的结果中，此时我们可以表a中key为空的字段赋一个随机的值，使得数据随机均匀地分不到不同的reducer上。例如：
select * from log a left outer join users b on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;
3 设置set hive.groupby.skewindata=true
这是通用的优化方法，对于group by或distinct设置set hive.groupby.skewindata=true
4. 大小表关联，大表和大表关联
4.1 大小表关联
将key相对分散，并且数据量小的表放在join的左边，这样可以有效减少内存溢出错误发生的几率；再进一步，可以使用mapjoin让小的维度表（1000条以下的记录条数）先进内存。在map端完成reduce
4.2 大表和大表关联
大表和大表关联：把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果。
4.3 大表和不小的表关联
使用map join解决数据倾斜的常景下小表关联大表的问题，但如果小表很大，怎么解决。这个使用的频率非常高，但如果小表很大，大到map join会出现bug或异常，这时就需要特别的处理。云瑞和玉玑提供了非常给力的解决方案。以下例子：
select * from log a left outer join members b on a.memberid = b.memberid
Members有600w+的记录，把members分发到所有的map上也是个不小的开销，而且map join不支持这么大的小表。如果用普通的join，又会碰到数据倾斜的问题。
解决方法：
select /*+mapjoin(x)*/* from log a left outer join
( select /*+mapjoin(c)*/d.*
from (select distinct memberid from log ) c
join members d
on c.memberid = d.memberid
)x on a.memberid = b.memberid
先根据log取所有的memberid，然后mapjoin 关联members取今天有日志的members的信息，然后在和log做mapjoin。
假如，log里memberid有上百万个，这就又回到原来map join问题。所幸，每日的会员uv不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。
参考：
http://www.dcharm.com/?p=32
http://janefucninax.blog.sohu.com/247717331.html
重点阅读：
http://sznmail.iteye.com/blog/1499789
http://sunyi514.github.io/2013/09/01/%E6%95%B0%E6%8D%AE%E4%BB%93%E5%BA%93%E4%B8%AD%E7%9A%84sql%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%EF%BC%88hive%E7%AF%87%EF%BC%89/