Spark 顛覆 MapReduce 保持的排序記錄，sparkmapreduce

Spark 顛覆 MapReduce 保持的排序記錄，sparkmapreduce

在過去幾年，Apache Spark的採用以驚人的速度增加著，通常被作為MapReduce後繼，可以支撐數千節點規模的叢集部署。在記憶體中數 據處理上，Apache Spark比MapReduce更加高效已經得到廣泛認識；但是當資料量遠超記憶體容量時，我們也聽到了一些機構在Spark使用 上的困擾。因此，我們與Spark社區一起，投入了大量的精力做Spark穩定性、擴充性、效能等方面的提升。既然Spark在GB或TB層級資料上運行 良好，那麼它在PB級資料上也應當同樣如此。

為了評估這些工作，最近我們與AWS一起完成了一個Sort Benchmark（Daytona Gray類別）測試，一個考量系統排序 100TB資料（萬億條記錄）速度的行業基準測試。在此之前，這項基準測試的世界記錄保持者是雅虎，使用2100節點的Hadoop MapReduce 叢集在72分鐘內完成計算。而根據測試結果得知，在使用了206個EC2節點的情況下，Spark將排序用時縮短到了23分鐘。這意味著在使用十分之一計 算資源的情況下，相同資料的排序上，Spark比MapReduce快3倍！

此外，在沒有官方PB排序對比的情況下，我們首次將Spark推到了1PB資料（十萬億條記錄）的排序。這個測試的結果是，在使用190個節點的情 況下，工作負載在短短不到4小時內完成，同樣遠超雅虎之前使用3800台主機耗時16個小時的記錄。同時，據我們所知，這也是公用雲環境首次完成的PB級 排序測試。

	Hadoop World Record	Spark 100 TB	Spark 1 PB
Data Size	102.5 TB	100 TB	1000 TB
Elapsed Time	72 mins	23 mins	234 mins
# Nodes	2100	206	190
# Cores	50400	6592	6080
# Reducers	10,000	29,000	250,000
	1.42 TB/min	4.27 TB/min	4.27 TB/min
Rate/node	0.67 GB/min	20.7 GB/min	22.5 GB/min
Sort Benchmark Daytona Rules	Yes	Yes	No
Environment	dedicated data center	EC2 (i2.8xlarge)	EC2 (i2.8xlarge)

為什麼會選擇排序？    

排序的核心是shuffle操作，資料的傳輸會橫跨叢集中所有主機。Shuffle基本支援了所有的分布式資料處理負載。舉個例子，在一個 串連了兩個不同資料來源的SQL查詢中，會使用shuffle將需要串連資料的元組移動到同一台主機；同時，類似ALS等協同過濾演算法同樣需要依賴 shuffle在網路中發送使用者或產品的評級（ratings）和權重（weights）。

大部分資料管道開始時都會有大量的未經處理資料，但是在管道處理過程中，隨著越來越多不相干資料被過濾，或者中間資料被更簡潔的表示，資料量必 然會減少。在100TB未經處理資料的查詢上，網路上shuffle的資料可能只有100TB的一小部分，這種模式也體現在MapReduce的命名。

然而，排序卻是非常有挑戰的，因為資料管道中的資料量並不會減少。如果對100TB的未經處理資料進行排序，網路中shuffle的資料必然也 是100TB。同時，在Daytona類型的基準測試中，為了容錯，不管是輸入資料還是輸出資料都需要做備份。實際上，在100TB的資料排序上，我們可 能會產生500TB的磁碟I/O及200TB的網路I/O。

因此，基於上述原因，當我們尋找Spark的測量標準和提升辦法時，排序這個最苛刻的工作負載成為了對比的不二之選。

產生如此結果的技術實現    

在超大規模工作負載上，我們投入了大量的精力來提升Spark。從細節上看，與這個基準測試高度相關的工作主要有3個： 

首先及最關鍵的，在Spark 1.1中我們引入了一個全新的shuffle實現，也就是基於排序的 shuffle（SPARK2045）。在此之前，Spark做的是基於雜湊的shuffle實現，它需要在記憶體中同時保持P（reduce的分割數 量）個緩衝區。而在基於排序的shuffle下，任何時候系統只使用一個緩衝區。這個操作將顯著地減少記憶體開銷，因此同一個情境下可以支撐數十萬任務（我 們在PB排序中使用了2.5萬個任務）。

其次，我們修訂了Spark的網路模型，通過JNI（SPARK2468）使用基於Netty的Epoll本地連接埠傳輸。同時，新的模型還擁有了獨立的記憶體池，繞過了JVM的記憶體 Clerk，從而減少記憶體回收造成的影響。

最後但同樣重要的是，我們建立了一個外部shuffle服務（SPARK3796），它與Spark本身的執行器完全解耦。這個新的服務基於上文所述的網路模型，同時，在Spark本身的執行器忙於GC處理時，它仍然可以保證shuffle檔案處理的繼續執行。

                          
   

通過這三項改變，我們的Spark叢集在map階段單 節點可以支撐每秒3GB的IO吞吐，在reduce階段單節點可以支撐1.1GB，從而榨乾這些機器間10Gbps的網路頻寬。

更多的技術細節    

TimSort：在Spark 1.1版本中，我們將預設排序演算法從 quicksort轉換到 TimSort，它是合并排 序和嵌入排序的一個衍生。在大部分現實世界資料集中，TimSort比quicksort更加高效，在部分排序資料中表現則更為優秀。不管在map階段還 是Reduce階段，我們都使用了TimSort。

緩衝位置的利用：在排序基準測試中，每條記錄的大小都是100位元組，而被排序的鍵是前10個位元組。在排序項目的 效能分析階 段，我們注意到快取命中率不如人意，因為每次比較都需要進行一個隨機的對象指標查詢。為此，我們重新設計了記錄在記憶體的布局，用16位元組長度（兩個長整 形）的記錄來表示每條記錄。在這裡，前10個位元組代表了排序的鍵，後4個位元組則代表了記錄的位置（鑒於位元組順序和符號，這點並不容易發現）。這樣一來，每 個比較只需要做一次緩衝查詢，而且它們都是連續的，從而避免了隨機的記憶體查詢。

使用TimSort和新的布局方式來利用快取命中，排序所佔用的CPU時間足足減少了5倍。

大規模下的容錯機制：在大規模下，許多問題都會暴露。在這個測試過程中，我們看到因為網路連通問題出現的節點丟失，Linux核心自旋，以及因為記憶體磁碟重組造成的節點停滯。幸運的是，Spark的容錯機制非常好，並且順利的進行故障恢複。

AWS的能量：如上文所述，我們使用了206個i2.8xlarge執行個體來跑這個I/O密集測試。通過SSD， 這些執行個體交付了非常高的I/O輸送量。我們將這些執行個體放到一個VPC放置組中，從而通過單SR-IOV增強網路效能，以獲得高效能（10Gbps）、低延 時和低抖動。        
   

Spark只能在記憶體中大放異彩？    

這個誤解一直圍繞著Spark，特別是剛進入社區中的新人更是如此認為。不錯，Spark因為記憶體計算的高效能聞名，然而Spark的設計 初衷和理念卻是一個通用的大資料處理平台——不管是使用記憶體還是磁碟。在資料無法完全放入記憶體時，基本上所有的Spark運算子都會做一些額外的處理。通 俗來說，Spark運算子是MapReduce的超集。

如本次測試所示，Spark可以勝任叢集記憶體大小N倍的資料集處理。

總結    

擊敗Hadoop MapReduce叢集創造的大規模資料處理記錄不僅是對我們工作的一個證明，也是對Spark承諾的一個驗證——在任何資料體積，Spark在效能和擴充性上都更具優勢。同時，我們也希望在使用者使用過程中，Spark可以帶來時間和開銷上的雙節省。

spark也是基於hadoop的？它與hadoop是並列的還是與mapreduce是並列的？

spark是一種分散式運算架構，和mapreduce並列，可以運行於yarn上。yarn是hadoop2.0的一種資源管理架構。對，就是這麼亂