关注 spark技术分享,
撸spark源码 玩spark最佳实践

spark面试必问|碰到数据倾斜你该咋办

目录:

一、数据倾斜介绍与定位

二、解决方法一:聚合数据源

三、解决方法二:提高shuffle操作reduce并行度

四、解决方法之三:随机key实现双重聚合

五、解决方法之四:将reduce join 转换为map join

六、解决方法之五:sample采样倾斜key进行两次join

七、解决方法之六:使用随机数以及扩容表进行join


、数据倾斜介绍与定位

a、数据倾斜的原理

在执行shuffle操作的时候,大家都知道,我们之前讲解过shuffle的原理。是按照key,来进行values的数据的输出、拉取和聚合的。同一个keyvalues,一定是分配到一个reduce task进行处理的。多个key对应的values,总共是90万。但是问题是,可能某个key对应了88万数据,key-88values,分配到一个task上去面去执行。另外两个task,可能各分配到了1万数据,可能是数百个key,对应的1万条数据。

第一个和第二个task,各分配到了1万数据;那么可能1万条数据,需要10分钟计算完毕;第一个和第二个task,可能同时在10分钟内都运行完了;第三个task88万条,88 * 10 =  880分钟 = 14.5个小时;

 

b、数据倾斜的现象,有两种表现:

 

1你的大部分的task,都执行的特别特别快,刷刷刷,就执行完了(你要用client模式,standalone clientyarn client,本地机器主要一执行spark-submit脚本,就会开始打印log),task175 finished;剩下几个task,执行的特别特别慢,前面的task,一般1s可以执行完5个;最后发现1000task998999 task,要执行1个小时,2个小时才能执行完一个task

 

出现数据倾斜了

还算好的,因为虽然老牛拉破车一样,非常慢,但是至少还能跑。

 

2运行的时候,其他task都刷刷刷执行完了,也没什么特别的问题;但是有的task,就是会突然间,啪,报了一个OOMJVM Out Of Memory,内存溢出了,task failedtask lostresubmitting task。反复执行几次都到了某个task就是跑不通,最后就挂掉。某个task就直接OOM,那么基本上也是因为数据倾斜了,task分配的数量实在是太大了!!!所以内存放不下,然后你的task每处理一条数据,还要创建大量的对象。内存爆掉了。

 

出现数据倾斜了

这种就不太好了,因为你的程序如果不去解决数据倾斜的问题,压根儿就跑不出来。

 

c、数据倾斜定位与出现问题的位置:

根据log去定位

 

出现数据倾斜的原因,基本只可能是因为发生了shuffle操作,在shuffle的过程中,出现了数据倾斜的问题。因为某个,或者某些key对应的数据,远远的高于其他的key

 

1你在自己的程序里面找找,哪些地方用了会产生shuffle的算子,groupByKeycountByKeyreduceByKeyjoin

 

2log

log一般会报是在你的哪一行代码,导致了OOM异常;或者呢,看log,看看是执行到了第几个stage!!!哪一个stagetask特别慢,就能够自己用肉眼去对你的spark代码进行stage的划分,就能够通过stage定位到你的代码,哪里发生了数据倾斜。去找找,代码那个地方,是哪个shuffle操作。


、解决方法一:聚合数据源

聚合数据源做法一:

groupByKeyreduceByKeygroupByKey,就是拿到每个key对应的valuesreduceByKey,说白了,就是对每个key对应的values执行一定的计算。现在这些操作,比如groupByKeyreduceByKey,包括之前说的join。都是在spark作业中执行的。

 

spark作业的数据来源,通常是哪里呢?90%的情况下,数据来源都是hive表(hdfs,大数据分布式存储系统)。hdfs上存储的大数据。hive表,hive表中的数据,通常是怎么出来的呢?有了spark以后,hive比较适合做什么事情?hive就是适合做离线的,晚上凌晨跑的,ETLextract transform load,数据的采集、清洗、导入),hive sql,去做这些事情,从而去形成一个完整的hive中的数据仓库;说白了,数据仓库,就是一堆表。spark作业的源表,hive表,其实通常情况下来说,也是通过某些hive etl生成的。hive etl可能是晚上凌晨在那儿跑。今天跑昨天的数据。

 

数据倾斜,某个key对应的80万数据,某些key对应几百条,某些key对应几十条;现在,咱们直接在生成hive表的hive etl中,对数据进行聚合。比如按key来分组,将key对应的所有的values,全部用一种特殊的格式,拼接到一个字符串里面去,比如“key=sessionid, value: action_seq=1|user_id=1|search_keyword….”。

 

key进行group,在spark中,拿到key=sessionidvalues<Iterable>hive etl中,直接对key进行了聚合。那么也就意味着,每个key就只对应一条数据。spark中,就不需要再去执行groupByKey+map这种操作了。直接对每个key对应的values字符串,map操作,进行你需要的操作即可。key,values串。spark中,可能对这个操作,就不需要执行shffule操作了,也就根本不可能导致数据倾斜。

 

或者是,对每个keyhive etl中进行聚合,对所有values聚合一下,不一定是拼接起来,可能是直接进行计算。reduceByKey,计算函数,应用在hive etl中,每个keyvalues

 

聚合数据源做法二:

 

你可能没有办法对每个key,就聚合出来一条数据;

 

那么也可以做一个妥协;对每个key对应的数据,10万条;有好几个粒度,比如10万条里面包含了几个城市、几天、几个地区的数据,现在放粗粒度;直接就按照城市粒度,做一下聚合,几个城市,几天、几个地区粒度的数据,都给聚合起来。比如说

 

city_iddatearea_id

select … from … group by city_iddatearea_id

 

尽量去聚合,减少每个key对应的数量,也许聚合到比较粗的粒度之后,原先有10万数据量的key,现在只有1万数据量。减轻数据倾斜的现象和问题。

 

、解决方法二:提高shuffle操作reduce并行度

如果第一种方法不适合做。那么采用第二种方法:提高shuffle操作的reduce并行度

增加reduce task的数量,就可以让每个reduce task分配到更少的数据量,这样的话,也许就可以缓解,或者甚至是基本解决掉数据倾斜的问题。

 

a、原理图介绍:


 

spark面试必问|碰到数据倾斜你该咋办



b、提升shuffle reduce端并行度的具体操作

主要给我们所有的shuffle算子,比如groupByKeycountByKeyreduceByKey在调用的时候,传入进去一个参数。一个数字。那个数字,就代表了那个shuffle操作的reduce端的并行度。那么在进行shuffle操作的时候,就会对应着创建指定数量的reduce task

 

这样的话,就可以让每个reduce task分配到更少的数据。基本可以缓解数据倾斜的问题。

 

比如说,原本某个task分配数据特别多,直接OOM,内存溢出了,程序没法运行,直接挂掉。按照log,找到发生数据倾斜的shuffle操作,给它传入一个并行度数字,这样的话,原先那个task分配到的数据,肯定会变少。就至少可以避免OOM的情况,程序至少是可以跑的。

c、提升shuffle reduce并行度的缺陷

治标不治本的意思,因为,它没有从根本上改变数据倾斜的本质和问题。不像第一个和第二个方案(直接避免了数据倾斜的发生)。原理没有改变,只是说,尽可能地去缓解和减轻shuffle reduce task的数据压力,以及数据倾斜的问题。

 

实际生产环境中的经验:

1、如果最理想的情况下,提升并行度以后,减轻了数据倾斜的问题,或者甚至可以让数据倾斜的现象忽略不计,那么就最好。就不用做其他的数据倾斜解决方案了。

 

2、不太理想的情况下,就是比如之前某个task运行特别慢,要5个小时,现在稍微快了一点,变成了4个小时;或者是原先运行到某个task,直接OOM,现在至少不会OOM了,但是那个task运行特别慢,要5个小时才能跑完。

 

那么,如果出现第二种情况的话,各位,就立即放弃这种方法,开始去尝试和选择后面的方法解决。

 

、解决方法之三:随机key实现双重聚合

 原理图介绍:

spark面试必问|碰到数据倾斜你该咋办



使用场景:(1groupByKey2reduceByKey

join,咱们通常不会这样来做,后面有针对不同的join造成的数据倾斜的问题的解决方案。


、解决方法之四:将reduce join 转换为map join

普通reduce join                      


 

spark面试必问|碰到数据倾斜你该咋办

map join:

spark面试必问|碰到数据倾斜你该咋办

 


 

普通的join

肯定是要走shuffle;那么,所以既然是走shuffle,那么普通的join,就肯定是走的是reduce join。先将所有相同的key,对应的values,汇聚到一个task中,然后再进行join

 

reduce join转换为map join

如果两个RDD要进行join,其中一个RDD是比较小的。一个RDD100万数据,一个RDD1万数据。(一个RDD1亿数据,一个RDD100万数据)其中一个RDD必须是比较小的,broadcast出去那个小RDD的数据以后,就会在每个executorblock manager中都驻留一份。要确保你的内存足够存放那个小RDD中的数据

这种方式下,根本不会发生shuffle操作,肯定也不会发生数据倾斜;从根本上杜绝了join操作可能导致的数据倾斜的问题;对于join中有数据倾斜的情况,大家尽量第一时间先考虑这种方式,效果非常好如果某个RDD比较小的情况下。

 

不适合的情况:

两个RDD都比较大,那么这个时候,你去将其中一个RDD做成broadcast,就很笨拙了。很可能导致内存不足。最终导致内存溢出,程序挂掉。而且其中某些key(或者是某个key),还发生了数据倾斜;此时可以采用最后两种方式。

 

特别声明:

对于join这种操作,不光是考虑数据倾斜的问题;即使是没有数据倾斜问题,也完全可以优先考虑,用我们讲的这种高级的reduce joinmap join的技术,不要用普通的join,去通过shuffle,进行数据的join;完全可以通过简单的map,使用map join的方式,牺牲一点内存资源;在可行的情况下,优先这么使用。不走shuffle,直接走map,性能肯定是提高很多的。

 

、解决方法之五:sample采样倾斜key进行两次join


 

spark面试必问|碰到数据倾斜你该咋办

方案的实现思路:其实关键之处在于,将发生数据倾斜的key,单独拉出来,放到一个RDD中去;就用这个原本会倾斜的key RDD跟其他RDD,单独去join一下,这个时候,key对应的数据,可能就会分散到多个task中去进行join操作,最后将join后的表进行union操作。

就不至于,这个key跟之前其他的key混合在一个RDD中时,导致一个key对应的所有数据,都到一个task中去,就会导致数据倾斜。

 

应用场景:

优先对于join,肯定是希望能够采用上一讲讲的,reduce join转换map join两个RDD数据都比较大,那么就不要那么搞了。

 

针对你的RDD的数据,你可以自己把它转换成一个中间表,或者是直接用countByKey()的方式,你可以看一下这个RDD各个key对应的数据量;此时如果你发现整个RDD就一个,或者少数几个key,是对应的数据量特别多;尽量建议,比如就是一个key对应的数据量特别多。

 

此时可以采用咱们的这种方案,单拉出来那个最多的key;单独进行join,尽可能地将key分散到各个task上去进行join操作。

 

什么时候不适用呢?

 

如果一个RDD中,导致数据倾斜的key,特别多;那么此时,最好还是不要这样了;还是使用我们最后一个方案,终极的join数据倾斜的解决方案。

 

 

进一步优化:

就是说,咱们单拉出来了,一个或者少数几个可能会产生数据倾斜的key,然后还可以进行更加优化的一个操作;

 

对于那个key,从另外一个要join的表中,也过滤出来一份数据,比如可能就只有一条数据。userid2infoRDD,一个userid key,就对应一条数据。然后呢,采取对那个只有一条数据的RDD,进行flatMap操作,打上100个随机数,作为前缀,返回100条数据。

单独拉出来的可能产生数据倾斜的RDD,给每一条数据,都打上一个100以内的随机数,作为前缀。

再去进行join,是不是性能就更好了。肯定可以将数据进行打散,去进行joinjoin完以后,可以执行map操作,去将之前打上的随机数,给去掉,然后再和另外一个普通RDD join以后的结果,进行union操作。

 

 

、解决方法之六:使用随机数以及扩容表进行join

当采用随机数和扩容表进行join解决数据倾斜的时候,就代表着,你的之前的数据倾斜的解决方案,都没法使用。这个方案是没办法彻底解决数据倾斜的,更多的,是一种对数据倾斜的缓解。

spark面试必问|碰到数据倾斜你该咋办



步骤:

1、选择一个RDD,要用flatMap,进行扩容(比较小的RDD),将每条数据,映射为多条数据,每个映射出来的数据,都带了一个n以内的随机数,通常来说,会选择10以内

2、将另外一个RDD,做普通的map映射操作,每条数据,都打上一个10以内的随机数。

3、最后,将两个处理后的RDD,进行join操作。

 

另一个方法

sample采样倾斜key并单独进行join

1、将key,从另外一个RDD中过滤出的数据,可能只有一条,或者几条,此时,咱们可以任意进行扩容,扩成1000倍。

2、将从第一个RDD中拆分出来的那个倾斜key RDD打上1000以内的一个随机数

3join并且提供并行度。这样配合上,提升shuffle reduce并行度,join(rdd, 1000)。通常情况下,效果还是非常不错的。打散成100份,甚至1000份,2000份,去进行join,那么就肯定没有数据倾斜的问题了吧。

 

此方法局限性:

1、因为你的两个RDD都很大,所以你没有办法去将某一个RDD扩的特别大,一般咱们就是10

2、如果就是10倍的话,那么数据倾斜问题,的确是只能说是缓解和减轻,不能说彻底解决。




大家都在看

spark sql源码系列:

是时候学习真正的spark技术了  从0到1认识 spark sql  spark sql 源码剖析 PushDownPredicate   spark sql 源码剖析 OptimizeIn 篇

structured streaming 系列:

structured streaming 原理剖析   structured streaming 碰上kafka structured streaming 是如何搞定乱序时间的

spark streaming 系列:

spark streaming 读取kafka各种姿势详解   spark streaming流式计算中的困境与解决之道 

spark core 系列:

彻底搞懂spark shuffle过程(1)  彻底搞懂spark shuffle过程(2)  spark内存管理-Tungsten框架探秘

spark 机器学习系列:

学习了 streaming 和 sql,别忘了还有 Mlib





关注【spark技术分享】


一起撸spark源码,一起玩spark最佳实践


spark面试必问|碰到数据倾斜你该咋办





原文始发于微信公众号(spark技术分享):spark面试必问|碰到数据倾斜你该咋办

赞(2) 打赏
未经允许不得转载:spark技术分享 » spark面试必问|碰到数据倾斜你该咋办
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

关注公众号:spark技术分享

联系我们联系我们

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏