写HQL语句的时候常常会遇到表Join的情况,一个简单的Join会被Hive解释成一个MapReduce任务,Map端分别读取两个表的数据,Reduce做真正的Join操作。
如果执行的过程中,如果发现有些Reduce任务比其他的Reduce任务慢很多,往往是发生了倾斜问题。
问题分析
select a.*, b.cat_name from dim_auction a join dim_category b on a.cat_id=b.cat_id
Join会被Hive解释成一个MapReduce任务时,Map端输出的记录是以Join的条件为Key的,即这些Map生成的Key都是 cat_id。随后,这些cat_id被Hash到多个Reduce任务中,来完成真正Join。所有拥有相同cat_id的记录一定会被分配到同一个 Reducer中。
但是每个cat_id多对应的记录数是不一样的,连衣裙类目的数据一定很多,钟点工类目的数据就很少。
如果某个Reducer比较悲催,分到了连衣裙类目,则其处理的数据量就会很大,最后表现在处理时间拖后腿的情况。
解决方法1 --- MapJoin
一个常用的解决手段是使用MapJoin,这种手段适合于关联的两个表有一个较小的情况。
其原理是,把Join动作提前到Map端,而不是Reduce端。
在Map的时候,对于大表,我们还是每个Map装载这个表的一部分,对于小表,我们把它放到每个Map中。这样每个Map都拥有小表的所有记录,可以在本地进行Join操作了。
具体的,在SQL中加入这样一个Hint就OK了:
select /*\+ MAPJOIN(b) \*/ a.*, b.cat_name from dim_auction a join dim_category b on a.cat_id=b.cat_id
解决方法2 ---分而治之
MapJoin是一个很好用的工具,但是却存在一个致命的弱点,就是其中一个表一定要比较小,能够完全装入单台机器的内存。
我们看下面一个例子:
select a.*, b.property_name from auction_property a left outer join ( select * from dim_base_properties where ds='20130620' ) b on a.property_id = b.property_id
auction_property表存储了每一个商品以及该商品的每一个属性。
dim_base_properties存储了每个属性的名称、以及一些其他元数据。
我们这次关联是想在auction_property表的基础上,加上每个属性的名称。
和类目一样,属性ID是有倾斜的,即有一些很常用的属性,被很多宝贝都引用了。
悲剧的事情是,auction_property和dim_base_properties这两个表都很大。。。
解决这个问题依赖于如下的观察:导致倾斜的Key的个数往往不多,也就是说,常用的属性就那么几个,剩下的大部分属性都不常用。
下面我们采用分治方法来解决这个问题:
第一步,找到的常用的属性。
create table lingyun_property_skew as select a.property_id, a.cnt, b.property_name from ( select property_id, count(*) as cnt from lingyun_auction_property a group by property_id order by cnt desc limit 1000 ) a join ( select * from tbdw.dim_base_properties where ds='20130620' ) b on a.property_id = b.property_id;
create table lingyun_auction_property_name as select * from ( select auction_id, property_id, value_id, property_name from lingyun_auction_property_name_part1 union all select auction_id, property_id, value_id, property_name from lingyun_auction_property_name_part2 ) a;
这里我们把auction_property表按照property_id汇总,并且找到最常用的1000个属性ID,并且查到了这些属性ID的名字。
这里1000可以扩展到上万个,只要保障能够被装进内存就可以了。
第二步是先解决常用属性的关联
create table lingyun_auction_property_name_temp as select /*+ MAPJOIN(b) */ a.*, b.property_name from auction_property a left outer join lingyun_property_skew b on a.property_id = b.property_id; create table lingyun_auction_property_name_part1 as select * from lingyun_auction_property_name_temp where property_name is not null;
这一步我们可以使用MAPJOIN是因为lingyun_property_skew是一个小表。
第三步是解决非常用属性的关联
create table lingyun_auction_property_name_part2 as select a.auction_id, a.property_id, a.value_id, b.property_name from ( select * from lingyun_auction_property_name_temp where property_name is null ) a join ( select * from tbdw.dim_base_properties where ds='20130620' ) b on a.property_id=b.property_id;
这一步不存在倾斜问题是因为可能导致倾斜的property_id已经从lingyun_auction_property_name_temp里面筛除掉了,剩下的每个property_id对应的商品数不会很多。
最后把两个表Union到一起,得到最终结果。
相关推荐
利用Hive进行复杂用户行为大数据分析及优化案例(全套视频+课件...14_Hive中的数据倾斜及解决方案-三种join方式 15_Hive中的数据倾斜及解决方案-group by 16_Hive中使用正则加载数据 17_Hive中使用Python脚本进行预处理
50.Hive中的数据倾斜及解决方案-三种join方式 51.Hive中的数据倾斜及解决方案-group by 52.Hive中使用正则加载数据 53. Hive中使用Python脚本进行预处理 第5章:Zeus任务资源调度工具 54.资源任务调度框架介绍 55....
group by 优化 set hive.map.aggr = true;... //解决数据倾斜的万能钥匙 当map阶段运行不了的时候,可以设置 set hive.map.aggr = false; 说明 设置hive.map.aggr=true,提高HiveQL聚合的执行性能。 set hive.ma
主要介绍了hive开发过程中常见的性能问题及优化方法: 数据倾斜: 1)group by 数据倾斜 2)join 数据倾斜 3)reduce数过少 4)大小表关联 动态分区 并行 小文件过多 等等
⼤数据常见问题之数据倾斜 什么是数据倾斜 简单的讲,数据倾斜就是我们在计算数据的时候,数据的分散度不够,导致⼤量的数据集中到了⼀台或者⼏台机器上计算,这些数据的计 算速度远远低于平均计算速度,导致整个...
大数据常见问题之数据倾斜全文共5页,当前为第1页。大数据常见问题之数据倾斜全文共5页,当前为第1页。大数据常见问题之数据倾斜 大数据常见问题之数据倾斜全文共5页,当前为第1页。 大数据常见问题之数据倾斜全文共...
本文来自于cnblogs,赘述了在工作中总结Hive的常用优化手段和在工作中使用Hive出现的问题。下面开始本篇文章的优化介绍:继续《那些年使用Hive踩过的坑》一文中的剩余部分.首先,我们来看看Hadoop的计算框架特性,在此...
SQL语句优化:union all和distinct,数据格式优化,小文件过多优化,并行执行优化,数据倾斜优化, Limit 限制调整优化,JOIN优化
⼤数据场景化解决⽅案 ⼤数据场景化解决⽅案 1.⼤数据的概念 维基百科的定义: ⼤数据是指利⽤常⽤软件⼯具捕获、管理和处理数据所耗时间超过可容忍时间的数据集。 2.⼤数据主流技术 数据采集: 使⽤Flume,可进⾏...
05_Hive重点知识回顾总结及小表与大表关联时MapJoin优化 06_Hive中大表与大表关联时SMB Join优化 07_Hive中高级优化及数据倾斜处理(一) 08_Hive中高级优化及数据倾斜处理(二 09_Hive中groupBy数据倾斜面试...
《Hadoop硬实战》收集了85个问题场景以及解决方案的实战演练。在关键问题领域对基础概念和实战方法做了权衡,例如导入导出、序列化,以及LZO压缩。你将会学习到每个技术的细节,以及当遇到一个具体问题时能够给出...
技术点34 定位reduce 端数据倾斜问题 技术点35 确定reduce 任务是否存在整体吞吐量过低 技术点36 缓慢的洗牌(shuffle)和排序 . 6.2.4 任务的一般性能问题 技术点37 作业竞争和调度器限制 技术点38 使用堆...