<small id='ktaHRP8L'></small> <noframes id='4zqYvWAC2'>

  • <tfoot id='tDirT'></tfoot>

      <legend id='wLUtGv8sfx'><style id='KGiqVnQx1'><dir id='BDUK7J'><q id='vq2sS'></q></dir></style></legend>
      <i id='UfOVW0rXq'><tr id='9MAlRp'><dt id='E9Mdg'><q id='vE4CGQ2xaD'><span id='0xyF'><b id='M3Pg5yNTk'><form id='uWSjX'><ins id='hx9nOTzGu'></ins><ul id='StnDIib'></ul><sub id='gSUO'></sub></form><legend id='CDN3lh'></legend><bdo id='Lwz3VPq'><pre id='C0ih'><center id='1mKIf9vb'></center></pre></bdo></b><th id='7Iq2D'></th></span></q></dt></tr></i><div id='oSJ9V1NI'><tfoot id='Z4PwB'></tfoot><dl id='1f0BhHb'><fieldset id='CV7A'></fieldset></dl></div>

          <bdo id='KN7JbgZU4H'></bdo><ul id='Dabwj'></ul>

          1. <li id='NrhKTa'></li>
            登陆

            spark面试必问|碰到数据歪斜你该怎么办?

            admin 2019-09-06 224人围观 ,发现0个评论

            spark技能共享 文章转载自大众号

            Spark引荐体系 , 作者 echoy189

            目录:
            一、数据歪斜介绍与定位
            二、处理办法一:聚合数据源
            三、处理办法二:进步shuffle操作reduce并行度
            四、处理办法之三:随机key完成两层聚合
            五、处理办法之四:将reduce join 转化为map join
            六、处理办法之五:sample采样歪斜key进行两次join
            七、处理办法之六:运用随机数以及扩容表进行join

            一、数据歪斜介绍与定位

            a、数据歪斜的原理

            在履行shuffle操作的时分,我们都知道,我们之前解说过shuffle的原理。是依照key,来进行values的数据的输出、拉取和聚合的。同一个key的values,必定是分配到一个reduce task进行处理的。多个key对应的values,总共是90万。可是问题是,或许某个key对应了88万数据,key-88万values,分配到一个task上去面去履行。别的两个task,或许各分配到了1万数据,或许是数百个key,对应的1万条数据。

            榜首个和第二个task,各分配到了1万数据;那么或许1万条数据,需求10分钟核算结束;榜首个和第二个task,或许一起在10分钟内都运转完了;第三个task要88万条,88 * 10 = 880分钟 = 14.5个小时;

            b、数据歪斜的现象,有两种体现:

            1、你的大部分的task,都履行的特别特别快,刷刷刷,就履行完了(你要用client形式,standalone client,yarn client,本地机器首要一履行spark-submit脚本,就会开端打印log),task175 finished;剩余几个task,履行的特别特别慢,前面的task,一般1s能够履行完5个;终究发现1000个task,998,999 task,要履行1个小时,2个小时才干履行完一个task。

            呈现数据歪斜了

            还算好的,由于尽管老牛拉破车相同,十分慢,可是至少还能跑。

            2、运转的时分,其他task都刷刷刷履行完了,也没什么特别的问题;可是有的task,便是会突然间,啪,报了一个OOM,JVM Out Of Memory,内存溢出了,task failed,task lost,resubmitting task。重复履行几回都到了某个task便是跑不通,终究就挂掉。某个task就直接OOM,那么底子上也是由于数据歪斜了,task分配的数量实在是太大了!!!所以内寄存不下,然后你的task每处理一条数据,还要创立许多的目标。内存爆掉了。

            呈现数据歪斜了

            这种就不太好了,由于你的程序假如不去处理数据歪斜的问题,压根儿就跑不出来。

            c、数据歪斜定位与呈现问题的方位:

            依据log去定位

            呈现数据歪斜的原因,底子只或许是由于发作了shuffle操作,在shuffle的过程中,呈现了数据歪斜的问题。由于某个,或许某些key对应的数据,远远的高于其他的key。

            1、你在自己的程序里边找找,哪些地方用了会发作shuffle的算子,groupByKeycountByKeyreduceByKeyjoin

            2、看log

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

            二、处理办法一:聚合数据源

            聚合数据源做法一:

            groupByKey、reduspark面试必问|碰到数据歪斜你该怎么办?ceByKey;groupByKey,便是拿到每个key对应的values;reduceByKey,说白了,便是对每个key对应的values履行必定的核算。现在这些操作,比方groupByKey和reduceByKey,包含之前说的join。都是在spark作业中履行的。

            spark作业的数据来历,一般是哪里呢?90%的状况spark面试必问|碰到数据歪斜你该怎么办?下,数据来历都是hive表(hdfs,大数据分布式存储体系)。hdfs上存储的大数据。hive表,hive表中的数据,一般是怎样出来的呢?有了spark今后,hive比较适合做什么工作?hive便是适合做离线的,晚上清晨跑的,ETL(extract 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=sessionid,values;hive etl中,直接对key进行了聚合。那么也就意味着,每个key就只对应一条数据。在spark中,就不需求再去履行groupByKey+map这种操作了。直接对每个key对应的values字符串,map操作,进行你需求的操作即可。key,values串。spark中,或许对这个操作,就不需求履行shffule操作了,也就底子不或许导致数据歪斜。

            或许是,对每个key在hive etl中进行聚合,对一切values聚合一下,不必定是拼接起来,或许是直接进行核算。reduceByKey,核算函数,运用在hive etl中,每个key的values。

            聚合数据源做法二:

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

            那么也能够做一个退让;对每个key对应的数据,10万条;有好几个粒度,比方10万条里边包含了几个城市、几天、几个区域的数据,现在放粗粒度;直接就依照城市粒spark面试必问|碰到数据歪斜你该怎么办?度,做一下聚合,几个城市,几天、几个区域粒度的数据去水印软件,都给聚合起来。比方说

            city_id,date,area_id

            select ... from ... group by city_id,date,area_id

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

            三、处理办法二:进步shuffle操作reduce并行度

            假如榜首种办法不适合做。那么选用第二种办法:进步shuffle操作的reduce并行度

            添加reduce task的数量,就能够让每个reduce task分配到更少的数据量,这样的话,或许就能够缓解,或许乃至是底子处理掉数据歪斜的问题。

            a、原理图介绍:


            b、进步shuffle reduce端并行度的具体操作

            首要给我们一切的shuffle算子,比方groupByKey、countByKey、reduceByKey。在调用的时分,传入进去一个参数。一个数字。那个数字,就代表了那个shuffle操作的reduce端的并行度。那么在进行shuffle操作的时分,就会对应着创立指定数量的reduce task。

            这样的话,就能够让每个reduce tasspark面试必问|碰到数据歪斜你该怎么办?k分配到更少的数据。底子能够缓解数据歪斜的问题。

            比方说,本来某个task分配数据特别多,直接OOM,内存溢出了,程序无法运转,直接挂掉。依照log,找到发作数据歪斜的shuffle操作,给它传入一个并行度数字,这样的话,原先那个task分配到的数据,必定会变少。就至少能够防止OOM的状况,程序至少是能够跑的。

            c、进步shuffle reduce并行度的缺点

            治标不治本的意思,由于,它没有从底子上改动数据歪斜的实质和问题。不像榜首个和第二个计划(直接防止了数据歪斜的发作)。原理没有改动,仅仅说,尽或许地去缓解和减轻shuffle reduce task的数据压力,以及数据歪斜的问题。

            实践出产环境中的经历:

            1、假如最抱负的状况下,进步并行度今后,减轻了数据歪斜的问题,或许乃至能够让数据歪斜的现象忽略不计,那么就最好。就不用做其他的数据歪斜处理计划了。

            2、不太抱负的状况下,便是比方之前某个task运转特别慢,要5个小时,现在略微快了一点,变成了4个小时;或许是原先运转到某个task,直接OOM,现在至少不会OOM了,可是那个task运转特别慢,要5个小时才干跑完。

            那么,假如呈现第二种状况的话,各位,就当即抛弃这种办法,开端去测验和挑选后边的办法处理。

            四、处理办法之三:随机key完成两层聚合

            原理图介绍:


            运用场景:(1)groupByKey(2)reduceByKey

            join,我们一般不会这样来做,后边有针对不同的join形成的数据歪斜的问题的处理计划。

            五、处理办法之四:将reduce join 转化为map join

            一般reduce join:


            map join:


            一般的join

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

            reduce join转化为map join

            假如两个RDD要进行join,其间一个RDD是比较小的。一个RDD是100万数据,一个RDD是1万数据。(一个RDD是1亿数据,一个RDD是100万数据)其间一个RDD有必要是比较小的,broadcast出去那个小RDD的数据今后,就会在每个executor的block manager中都驻留一份。要保证你的内存满足寄存那个小RDD中的数据

            这种办法下,底子不会发作shuffle操作,必定也不会发作数据歪斜;从底子上杜绝了join操作或许导致的数据歪斜的问题;关于join中有数据歪斜的状况,我们尽量榜首时间先考虑这种办法,作用十分好假如某个RDD比较小的状况下。

            不适合的状况:

            两个RDD都比较大,那么这个时分,你去将其间一个RDD做成broadcast,就很蠢笨了。很或许导致内存不足。终究导致内存溢出,程序挂掉。而且其间某些kespark面试必问|碰到数据歪斜你该怎么办?y(或许是某个key),还发作了数据歪斜;此刻能够选用终究两种办法。

            特别声明:

            关于join这种操作,不光是考虑数据歪斜的问题;即使是没有数据歪斜问题,也完全能够优先考虑,用我们讲的这种高档的reduce join转map join的技能,不要用一般的join,去经过shuffle,进行数据的join;完全能够经过简略的map,运用map join的办法,献身一点内存资源;在可行的状况下,优先这么运用。不走shuffle,直接走map,功能必定是进步许多的。

            六、处理办法之五:sample采样歪斜key进行两次join


            计划的完成思路:其实要害之处在于,将发作数据歪斜的key,独自拉出来,放到一个RDD中去;就用这个本来会歪斜的key RDD跟其他RDD,独自去join一下,这个时分,key对应的数据,或spark面试必问|碰到数据歪斜你该怎么办?许就会涣散到多个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,是不是功能就更好了。必定能够将数据进行打散,去进行join。join完今后,能够履行map操作,去将之前打上的随机数,给去掉,然后再和别的一个一般RDD join今后的成果,进行union操作。

            七、处理办法之六:运用随机数以及扩容表进行join

            当选用随机数和扩容表进行join处理数据歪斜的时分,就代表着,你的之前的数据歪斜的处理计划,都无法运用。这个计划是没办法彻底处理数据歪斜的,更多的,是一种对数据歪斜的缓解。


            过程:

            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以内的一个随机数

            3、join而且供给并行度。这样配合上,进步shuffle reduce并行度,join(rdd, 1000)。一般状况下,作用仍是十分不错的。打散成100份,乃至1000份,2000份,去进行join,那么就必定没有数据歪斜的问题了吧。

            此办法局限性:

            1、由于你的两个RDD都很大,所以你没有办法去将某一个RDD扩的特别大,一般我们便是扩10倍

            2、假如便是10倍的话,那么数据歪斜问题,的确是只能说是缓解和减轻,不能说彻底处理。

            请关注微信公众号
            微信二维码
            不容错过
            Powered By Z-BlogPHP