这篇文章主要讲解了“Hive数据倾斜的原因及优化方法”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Hive数据倾斜的原因及优化方法”吧！
我们提供的服务有：网站制作、网站设计、微信公众号开发、网站优化、网站认证、廉江ssl等。为上1000家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的廉江网站制作公司
数据倾斜成因：由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点。具体为某一个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。
感谢各位的阅读，以上就是“Hive数据倾斜的原因及优化方法”的内容了，经过本文的学习后，相信大家对Hive数据倾斜的原因及优化方法这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！