Spark調(diào)優(yōu)應(yīng)該怎么做

今天就跟大家聊聊有關(guān)Spark調(diào)優(yōu)應(yīng)該怎么做，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

　　死鎖的問題通過分析死鎖日志文件解決了，由于上面一塊錯誤的認(rèn)識。一直認(rèn)為兩個非唯一索引可以命中單條記錄，其實mysql為了性能命中了多條。

　　一個簡單的update語句，update？whereid1=1andid2=2id1和id2都是非唯一索引，這時有的語句會對因為優(yōu)化導(dǎo)致上鎖其他索引周邊的數(shù)據(jù)條目，這時他會等待內(nèi)建唯一索引的鎖，而同樣的語句會對內(nèi)建唯一索引加鎖，等待id1或者id2的鎖，出現(xiàn)同一條語句回環(huán)等待鎖的釋放，導(dǎo)致死鎖發(fā)生。

　　以后還是需要多看一些數(shù)據(jù)庫方面的書籍，對原理性知識了解的更多一些。

Spark中主要進(jìn)程的作用？

　　Driver進(jìn)程：負(fù)責(zé)任務(wù)的分發(fā)和結(jié)果的回收。

　　Executor進(jìn)程：負(fù)責(zé)具體任務(wù)的執(zhí)行。

　　Master進(jìn)程：Spark資源管理的主進(jìn)程，負(fù)責(zé)資源調(diào)度。

　　Worker進(jìn)程：Spark資源管理的從進(jìn)程，woker節(jié)點主要運行Executor

如何選擇一種最合適的持久化策略？

　　默認(rèn)情況下，性能最高的當(dāng)然是MEMORY_ONLY，但前提是你的內(nèi)存必須足夠足夠大，可以綽綽有余地存放下整個RDD的所有數(shù)據(jù)。因為不進(jìn)行序列化與反序列化操作，就避免了這部分的性能開銷；對這個RDD的后續(xù)算子操作，都是基于純內(nèi)存中的數(shù)據(jù)的操作，不需要從磁盤文件中讀取數(shù)據(jù)，性能也很高；而且不需要復(fù)制一份數(shù)據(jù)副本，并遠(yuǎn)程傳送到其他節(jié)點上。但是這里必須要注意的是，在實際的生產(chǎn)環(huán)境中，恐怕能夠直接用這種策略的場景還是有限的，如果RDD中數(shù)據(jù)比較多時（比如幾十億），直接用這種持久化級別，會導(dǎo)致JVM的OOM內(nèi)存溢出異常。

　　如果使用MEMORY_ONLY級別時發(fā)生了內(nèi)存溢出，那么建議嘗試使用MEMORY_ONLY_SER級別。該級別會將RDD數(shù)據(jù)序列化后再保存在內(nèi)存中，此時每個partition僅僅是一個字節(jié)數(shù)組而已，大大減少了對象數(shù)量，并降低了內(nèi)存占用。這種級別比MEMORY_ONLY多出來的性能開銷，主要就是序列化與反序列化的開銷。但是后續(xù)算子可以基于純內(nèi)存進(jìn)行操作，因此性能總體還是比較高的。此外，可能發(fā)生的問題同上，如果RDD中的數(shù)據(jù)量過多的話，還是可能會導(dǎo)致OOM內(nèi)存溢出的異常。

　　如果純內(nèi)存的級別都無法使用，那么建議使用MEMORY_AND_DISK_SER策略，而不是MEMORY_AND_DISK策略。因為既然到了這一步，就說明RDD的數(shù)據(jù)量很大，內(nèi)存無法完全放下。序列化后的數(shù)據(jù)比較少，可以節(jié)省內(nèi)存和磁盤的空間開銷。同時該策略會優(yōu)先盡量嘗試將數(shù)據(jù)緩存在內(nèi)存中，內(nèi)存緩存不下才會寫入磁盤。

　　通常不建議使用DISK_ONLY和后綴為_2的級別：因為完全基于磁盤文件進(jìn)行數(shù)據(jù)的讀寫，會導(dǎo)致性能急劇降低，有時還不如重新計算一次所有RDD。后綴為_2的級別，必須將所有數(shù)據(jù)都復(fù)制一份副本，并發(fā)送到其他節(jié)點上，數(shù)據(jù)復(fù)制以及網(wǎng)絡(luò)傳輸會導(dǎo)致較大的性能開銷，除非是要求作業(yè)的高可用性，否則不建議使用。

看完上述內(nèi)容，你們對Spark調(diào)優(yōu)應(yīng)該怎么做有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。