转:hive表Join的倾斜问题以及解决方法

标签: hive join 问题 | 发表时间:2015-05-25 10:24 | 作者:tobyqiu
出处:http://www.iteye.com

写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到一起,得到最终结果。

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [hive join 问题] 推荐:

Hive中的join

- - CSDN博客云计算推荐文章
select a.* from a join b on a.id = b.id select a.* from a join b on (a.id = b.id and a.department = b.department). 在使用join写查询的时候有一个原则:应该将条目少的表或者子查询放在join操作符的左边.

转:hive表Join的倾斜问题以及解决方法

- - SQL - 编程语言 - ITeye博客
写HQL语句的时候常常会遇到表Join的情况,一个简单的Join会被Hive解释成一个MapReduce任务,Map端分别读取两个表的数据,Reduce做真正的Join操作. 如果执行的过程中,如果发现有些Reduce任务比其他的Reduce任务慢很多,往往是发生了倾斜问题.  Join会被Hive解释成一个MapReduce任务时,Map端输出的记录是以Join的条件为Key的,即这些Map生成的Key都是 cat_id.

hive join 优化 --小表join大表

- - CSDN博客云计算推荐文章
在小表和大表进行join时,将 小表放在前边,效率会高,hive会将小表进行缓存. 使用mapjoin将小表放入内存,在map端和大表逐一匹配,从而省去reduce. 在0.7版本后,也可以用配置来自动优化. 作者:smile0198 发表于2014-10-25 21:49:25 原文链接. 阅读:62 评论:0 查看评论.

Hive Join 优化 翻译

- - 数据库 - ITeye博客
翻译自  https://cwiki.apache.org/confluence/display/Hive/LanguageManual+JoinOptimization#LanguageManualJoinOptimization-AutoConversiontoSMBMapJoin. Join Optimization ----Join 调优.

Hive JOIN使用详解

- - 数据库 - ITeye博客
Hive是基于Hadoop平台的,它提供了类似SQL一样的查询语言HQL. 有了Hive,如果使用过SQL语言,并且不理解Hadoop MapReduce运行原理,也就无法通过编程来实现MR,但是你仍然可以很容易地编写出特定查询分析的HQL语句,通过使用类似SQL的语法,将HQL查询语句提交Hive系统执行查询分析,最终Hive会帮你转换成底层Hadoop能够理解的MR Job.

Hive高级查询(group by、 order by、 join等)

- - CSDN博客推荐文章
所有值不全为NULL时,加1操作 count(1). 不管有没有值,只要有这条记录,值就加1 count(col) col列里面的值为null,值不会加1,这个列里面的值不为NULL,才加1. sum(可转成数字的值) 返回bigint. avg(可转成数字的值)返回double. distinct不同值个数.

Hive中Join的原理和机制

- - 编程语言 - ITeye博客
Hive中Join的原理和机制. 笼统的说,Hive中的Join可分为Common Join(Reduce阶段完成join)和Map Join(Map阶段完成join). 本文简单介绍一下两种join的原理和机制. 如果不指定MapJoin或者不符合MapJoin的条件,那么Hive解析器会将Join操作转换成Common Join,即:在Reduce阶段完成join.

hive 配置文件以及join中null值的处理

- - CSDN博客云计算推荐文章
1.  三种设定方式:配置文件. ·   用户自定义配置文件:$HIVE_CONF_DIR/hive-site.xml. ·   默认配置文件:$HIVE_CONF_DIR/hive-default.xml. 用户自定义配置会覆盖默认配置. 另外,Hive也会读入Hadoop的配置,因为Hive是作为Hadoop的客户端启动的,Hadoop的配置文件包括.

Hive中小表与大表关联(join)的性能分析

- - 数据库 - ITeye博客
经常看到一些Hive优化的建议中说当小表与大表做关联时,把小表写在前面,这样可以使Hive的关联速度更快,提到的原因都是说因为小表可以先放到内存中,然后大表的每条记录再去内存中检测,最终完成关联查询. 这样的原因看似合理,但是仔细推敲,又站不住脚跟. 如果所谓的小表在内存中放不下怎么办. 我用2个只有几条记录的表做关联查询,这应该算是小表了,在查看reduce的执行日志时依然是有写磁盘的操作的.

hive中与hbase外部表join时内存溢出(hive处理mapjoin的优化器机制)

- - CSDN博客云计算推荐文章
与hbase外部表(wizad_mdm_main)进行join出现问题:. 最后在进行到0.83时,内存溢出失败. 默认情况下,Hive会自动将小表加到DistributeCache中,然后在Map扫描大表的时候,去和DistributeCache中的小表做join,这称为Mapjoin. 这里wizad_mdm_main是基于HBase的外部表,而这张表在HDFS上的源路径为 /hivedata/warehouse/wizad.db/wizad_mdm_main,实际这个目录为空,.