表现:任务进度长时间维持在99%,查看任务监控页面8088,发现只有少量Reduce子任务为完成

主要原因:

1.key分布不均

2.业务数据本省的特性

3.建表时考虑不周

4.某些SQL语句本身就有数据倾斜问题

解决方案:

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端进行聚合

　　　　　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 中），最后完成最终的聚合操作。

　　2）map和reduce优化。

　　　　1.当出现小文件过多，需要合并小文件。可以通过set hive.merge.mapfiles=true来解决。

?　　　? ?2.单个文件大小稍稍大于配置的block块的大写，此时需要适当增加map的个数。解决方法：set mapred.map.tasks个数

　? ?　　 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;?

?

---

1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。