Hive数据倾斜的原因及优化方法
这篇文章主要讲解了“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数据倾斜的原因及优化方法这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!
当前标题:Hive数据倾斜的原因及优化方法
网站URL:http://myzitong.com/article/pdissp.html