SparkBench簡介

SparkBench是Spark的基準效能測試專案，由來自IBM Watson研究中心的五位研究者（Min Li, Jian Tan, Yandong Wang, Li Zhang, Valentina Salapura）發起，並貢獻至開源社群。

SparkBench的測試專案覆蓋了Spark支援的四種最主流的應用型別，即機器學習、圖計算、SQL查詢和流資料計算。每種型別的應用又選擇了最常用的幾個演算法或者應用進行比對測試，測試結果從系統資源消耗、時間消耗、資料流特點等各方面全面考察，總體而言是比較全面的測試。

所有的研究結果以論文的形式公開發布，原文可在SparkBench的官方網站下載，測試相關的資料和程式碼也可下載供測試使用，本文將主要的研究結果呈現給大家。

SparkBench的目的

SparkBench最主要的目的是通過基準效能測試，研究Spark與傳統計算平臺的不同之處，為搭建Spark平臺提供參考和通用指導原則。具體而言SparkBench可以在如下場景中發揮作用：

1、重點領域需要有參考資料和定量分析結果，包括：Spark快取設定、記憶體管理優化、排程策略；

2、需要不同硬體、不同平臺中執行Spark的效能參照資料；

3、尋找Spark叢集規劃指導原則，幫助定位資源配置中的瓶頸，通過合理的配置使資源競爭最小化；

4、需要從多個角度深入分析Spark平臺，包括：負載型別、關鍵配置引數、擴充套件性和容錯性等

SparkBench測試專案

SparkBench主要的的測試專案，按負載型別劃分如下表所示：

其中機器學習型別選擇了最常用的邏輯迴歸、支援向量機和矩陣分解演算法，這些是在進行資料歸類或者構建推薦系統時最常用的機器學習演算法，很有代表性。圖計算類別中選取了最流行的三種圖計算演算法：PangeRank、SVD++和TriangleCount，各具特點。SQL查詢類別同時測試了Hive on Spark和原生態的Spark SQL，測試覆蓋最常用的三種SQL操作：select、aggregate和 join。流計算類別分別測試了Twitter資料介面Twitter4j的流資料和模擬使用者訪問網頁的流資料(PageView)。

除了表中列出的測試專案，目前最新版本的SparkBench還包括很多其他負載型別的測試專案：KMeans，LinearRegression，DecisionTree,ShortestPaths， LabelPropagation， ConnectedComponent， StronglyConnectedComponent，PregelOperatio。

SparkBench的測試資料

SparkBench大部分測試資料由專案自帶的資料生成器生成，其中SQL查詢使用模擬生成的電子商務系統的訂單資料，流計算使用的分別是Twitter資料（Twitter4j每60秒釋出一次最熱門的標籤資料）和模擬生成的使用者活動資料(使用者點選、頁面訪問統計等等)。具體測試專案的資料量如下表所示：

SparkBench的研究方法

SparkBench基準測試通過每個測試專案指標的縱向對比，和多個測試專案指標的橫向對比，來發現不同工作負載的規律，目前版本研究的主要指標是：任務執行時間、資料處理速度和對資源的消耗情況。在未來的版本中會陸續加入其它方面的指標進行研究，包括shuffle資料量, 輸入輸出資料量等。

SparkBench測試環境

公開發布的結果是基於IBM SoftLayer雲端計算平臺的測試環境：總共11臺虛擬主機，每臺配置4核CPU，8GB的記憶體和2塊100GB的虛擬硬碟(一塊盤分配給HDFS，另一塊做為Spark本地快取使用)，網路頻寬1Gbps。11臺虛擬主機中，只有1臺作為管理節點，剩下的10臺作為HDFS資料節點和Spark計算節點，每個Spark計算節點只設置1個executor並分配了6GB的最大記憶體。

可能會有人擔心虛擬機器測試結果會與物理環境測試結果相差過大，對於這一點論文指出，經過實際測試，在該虛擬環境中的測試結果與同等配置硬體環境的測試結果相比，相差不超過5%。

背景交代完畢，下面是最重要的內容：SparkBench測試結果及分析！

SparkBenc測結果和分析

任務執行時間對比

MapReduce作業分為Map和Reduce兩個階段，類似的Spark作業也可分為兩部分：ShuffleMapTask和ResultTask。前者由Spark DAG生成，會在不同節點間分發資料，產生一系列高代價的操作：IO、資料序列化、反序列化等。按這兩個階段（分別顯示為Shuffle Time和Regular Time）統計的執行時間佔比如下：

測試結果顯示，除了邏輯迴歸測試專案中ShuffleMapTasks階段執行時間佔比小於一半，其他測試專案都超了過50%，其中HIVE SQL/Spark SQL和矩陣分解演算法等這幾個測試的ShuffleMapTasks時間佔比接近100%！ 論文中論述的原因是：SQL查詢及矩陣分解演算法都使用了大量的聚合和資料關聯操作(RDD或表)，比如矩陣分解演算法中GroupBy操作就佔用了約98%的時間，這樣的操作會使Spark花費大量時間在不同Stage之間的協同和資料分發上。

測試專案的資源佔比分析

我們摘選幾個關鍵測試專案的測試結果呈現如下:

邏輯迴歸測試：對CPU和記憶體的佔用較為平均，分別為63%和5.2GB；對磁碟IO的佔用峰值出現在測試開始階段，後繼佔用逐漸減少。

SVM測試專案：對CPU和IO的佔用具有雙峰的特點，分別在測試開始不久和測試結束前佔用較多CPU和IO資源。

矩陣分解測試： 佔用較高CPU和記憶體，對磁碟IO的佔用特點是有大量的本地盤操作而不是HDFS操作，這是因為該工作負載產生大量的Shuffle資料，Shuffle是由本地盤的IO來完成的。

SQL查詢測試專案：HIVE SQL和Spark Native SQL對資源的佔用規律類似，都佔用了將近100%的資源！ 這與SQL計算中有大量的資料表關聯有關。

流計算測試專案：兩個流計算測試專案的資源佔用規律類似。與其他負載型別相比，除了記憶體佔用逐漸變大，對其他資源(CPU/IO/網路)的佔用率較低。

測試結果的指導意義

通過對四種工作負載、多個測試專案的結果分析，得到如下結論：

1. 記憶體資源對Spark尤為重要，因為所有型別的負載都需要在記憶體中儲存大量RDD資料，因此係統配置時需要優先配置記憶體；

2. 進行優化時，Shuffle的優化異常重要，大部分負載超過50%的執行時間都用在Shuffle上。

有趣！只增加CPU可能會降低效能

SparkBench測試還研究了增加CPU資源對負載效能的影響。測試中選用三種典型的負載(邏輯迴歸、PangeRank和Hive SQL)，來研究線性增加CPU個數對任務執行時間的影響。

由於Spark中預設一個CPU Core分配一個Executor，只要系統CPU資源足夠多，Spark會啟動多個並行任務(Executor)，因此增加CPU個數就是增加併發任務數量。而在現有環境中CPU核數從1增加到2，總體上都可以減少執行時間，成倍增加效率；但如果過度增加CPU可能不僅沒能改善，反而會降低效能，參見HiveSQL測試結果：