Spark性能調優

1.壓縮

KyroSerializer相比于JavaSerialize處理性能上10倍以上（綜合了記憶體以及CPU）；但是對于基本類型比如Int等壓縮效果和javaSerializer相比并沒有明顯優勢；另外Kyro支援的Java對象類型比較少，需要做相關配置。

2. Shuffle原理以及Manager選擇

Shuffle是指spark的某個節點發起，向另外一節點發送資料的行為。Shuffle在記憶體中整理資料後将會flush到硬碟檔案中，這個過程稱之為“spill”，每個Task裡面會有100M的“緩存”，一旦存儲資料達到了門檻值比例（spill.percent，預設是0.8）則會flush到硬碟的一個臨時檔案中；然後基于檔案進行檔案傳輸。、

而且傳輸過程可能并不是之前設想的那種零拷貝，而是以資料為機關一條一條的發過去。為什麼呢？因為在代碼處理過程中（foreachPartition）就是逐條讀取，是以要麼是逐條發送，要麼就是即使直接發送過去，但是資料協定保證了可以分辨每條記錄。

Shuffle有兩種Manager：HashManager和SortManager；

Hash Manager将會對于資料基于分區進行，如果有m個分區（mapper），目标是n個reducer，那麼将會有m*n個檔案。Hash在生成資料的過程中不會對檔案進行排序，資料整理完成後，将會直接寫入到shuffle檔案中；

Sort Managere則是會對資料進行排序，然後再寫入到shuffle檔案中。而且sort的資料是寫入到一個shuffle檔案中，對于不同reducer，将會有在檔案中做标記。

在實際應用中就有了性能差别，對于分區較少的場景下，或者說m*n資料較少的情況下，因為資料不需要排序，是以其shuffle性能将會優于sort manager；但是對于分區很多的場景下，因為每個檔案對應一個stream，将會因為檔案的開銷而使得其性能嚴重下降，進而效率是低于sortManager。

3. Cache

緩存資料，不多說了，避免了和硬碟IO，提升性能。

4. 資料壓縮

資料壓縮發生在Shuffle的時候，Spark支援三種壓縮算法，Snappy，LZF，LZ4；LZF以及LZ4的壓縮處理速度是要好于snappy的，但是壓縮率相對而言比Snappy要小。snappy的壓縮率比較低，但是對于CPU壓力同樣比較小。LZ4各方面表現都比較好，但是同樣也消耗比較大的CPU的資源；是以看資源情況和壓力所在選擇 / 不選擇壓縮算法。