hive数据倾斜原因解决方法

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进行关联;
解决方法1:id为null的不参与关联
比如:

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: 给null值分配随机的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; 

合理设置Map数

  1. 通常情况下,作业会通过input的目录产生一个或者多个map任务。
    主要的决定因素有:input的文件总个数,input的文件大小,集群设置的文件块大小。
  2. 是不是map数越多越好?
    答案是否定的。如果一个任务有很多小文件(远远小于块大小128m),则每个小文件也会被当做一个块,用一个map任务来完成,而一个map任务启动和初始化的时间远远大于逻辑处理的时间,就会造成很大的资源浪费。而且,同时可执行的map数是受限的。
  3. 是不是保证每个map处理接近128m的文件块,就高枕无忧了?
    答案也是不一定。比如有一个127m的文件,正常会用一个map去完成,但这个文件只有一个或者两个小字段,却有几千万的记录,如果map处理的逻辑比较复杂,用一个map任务去做,肯定也比较耗时。
    针对上面的问题2和3,我们需要采取两种方式来解决:即减少map数和增加map数;
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,319评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,801评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,567评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,156评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,019评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,090评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,500评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,192评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,474评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,566评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,338评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,212评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,572评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,890评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,169评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,478评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,661评论 2 335

推荐阅读更多精彩内容