hive数据倾斜优化策略_warn exec.groupbyoperator: disable hash aggr: #has

友情提示：更多有关大数据、人工智能方面技术文章请关注博主个人微信公众号：bigdata_shequ！

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

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

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

) from user group by user.gender  

hive.groupby.skewindata =true

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

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

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亿条记录。

一个大表和一个小配置表的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

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