hive优化数据倾斜
作者:互联网
hive数据倾斜产⽣的原因
数据倾斜的原因很⼤部分是join倾斜和聚合倾斜两⼤类
⼀、Hive倾斜之group by聚合倾斜
原因:
分组的维度过少,每个维度的值过多,导致处理某值的reduce耗时很久;
对⼀些类型统计的时候某种类型的数据量特别多,其他的数据类型特别少。当按照类型进⾏group by的时候,会将相同的group by字
段的reduce任务需要的数据拉取到同⼀个节点进⾏聚合,⽽当其中每⼀组的数据量过⼤时,会出现其他组的计算已经完成⽽这个
reduce还没有计算完成,其他的节点⼀直等待这个节点的任务执⾏完成,所以会⼀直看到map 100% reduce99%的情况;
解决⽅法:
set hive.map.aggr=true;
set hive.groupby.skewindata=true;
原理:
hive.map.aggr=true 这个配置代表开启map端聚合;
hive.groupby.skewindata=true,当选项设定为true,⽣成的查询计划会有两个MR Job。当第⼀个MR Job中,Map的输出结果结
合会随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果。这样处理的结果是相同的Group By Key有可能被分发到不同
的Reduce中,从⽽达到负载均衡的⽬的。第⼆个MR Job再根据预处理的数据结果按照Group By Key分布到reduce中,这个过程可
以保证相同的key被分到同⼀个reduce中,最后完成最终的聚合操作。
⼆、Hive倾斜之Map和Reduce优化
原因1:当出现⼩⽂件过多,需要合并⼩⽂件。可以通过set hive.merge.mapredfiles=true来解决;
原因2:输⼊数据存在⼤块和⼩块的严重问题,⽐如 说:⼀个⼤⽂件128M,还有1000个⼩⽂件,每 个1KB。 解决⽅法:任务输⼊
前做⽂件合并,将众多⼩⽂件合并成⼀个⼤⽂件。通过set hive.merge.mapredfiles=true解决;
原因3:单个⽂件⼤⼩稍稍⼤于配置的block块的⼤⼩,此时需要适当增加map的个数。解决⽅法:set mapred.map.tasks的个数;
原因4:⽂件⼤⼩适中,但是map端计算量⾮常⼤,如:select id,count(*),sum(case when…),sum(case when …)…需要增加map
个数。解决⽅法:set mapred.map.tasks个数,set mapred.reduce.tasks个数;
三、Hive倾斜之HQL中包含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;
四、Hive倾斜之HQL中join优化
原因:当遇到⼀个⼤表和⼀个⼩表进⾏join操作时。使⽤mapjoin将⼩表加载到内存中。如:select /*+ MAPJOIN(a) */ a.c1, b.c1,b.c2 from a join b where a.c1 = b.c1;
遇到需要进⾏join,但是关联字段有数据为null,如表⼀的id需要和表⼆的id进⾏关联;
hive数据倾斜的优化核心思想:
1、减少数据量
利用分区或者分桶,不过分桶用的很少,影响数据同步的效率,还有就是列比较多的表,做个裁剪,把列变少
2、避免数据倾斜
简单的讲,数据倾斜就是我们在计算数据的时候,数据的分散度不够,由于数据分布不均匀,造成数据大量的集中到一点,造成数据热点,查询卡住啦,
比如hivesql里的distinct、 group By、join就会出现这个现象。
1)一般我会用group by替换distinct,
2)group by的时候把数据量大的分组单独计算再用union all合并到一起
3)开启mapjoin
select /* +mapjoin(e)*/ from mydb.emp e;
3、使用一些语句的优化
比如使用with as临时表啊,group by替换distinct啊等等
4、参数配置优化
之前平台工程师或者数据组长会配置一些参数,我们开发一般很少配置
5、使用高效的查询引擎
我们后期使用了sparksql,这个明显提升了效率啦
6、存储格式(压缩)优化
我们还会使用ORC格式,这个对查询效率也有提升
7、根据业务逻辑对业务实现的整体进行优化
还有就是我们设置合理的分层,让数据逐步处理
标签:map,set,倾斜,数据,hive,group,优化 来源: https://www.cnblogs.com/qianmojie/p/16246150.html