什么是Hive数据倾斜问题
- 操作:join,group by,count distinct
- 现象:任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成;查看未完成的子任务,可以看到本地读写数据量积累非常大,通常超过10GB可以认定为发生数据倾斜。
- 原因:key分布不均匀
- 倾斜度衡量:平均记录数超过50w且最大记录数是超过平均记录数的4倍;最长时长比平均时长超过4分钟,且最大时长超过平均时长的2倍
Hive的典型操作时多表关联
查询
SELECT a.* FROM a JOIN b ON (a.id = b.id AND a.department = b.department)
1. 判断是否有数据倾斜
通过对表做group by key操作,取Top N,看表中是否有大量相同的Key
2.Reducer端数据倾斜
Hive查询底层是基于Hadoop的Map Reduce,如果一个Reducer要处理的数据量远多于其它Reducer要处理的数据量,那么就会产生Reducer端的数据倾斜。那么Reducer要处理的数据量是如何确定的呢?通常数据(KV数值对)Shuffle到某个Reducer是根据Key进行Hash然后对Reducer个数进行取模。那么Reducer端的优化包含三种做法
2.1 增加Reducer个数
set mapred.reduce.tasks=500; SELECT a.*,b.name FROM a JOIN b ON (a.id = b.id AND a.department = b.department);
2.2 空KEY过滤
有时join超时是因为某些key对应的数据太多,而相同key对应的数据都会发送到相同的reducer上,从而导致内存不够。此时我们应该仔细分析这些异常的key,很多情况下,这些key对应的数据是异常数据,我们需要在SQL语句中进行过滤。例如key对应的字段为空。
SELECT table_a.* , b.name FROM ( SELECT * FROM a WHERE id is not null )table_a JOIN b ON (table_a.id = b.id AND table_a.department = b.department)
2.3 空KEY转换
有时虽然某个key为空对应的数据很多,但是相应的数据不是异常数据,必须要包含在join的结果中,此时我们可以表a中key为空的字段赋一个随机的值,使得数据随机均匀地分不到不同的reducer上。例如:
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;
3 设置set hive.groupby.skewindata=true
这是通用的优化方法,对于group by或distinct设置set hive.groupby.skewindata=true
4. 大小表关联,大表和大表关联
4.1 大小表关联
将key相对分散,并且数据量小的表放在join的左边,这样可以有效减少内存溢出错误发生的几率;再进一步,可以使用mapjoin让小的维度表(1000条以下的记录条数)先进内存。在map端完成reduce
4.2 大表和大表关联
大表和大表关联:把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。
4.3 大表和不小的表关联
使用map join解决数据倾斜的常景下小表关联大表的问题,但如果小表很大,怎么解决。这个使用的频率非常高,但如果小表很大,大到map join会出现bug或异常,这时就需要特别的处理。云瑞和玉玑提供了非常给力的解决方案。以下例子:
select * from log a left outer join members b on a.memberid = b.memberid
Members有600w+的记录,把members分发到所有的map上也是个不小的开销,而且map join不支持这么大的小表。如果用普通的join,又会碰到数据倾斜的问题。
解决方法:
select /*+mapjoin(x)*/* from log a left outer join ( select /*+mapjoin(c)*/d.* from (select distinct memberid from log ) c join members d on c.memberid = d.memberid )x on a.memberid = b.memberid
先根据log取所有的memberid,然后mapjoin 关联members取今天有日志的members的信息,然后在和log做mapjoin。
假如,log里memberid有上百万个,这就又回到原来map join问题。所幸,每日的会员uv不会太多,有交易的会员不会太多,有点击的会员不会太多,有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。
参考:
http://www.dcharm.com/?p=32
http://janefucninax.blog.sohu.com/247717331.html
重点阅读:
http://sznmail.iteye.com/blog/1499789
http://sunyi514.github.io/2013/09/01/%E6%95%B0%E6%8D%AE%E4%BB%93%E5%BA%93%E4%B8%AD%E7%9A%84sql%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%EF%BC%88hive%E7%AF%87%EF%BC%89/
相关推荐
利用Hive进行复杂用户行为大数据分析及优化案例(全套视频+课件...14_Hive中的数据倾斜及解决方案-三种join方式 15_Hive中的数据倾斜及解决方案-group by 16_Hive中使用正则加载数据 17_Hive中使用Python脚本进行预处理
大数据hive数据倾斜,hive-sql优化
Hive优化方法整理 hive 数据倾斜 内连接
Hive原理/Hive SQL/Hive 函数/数据仓库分层和建模/Hive sql优化/数据倾斜
总结了hive中数据处理发生的倾斜问题,不同的原因对应不同的解决方案,比较具体可实操的方法
涉及到Hive优化相关的一些常用技巧,当Hive出现数据倾斜时或者负载不均衡等情况,往往会出现耗久,甚至跑不出结果的尴尬场面,这个时候如果计算资源监控显示有没有完全饱和利用,就需要涉及到优化了;
Hive性能优化 数据倾斜 hql优化 count(distinct)优化
hiveSQL优化整理版,基于hive2整理,从数据倾斜、表优化、并行、压缩、语法树方面整理
Hive查询生成多个map reduce job,一个map reduce job又有map,reduce,spill,shuffle,sort等多个阶段,所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化,针对MR全局的优化以及针对整个查询的优化。...
主要介绍了hive开发过程中常见的性能问题及优化方法: 数据倾斜: 1)group by 数据倾斜 2)join 数据倾斜 3)reduce数过少 4)大小表关联 动态分区 并行 小文件过多 等等
50.Hive中的数据倾斜及解决方案-三种join方式 51.Hive中的数据倾斜及解决方案-group by 52.Hive中使用正则加载数据 53. Hive中使用Python脚本进行预处理 第5章:Zeus任务资源调度工具 54.资源任务调度框架介绍 55....
从数据倾斜,jvm重用,语句编写等方面对hive查询进行优化。
数据量大不是问题,数据倾斜是个问题 jobs数比较多的作业运行效率相对比较低,比如及时有几百行的表,如果多次关联汇总,产生十几个jobs,耗时很长,原因是map reduce作业初始化的时间是比较长的
业务逻辑,我们从业务逻辑的层面上来优化数据倾斜,比如上面的例子,我们单独对这两个城市来做count,最后和其它城市做整合。 大数据常见问题之数据倾斜全文共5页,当前为第4页。大数据常见问题之数据倾斜全文共5页...
业务逻辑,我们从业务逻辑的层⾯上来优化数据倾斜,⽐如上⾯的例⼦,我们单独对这两个城市来做count,最后和其它城市做整 合。 2.程序层⾯,⽐如说在Hive中,经常遇到count(distinct)操作,这样会导致最终只有⼀个...
SQL语句优化:union all和distinct,数据格式优化,小文件过多优化,并行执行优化,数据倾斜优化, Limit 限制调整优化,JOIN优化
07_Hive中高级优化及数据倾斜处理(一) 08_Hive中高级优化及数据倾斜处理(二 09_Hive中groupBy数据倾斜面试详解及HBase 性能优化详解 10_大数据项目简历编写指导及HADOOP 项目业务需求补充说明
group by 优化 set hive.map.aggr = true;... //解决数据倾斜的万能钥匙 当map阶段运行不了的时候,可以设置 set hive.map.aggr = false; 说明 设置hive.map.aggr=true,提高HiveQL聚合的执行性能。 set hive.ma