在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機制
上一篇:發那科系統的加工中心該怎樣編寫宏程序？能否舉壹個簡單的例子！~需要改參數嗎！越詳細越好！~~先謝謝了！下一篇:壹個轉換開關和壹個中間繼電器如何實現手動與自動切換