精华内容
下载资源
问答
  • hadoop 数据倾斜

    万次阅读 2013-12-13 16:36:32
    数据倾斜,map /reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条...

    数据倾斜是指,map /reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条key所在的reduce节点所处理的数据量比其他节点就大很多,从而导致某几个节点迟迟运行不完。

     

    阿里的这篇比较实用,通俗易懂:数据倾斜总结 http://www.tbdata.org/archives/2109

    有篇分析比较详细,如果需要使用可以细读:http://blog.csdn.net/core_cto/article/details/8644692 浅析 Hadoop 中的数据倾斜

     

    ·         症状和原因:

    ·    操作:join,group by,count distinct

    ·    原因:key分布不均匀,人为的建表疏忽,业务数据特点。

    ·    症状:任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成;查看未完成的子任务,可以看到本地读写数据量积累非常大,通常超过10GB可以认定为发生数据倾斜。

    ·    倾斜度:平均记录数超过50w且最大记录数是超过平均记录数的4倍;最长时长比平均时长超过4分钟,且最大时长超过平均时长的2倍。

    我遇到的问题:

    select * from a join b;

    1. a1000多万,b表不到2亿,用mapjoin显然不行;

    2. 设置参数 set hive.groupby.skewindata=true,不起作用;

    3. 由于关连键为手机号,自认为业务数据上不存在数据倾斜;

     

    后来通过查看每个表里面关联键的分布,才发现两个表里面都存在空串'',而且严重倾斜,大表里面的空串数量有400多万。

    将两个表的空串过滤后再进行关联,job时间由原来的40多分钟减少到2分钟。

    总结:

     1. 数据倾斜的原因就那么几种,逐一排查;

     2. 细心,动手,不能光凭感觉来判定;

     3. 判定某一个表的key是否存在数据倾斜,就是group by key,top N来看;

     

     

    附:数据倾斜常用解决方法:

     

     

    1. 万能膏药:hive.groupby.skewindata=true

    2. 大小表关联:将key相对分散,并且数据量小的表放在join的左边,这样有效减少内存溢出错误发生几率;再进一步,可用map join让小的维度表(1000条以下的记录条数)先进内存。在map端完成reduce.

    3. 大表和大表关联:把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。

    4. count distinct大量相同特殊值:(空值单独处理)count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1。如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union

     

     

     

    hadoop程序进行数据关联时,常碰到数据倾斜的情况,这里提供一种解决方法。

     (1)设置一个hash份数N,用来对条数众多的key进行打散。

     (2)对有多条重复key的那份数据进行处理:从1N将数字加在key后面作为新key,如果需要和另一份数据关联的话,则要重写比较类和分发类(方法如上篇《hadoop job解决大数据量关联的一种方法》)。如此实现多条key的平均分发。

     int iNum = iNum % iHashNum;

     String strKey = key + CTRLC + String.valueOf(iNum) + CTRLB + “B”;

     3)上一步之后,key被平均分散到很多不同的reduce节点。如果需要和其他数据关联,为了保证每个reduce节点上都有关联的key,对另一份单一key的数据进行处理:循环的从1N将数字加在key后面作为新key

     for(int i = 0; i < iHashNum; ++i){

     String strKey =key + CTRLC + String.valueOf(i) ;

     output.collect(new Text(strKey), new Text(strValues));}

     以此解决数据倾斜的问题,经试验大大减少了程序的运行时间。但此方法会成倍的增加其中一份数据的数据量,以增加shuffle数据量为代价,所以使用此方法时,要多次试验,取一个最佳的hash份数值。

    ======================================

     用上述的方法虽然可以解决数据倾斜,但是当关联的数据量巨大时,如果成倍的增长某份数据,会导致reduce shuffle的数据量变的巨大,得不偿失,从而无法解决运行时间慢的问题。

    有一个新的办法可以解决成倍增长数据的缺陷:

    在两份数据中找共同点。用重复较少的某个属性作为分布给reduce的依据。比如两份数据里除了关联的字段以外,还有另外相同含义的字段,如果这个字段在所有log中的重复率比较小,则用这个字段计算hash值,如果是数字,直接用来模hash的份数,如果是字符可以用hashcode来模hash的份数(当然数字为了避免落到同一个reduce上的数据过多,也可以用hashcode),这样如果字段值分布足够平均就可以解决上述问题。

    我到过的处理的方式
    1.mapjoin方式
    /*+ MAPJOIN(c,d,e,f) */
    其中c,d,e,f是你小表,也就是说可能会倾斜数据的表;
    但是对于join,在判断小表不大于1G的情况下,使用map join,也就是要考虑c,d,e,f等表的大小,不能超过内存限制,否则会出现OOM错误;

    2.控制空值分布
    Java代码 复制代码 收藏代码
    1. select
    2. '${date}' as thedate,
    3. a.search_type,
    4. a.query,
    5. a.category,
    6. a.cat_name,
    7. a.brand_id,
    8. a.brand_name,
    9. a.dir_type,
    10. a.rewcatid,
    11. a.new_cat_name,
    12. a.new_brand_id,
    13. f.brand_name as new_brand_name,
    14. a.pv,
    15. a.uv,
    16. a.ipv,
    17. a.ipvuv,
    18. a.trans_amt,
    19. a.trans_num,
    20. a.alipay_uv
    21. from fdi_search_query_cat_qp_temp a
    22. left outer join brand f
    23. on
    24. f.pt='${date}000000'
    25. and case when a.new_brand_id is null then concat('hive',rand() ) else a.new_brand_id end = f.brand_id;
    select 
    	'${date}' as thedate,
    	a.search_type,
    	a.query,
    	a.category,
    	a.cat_name,
    	a.brand_id,
    	a.brand_name,
    	a.dir_type,
    	a.rewcatid,
    	a.new_cat_name,
    	a.new_brand_id,
    	f.brand_name as new_brand_name,
    	a.pv,
    	a.uv, 
    	a.ipv,
    	a.ipvuv,
    	a.trans_amt,
    	a.trans_num,
    	a.alipay_uv
    from fdi_search_query_cat_qp_temp a
    left outer join brand f
    on      
    	 f.pt='${date}000000'
    	and case when a.new_brand_id is null then concat('hive',rand() ) else a.new_brand_id end = f.brand_id;

    这样的写法把空值的 key 变成一个字符串加上随机数,就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。

    如果上述的方法还不能解决,比如当有多个JOIN的时候,建议建立临时表,然后拆分HIVE SQL语句;
    关于数据倾斜,阿里集团数据平台上的博客文章有很好的几个方法,敢兴趣的人也可以去看一下:http://www.tbdata.org/archives/2109

    3.关于nonstrict
    join同样一张表多次的时候,会出现这样的错误信息:
    FAILED: Error in semantic analysis: In strict mode, cartesian product is not allowed. If you really want to perform the operation, set hive.mapred.mode=nonstrict
    解决方式是在SQL前面加上如下:
    set hive.mapred.mode=nonstrict;
    strict模式在下面三种情况下有限制:
    (1) partition表需要加上分区裁剪
    (2) order by 只有一个reduce,需要加上limit
    (3) join时,如果只有一个reduce,笛卡尔积不支持。

    HIVE小技巧:
    1.hive sql中:
    sum(t.shop_gmvcount + t.GMVCOUNT_NEW + t.auc_shop_gmvcount + t.spu_gmv_cnt) gmv_cnt,
    这样的统计结果,当t.t.shop_gmvcount为NULL时,即使后面的t.GMVCOUNT_NEW 不为null,那么总计的结果这个计算仍然是NULL;
    修改的方法是:采用sum(coalesce(t.shop_gmvcount,cast(0 as bigint)) + coalesce(t.GMVCOUNT_NEW,cast(0 as bigint))
    这样的方式,coalesce函数类似于ORACLE数据库里面的nvl

    2。join中where的过滤,on里面才能起到表的过滤,放在where里面起不到提前过滤的情况;

    3.left semi jioin的使用
    LEFT SEMI JOIN 是 IN/EXISTS 子查询的一种更高效的实现。Hive 当前没有实现 IN/EXISTS 子查询,所以你可以用 LEFT SEMI JOIN 重写你的子查询语句。LEFT SEMI JOIN 的限制是, JOIN 子句中右边的表只能在 ON 子句中设置过滤条件,在 WHERE 子句、SELECT 子句或其他地方过滤都不行。
    展开全文
  • 数据倾斜及其高效解决方法

    万次阅读 多人点赞 2018-11-13 18:20:07
    数据倾斜:mapreduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千...

    数据倾斜是大数据领域绕不开的拦路虎,当你所需处理的数据量到达了上亿甚至是千亿条的时候,数据倾斜将是横在你面前一道巨大的坎。很可能有几周甚至几月都要头疼于数据倾斜导致的各类诡异的问题。

    数据倾斜是指:mapreduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条key所在的reduce节点所处理的数据量比其他节点就大很多,从而导致某几个节点迟迟运行不完。Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在。

    以下是一些常见的数据倾斜情形:

    一、Group by 倾斜

    group by造成的倾斜相对来说比较容易解决。hive提供两个参数可以解决:

    1.1 hive.map.aggr

    一个是hive.map.aggr,默认值已经为true,他的意思是做map aggregation,也就是在mapper里面做聚合。这个方法不同于直接写mapreduce的时候可以实现的combiner,但是却实现了类似combiner的效果。事实上各种基于mr的框架如pig,cascading等等用的都是map aggregation(或者叫partial aggregation)而非combiner的策略,也就是在mapper里面直接做聚合操作而不是输出到buffer给combiner做聚合。对于map aggregation,hive还会做检查,如果aggregation的效果不好,那么hive会自动放弃map aggregation。判断效果的依据就是经过一小批数据的处理之后,检查聚合后的数据量是否减小到一定的比例,默认是0.5,由hive.map.aggr.hash.min.reduction这个参数控制。所以如果确认数据里面确实有个别取值倾斜,但是大部分值是比较稀疏的,这个时候可以把比例强制设为1,避免极端情况下map aggr失效。hive.map.aggr还有一些相关参数,比如map aggr的内存占用等,具体可以参考这篇文章

    1.2 hive.groupby.skewindata

    另一个参数是hive.groupby.skewindata。这个参数的意思是做reduce操作的时候,拿到的key并不是所有相同值给同一个reduce,而是随机分发,然后reduce做聚合,做完之后再做一轮MR,拿前面聚合过的数据再算结果。所以这个参数其实跟hive.map.aggr做的是类似的事情,只是拿到reduce端来做,而且要额外启动一轮job,所以其实不怎么推荐用,效果不明显。

    1.3 count distinct 改写

    另外需要注意的是count distinct操作往往需要改写SQL,可以按照下面这么做:

    /*改写前*/
    select a, count(distinct b) as c from tbl group by a;
    
    /*改写后*/
    select a, count(*) as c from (select a, b from tbl group by a, b) group by a;

    二、Join倾斜

    2.1 skew join

    join造成的倾斜,常见情况是不能做map join的两个表(能做map join的话基本上可以避免倾斜),其中一个是行为表,另一个应该是属性表。比如我们有三个表,一个用户属性表users,一个商品属性表items,还有一个用户对商品的操作行为表日志表logs。假设现在需要将行为表关联用户表:

    select * from logs a join users b on a.user_id = b.user_id;

    其中logs表里面会有一个特殊用户user_id = 0,代表未登录用户,假如这种用户占了相当的比例,那么个别reduce会收到比其他reduce多得多的数据,因为它要接收所有user_id = 0的记录进行处理,使得其处理效果会非常差,其他reduce都跑完很久了它还在运行。

    hive给出的解决方案叫skew join,其原理把这种user_id = 0的特殊值先不在reduce端计算掉,而是先写入hdfs,然后启动一轮map join专门做这个特殊值的计算,期望能提高计算这部分值的处理速度。当然你要告诉hive这个join是个skew join,即:set

    hive.optimize.skewjoin = true;

    还有要告诉hive如何判断特殊值,根据hive.skewjoin.key设置的数量hive可以知道,比如默认值是100000,那么超过100000条记录的值就是特殊值。总结起来,skew join的流程可以用下图描述:

    2.2 特殊值分开处理法

    不过,上述方法还要去考虑阈值之类的情况,其实也不够通用。所以针对join倾斜的问题,一般都是通过改写sql解决。对于上面这个问题,我们已经知道user_id = 0是一个特殊key,那么可以把特殊值隔离开来单独做join,这样特殊值肯定会转化成map join,非特殊值就是没有倾斜的普通join了:

    select
    	*
    from
    	(
    		select * from logs where user_id = 0
    	)
    	a
    join
    	(
    		select * from users where user_id = 0
    	)
    	b
    on
    	a.user_id = b.user_id
    
    union all
    
    select * from logs a join users b on a.user_id <> 0 and a.user_id = b.user_id;

    2.3 随机数分配法

    上面这种个别key倾斜的情况只是一种倾斜情况。最常见的倾斜是因为数据分布本身就具有长尾性质,比如我们将日志表和商品表关联:

    select * from logs a join items b on a.item_id = b.item_id;

    这个时候,分配到热门商品的reducer就会很慢,因为热门商品的行为日志肯定是最多的,而且我们也很难像上面处理特殊user那样去处理item。这个时候就会用到加随机数的方法,也就是在join的时候增加一个随机数,随机数的取值范围n相当于将item给分散到n个reducer:

    select
    	a.*,
    	b.*
    from
    	(
    		select *, cast(rand() * 10 as int) as r_id from logs
    	)
    	a
    join
    	(
    		select *, r_id from items lateral view explode(range_list(1, 10)) rl as r_id
    	)
    	b
    on
    	a.item_id = b.item_id
    	and a.r_id = b.r_id

    上面的写法里,对行为表的每条记录生成一个1-10的随机整数,对于item属性表,每个item生成10条记录,随机key分别也是1-10,这样就能保证行为表关联上属性表。其中range_list(1,10)代表用udf实现的一个返回1-10整数序列的方法。这个做法是一个解决join倾斜比较根本性的通用思路,就是如何用随机数将key进行分散。当然,可以根据具体的业务场景做实现上的简化或变化。

    2.4 业务设计

    除了上面两类情况,还有一类情况是因为业务设计导致的问题,也就是说即使行为日志里面join key的数据分布本身并不明显倾斜,但是业务设计导致其倾斜。比如对于商品item_id的编码,除了本身的id序列,还人为的把item的类型也作为编码放在最后两位,这样如果类型1(电子产品)的编码是00,类型2(家居产品)的编码是01,并且类型1是主要商品类,将会造成以00为结尾的商品整体倾斜。这时,如果reduce的数量恰好是100的整数倍,会造成partitioner把00结尾的item_id都hash到同一个reducer,引爆问题。这种特殊情况可以简单的设置合适的reduce值来解决,但是这种坑对于不了解业务的情况下就会比较隐蔽。

    三、典型的业务场景

    3.1 空值产生的数据倾斜

    场景:如日志中,常会有信息丢失的问题,比如日志中的 user_id,如果取其中的 user_id 和 用户表中的user_id 关联,会碰到数据倾斜的问题。

    • 解决方法1: user_id为空的不参与关联
    select
    	*
    from
    	log a
    join users b
    on
    	a.user_id is not null
    	and a.user_id = b.user_id
    
    union all
    
    select * from log a where a.user_id is null;
    • 解决方法2 :赋与空值分新的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;

    结论:方法2比方法1效率更好,不但io少了,而且作业数也少了。解决方法1中 log读取两次,jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数,就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。

    3.2 不同数据类型关联产生数据倾斜

    场景:用户表中user_id字段为int,log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时,默认的Hash操作会按int型的id来进行分配,这样会导致所有string类型id的记录都分配到一个Reducer中。

    解决方法:把数字类型转换成字符串类型

    select
    	*
    from
    	users a
    left outer join logs b
    on
    	a.usr_id = cast(b.user_id as string)

    3.3 小表不小不大,怎么用 map join 解决倾斜问题

    使用 map join 解决小表(记录数少)关联大表的数据倾斜问题,这个方法使用的频率非常高,但如果小表很大,大到map join会出现bug或异常,这时就需要特别的处理。 以下例子:

    select * from log a left outer join users b on a.user_id = b.user_id;

    users 表有 600w+ 的记录,把 users 分发到所有的 map 上也是个不小的开销,而且 map join 不支持这么大的小表。如果用普通的 join,又会碰到数据倾斜的问题。

    select
    	/*+mapjoin(x)*/
    	*
    from
    	log a
    left outer join
    	(
    		select
    			/*+mapjoin(c)*/
    			d.*
    		from
    			(
    				select distinct user_id from log
    			)
    			c
    		join users d
    		on
    			c.user_id = d.user_id
    	)
    	x on a.user_id = b.user_id;

    假如,log里user_id有上百万个,这就又回到原来map join问题。所幸,每日的会员uv不会太多,有交易的会员不会太多,有点击的会员不会太多,有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。

    四、总结

    使map的输出数据更均匀的分布到reduce中去,是我们的最终目标。由于Hash算法的局限性,按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤:

    • 1)采样log表,哪些user_id比较倾斜,得到一个结果表tmp1。由于对计算框架来说,所有的数据过来,他都是不知道数据分布情况的,所以采样是并不可少的。
    • 2)数据的分布符合社会学统计规则,贫富不均。倾斜的key不会太多,就像一个社会的富人不多,奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。
    • 3)map读入users和log,假如记录来自log,则检查user_id是否在tmp2里,如果是,输出到本地文件a,否则生成的key,value对,假如记录来自member,生成的key,value对,进入reduce阶段。
    • 4)最终把a文件,把Stage3 reduce阶段输出的文件合并起写到hdfs。

    如果确认业务需要这样倾斜的逻辑,考虑以下的优化方案:

    • 1)对于join,在判断小表不大于1G的情况下,使用map join
    • 2)对于group by或distinct,设定 hive.groupby.skewindata=true
    • 3)尽量使用上述的SQL语句调节进行优化

    五、参考文献

    数据分析系列(3):数据倾斜

    展开全文
  • 更多文章,可关注微信公众号:Excel办公小技巧 ...数据倾斜,分布式计算时,一些节点计算量高于其他节点,速度很慢,导致其他节点计算完成后,还要等待这些节点完成。 Q2 数据倾斜有什么表现? 直观上..

     数据倾斜,看字面很简单,但实际还是不知道发生了什么情况。对于像我这样很多非技术类同学,想把技术原理弄懂,可能需要了解很多相关知识才能真正理解,这不太现实。所以,我们需要找到简单而又清晰的理解。相信理读完以下四点, 还是对数据倾斜有一个比较清晰的认知的。

    数据倾斜的理解及优化

    Q1 什么是数据倾斜?

    数据倾斜是指,分布式计算时,一些节点计算量高于其他节点,速度很慢,导致其他节点计算完成后,还要等待这些节点完成。

    Q2 数据倾斜有什么表现?

    直观上可以看到map100%,reduce还卡在99%呢。

    Q3 数据倾斜产生的原因是什么?

    一般与业务逻辑和计算数据量有关。key分布的数据量不均匀,比如有的key有100万条数据,有的只有100条,处理100万条明显比处理10条数据的key慢。同时,整体任务的运行速度取决于最慢的那个。

    Q4 数据倾斜发生时,如何优化?

    a. 清除无效的倾斜数据,比如我们使用的表,需要聚合的字段有大量空值,而大部分分析场景下,是不需要空值的,这时,我们就可以将无效的数据剔除;

    b. 强制拆解key,如果个别的key数据量过大,那么我们可以将key拆分成多组,聚合完成后,再按原本的key聚合,即可得到原来的需求数据。

        当然了,如果CPU和资源足够,机器跑的动,key数据量大也没那么慢,这就是白天和晚上运行任务的差异。

    更多文章,可关注微信公众号:Excel办公小技巧

    展开全文
  • hive 数据倾斜

    2015-05-13 10:03:50
    数据倾斜,map /reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条...

    数据倾斜是指,map /reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条key所在的reduce节点所处理的数据量比其他节点就大很多,从而导致某几个节点迟迟运行不完。

    一、  空值数据倾斜

    场景:如日志中,常会有信息丢失的问题,比如全网日志中的user_id,如果取其中的user_id和bmw_users关联,会碰到数据倾斜的问题。

    解决方法1: user_id为空的不参与关联

    Select * From log a

    Join bmw_users b

    On a.user_id is not null

    And a.user_id = b.user_id

    Union all

    Select * from log a

    where a.user_id is null;

    解决方法2 :赋与空值分新的key值

    Select *  

    from log a 

    left outer join bmw_users b 

    on case when a.user_id is null thenconcat(‘dp_hive’,rand() ) else a.user_id end = b.user_id; 

    结论:方法2比方法效率更好,不但io少了,而且作业数也少了。方法1 log读取两次,jobs是2。方法2 job数是1 。这个优化适合无效id(比如-99,’’,null等)产生的倾斜问题。把空值的key变成一个字符串加上随机数,就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。附上hadoop通用关联的实现方法(关联通过二次排序实现的,关联的列为parition key,关联的列c1和表的tag组成排序的group key,根据parition key分配reduce。同一reduce内根据group key排序)

    二、不同数据类型关联产生数据倾斜

    场景:一张表s8的日志,每个商品一条记录,要和商品表关联。但关联却碰到倾斜的问题。s8的日志中有字符串商品id,也有数字的商品id,类型是string的,但商品中的数字id是bigint的。猜测问题的原因是把s8的商品id转成数字id做hash来分配reduce,所以字符串id的s8日志,都到一个reduce上了,解决的方法验证了这个猜测。

    解决方法:把数字类型转换成字符串类型

    Select * from s8_log a

    Left outer join r_auction_auctions b

    On a.auction_id = cast(b.auction_id as string);

    三、大表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特性对表做切分。


    展开全文
  • 数据倾斜理解;

    2019-04-02 08:54:53
    数据倾斜,map /reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条...
  • Spark如何处理数据倾斜

    万次阅读 多人点赞 2018-08-17 20:38:22
    数据倾斜我们在并行进行数据处理的时候,由于数据Spark的单个Partition)的分布不均,导致大量的数据集中分不到一台或者某几台计算节点上,导致处理速度远低于平均计算速度,从而拖延导致整个计算过程过慢,影响...
  • hive如何应对数据倾斜

    千次阅读 2015-06-20 11:01:42
    概念:数据倾斜,map /reduce程序执行时,reduce节点大部分执行完毕,但是 有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一 个key的条数比其他key多很多(有时是百倍或者千...
  • hadoop 数据倾斜详解

    千次阅读 2017-02-28 18:32:09
    数据倾斜,map /reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条...
  • Spark 之 解决数据倾斜(一)

    千次阅读 2021-06-14 00:56:11
    Spark中的数据倾斜问题主要shuffle过程中出现的数据倾斜问题,是由于不同的key对应的数据量不同导致的不同task所处理的数据量不同的问题。 例如,reduce点一共要处理100万条数据,第一个和第二个task分别被分配到...
  • 数据倾斜:mapreduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条key...
  • 数据倾斜,map /reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条...
  • Map端数据倾斜

    千次阅读 2018-08-09 10:35:00
    MapReduce任务的数据倾斜一般的是Reduce端数据倾斜,Map端怎么还会出现数据倾斜呢。~~ Mapper任务如下图所示,其中一个map任务耗时特别长 跑了一个ETL程序,两个Map分别读取两类数据,一个是lzo格式,另外...
  • Spark中的数据倾斜问题主要shuffle过程中出现的数据倾斜问题,是由于不同的key对应的数据量不同导致的不同task所处理的数据量不同的问题。 例如,reduce点一共要处理100万条数据,第一个和第二个task分别被分配到...
  • 数据倾斜解决方案

    2017-03-25 09:27:33
    数据倾斜指的是,并行处理的数据集中,某一部分(如Spark或Kafka的一个Partition)的数据显著多于其它部分,从而使得该部分的处理速度成为整个数据集处理的瓶颈。 数据倾斜是如何造成的  在Spark中,同一个...
  • 转至元数据结尾转至元数据起始数据倾斜指的是某个节点的数据太大,数据跑不完。而任务倾斜则是节点出问题,任务跑的慢。正好和目前出现的executor&amp;task lost相呼应。task倾斜原因比较多,网络io,cpu,mem都有...
  • spark如何定位数据倾斜

    千次阅读 2020-04-18 08:11:51
    在大数据处理过程中常常出现数据倾斜(Data Skew)。...数据倾斜指的是,并行处理的数据集中,某一部分(如 Spark 或 Kafka的一个 Partition)的数据显著多于其它部分,从而使得该部分的处理速度成为整个数据集...
  • hive中数据倾斜

    2019-04-16 08:42:20
    数据倾斜通常hive根据key值hash分发到各个节点,相同的key值会分发到一个执行节点中,由于某些key值对应的数据量比其它key值的数据量大很多,导致某些执行节点的运行时间远大于其它节点,从而导致整个job执行时间...
  • mr数据倾斜优化

    千次阅读 2018-07-29 11:31:49
    减小数据倾斜的性能损失 数据倾斜是数据中的常见情况。数据中不可避免地会出现离群值(outlier),并导致数据倾斜。这些离群值会显著地拖慢MapReduce的执行。常见的数据倾斜有以下几类: 数据频率倾斜——某一个...
  • Spark 数据倾斜的整理

    2020-05-01 16:59:39
    目录:1、 什么是数据倾斜????(基于Spark 架构)2、何谓数据倾斜????3、数据倾斜是如何造成的????4、数据倾斜是如何解决的????1.仔细查看定位导致数据倾斜的代码。(数据倾斜只会发生在 shuffle ...
  • 整体倾斜度调整

    千次阅读 2015-11-06 22:51:11
    扫描图像中的前景可能存在一定程度的倾斜,本文以一行倾斜的数字为例,需要进行适当的调整以使字符处在同一水平位置,这样既有利于后续的字符分割,也可以降低字符识别的难度。  一般来说,对于若干字符组成的图像...
  • Hive数据倾斜问题总结

    千次阅读 2017-11-25 21:45:55
    Hive数据倾斜问题总结1、MapReduce数据倾斜Hive查询最终转换为MapReduce操作,所以要先了解MapReduce数据倾斜问题。MapReduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致...
  • Hive大数据倾斜总结

    千次阅读 2016-03-10 15:37:50
    所谓数据倾斜,说的是由于数据分布不均匀,个别值集中占据大部分数据量,加上Hadoop的计算模式,导致计算资源不均匀引起性能下降。 还是拿网站的访问日志说事吧。假设网站访问日志中会记录用户的user_id,并且对于...
  • hive中的数据倾斜 数据倾斜就是由于数据分布不均匀,数据大量集中到一点上,造成数据热点。大多数情况下,分为一下三种情况: 1.map端执行比较快,reduce执行很慢,因为partition造成的数据倾斜。 2.某些reduce很快...
  • 数据倾斜指的是,并行处理的数据集中,某一部分(如Spark或Kafka的一个Partition)的数据显著多于其它部分,从而使得该部分的处理速度成为整个数据集处理的瓶颈。 数据倾斜俩大直接致命后果。 1、数据倾斜直接...
  • 数据倾斜解决方案之三:使用随机Key实现双重聚合本节讲解使用随机Key实现双重聚合,首先讲解什么是随机Key双重聚合;...随机Key双重聚合是:Spark分布式计算对RDD调用reduceByKey各算子进行计算,使用对Key
  • Hive中的数据倾斜

    2017-05-11 17:39:34
    Hive中的数据倾斜 hive 1. 什么是数据倾斜 mapreduce中,相同key的value都给一个reduce,如果个别key的数据过多,而其他key的较少,就会出现数据倾斜。通俗的说,就是我们在处理的时候数据分布的不均...
  • 倾斜摄影模型生成DSM、DOM操作流程

    万次阅读 2016-10-31 11:46:55
    本文介绍了如何在超图桌面平台通过倾斜摄影模型提取DSM、DOM数据。
  • ,即热点 key,的是在一段时间内,该 key 的访问量远远高于其他的 redis key, 导致大部分的访问流量在经过 proxy 分片之后,都集中访问到某一个 redis 实例上。hot key 通常在不同业务中,存储着不同的热点信息。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 29,037
精华内容 11,614
关键字:

倾斜是指