hive---大表Join的数据偏斜

大表Join的数据偏斜

MapReduce编程模型下开发代码需要考虑数据偏斜的问题,Hive代码也是一样。数据偏斜的原因包括以下两点:

1. Map输出key数量极少,导致reduce端退化为单机作业。

2. Map输出key分布不均,少量key对应大量value,导致reduce端单机瓶颈。

Hive中我们使用MapJoin解决数据偏斜的问题,即将其中的某个表(全量)分发到所有Map端进行Join,从而避免了reduce。这要求分发的表可以被全量载入内存。

极限情况下,Join两边的表都是大表,就无法使用MapJoin。

这种问题最为棘手,目前已知的解决思路有两种:

1. 如果是上述情况1,考虑先对Join中的一个表去重,以此结果过滤无用信息。这样一般会将其中一个大表转化为小表,再使用MapJoin 。

一个实例是广告投放效果分析,例如将广告投放者信息表i中的信息填充到广告曝光日志表w中,使用投放者id关联。因为实际广告投放者数量很少(但是投放者信息表i很大),因此可以考虑先在w表中去重查询所有实际广告投放者id列表,以此Join过滤表i,这一结果必然是一个小表,就可以使用MapJoin。

2. 如果是上述情况2,考虑切分Join中的一个表为多片,以便将切片全部载入内存,然后采用多次MapJoin得到结果。

一个实例是商品浏览日志分析,例如将商品信息表i中的信息填充到商品浏览日志表w中,使用商品id关联。但是某些热卖商品浏览量很大,造成数据偏斜。例如,以下语句实现了一个innerjoin逻辑,将商品信息表拆分成2个表:

select * from

(

select w.id, w.time, w.amount, i1.name, i1.loc, i1.cat

from w left outer join i sampletable(1 out of 2 on id) i1

)

union all

(

select w.id, w.time, w.amount, i2.name, i2.loc, i2.cat

from w left outer join i sampletable(1 out of 2 on id) i2

)

);

以下语句实现了left outer join逻辑:

select t1.id, t1.time, t1.amount,

coalease(t1.name,t2.name),

coalease(t1.loc, t2.loc),

coalease(t1.cat, t2.cat)

from (

select w.id, w.time,w.amount, i1.name, i1.loc, i1.cat

from w left outer join isampletable(1 out of 2 on id) i1

) t1 left outer join i sampletable(2 out of 2 on id)t2;

上述语句使用Hive的sample table特性对表做切分。

更多精彩内容请关注:http://bbs.superwu.cn

关注超人学院微信二维码:

时间: 2024-08-06 21:14:36

hive---大表Join的数据偏斜的相关文章

hive大表和小表MapJoin关联查询优化

大表和小表关联查询可以采用mapjoin优化查询速度.那什么是mapjoin呢?理解MapJoin之前先介绍另一种Join方式,CommonJoin.我们知道Hive编写SQL语句,Hive会将SQL解析成MapReduce任务.对于一个简单的关联查询,CommonJoin任务设计Map阶段和Reduce阶段.Mapper 从连接表中读取数据并将连接的 key 和连接的 value 键值对输出到中间文件中.Hadoop 在所谓的 shuffle 阶段对这些键值对进行排序和合并.Reducer 将

【Spark调优】大表join大表,少数key导致数据倾斜解决方案

[使用场景] 两个RDD进行join的时候,如果数据量都比较大,那么此时可以sample看下两个RDD中的key分布情况.如果出现数据倾斜,是因为其中某一个RDD中的少数几个key的数据量过大,而另一个RDD中的所有key都分布比较均匀,此时可以考虑采用本解决方案. [解决方案] 对有数据倾斜那个RDD,使用sample算子采样出一份样本,统计下每个key的数量,看看导致数据倾斜数据量最大的是哪几个key. 然后将这几个key对应的数据从原来的RDD中拆分出来,形成一个单独的RDD,并给每个ke

20亿与20亿表关联优化方法(超级大表与超级大表join优化方法)

记得5年前遇到一个SQL.就是一个简单的两表关联.SQL跑了几乎相同一天一夜,这两个表都非常巨大.每一个表都有几十个G.数据量每一个表有20多亿,表的字段也特别多. 相信大家也知道SQL慢在哪里了,单个进程的PGA 是绝对放不下几十个G的数据,这就会导致消耗大量temp tablespace,SQL慢就是慢在temp来回来回来回...的读写数据. 遇到这样的超级大表与超级大表怎么优化呢?这篇文章将告诉你答案. 首先创建2个測试表 t1,t2 数据来自dba_objects create tabl

[Hive]Hive数据倾斜(大表join大表)

业务背景 用户轨迹工程的性能瓶颈一直是etract_track_info,其中耗时大户主要在于trackinfo与pm_info进行左关联的环节,trackinfo与pm_info两张表均为GB级别,左关联代码块如下: from trackinfo a left outer join pm_info b on (a.ext_field7 = b.id) 使用以上代码块需要耗时1.5小时. 优化流程 第一次优化 考虑到pm_info表的id是bigint类型,trackinfo表的ext_fiel

hive中大表join

排序存储数据至BUCKETS,这样可以顺序进行join

hive join 优化 --小表join大表

1.小.大表 join 在小表和大表进行join时,将小表放在前边,效率会高,hive会将小表进行缓存. 2.mapjoin 使用mapjoin将小表放入内存,在map端和大表逐一匹配,从而省去reduce. 例子: select /*+MAPJOIN(b)*/ a.a1,a.a2,b.b2 from tablea a JOIN tableb b ON a.a1=b.b1 在0.7版本后,也可以用配置来自动优化 set hive.auto.convert.join=true;

大数据开发实战:Hive优化实战3-大表join大表优化

5.大表join大表优化 如果Hive优化实战2中mapjoin中小表dim_seller很大呢?比如超过了1GB大小?这种就是大表join大表的问题.首先引入一个具体的问题场景,然后基于此介绍各自优化方案. 5.1.问题场景 问题场景如下: A表为一个汇总表,汇总的是卖家买家最近N天交易汇总信息,即对于每个卖家最近N天,其每个买家共成交了多少单,总金额是多少,假设N取90天,汇总值仅取成交单数.A表的字段有:buyer_id. seller_id.pay_cnt_90day. B表为卖家基本信

hive大数据倾斜总结

在做Shuffle阶段的优化过程中,遇到了数据倾斜的问题,造成了对一些情况下优化效果不明显.主要是因为在Job完成后的所得到的 Counters是整个Job的总和,优化是基于这些Counters得出的平均值,而由于数据倾斜的原因造成map处理数据量的差异过大,使得这些平均 值能代表的价值降低.Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个 reduce中,就是解决数据倾斜的根本所在.规避错误来更好的运行比解决错误更高效.在

Hive 的 map join

学习自 http://blog.csdn.net/xqy1522/article/details/6699740 1. Map Join 的使用场景: 关联操作中有一张表非常小 不等值的链接操作 2. 语法: 使用 hint 的方式指定join时使用mapjoin. select /*+ mapjoin(c)*/ -- hint c.tag,b.yemaozi_pre from (select row_number() over(partition by 1 order by yemaozi_p