Spark技術内幕： 如何解決Shuffle Write一定要落盤的問題？

在spark 0.6和0.7時，shuffle的結果都需要先存儲到記憶體中（有可能要寫入磁盤），是以對于大資料量的情況下，發生gc和oom的機率非常大。是以在spark 0.8的時候，shuffle的每個record都會直接寫入磁盤，并且為下遊的每個task都生成一個單獨的檔案。這樣解決了shuffle解決都需要存入記憶體的問題，但是又引入了另外一個問題：生成的小檔案過多，尤其在每個檔案的資料量不大而檔案特别多的時候，大量的随機讀會非常影響性能。spark 0.8.1為了解決0.8中引入的問題，引入了fileconsolidation機制，在一定程度上解決了這個問題。由此可見，hash based shuffle在scalability方面的确有局限性。而spark1.0中引入的shuffle pluggable framework，為加入新的shuffle機制和引入第三方的shuffle機制奠定了基礎。在spark1.1的時候，引入了sort based shuffle；并且在spark1.2.0時，sort based shuffle已經成為shuffle的預設選項。但是，随着記憶體成本的不斷下降和容量的不斷上升，spark core會在未來重新将shuffle的過程全部是in memory的嗎？我認為這個不太可能也沒太大必要，如果使用者對于性能有比較苛刻的要求而shuffle的過程的确是性能優化的重點，那麼可以嘗試以下實作方式：

1)       worker的節點采用固态硬碟

2)       woker的shuffle結果儲存到ramdisk上

3)       根據自己的應用場景，實作自己的shuffle機制