Hive数据倾斜的原因及优化方法

这篇文章主要讲解了“Hive数据倾斜的原因及优化方法”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Hive数据倾斜的原因及优化方法”吧！

数据倾斜成因：由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点。具体为某一个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数据倾斜的原因及优化方法这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！