在2014 Sort Benchmark國際大賽上，百度成功奪冠，其幕后英雄無疑卓越的Shuffle機制，在孫垚光的分享中，我們對Shuffle的發(fā)展、細節(jié)和未來有了一次深度的接觸。

　　Shuffle簡介

　　孫垚光表示，簡單來說，Shuffle就是按照一定的分組和規(guī)則Map一個數(shù)據(jù)，然后傳入Reduce端。不管對于MapReduce還是Spark，Shuffle都是一個非常重要的階段。然而，雖然Shuffle解決的問題相同，但是在Spark和MapReduce中，Shuffle流程（具體時間和細節(jié)）仍然存在一定的差別：

　　Baidu Shuffle發(fā)展歷程

　　通過孫垚光了解到，Shuffle在百度的發(fā)展主要包括兩個階段：跟隨社區(qū)和獨立發(fā)展。從2008年百度的MapReduce/Hadoop起步開始，百度就開始跟隨社區(qū)，使用社區(qū)版本，期間的主要工作包含Bug修復和性能優(yōu)化兩個方面（增加內存池、減少JVMGC，傳輸Server由Jetty換Netty，及批量傳輸、聚合數(shù)據(jù)等方面）。

　　分離了shuffle和Map/Reduce

　　在2012年開始，Baidu Shuffle開啟獨立發(fā)展階段，主要源于下一代離線計算系統(tǒng)的開發(fā)，Shuffle被抽離為獨立的ShuffleService服務，從而提高了集群資源的利用率。

　　截止此時，不管是社區(qū)版本（MapReduce/Spark），還是百度研發(fā)的ShuffleService，它們都是基于磁盤的PULL模式?；诖疟P，所有Map的數(shù)據(jù)都會放到磁盤，雖然Spark號稱內存計算，但是涉及到Shuffle時還是會寫磁盤?；赑ULL，所有數(shù)據(jù)在放到Map端的磁盤之后，Reduce在使用時還需要主動的拉出來，因此會受到兩個問題影響：首先，業(yè)務數(shù)據(jù)存儲在Map端的服務器上，機器宕機時會不可避免丟失數(shù)據(jù)，這一點在大規(guī)模分布式集群中非常致命；其次，更重要的是，Shuffle階段會產(chǎn)生大量的磁盤尋道（隨機讀）和數(shù)據(jù)重算（中間數(shù)據(jù)存在本地磁盤），舉個例子，某任務有1百萬個Map，1萬個Reduce，如果一次磁盤尋道的時間是10毫秒，那么集群總共的磁盤尋道時間= 1000000 ×10000 ×0.01 = 1億秒。

　　New Shuffle

　　基于這些問題，百度設計了基于內存的PUSH模式。新模式下，Map輸出的數(shù)據(jù)將不落磁盤，并在內存中及時地Push給遠端的Shuffle模塊，從而將獲得以下提升：

　　New Shuffle的優(yōu)勢

New Shuffle架構

如圖所示，藍色部分為New Shuffle部分，主要包含兩個部分：數(shù)據(jù)寫入和讀取的API，Map端會使用這個接口來讀取數(shù)據(jù)，Reduce會使用這個接口來讀取數(shù)據(jù)；其次，最終重要的是，服務器端使用了典型的主從架構，用多個shuffle工作者節(jié)點來shuffle數(shù)據(jù)。同時，在系統(tǒng)設計中，Master非常有利于橫向擴展，讓shuffle不會成為整個分布式系統(tǒng)的瓶頸。

讓New Shuffle模塊專注于shuffle，不依賴于外部計算模塊，從而計算模塊可以專注于計算，同時還避免了磁盤IO。然而New Shuffle帶來的問題也隨之暴漏，其中影響比較重要的兩個就是：慢節(jié)點和數(shù)據(jù)重復。

慢節(jié)點。以shuffle寫入過程中出現(xiàn)慢節(jié)點為例，通常包含兩個情況。首先，Shuffle自身慢節(jié)點，對比社區(qū)版本中只會影響到一個task，New Shuffle中常常會影響到一片集群。在這里，百度為每個Shuffle節(jié)點都配置了一個從節(jié)點，當Map檢測到一個慢節(jié)點時，系統(tǒng)會自動切換到從節(jié)點。其次，DFS出現(xiàn)慢節(jié)點，這個情況下，Shuffle的從節(jié)點只能起到緩解作用。這種情況下，首先DFS系統(tǒng)會自動檢測出慢節(jié)點，并進行替換。比如，傳統(tǒng)的HDFS會以pipeline的形式進行寫入，而DFS則轉換為分發(fā)寫。

在此之外，New Shuffle還需要解決更多問題，比如資源共享和隔離等。同時，基于New Shuffle的機制，New Shuffle還面臨一些其他挑戰(zhàn)，比如Reduce全啟動、數(shù)據(jù)過于分散、對DFS壓力過大、連接數(shù)等等。

　　數(shù)據(jù)重復。如上圖所示，這些問題主要因為New Shuffle對上層組件缺少感知，這個問題的解決主要使用task id和block id進行去重。

　　New Shuffle展望

　　孫垚光表示，New Shuffle使用了通用的Writer和Reader接口，當下已經(jīng)支持百度MR和DCE（DAG、C++），同時即將對開源Spark提供支持。在未來，New Shuffle無疑將成為更通用的組件，支持更多的計算模型。