MapReduce和Spark的Shuffle過程對比

MapReduce Spark

Shuffle後續優化方向

通過上面的介紹，我們了解到，Shuffle過程的主要存儲媒體是磁盤，盡量的減少IO是Shuffle的主要優化方向。我們腦海中都有那個經典的存儲金字塔體系，Shuffle過程為什麼把結果都放在磁盤上，那是因為現在記憶體再大也大不過磁盤，記憶體就那麼大，還這麼多張嘴吃，當然是配置設定給最需要的了。如果具有“土豪”記憶體節點，減少Shuffle

IO的最有效方式無疑是盡量把資料放在記憶體中。下面列舉一些現在看可以優化的方面，期待經過我們不斷的努力，TDW計算引擎運作地更好。

MapReduce Shuffle後續優化方向

壓縮：對資料進行壓縮，減少寫讀資料量；
減少不必要的排序：并不是所有類型的Reduce需要的資料都是需要排序的，排序這個nb的過程如果不需要最好還是不要的好；
記憶體化：Shuffle的資料不放在磁盤而是盡量放在記憶體中，除非逼不得已往磁盤上放；當然了如果有性能和記憶體相當的第三方存儲系統，那放在第三方存儲系統上也是很好的；這個是個大招；
網絡架構：netty的性能據說要占優了；
本節點上的資料不走網絡架構：對于本節點上的Map輸出，Reduce直接去讀吧，不需要繞道網絡架構。
           

Spark Shuffle後續優化方向

Spark作為MapReduce的進階架構，對于Shuffle過程已經是優化了的，特别是對于那些具有争議的步驟已經做了優化，但是Spark的Shuffle對于我們來說在一些方面還是需要優化的。
壓縮：對資料進行壓縮，減少寫讀資料量；
記憶體化：Spark曆史版本中是有這樣設計的：Map寫資料先把資料全部寫到記憶體中，寫完之後再把資料刷到磁盤上；考慮記憶體是緊缺資源，後來修改成把資料直接寫到磁盤了；對于具有較大記憶體的叢集來講，還是盡量地往記憶體上寫吧，記憶體放不下了再放磁盤。