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

　　Shuffle簡(jiǎn)介

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

　　Baidu Shuffle發(fā)展歷程

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

　　分離了shuffle和Map/Reduce

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

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

　　New Shuffle

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

　　New Shuffle的優(yōu)勢(shì)

New Shuffle架構(gòu)

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

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

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

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

　　數(shù)據(jù)重復(fù)。如上圖所示，這些問題主要因?yàn)镹ew Shuffle對(duì)上層組件缺少感知，這個(gè)問題的解決主要使用task id和block id進(jìn)行去重。

　　New Shuffle展望

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