温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

hive语句如何优化

发布时间:2021-12-10 09:58:26 来源:亿速云 阅读:212 作者:小新 栏目:云计算

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

倾斜分成group by造成的倾斜和join造成的倾斜

hive语句如何优化
假设网站访问日志中会记录用户的user_id,并且对于注册用户使用其用户表的user_id,对于非注册用户使用一个user_id=0代表。那么鉴于大多数用户是非注册用户(只看不写),所以user_id=0占据了绝大多数。而如果进行计算的时候如果以user_id作为group by的维度或者是join key,那么个别Reduce会收到比其他Reduce多得多的数据——因为它要接收所有user_id=0的记录进行处理,使得其处理效果会非常差,其他Reduce都跑完很久了它还在运行。

1.group by造成的倾斜

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语句如何优化

所以这个参数其实跟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字段排序,一般这种分布方式是很倾斜的

2.join造成的倾斜

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语句如何优化”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI