数据倾斜是进行大数据计算时最常常遇到的问题之一。当咱们在执行HiveQL或者运行MapReduce做业时候,若是遇到一直卡在map100%,reduce99%通常就是遇到了数据倾斜的问题。数据倾斜实际上是进行分布式计算的时候,某些节点的计算能力比较强或者须要计算的数据比较少,早早执行完了,某些节点计算的能力较差或者因为此节点须要计算的数据比较多,致使出现其余节点的reduce阶段任务执行完成,可是这种节点的数据处理任务尚未执行完成。html
在hive中产生数据倾斜的缘由和解决方法:负载均衡
1)group by,我使用Hive对数据作一些类型统计的时候遇到过某种类型的数据量特别多,而其余类型数据的数据量特别少。当按照类型进行group by的时候,会将相同的group by字段的reduce任务须要的数据拉取到同一个节点进行聚合,而当其中每一组的数据量过大时,会出现其余组的计算已经完成而这里还没计算完成,其余节点的一直等待这个节点的任务执行完成,因此会看到一直map 100% reduce 99%的状况。分布式
解决方法:set hive.map.aggr=true大数据
set hive.groupby.skewindata=true优化
原理:hive.map.aggr=true 这个配置项表明是否在map端进行聚合,至关于combinerhtm
hive.groupby.skwindata=true 当选项设定为 true,生成的查询计划会有两个 MR Job。第一个 MR Job 中,Map 的输出结果集合会随机分布到 Reduce 中,每一个 Reduce 作部分聚合操做,并输出结果,这样处理的结果是相同的 Group By Key 有可能被分发到不一样的 Reduce 中,从而达到负载均衡的目的;第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中(这个过程能够保证相同的 Group By Key 被分布到同一个 Reduce 中),最后完成最终的聚合操做。blog
2)map和reduce优化。内存
1.当出现小文件过多,须要合并小文件。能够经过set hive.merge.mapfiles=true来解决。文档
2.单个文件大小稍稍大于配置的block块的大写,此时须要适当增长map的个数。解决方法:set mapred.map.tasks个数get
3.文件大小适中,但map端计算量很是大,如select id,count(*),sum(case when...),sum(case when...)...须要增长map个数。解决方法:set mapred.map.tasks个数,set mapred.reduce.tasks个数
3)当HiveQL中包含count(distinct)时
若是数据量很是大,执行如select a,count(distinct b) from t group by a;类型的SQL时,会出现数据倾斜的问题。
解决方法:使用sum...group by代替。如select a,sum(1) from (select a, b from t group by a,b) group by a;
4)当遇到一个大表和一个小表进行join操做时。
解决方法:使用mapjoin 将小表加载到内存中。
如:select /*+ MAPJOIN(a) */
a.c1, b.c1 ,b.c2
from a join b
where a.c1 = b.c1;
5)遇到须要进行join的可是关联字段有数据为空,如表一的id须要和表二的id进行关联
解决方法1:id为空的不参与关联
好比:select * from log a
join users b
on a.id is not null and a.id = b.id
union all
select * from log a
where a.id is null;
解决方法2:给空值分配随机的key值
如:select * from log a
left outer join users b
on
case when a.user_id is null
then concat(‘hive’,rand() )
else a.user_id end = b.user_id;