SparkBench簡介

SparkBench是的基準性能測試項目，由來自IBM Watson研究中心的五位研究者（Min Li, Jian Tan, Yandong Wang, Li Zhang, Valentina Salapura）發起，并貢獻至開源社區。

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

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

SparkBench的目的

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

1、重點領域需要有參考數據和定量分析結果，包括：Spark緩存設置、內存管理優化、調度策略；

2、需要不同硬件、不同平臺中運行Spark的性能參照數據；

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

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兩個階段，類似的作業也可分為兩部分：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. 內存資源對尤為重要，因為所有類型的負載都需要在內存中保存大量RDD數據，因此系統配置時需要優先配置內存；

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

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

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

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

詳情請咨詢！

客服熱線：023-66090381