干貨分享：SparkBench--Spark平臺(tái)的基準(zhǔn)性能測(cè)試

---

SparkBench簡(jiǎn)介

SparkBench是的基準(zhǔn)性能測(cè)試項(xiàng)目，由來(lái)自IBM Watson研究中心的五位研究者（Min Li, Jian Tan, Yandong Wang, Li Zhang, Valentina Salapura）發(fā)起，并貢獻(xiàn)至開(kāi)源社區(qū)。

SparkBench的測(cè)試項(xiàng)目覆蓋了Spark支持的四種最主流的應(yīng)用類型，即機(jī)器學(xué)習(xí)、圖計(jì)算、SQL查詢和流數(shù)據(jù)計(jì)算。每種類型的應(yīng)用又選擇了最常用的幾個(gè)算法或者應(yīng)用進(jìn)行比對(duì)測(cè)試，測(cè)試結(jié)果從系統(tǒng)資源消耗、時(shí)間消耗、數(shù)據(jù)流特點(diǎn)等各方面全面考察，總體而言是比較全面的測(cè)試。

所有的研究結(jié)果以論文的形式公開(kāi)發(fā)布，原文可在SparkBench的官方網(wǎng)站下載，測(cè)試相關(guān)的數(shù)據(jù)和代碼也可下載供測(cè)試使用，本文將主要的研究結(jié)果呈現(xiàn)給大家。

SparkBench的目的

SparkBench最主要的目的是通過(guò)基準(zhǔn)性能測(cè)試，研究與傳統(tǒng)計(jì)算平臺(tái)的不同之處，為搭建Spark平臺(tái)提供參考和通用指導(dǎo)原則。具體而言SparkBench可以在如下場(chǎng)景中發(fā)揮作用：

1、重點(diǎn)領(lǐng)域需要有參考數(shù)據(jù)和定量分析結(jié)果，包括：Spark緩存設(shè)置、內(nèi)存管理優(yōu)化、調(diào)度策略；

2、需要不同硬件、不同平臺(tái)中運(yùn)行Spark的性能參照數(shù)據(jù)；

3、尋找集群規(guī)劃指導(dǎo)原則，幫助定位資源配置中的瓶頸，通過(guò)合理的配置使資源競(jìng)爭(zhēng)最小化；

4、需要從多個(gè)角度深入分析Spark平臺(tái)，包括：負(fù)載類型、關(guān)鍵配置參數(shù)、擴(kuò)展性和容錯(cuò)性等

SparkBench測(cè)試項(xiàng)目

SparkBench主要的的測(cè)試項(xiàng)目，按負(fù)載類型劃分如下表所示：

其中機(jī)器學(xué)習(xí)類型選擇了最常用的邏輯回歸、支持向量機(jī)和矩陣分解算法，這些是在進(jìn)行數(shù)據(jù)歸類或者構(gòu)建推薦系統(tǒng)時(shí)最常用的機(jī)器學(xué)習(xí)算法，很有代表性。圖計(jì)算類別中選取了最流行的三種圖計(jì)算算法：PangeRank、SVD++和TriangleCount，各具特點(diǎn)。SQL查詢類別同時(shí)測(cè)試了Hive on Spark和原生態(tài)的Spark SQL，測(cè)試覆蓋最常用的三種SQL操作：select、aggregate和 join。流計(jì)算類別分別測(cè)試了Twitter數(shù)據(jù)接口Twitter4j的流數(shù)據(jù)和模擬用戶訪問(wèn)網(wǎng)頁(yè)的流數(shù)據(jù)(PageView)。

除了表中列出的測(cè)試項(xiàng)目，目前最新版本的SparkBench還包括很多其他負(fù)載類型的測(cè)試項(xiàng)目：KMeans，LinearRegression，DecisionTree,ShortestPaths， LabelPropagation， ConnectedComponent， StronglyConnectedComponent，PregelOperatio。

SparkBench的測(cè)試數(shù)據(jù)

SparkBench大部分測(cè)試數(shù)據(jù)由項(xiàng)目自帶的數(shù)據(jù)生成器生成，其中SQL查詢使用模擬生成的電子商務(wù)系統(tǒng)的訂單數(shù)據(jù)，流計(jì)算使用的分別是Twitter數(shù)據(jù)（Twitter4j每60秒發(fā)布一次最熱門的標(biāo)簽數(shù)據(jù)）和模擬生成的用戶活動(dòng)數(shù)據(jù)(用戶點(diǎn)擊、頁(yè)面訪問(wèn)統(tǒng)計(jì)等等)。具體測(cè)試項(xiàng)目的數(shù)據(jù)量如下表所示：

SparkBench的研究方法

SparkBench基準(zhǔn)測(cè)試通過(guò)每個(gè)測(cè)試項(xiàng)目指標(biāo)的縱向?qū)Ρ龋投鄠€(gè)測(cè)試項(xiàng)目指標(biāo)的橫向?qū)Ρ龋瑏?lái)發(fā)現(xiàn)不同工作負(fù)載的規(guī)律，目前版本研究的主要指標(biāo)是：任務(wù)執(zhí)行時(shí)間、數(shù)據(jù)處理速度和對(duì)資源的消耗情況。在未來(lái)的版本中會(huì)陸續(xù)加入其它方面的指標(biāo)進(jìn)行研究，包括shuffle數(shù)據(jù)量, 輸入輸出數(shù)據(jù)量等。

SparkBench測(cè)試環(huán)境

公開(kāi)發(fā)布的結(jié)果是基于IBM SoftLayer云計(jì)算平臺(tái)的測(cè)試環(huán)境：總共11臺(tái)虛擬主機(jī)，每臺(tái)配置4核CPU，8GB的內(nèi)存和2塊100GB的虛擬硬盤(一塊盤分配給HDFS，另一塊做為Spark本地緩存使用)，網(wǎng)絡(luò)帶寬1Gbps。11臺(tái)虛擬主機(jī)中，只有1臺(tái)作為管理節(jié)點(diǎn)，剩下的10臺(tái)作為HDFS數(shù)據(jù)節(jié)點(diǎn)和Spark計(jì)算節(jié)點(diǎn)，每個(gè)Spark計(jì)算節(jié)點(diǎn)只設(shè)置1個(gè)executor并分配了6GB的最大內(nèi)存。

可能會(huì)有人擔(dān)心虛擬機(jī)測(cè)試結(jié)果會(huì)與物理環(huán)境測(cè)試結(jié)果相差過(guò)大，對(duì)于這一點(diǎn)論文指出，經(jīng)過(guò)實(shí)際測(cè)試，在該虛擬環(huán)境中的測(cè)試結(jié)果與同等配置硬件環(huán)境的測(cè)試結(jié)果相比，相差不超過(guò)5%。

背景交代完畢，下面是最重要的內(nèi)容：SparkBench測(cè)試結(jié)果及分析！

SparkBenc測(cè)結(jié)果和分析

任務(wù)運(yùn)行時(shí)間對(duì)比

MapReduce作業(yè)分為Map和Reduce兩個(gè)階段，類似的作業(yè)也可分為兩部分：ShuffleMapTask和ResultTask。前者由Spark DAG生成，會(huì)在不同節(jié)點(diǎn)間分發(fā)數(shù)據(jù)，產(chǎn)生一系列高代價(jià)的操作：IO、數(shù)據(jù)序列化、反序列化等。按這兩個(gè)階段（分別顯示為Shuffle Time和Regular Time）統(tǒng)計(jì)的運(yùn)行時(shí)間占比如下：

測(cè)試結(jié)果顯示，除了邏輯回歸測(cè)試項(xiàng)目中ShuffleMapTasks階段運(yùn)行時(shí)間占比小于一半，其他測(cè)試項(xiàng)目都超了過(guò)50%，其中HIVE SQL/Spark SQL和矩陣分解算法等這幾個(gè)測(cè)試的ShuffleMapTasks時(shí)間占比接近100%！ 論文中論述的原因是：SQL查詢及矩陣分解算法都使用了大量的聚合和數(shù)據(jù)關(guān)聯(lián)操作(RDD或表)，比如矩陣分解算法中GroupBy操作就占用了約98%的時(shí)間，這樣的操作會(huì)使Spark花費(fèi)大量時(shí)間在不同Stage之間的協(xié)同和數(shù)據(jù)分發(fā)上。

測(cè)試項(xiàng)目的資源占比分析

我們摘選幾個(gè)關(guān)鍵測(cè)試項(xiàng)目的測(cè)試結(jié)果呈現(xiàn)如下:

邏輯回歸測(cè)試：對(duì)CPU和內(nèi)存的占用較為平均，分別為63%和5.2GB；對(duì)磁盤IO的占用峰值出現(xiàn)在測(cè)試開(kāi)始階段，后繼占用逐漸減少。

SVM測(cè)試項(xiàng)目：對(duì)CPU和IO的占用具有雙峰的特點(diǎn)，分別在測(cè)試開(kāi)始不久和測(cè)試結(jié)束前占用較多CPU和IO資源。

矩陣分解測(cè)試： 占用較高CPU和內(nèi)存，對(duì)磁盤IO的占用特點(diǎn)是有大量的本地盤操作而不是HDFS操作，這是因?yàn)樵摴ぷ髫?fù)載產(chǎn)生大量的Shuffle數(shù)據(jù)，Shuffle是由本地盤的IO來(lái)完成的。

SQL查詢測(cè)試項(xiàng)目：HIVE SQL和Spark Native SQL對(duì)資源的占用規(guī)律類似，都占用了將近100%的資源！ 這與SQL計(jì)算中有大量的數(shù)據(jù)表關(guān)聯(lián)有關(guān)。

流計(jì)算測(cè)試項(xiàng)目：兩個(gè)流計(jì)算測(cè)試項(xiàng)目的資源占用規(guī)律類似。與其他負(fù)載類型相比，除了內(nèi)存占用逐漸變大，對(duì)其他資源(CPU/IO/網(wǎng)絡(luò))的占用率較低。

測(cè)試結(jié)果的指導(dǎo)意義

通過(guò)對(duì)四種工作負(fù)載、多個(gè)測(cè)試項(xiàng)目的結(jié)果分析，得到如下結(jié)論：

1. 內(nèi)存資源對(duì)尤為重要，因?yàn)樗蓄愋偷呢?fù)載都需要在內(nèi)存中保存大量RDD數(shù)據(jù)，因此系統(tǒng)配置時(shí)需要優(yōu)先配置內(nèi)存；

2. 進(jìn)行優(yōu)化時(shí)，Shuffle的優(yōu)化異常重要，大部分負(fù)載超過(guò)50%的執(zhí)行時(shí)間都用在Shuffle上。

有趣！只增加CPU可能會(huì)降低性能

SparkBench測(cè)試還研究了增加CPU資源對(duì)負(fù)載性能的影響。測(cè)試中選用三種典型的負(fù)載(邏輯回歸、PangeRank和Hive SQL)，來(lái)研究線性增加CPU個(gè)數(shù)對(duì)任務(wù)執(zhí)行時(shí)間的影響。

由于中默認(rèn)一個(gè)CPU Core分配一個(gè)Executor，只要系統(tǒng)CPU資源足夠多，Spark會(huì)啟動(dòng)多個(gè)并行任務(wù)(Executor)，因此增加CPU個(gè)數(shù)就是增加并發(fā)任務(wù)數(shù)量。而在現(xiàn)有環(huán)境中CPU核數(shù)從1增加到2，總體上都可以減少執(zhí)行時(shí)間，成倍增加效率；但如果過(guò)度增加CPU可能不僅沒(méi)能改善，反而會(huì)降低性能，參見(jiàn)HiveSQL測(cè)試結(jié)果：

詳情請(qǐng)咨詢！

客服熱線：023-66090381