小编给大家分享一下hive语句如何优化,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!
倾斜分成group by造成的倾斜和join造成的倾斜

假设网站访问日志中会记录用户的user_id,并且对于注册用户使用其用户表的user_id,对于非注册用户使用一个user_id=0代表。那么鉴于大多数用户是非注册用户(只看不写),所以user_id=0占据了绝大多数。而如果进行计算的时候如果以user_id作为group by的维度或者是join key,那么个别Reduce会收到比其他Reduce多得多的数据——因为它要接收所有user_id=0的记录进行处理,使得其处理效果会非常差,其他Reduce都跑完很久了它还在运行。
group by造成的倾斜有两个参数可以解决:
map 一个是Hive.Map.aggr,默认值已经为true,意思是会做Map端的combiner。所以如果你的group by查询只是做count(*)的话,其实是看不出倾斜效果的,但是如果你做的是count(distinct),那么还是会看出一点倾斜效果。
reduce 另一个参数是Hive.groupby. skewindata。这个参数的意思是做Reduce操作的时候,拿到的key并不是所有相同值给同一个Reduce,而是随机分发,然后Reduce做聚合,做完之后再做一轮MR,拿前面聚合过的数据再算结果。
set Hive.optimize.skewjoin = true;
还有要告诉Hive如何判断特殊值,根据Hive.skewjoin.key设置的数量Hive可以知道,比如默认值是100000,那么超过100000条记录的值就是特殊值。

所以这个参数其实跟Hive.Map.aggr做的是类似的事情,只是拿到Reduce端来做,而且要额外启动一轮Job,所以其实不怎么推荐用,效果不明显。
优化思路是: 先替从后统计
/*改写前*/ 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)是按group by 字段分组,按distinct字段排序,一般这种分布方式是很倾斜的
join造成的倾斜,就比如上面描述的网站访问日志和用户表两个表join:
select a.* from logs a join users b on a.user_id = b.user_id;
1.倾斜的单独处理
另外对于特殊值的处理往往跟业务有关系,所以也可以从业务角度重写sql解决。比如前面这种倾斜join,可以把特殊值隔离开来(从业务角度说,users表应该不存在user_id = 0的情况,但是这里还是假设有这个值,使得这个写法更加具有通用性):
select a.* from ( select a.* from (select * from logs where user_id = 0) a join (select * from users where user_id = 0) b on a.user_id = b.user_id union all select a.* from logs a join users b on a。user_id <> 0 and a。user_id = b.user_id )t;
2.倾斜的随机化处理
Select * from log a left outer join bmw_users b on case when a.user_id is null then concat(‘dp_hive’,rand() ) else a.user_id end = b.user_id;
3.字符类型的hash倾斜处理
统一hash规则,int和string的区别?
本质上:
h(1) 和h('1') ,本质上分配到partition上没有什么区别,根本就解决不了数据倾斜的问题。
区别在于:
h(10)可能与h(1)产生hash碰撞,因为hash值可能一样,导致进一步的数据倾斜
而:
h('10') h('1') ,本质上hash不一样;但是如果partition数量较小,可能导致分配到同一个partition里面
HashPartitioner是mapreduce的默认partitioner。
计算方法是
which reducer=(key.hashCode() & Integer.MAX_VALUE) % numReduceTasks
所以下面问题二的优化思路就是这个意思:
问题2:不同数据类型id的关联会产生数据倾斜问题。
一张表s8的日志,每个商品一条记录,要和商品表关联。但关联却碰到倾斜的问题。s8的日志中有字符串商品id,也有数字的商品id,类型是string的,但商品中的数字id是bigint的。猜测问题的原因是把s8的商品id转成数字id做hash来分配reduce,所以字符串id的s8日志,都到一个reduce上了,解决的方法验证了这个猜测。
方法:把数字类型转换成字符串类型
Select * from s8_log a
Left outer join r_auction_auctions b
On a.auction_id = cast(b.auction_id as string);
以上是“hive语句如何优化”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。