hive数据倾斜优化策略

清疚 2022-11-20 09:37 237阅读 0赞

# hive数据倾斜优化策略 #

Hive数据倾斜

Group By 中的计算均衡优化

1.Map端部分聚合

先看看下面这条SQL，由于用户的性别只有男和女两个值 （未知）。如果没有map端的部分聚合优化，map直接把groupby\_key 当作reduce\_key发送给reduce做聚合，就会导致计算不均衡的现象。虽然map有100万个，但是reduce只有两个在做聚合，每个reduce处理100亿条记录。

selectuser.gender,count(1) from user group by user.gende

![70][]

没开map端聚合产生的计算不均衡现象

hive.map.aggr=true参数控制在group by的时候是否map局部聚合，这个参数默认是打开的。参数打开后的计算过程如下图。由于map端已经做了局部聚合，虽然还是只有两个reduce做最后的聚合，但是每个reduce只用处理100万行记录，相对优化前的100亿小了1万

![70 1][]

map端聚合打开map聚合开关缺省是打开的，但是不是所有的聚合都需要这个优化。考虑先面的sql,如果groupby\_key是用户ID，因为用户ID没有重复的，因此map聚合没有太大意义，并且浪费资源。

select user..id,count(1) from user group by user.id

hive.groupby.mapaggr.checkinterval = 100000

Hive.map.aggr.hash.min.reduction=0.5

上面这两个参数控制关掉map聚合的策略。Map开始的时候先尝试给前100000 条记录做hash聚合，如果聚合后的记录数/100000>0.5说明这个groupby\_key没有什么重复的，再继续做局部聚合没有意义，100000 以后就自动把聚合开关关掉，在map的log中会看到下面的提示：2011-02-23 06:46:11,206 WARN org.apache.hadoop.hive.ql.exec.GroupByOperator: Disable Hash Aggr: \#hash table = 99999 \#total = 100000 reduction = 0.0 minReduction = 0.52.

数据倾斜

通常这种情况都是在有distinct出现的时候，比如下面的sql,由于map需要保存所有的user.id

,map聚合开关会自动关掉，导致出现计算不均衡的现象，只有2个redcue做聚合，每个reduce处理100亿条记录。

select user.gender,count(distinct user.id

) from user group by user.gender

![70 2][]

hive.groupby.skewindata =true

参数会把上面的sql翻译成两个MR，第一个MR的reduce\_key是gender+id。因为id是一个随机散列的值，因此这个MR的reduce计算是很均匀的，reduce完成局部聚合的工作

![70 3][]

MR1第二个MR完成最终的聚合，统计男女的distinct id值，数据流如下图所示，每个Map只输出两条记录，因此虽然只有两个redcue计算也没有关系，绝大部分计算量已经在第一个MR完成

![70 4][]

MR2 hive.groupby.skewindata

默认是关闭的，因此如果确定有不均衡的情况，需要手动打开这个开关。当然，并不是所有的有distinct的group by都需要打开这个开关，比如下面的

sql。因为user.id

select id,count (distinct gender) from user group by user.id

select gender,count (distinct id) from user group by user.gender

是一个散列的值，因此已经是计算均衡的了，所有的reduce都会均匀计算。只有在groupby\_key不散列，而distinct\_key散列的情况下才需要打开这个开关，其他的情况map聚合优化就足矣。   
  
;三．Join 中的计算均衡优化在hive中，join操作一般都是在reduce阶段完成的，写sql的时候要注意把小表放在join的左边，原因是在 Join 操作的 Reduce 阶段，位于 Join 操作符左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生 out of memory 错误的几率。 一个大表和一个配置表的reduce join经常会引起计算不均衡的情况。比如配置表gender\_config(gender string,gender\_id int)。把“男”“女”字符串映射成一个id。配置表和上面的user表join的sql如下： select user.id

gender\_config.gender\_id from gender\_config join user on gender\_config.gender=user.gender gender 只有男女两个值，hive处理join的时候把join\_key作为reduce\_key,因此会出现和group by类似的reduce计算不均衡现象，只有两个reduce参与计算，每个reduce计算100亿条记录。

![70 5][]

一个大表和一个小配置表的reduce join流程图 这种大表和配置表通常采用mapjoin的方式来解决这种不均衡的现象。目前hive是采用/\*+ MAPJOIN(gender\_config) \*/提示的方式告诉翻译器把sql翻译成mapjoin，提示里必须指明配置表是哪个。 select /\*+ MAPJOIN(gender\_config) \*/ user.id

gender\_config.gender\_id from gender\_config join user on gender\_config.gender=user.gender

![70 6][]

一个大表和一个小配置表的map join流程图 每个map会把小表读到hash table，然后和大表做hash join。因此map join的关键是小表能放入map进程的内存，如果内存放不下会序列化到硬盘，效率会直线下降。 成千上万个map从hdfs读这个小表进自己的内存，使得小表的读操作变成成个join的瓶颈，甚至有些时候有些map读这个小表会失败（因为同时有太多进程读了），最后导致join失败。临时解决办法是增加小表的副本个数。下一步优化可以考虑把小表放入Distributed Cache里，map读本地文件即可。

[70]: /images/20221120/84ea865d0eca4a9da17ce038fa86d54d.png
[70 1]: /images/20221120/8a96dc14acff41c88b6d25f2a57c3a3e.png
[70 2]: /images/20221120/bd9a564790cc41dcbaa099eebdde6282.png
[70 3]: /images/20221120/9d226f8e9f2242d89cb864014ed57e98.png
[70 4]: /images/20221120/d6b8c72ceca7461fa644a2507c0f05ae.png
[70 5]: /images/20221120/70fed63a5ea14ad9bb14748f5795fbab.png
[70 6]: /images/20221120/681e2652c74e42c6bf0018f45a9970ae.png