您好,登錄后才能下訂單哦!
如何理解spark調優中的高層通用調優,很多新手對此不是很清楚,為了幫助大家解決這個難題,下面小編將為大家詳細講解,有這方面需求的人可以來學習下,希望你能有所收獲。
一,并行度
集群不會被充分利用,除非您將每個操作的并行級別設置得足夠高。Spark自動會根據文件的大小,是否可分割等因素來設置map的數目(后面會詳細講解輸入格式,同時詳細講解各種輸入的map數的決定)。對于分布式reduce操作,例如groupbykey和reducebykey,默認它使用的是分區數最大的父RDD的分區數決定reduce的數目。你也可以通過設置spark.default.parallelism來改變默認值,建議值是每個CPU執行2-3個tasks。
二,Reduce任務的內存使用
有時候內存溢出并不是由于你的RDD不適合放在內存里面,而是由于你的某個task的工作集太大了,比如使用groupbykey的時候reduce任務數據集太大了。Spark的shuffle操作(sortByKey, groupByKey, reduceByKey, join, etc)會構建一個hash表,每個task執行一個分組的數據,單個往往會很大。最簡單的改善方法是增加并行度,讓每個task的輸入變得更小。Spark可以高效的支持短達200ms的任務,因為復用了Executor的JVM,這可以降低啟動成本,所以你可以很安全的增加并行度,使其超過你的集群core數目。
三,廣播變量
使用spark的廣播功能可以大幅度減少每個序列化后的task的大小,也可以減少在集群中執行一個job的代價。如果你的任務中使用了大的對象,比如靜態表,可以考慮將它聲明成廣播變量。在driver節點,spark會打印出每個task序列化后的大小,所以你可以通過查看task的大小判斷你的task是否過大,通常task的大小超過20KB就值得調優了。
四,數據本地性
數據的本地性可能會對Spark jobs產生重大影響。如果數據和在其上操作的代碼在一起,則計算往往是快速的。但如果代碼和數據分開,則必須要有一方進行移動。典型的情況是將序列化后的代碼移動到數據所在的地方,因為數據往往比代碼大很多。Spark構建調度計劃的原則就是數據本地性。
數據本地性就是數據離處理他的代碼有多遠。根據數據和代碼當前的位置,數據本地性等級。從最近到最遠的順序列出如下:
1,PROCESS_LOCAL
數據和代碼在同一個JVM中,這是最佳的數據本地性。
2,NODE_LOCAL
數據和代碼在相同的節點。比如數據在同一節點的HDFS上,或者在統一節點的Executor上。由于數據要在多個進程間移動,所以比PROCESS_LOCAL稍慢。
3,NO_PREF
數據可以從任何地方快速訪問,沒有數據本地性。
4,RACK_LOCAL
數據和代碼在相同的機架。數據位于同一機架上的不同服務器上,因此需要通過網絡發送,通常通過單個交換機發送
5,ANY
數據在網絡上的其他地方,而不在同一個機架中。
Spark傾向于調度任務依據最高的數據本地性,但這往往是不可能的。在任何空閑的Executor上沒有未處理數據的情況下,Spark會切換到較低的數據本地性。這種情況下會有兩個選擇:
1),等待CPU空閑,然后在相同的server上啟動task。
2),立即在一個需要遷移數據的較遠位置啟動一個新的task。
Spark的典型處理策略是等待繁忙CPU釋放,時間很短。一旦超時,將移動數據到空閑CPU的地方執行任務。每個級別之間的回退等待超時可以在一個參數中單獨配置或全部配置。如果任務較長,且數據本地性較差,可以適當調整Spark.locatity超時時間相關的配置。具體配置如下:
屬性 | 默認值 | 含義 |
spark.locality.wait | 3s | 超時時間,放棄等待在較低數據本地性新啟任務。 |
spark.locality.wait.node | spark.locality.wait | NODE_LOCAL等待超時時間 |
spark.locality.wait.process | spark.locality.wait | PROCESS_LOCAL等待超時時間 |
spark.locality.wait.rack | spark.locality.wait | RACK_LOCAL等待超時時間 |
主要調優就是序列化和內存調優。
看完上述內容是否對您有幫助呢?如果還想對相關知識有進一步的了解或閱讀更多相關文章,請關注億速云行業資訊頻道,感謝您對億速云的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。