您好,登錄后才能下訂單哦!
本篇文章給大家分享的是有關(guān)Spark性能優(yōu)化的10大問題及其解決方案是什么,小編覺得挺實(shí)用的,因此分享給大家學(xué)習(xí),希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。
問題1:reduce task數(shù)目不合適
解決方案:
需要根據(jù)實(shí)際情況調(diào)整默認(rèn)配置,調(diào)整方式是修改參數(shù)spark.default.parallelism。通常的,reduce數(shù)目設(shè)置為core數(shù)目的2-3倍。數(shù)量太大,造成很多小任務(wù),增加啟動(dòng)任務(wù)的開銷;數(shù)目太小,任務(wù)運(yùn)行緩慢。所以要合理修改reduce的task數(shù)目即spark.default.parallelism
問題2:shuffle磁盤IO時(shí)間長
解決方案:
設(shè)置spark.local.dir為多個(gè)磁盤,并設(shè)置磁盤的IO速度快的磁盤,通過增加IO來優(yōu)化shuffle性能;
問題3:map|reduce數(shù)量大,造成shuffle小文件數(shù)目多
解決方案:
通過設(shè)置spark.shuffle.consolidateFiles為true,來合并shuffle中間文件,此時(shí)文件數(shù)為reduce tasks數(shù)目;
問題4:序列化時(shí)間長、結(jié)果大
解決方案:
spark默認(rèn)使用JDK 自帶的ObjectOutputStream,這種方式產(chǎn)生的結(jié)果大、CPU處理時(shí)間長,可以通過設(shè)置spark.serializer為org.apache.spark.serializer.KeyoSerializer。
另外如果結(jié)果已經(jīng)很大,那就最好使用廣播變量方式了,結(jié)果你懂得。
問題5:單條記錄消耗大
解決方案:
使用mapPartition替換map,mapPartition是對每個(gè)Partition進(jìn)行計(jì)算,而map是對partition中的每條記錄進(jìn)行計(jì)算;
問題6 : collect輸出大量結(jié)果時(shí)速度慢
解決方案:
collect源碼中是把所有的結(jié)果以一個(gè)Array的方式放在內(nèi)存中,可以直接輸出到分布式的文件系統(tǒng),然后查看文件系統(tǒng)中的內(nèi)容;
問題7: 任務(wù)執(zhí)行速度傾斜
解決方案:
如果數(shù)據(jù)傾斜,一般是partition key取得不好,可以考慮其他的并行處理方式,并在中間加上aggregation操作;如果是Worker傾斜,例如在某些Worker上的executor執(zhí)行緩慢,可以通過設(shè)置spark.speculation=true 把那些持續(xù)慢的節(jié)點(diǎn)去掉;
問題8: 通過多步驟的RDD操作后有很多空任務(wù)或者小任務(wù)產(chǎn)生
解決方案:
使用coalesce或者repartition去減少RDD中partition數(shù)量;
問題9:Spark Streaming吞吐量不高
可以設(shè)置spark.streaming.concurrentJobs
問題10:Spark Streaming 運(yùn)行速度突然下降了,經(jīng)常會有任務(wù)延遲和阻塞
解決方案:
這是因?yàn)槲覀冊O(shè)置job啟動(dòng)interval時(shí)間間隔太短了,導(dǎo)致每次job在指定時(shí)間無法正常執(zhí)行完成,換句話說就是創(chuàng)建的windows窗口時(shí)間間隔太密集了;
以上就是Spark性能優(yōu)化的10大問題及其解決方案是什么,小編相信有部分知識點(diǎn)可能是我們?nèi)粘9ぷ鲿姷交蛴玫降摹OM隳芡ㄟ^這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。