史凌云,鄭瑩瑩,譚 勵(lì),許利杰,王 偉,4,魏 峻,4

1(北京工商大學(xué) 計(jì)算機(jī)與信息工程學(xué)院,北京 100048)

2(中國(guó)科學(xué)院 軟件研究所,北京 100190)

3(中國(guó)科學(xué)院大學(xué),北京 100049)

4(計(jì)算機(jī)科學(xué)國(guó)家重點(diǎn)實(shí)驗(yàn)室,北京 100190)

引言

隨著信息時(shí)代的到來(lái),互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、云計(jì)算等技術(shù)的飛速發(fā)展和廣泛應(yīng)用,數(shù)據(jù)在各個(gè)行業(yè)不斷地產(chǎn)生、積累并爆發(fā)式增長(zhǎng),已經(jīng)成為一種重要的生產(chǎn)因素,并滲透到每一個(gè)行業(yè)和業(yè)務(wù)職能領(lǐng)域[1].大數(shù)據(jù)被喻為“未來(lái)的新石油”[2],已經(jīng)成為社會(huì)各界關(guān)注的熱點(diǎn),甚至成為各界爭(zhēng)奪的焦點(diǎn),大數(shù)據(jù)時(shí)代已經(jīng)到來(lái).相較于傳統(tǒng)的數(shù)據(jù),大數(shù)據(jù)具有數(shù)據(jù)規(guī)模大、數(shù)據(jù)類型多、數(shù)據(jù)處理速度快、數(shù)據(jù)價(jià)值密度低等特征,這些特征對(duì)大數(shù)據(jù)處理和應(yīng)用提出了更高的要求和更大的挑戰(zhàn).

目前對(duì)大數(shù)據(jù)處理的形式主要包括批式處理和流式處理[3].其中,批式處理是指對(duì)靜態(tài)有界數(shù)據(jù)的處理,對(duì)計(jì)算的實(shí)時(shí)性要求不高且應(yīng)用場(chǎng)景廣泛,具有代表性的批量大數(shù)據(jù)處理系統(tǒng)有Apache Hadoop[4]和Apache Spark[5]等.但是,隨著社交網(wǎng)絡(luò)、電子商務(wù)等技術(shù)的飛速發(fā)展和應(yīng)用,越來(lái)越多的應(yīng)用場(chǎng)景要求從海量的數(shù)據(jù)中及時(shí)獲取價(jià)值,并以很低的延遲來(lái)分析實(shí)時(shí)數(shù)據(jù).例如,以阿里巴巴為代表的電商平臺(tái)基于流式大數(shù)據(jù)處理系統(tǒng)實(shí)時(shí)統(tǒng)計(jì)和分析用戶行為,更新商品搜索引擎.因此,針對(duì)流式大數(shù)據(jù)的實(shí)時(shí)處理越來(lái)越流行,應(yīng)用場(chǎng)景也越來(lái)越重要.流式大數(shù)據(jù)處理系統(tǒng)的地位日漸凸顯,在業(yè)界也已經(jīng)有了非常廣泛的應(yīng)用,常見的有Apache Strom[6]、Apache Flink[7]、Apache Spark Streaming[8]等.

流式數(shù)據(jù)本身的實(shí)時(shí)性、難重復(fù)以及動(dòng)態(tài)變化等特性,以及流式數(shù)據(jù)計(jì)算所需的數(shù)據(jù)無(wú)限性、計(jì)算有界性、計(jì)算實(shí)時(shí)性等特征,對(duì)流式大數(shù)據(jù)處理系統(tǒng)的性能和可靠性提出了更高的要求.流式大數(shù)據(jù)處理系統(tǒng)需要提供低延遲的數(shù)據(jù)處理,同時(shí)保證計(jì)算的正確性.然而,隨著集群規(guī)模的擴(kuò)大,系統(tǒng)發(fā)生故障的概率也會(huì)增大,無(wú)法預(yù)知的錯(cuò)誤可能會(huì)隨時(shí)出現(xiàn)在任意一個(gè)節(jié)點(diǎn).一旦大數(shù)據(jù)處理系統(tǒng)出現(xiàn)問(wèn)題,可能會(huì)產(chǎn)生不可挽回的損失.因此,針對(duì)流式大數(shù)據(jù)處理系統(tǒng)及其基準(zhǔn)測(cè)試框架的研究已經(jīng)成為了一個(gè)熱點(diǎn)問(wèn)題.

現(xiàn)今已有多種流式大數(shù)據(jù)基準(zhǔn)測(cè)試框架,如Yahoo!Streaming Benchmark[9]和HiBench[10]等.但Yahoo!Streaming Benchmark 應(yīng)用場(chǎng)景單一,覆蓋程度較低;HiBench 僅能夠支持簡(jiǎn)單流式數(shù)據(jù),本質(zhì)仍是一個(gè)批式大數(shù)據(jù)基準(zhǔn)測(cè)試框架.因此,現(xiàn)有流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架仍存在不足,比如應(yīng)用場(chǎng)景的設(shè)計(jì)較為簡(jiǎn)單,評(píng)價(jià)指標(biāo)選取上較為單一,集中在吞吐量和延遲等.

針對(duì)現(xiàn)有流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架的不足和面臨的挑戰(zhàn),本文設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)股票交易場(chǎng)景下的流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架.該框架包括流式數(shù)據(jù)生成方法、應(yīng)用場(chǎng)景構(gòu)造和評(píng)價(jià)指標(biāo)3 個(gè)部分,以Socket 作為流式數(shù)據(jù)源,選取真實(shí)的股票交易數(shù)據(jù)構(gòu)造了三個(gè)數(shù)據(jù)流,具體應(yīng)用覆蓋GroupBy 操作和Join 操作,并選取延遲、吞吐量、GC 時(shí)間和CPU利用率作為評(píng)價(jià)指標(biāo),構(gòu)建了一個(gè)實(shí)時(shí)計(jì)算與結(jié)構(gòu)化數(shù)據(jù)相結(jié)合的場(chǎng)景.此外,本文還針對(duì)數(shù)據(jù)輸入速率和執(zhí)行器內(nèi)核數(shù)量設(shè)計(jì)了兩個(gè)實(shí)驗(yàn),在Apache Spark Streaming 中對(duì)該框架進(jìn)行實(shí)際的集群測(cè)試,對(duì)測(cè)試結(jié)果進(jìn)行分析并得出結(jié)論,分析系統(tǒng)性能表現(xiàn),同時(shí)發(fā)現(xiàn)大數(shù)據(jù)處理系統(tǒng)存在的問(wèn)題,并分析瓶頸所在,從而盡大可能地減少實(shí)際運(yùn)行過(guò)程中可能出現(xiàn)的故障.本文的主要貢獻(xiàn)如下:

(1)總結(jié)了現(xiàn)有流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架特點(diǎn)及其不足.

(2)提出了一種流式數(shù)據(jù)生成方法,并使用多種測(cè)試指標(biāo)進(jìn)行結(jié)果評(píng)測(cè).

(3)設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)基于股票交易場(chǎng)景的流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架.

(4)應(yīng)用流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架對(duì)Apache Spark Streaming 進(jìn)行性能測(cè)試,發(fā)現(xiàn)并分析系統(tǒng)的不足.

1 相關(guān)工作

不同于批式大數(shù)據(jù)處理,流式大數(shù)據(jù)處理起步較晚,目前在業(yè)內(nèi)并沒有統(tǒng)一的基準(zhǔn)測(cè)試標(biāo)準(zhǔn).現(xiàn)有的流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架的相關(guān)研究如下.

Hesse 和Lorenz[11]從體系結(jié)構(gòu)等方面對(duì)比了Apache Storm、Flink、Spark Streaming 和Samza platforms.Gradvohl 等人[12]從系統(tǒng)容錯(cuò)方面分析對(duì)比了Google Millwheel[13]、Yahoo Apache S4[14]、Spark Streaming 和Storm.然而,這兩篇文獻(xiàn)僅限于概念性討論,沒有實(shí)驗(yàn)性的定量性能評(píng)估.Nabi 等人[15]提出了一個(gè)基準(zhǔn)測(cè)試,測(cè)量Apache Spark 和Apache Storm 的延遲和吞吐量,為流處理平臺(tái)的實(shí)驗(yàn)比較創(chuàng)造了第一步.Dayarathna 和Suzumura[16]使用基準(zhǔn)測(cè)試比較了3 個(gè)流處理系統(tǒng)的吞吐量、CPU 和內(nèi)存消耗以及網(wǎng)絡(luò)使用情況.

此外,部分流式大數(shù)據(jù)處理系統(tǒng)的開發(fā)廠商選擇了自己認(rèn)為有代表性、能驗(yàn)證系統(tǒng)功能性的應(yīng)用場(chǎng)景進(jìn)行測(cè)試.如Yahoo!開發(fā)的分布式流計(jì)算平臺(tái)S4 選取了廣告點(diǎn)擊率計(jì)算(Click-Through Rate)進(jìn)行性能驗(yàn)證,以測(cè)試S4 處理流式數(shù)據(jù)的極限[2].Apache Storm 選取一個(gè)簡(jiǎn)單的應(yīng)用,統(tǒng)計(jì)了不同應(yīng)用下參與的用戶數(shù),并測(cè)試其在故障下的表現(xiàn)[17].Apache Spark Streaming 僅對(duì)Grep、WordCount、TopKCount 這3 個(gè)常見應(yīng)用的吞吐量和故障恢復(fù)能力進(jìn)行測(cè)試.應(yīng)用場(chǎng)景簡(jiǎn)單以及流式計(jì)算特征的覆蓋率低使得這些測(cè)試框架無(wú)法全面的剖析流式大數(shù)據(jù)處理系統(tǒng)所面臨的性能及可靠性問(wèn)題.

現(xiàn)有的針對(duì)多種流式大數(shù)據(jù)處理系統(tǒng)的基準(zhǔn)測(cè)試框架,其測(cè)試系統(tǒng)大多以Apache Storm、Apache Spark 和Apace Flink 為主.例如Lopez 等人[18]提出了一個(gè)針對(duì)Apache Storm、Apache Spark 和Apace Flink的基準(zhǔn)測(cè)試框架,測(cè)試了3 個(gè)系統(tǒng)在節(jié)點(diǎn)故障情況下的吞吐量.Karimov 等人[19]提出了一個(gè)分布式流處理引擎基準(zhǔn)測(cè)試框架,對(duì)Apache Storm、Apache Spark 和Apache Flink 的性能進(jìn)行評(píng)估,并定義和測(cè)試流式大數(shù)據(jù)處理系統(tǒng)的可持續(xù)性能.由Yahoo!的一個(gè)團(tuán)隊(duì)設(shè)計(jì)并實(shí)現(xiàn)的Yahoo! Streaming Benchmark 通過(guò)Kafka 和Redis 進(jìn)行數(shù)據(jù)檢索和存儲(chǔ),對(duì)Apache Storm、Apache Spark 和Apace Flink 進(jìn)行實(shí)驗(yàn),測(cè)量了延遲和吞吐量[9].Perera 等人使用Yahoo! Streaming Benchmark 和Karamel[20]在云環(huán)境中提供Apache Spark 和Apache Flink 的可復(fù)制批處理和流基準(zhǔn)[21].但Yahoo! Streaming Benchmark 在應(yīng)用場(chǎng)景上覆蓋度較低,且只支持一個(gè)工作負(fù)載.

綜上所述,現(xiàn)有的流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架還存在各種不足,應(yīng)用用場(chǎng)景設(shè)計(jì)較為簡(jiǎn)單,評(píng)價(jià)指標(biāo)選取上較為單一,集中在吞吐量和延遲.針對(duì)現(xiàn)有的流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架存在的不足,本文構(gòu)造了股票高頻交易場(chǎng)景,并選擇延遲、吞吐量、GC 時(shí)間和CPU 利用率作為評(píng)價(jià)指標(biāo).

2 流式大數(shù)據(jù)系統(tǒng)基準(zhǔn)測(cè)試框架設(shè)計(jì)與實(shí)現(xiàn)

本文基于流式大數(shù)據(jù)及其特征,設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架,包括流式數(shù)據(jù)生成方法、應(yīng)用場(chǎng)景構(gòu)造和評(píng)價(jià)指標(biāo).

通過(guò)流式數(shù)據(jù)生成方法,生成符合流式特征的股票交易數(shù)據(jù);通過(guò)應(yīng)用場(chǎng)景構(gòu)造,構(gòu)建一個(gè)股票交易場(chǎng)景用于系統(tǒng)測(cè)試;通過(guò)明確測(cè)試評(píng)價(jià)指標(biāo),收集并分析指標(biāo)數(shù)據(jù),從而分析系統(tǒng)性能并得出測(cè)試結(jié)論.基準(zhǔn)測(cè)試系統(tǒng)架構(gòu)圖如圖1 所示.

圖1 基準(zhǔn)測(cè)試系統(tǒng)架構(gòu)圖

2.1 流式數(shù)據(jù)生成方法

一般的批式大數(shù)據(jù)可以預(yù)先產(chǎn)生和存儲(chǔ),使用方便.而由于流式計(jì)算的有界性和實(shí)時(shí)性等特點(diǎn),數(shù)據(jù)生成需提供實(shí)時(shí)、高速的流式數(shù)據(jù),從而通過(guò)測(cè)試發(fā)現(xiàn)系統(tǒng)的瓶頸,保證基準(zhǔn)測(cè)試的有效性,這些都對(duì)流式大數(shù)據(jù)的生成方式提出了更為嚴(yán)格的要求.

Apache Spark Streaming 提供了兩種數(shù)據(jù)源,基礎(chǔ)數(shù)據(jù)源和高級(jí)數(shù)據(jù)源.基礎(chǔ)數(shù)據(jù)源是Streaming API 中直接提供的數(shù)據(jù)源,如socket 套接字、文件系統(tǒng)等.高級(jí)數(shù)據(jù)源是通過(guò)第三方類提供支持,如Kafka、Flume、Kinesis、Twitter 等.由于使用第三方工具生成數(shù)據(jù)本身會(huì)對(duì)性能有所影響[22],因此本文選用基礎(chǔ)的Socket傳輸方式作為Apache Spark Streaming 的數(shù)據(jù)源.Socket傳輸方式可通過(guò)程序控制向指定端口發(fā)送數(shù)據(jù),并可以通過(guò)調(diào)節(jié)參數(shù)改變數(shù)據(jù)的傳輸速度,以生成不同流速的流式大數(shù)據(jù).

針對(duì)股票高頻交易這一應(yīng)用場(chǎng)景,本文選擇了現(xiàn)實(shí)的股票交易數(shù)據(jù)作為數(shù)據(jù)源,主要涉及的數(shù)據(jù)類型為數(shù)值型和字符型,方便進(jìn)行流式SQL 的計(jì)算.

2.2 應(yīng)用場(chǎng)景構(gòu)造

流式計(jì)算的應(yīng)用場(chǎng)景有很多,其中比較典型的是在金融銀行業(yè)的應(yīng)用.在金融銀行領(lǐng)域的日常運(yùn)營(yíng)過(guò)程中往往會(huì)產(chǎn)生大量的實(shí)時(shí)數(shù)據(jù),需要對(duì)這些海量數(shù)據(jù)進(jìn)行實(shí)時(shí)分析處理以獲得其內(nèi)在價(jià)值,從而幫助金融銀行進(jìn)行分析決策[23].其中本文選取的股票的高頻交易就是流式處理系統(tǒng)在金融銀行業(yè)的一個(gè)應(yīng)用.

(1)數(shù)據(jù)流構(gòu)造

實(shí)驗(yàn)構(gòu)建了一個(gè)股票交易數(shù)據(jù)分析的場(chǎng)景,在滿足實(shí)際生產(chǎn)生活要求的同時(shí),盡可能多地覆蓋流式計(jì)算特征.股票交易數(shù)據(jù)分析場(chǎng)景涉及3 個(gè)數(shù)據(jù)流:股票變化流、用戶交易流和用戶持倉(cāng)流,如表1 所示.

表1 數(shù)據(jù)流設(shè)計(jì)

STOCK 是股票變化流,用于描述不同時(shí)間點(diǎn)股票的價(jià)格情況.其中,szcode 代表股票編號(hào),eventTime 代表當(dāng)前時(shí)間,lastPrice 代表當(dāng)前價(jià)格.

TRANSACTION 是股票交易流,用于描述不同時(shí)間點(diǎn)股票交易情況.其中,szcode 代表交易的股票編號(hào),userID 代表用戶編號(hào),eventTime 代表交易時(shí)間,Turnover 代表成交量,Price 代表成交價(jià)格.

POSITION 是用戶持倉(cāng)流,用于描述不同時(shí)間點(diǎn)用戶股票持倉(cāng)情況.其中,userID 代表用戶編號(hào),szcode代表該用戶持有的股票編號(hào),lastPrice 代表上次成交價(jià)格,openInterest 代表持倉(cāng)量.

(2)具體應(yīng)用構(gòu)造

本文主要實(shí)現(xiàn)了對(duì)GroupBy 和Join 應(yīng)用的覆蓋,設(shè)計(jì)如下:

1)GroupBy

GroupBy 是Apache Spark 中基本、常見的API,相當(dāng)于SQL 查詢中的groupby()函數(shù).實(shí)驗(yàn)中實(shí)時(shí)獲取用戶交易流的數(shù)據(jù),并按照股票編號(hào)這一字段進(jìn)行聚合,計(jì)算每只股票在一段時(shí)間內(nèi)的總成交額.

# SQL Query (GroupBy)

#實(shí)時(shí)計(jì)算n 分鐘內(nèi)每只股票的成交額.

SELECT szcode,SUM(Price*Turnover)

FROM TRANSACTION [Range n,Slide s]

GROUP BY szcode

2)Join

實(shí)驗(yàn)中對(duì)股票變化流和用戶持倉(cāng)流進(jìn)行Join 操作,按照股票編號(hào)進(jìn)行連接,實(shí)現(xiàn)對(duì)各個(gè)用戶持倉(cāng)股票市值的實(shí)時(shí)計(jì)算.

# SQL Query (Join)

#每個(gè)用戶所持股票的市值(用戶持有量*當(dāng)前價(jià)格)

SELECT c.userID,SUM(lastPrice* openInterest)

FROM POSITION[Range n,Slide s] as p,STOCK[Range n,Slide s] as s,

ON p.szcode = s.szcode

GROUP BY p.userID

Join 可以建立不同數(shù)據(jù)流之間的連接,是大數(shù)據(jù)計(jì)算中的高級(jí)特性,復(fù)雜且代價(jià)大,但大多數(shù)場(chǎng)景都需要進(jìn)行復(fù)雜的Join 操作.

Spark Streaming 會(huì)將逐條采集的數(shù)據(jù)按照事先設(shè)置好的批處理間隔匯總成一批數(shù)據(jù)進(jìn)行處理,Join 操作是在每一個(gè)批數(shù)據(jù)上進(jìn)行的,因此可通過(guò)對(duì)批處理間隔的合理設(shè)置避免Join 操作造成的運(yùn)算復(fù)雜度較高.

2.3 評(píng)價(jià)指標(biāo)

針對(duì)流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試中評(píng)價(jià)指標(biāo)單一的問(wèn)題,本文通過(guò)延遲、吞吐量、GC 時(shí)間等個(gè)方面對(duì)流式大數(shù)據(jù)處理系統(tǒng)進(jìn)行評(píng)價(jià).

延遲(Latency)是流式大數(shù)據(jù)處理中的一項(xiàng)常見且重要的指標(biāo),表示在處理過(guò)程中由于網(wǎng)絡(luò)或者計(jì)算產(chǎn)生的時(shí)間差.一般可以將延遲分為系統(tǒng)延遲和事件延遲[11].本文將延遲定義為數(shù)據(jù)從源段到輸出端所經(jīng)歷的非計(jì)算時(shí)間.

吞吐量(Throughput)是系統(tǒng)在單位時(shí)間內(nèi)的數(shù)據(jù)處理量.本文通過(guò)計(jì)算單位時(shí)間內(nèi)數(shù)據(jù)源端輸出的數(shù)據(jù)總量作為系統(tǒng)的吞吐量.

GC 時(shí)間(GC time)是系統(tǒng)執(zhí)行過(guò)程中垃圾回收機(jī)制的執(zhí)行時(shí)間.垃圾回收即遍歷應(yīng)用程序在Heap 上動(dòng)態(tài)分配的所有對(duì)象,識(shí)別那些已經(jīng)死亡即不再被引用的對(duì)象,將該對(duì)象占用的內(nèi)存空間回收.垃圾回收的開銷是流式大數(shù)據(jù)處理系統(tǒng)內(nèi)存管理需要考慮的因素之一,本文通過(guò)GC 執(zhí)行時(shí)間衡量.

CPU 資源(CPU resources)即系統(tǒng)運(yùn)行時(shí)的CPU 使用率.

Apache Spark Streaming 提供了Web UI 界面,在任務(wù)執(zhí)行過(guò)程中,可以實(shí)時(shí)查詢?nèi)蝿?wù)運(yùn)行情況,便于測(cè)試指標(biāo)的查看和收集.本文借助Apache Spark Streaming提供的API 接口,實(shí)時(shí)收集運(yùn)行時(shí)的延遲、吞吐量、GC 時(shí)間等評(píng)價(jià)指標(biāo)數(shù)據(jù),并以此進(jìn)行實(shí)驗(yàn)分析.

3 實(shí)驗(yàn)驗(yàn)證

本節(jié)對(duì)基于Apache Spark Streaming 實(shí)現(xiàn)的股票交易場(chǎng)景下的應(yīng)用進(jìn)行了以下兩組測(cè)試:(1)測(cè)試數(shù)據(jù)輸入速率對(duì)系統(tǒng)性能的影響;(2)測(cè)試執(zhí)行器內(nèi)核數(shù)量對(duì)系統(tǒng)性能及擴(kuò)展性的影響.通過(guò)對(duì)測(cè)試結(jié)果的分析,總結(jié)了系統(tǒng)的在不同的測(cè)試參數(shù)下的性能表現(xiàn).

3.1 實(shí)驗(yàn)環(huán)境

為了模擬流式大數(shù)據(jù)處理系統(tǒng)在現(xiàn)實(shí)中的應(yīng)用,提高大數(shù)據(jù)處理的效率,實(shí)驗(yàn)搭建了集群,部署了分布式計(jì)算環(huán)境用于Apache Spark Streaming 測(cè)試.測(cè)試集群由五臺(tái)機(jī)器組成,包括1 臺(tái)Master 節(jié)點(diǎn)和4 臺(tái)Slave 節(jié)點(diǎn),共20 cores,集群架構(gòu)如圖2 所示,各個(gè)節(jié)點(diǎn)的配置信息如表2 所示.

圖2 集群架構(gòu)圖

表2 測(cè)試集群配置

3.2 實(shí)驗(yàn)設(shè)計(jì)

實(shí)驗(yàn)采用控制變量法,每次改變單一變量測(cè)試系統(tǒng)在不同情況下的性能表現(xiàn),每組進(jìn)行五次測(cè)試,記錄平均值.本文針對(duì)Apache Spark Streaming 設(shè)計(jì)了兩個(gè)實(shí)驗(yàn),從數(shù)據(jù)輸入速率和任務(wù)并發(fā)度兩個(gè)方面考慮.

(1)通過(guò)控制socket 數(shù)據(jù)輸入端的線程休眠時(shí)間,測(cè)試系統(tǒng)輸入端的速率、執(zhí)行時(shí)間、任務(wù)數(shù)、延遲和GC 時(shí)間.

(2)通過(guò)控制每個(gè)執(zhí)行器的內(nèi)核數(shù),改變?nèi)蝿?wù)并發(fā)度,測(cè)試系統(tǒng)的擴(kuò)展性,以及吞吐量、延遲和GC 時(shí)間的影響.

3.3 實(shí)驗(yàn)結(jié)果及結(jié)論

(1)測(cè)試一:數(shù)據(jù)輸入速率對(duì)系統(tǒng)性能的影響

實(shí)驗(yàn)通過(guò)Thread.sleep();函數(shù)控制socket 端向指定端口發(fā)送數(shù)據(jù)的速率,將線程的休眠時(shí)間分別設(shè)為500 毫秒,100 ms,50 ms,10 ms,1 ms 以及0,即每間隔500 ms,100 ms,50 ms,10 ms,1 ms 以及無(wú)間隔地發(fā)送數(shù)據(jù).同時(shí),將數(shù)據(jù)的生成時(shí)間固定為5 min,實(shí)現(xiàn)對(duì)輸入端數(shù)據(jù)速率的控制.測(cè)試一的實(shí)驗(yàn)結(jié)果如表3 所示.

表3 測(cè)試一實(shí)驗(yàn)結(jié)果

通過(guò)實(shí)驗(yàn)數(shù)據(jù)分析,可得結(jié)論如下:

1)發(fā)現(xiàn)一:當(dāng)數(shù)據(jù)輸入速率較高時(shí),系統(tǒng)延遲呈現(xiàn)較大的增長(zhǎng).

實(shí)驗(yàn)記錄了不同速率下的系統(tǒng)總延遲,如圖3 所示.可以發(fā)現(xiàn)隨著速率的增加,系統(tǒng)延遲總體呈上升趨勢(shì)的,這是符合邏輯的.但是在輸入速率較低、相差不大的情況下,系統(tǒng)延遲增加緩慢,控制在一定范圍之內(nèi),而當(dāng)輸入速率較高時(shí),系統(tǒng)延遲會(huì)呈現(xiàn)一個(gè)較大的增長(zhǎng).

2)發(fā)現(xiàn)二:輸入速率的提高會(huì)使系統(tǒng)資源利用率增加.

隨著輸入速率的提高,實(shí)驗(yàn)從GC 時(shí)間和CPU 資源兩個(gè)方面分析了系統(tǒng)資源利用率的變化.

圖3 不同速率下延遲比較

Apache Spark 默認(rèn)會(huì)將每個(gè)執(zhí)行器的60%的內(nèi)存空間用于緩存RDD,則在任務(wù)執(zhí)行期間,只有40%的內(nèi)存空間可以用來(lái)存放創(chuàng)建的對(duì)象.如果創(chuàng)建的對(duì)象過(guò)大,超過(guò)可用的內(nèi)存空間,就會(huì)觸發(fā)java JVM 的垃圾回收機(jī)制.從圖4 中可以看到,隨著輸入速率的提高,系統(tǒng)的GC 執(zhí)行時(shí)間也會(huì)增加,這是因?yàn)檩斎胨俾实奶岣?任務(wù)數(shù)量及創(chuàng)建的對(duì)象也會(huì)增加,從而使GC 執(zhí)行次數(shù)增加,即系統(tǒng)運(yùn)行時(shí)的內(nèi)存占用量增加.

圖4 不同速率下GC 時(shí)間比較

此外,隨著輸入速率的提高,CPU 利用率呈增長(zhǎng)趨勢(shì),CPU 負(fù)載逐步提升.但即使在速度達(dá)到最大時(shí),master節(jié)點(diǎn)CPU 利用率平均為28.71%,最大可達(dá)48.47%,CPU 資源并未得到充分利用.

綜上所述,輸入速率的提高會(huì)使系統(tǒng)資源利用率增加,但在Socket 輸入最大值的情況下,仍未實(shí)現(xiàn)系統(tǒng)資源的充分利用.

3)發(fā)現(xiàn)三:數(shù)據(jù)輸入速率在一定閾值內(nèi),系統(tǒng)性能相對(duì)穩(wěn)定;數(shù)據(jù)輸入速率超過(guò)閾值時(shí),系統(tǒng)性能下降.

通過(guò)對(duì)表3 實(shí)驗(yàn)結(jié)果中的數(shù)據(jù)輸入速率與其他性能指標(biāo)的關(guān)系進(jìn)行分析,可以發(fā)現(xiàn)當(dāng)數(shù)據(jù)輸入速率在19.30 records/s 到92.50 records/s 范圍內(nèi)時(shí),程序執(zhí)行時(shí)間和GC 時(shí)間分別穩(wěn)定在8.5 s 和6 s,任務(wù)數(shù)和延遲波動(dòng)較小.當(dāng)數(shù)據(jù)輸入速率提升到1701.06 records/s時(shí),系統(tǒng)在執(zhí)行時(shí)間、任務(wù)數(shù)、延遲、GC 等性能指標(biāo)的度量上略有增長(zhǎng).然而,當(dāng)數(shù)據(jù)輸入速率上升到46 071.31 records/s 時(shí),系統(tǒng)的執(zhí)行時(shí)間比數(shù)據(jù)輸入速率為1701.06 records/s 時(shí)增長(zhǎng)了1 min,延遲增長(zhǎng)了205 ms,執(zhí)行的任務(wù)數(shù)卻有所減少.由此可以得出結(jié)論:數(shù)據(jù)輸入速率在一定閾值內(nèi)時(shí),系統(tǒng)的整體性能相對(duì)穩(wěn)定;當(dāng)數(shù)據(jù)輸入速率超過(guò)這一閾值時(shí),系統(tǒng)性能會(huì)有所下降.

分析原因?yàn)殡S著輸入速率的提高,系統(tǒng)接收的數(shù)據(jù)越來(lái)越多,系統(tǒng)的數(shù)據(jù)處理能力趨于飽和,甚至可能會(huì)出現(xiàn)計(jì)算過(guò)程中一個(gè)批次花費(fèi)的時(shí)間大于系統(tǒng)設(shè)置的批處理間隔,這意味著數(shù)據(jù)接收速率大于數(shù)據(jù)處理速率,數(shù)據(jù)處理能力降低,系統(tǒng)性能也發(fā)生一定程度下降.但Spark Streaming 系統(tǒng)自身帶有反壓機(jī)制(Back Pressure),即使時(shí)間間隔內(nèi)無(wú)法完全處理當(dāng)前接收的數(shù)據(jù),也不會(huì)導(dǎo)致執(zhí)行器內(nèi)存泄漏.

此外,從圖5 中可以看出,任務(wù)數(shù)除了在速率從3.97 records/s 上升到19.3 records/s 時(shí)出現(xiàn)大幅度增長(zhǎng)外,之后不再隨著數(shù)據(jù)輸入速率的增加發(fā)生較大變化,且在速率達(dá)到最大時(shí)出現(xiàn)下降,可見系統(tǒng)的任務(wù)數(shù)隨著數(shù)據(jù)輸入速率的增加出現(xiàn)瓶頸.

圖5 不同速率下任務(wù)數(shù)變化

(2)測(cè)試二:執(zhí)行器內(nèi)核數(shù)量對(duì)對(duì)系統(tǒng)性能及擴(kuò)展性的影響

執(zhí)行器(executor)是Apache Spark 任務(wù)的執(zhí)行單元,運(yùn)行在worker 上,是一組計(jì)算資源的集合.執(zhí)行器的內(nèi)核(core)數(shù)量可理解為執(zhí)行器的工作線程,實(shí)驗(yàn)通過(guò)改變執(zhí)行器的內(nèi)核數(shù)控制系統(tǒng)的并發(fā)度.

實(shí)驗(yàn)中共系統(tǒng)設(shè)置了4 個(gè)執(zhí)行器,將每個(gè)執(zhí)行器的內(nèi)核個(gè)數(shù)分別設(shè)置為2、4、8 和16,測(cè)試了2 min內(nèi)數(shù)據(jù)接收情況、系統(tǒng)總延遲以及GC 時(shí)間.測(cè)試二實(shí)驗(yàn)結(jié)果如表4 所示.

表4 測(cè)試二實(shí)驗(yàn)結(jié)果

通過(guò)實(shí)驗(yàn)數(shù)據(jù)分析,可得結(jié)論如下:

1)發(fā)現(xiàn)一:執(zhí)行器的內(nèi)核數(shù)對(duì)系統(tǒng)吞吐量影響不大.

在數(shù)據(jù)輸入速率相同的情況下,隨著每個(gè)執(zhí)行器內(nèi)核個(gè)數(shù)的增加,系統(tǒng)在2 min 內(nèi)接收的數(shù)據(jù)整體呈現(xiàn)減少的趨勢(shì),但從圖6 中可以看到,在考慮到網(wǎng)絡(luò)波動(dòng)的情況下,系統(tǒng)接收數(shù)據(jù)的能力相似.因此,系統(tǒng)并發(fā)度的提升對(duì)Apache Spark Streaming 的吞吐量并沒有太大影響.

圖6 不同內(nèi)核數(shù)下的數(shù)據(jù)接收情況

2)發(fā)現(xiàn)二:執(zhí)行器內(nèi)核數(shù)量的增加可降低系統(tǒng)延遲.

結(jié)合結(jié)論一分析,在系統(tǒng)接收的數(shù)據(jù)量相差不大的情況下,隨著每個(gè)執(zhí)行器內(nèi)核個(gè)數(shù)的增加,系統(tǒng)的延遲會(huì)大幅度降低,內(nèi)核數(shù)為16 時(shí)的延遲只有內(nèi)核數(shù)為2 時(shí)的1/3,如圖7 所示.

分析原因?yàn)閧任務(wù)執(zhí)行的并發(fā)度 = 執(zhí)行器的總數(shù)目 * 每個(gè)執(zhí)行器的內(nèi)核數(shù)},當(dāng)每個(gè)執(zhí)行器內(nèi)核數(shù)量增加時(shí),任務(wù)并發(fā)度也會(huì)提高,多任務(wù)的并發(fā)執(zhí)行使得從而使系統(tǒng)延遲大幅度降低.可見系統(tǒng)并行度的提高使得Apache Spark Streaming 系統(tǒng)資源的利用率也隨之提高,系統(tǒng)在延遲上的擴(kuò)展性良好.

圖7 不同內(nèi)核數(shù)下延遲比較

3)發(fā)現(xiàn)三:執(zhí)行器內(nèi)核數(shù)量的增加會(huì)造成系統(tǒng)資源利用率增加.

隨著內(nèi)核數(shù)量的增加,任務(wù)并發(fā)度提高,導(dǎo)致系統(tǒng)GC 時(shí)間增加,如圖8 所示.

圖8 不同內(nèi)核數(shù)下GC 時(shí)間比較

分析原因?yàn)閮?nèi)核數(shù)量的增加提高了任務(wù)并發(fā)度,使得大量的對(duì)象會(huì)被創(chuàng)建,出發(fā)Java 垃圾回收機(jī)制的次數(shù)也會(huì)增加,從而使GC 時(shí)間增加.因此適當(dāng)減少內(nèi)核個(gè)數(shù)也是降低系統(tǒng)GC 開銷的一種方法.

此外,系統(tǒng)并發(fā)度的提高也使得CPU 利用率有所提高,在16 cores 時(shí)CPU 利用率平均為31.05%,最大可達(dá)35.35%.

綜上所述,執(zhí)行器內(nèi)核數(shù)的增加會(huì)提高系統(tǒng)并發(fā)度從而增加系統(tǒng)資源利用率.

4 結(jié)束語(yǔ)

本文設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)流式大數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測(cè)試框架,以Socket 作為流式數(shù)據(jù)生成,構(gòu)造股票高頻交易場(chǎng)景,并實(shí)現(xiàn)了GroupBy 和Join 兩個(gè)典型應(yīng)用,將實(shí)時(shí)計(jì)算與結(jié)構(gòu)化數(shù)據(jù)相結(jié)合.測(cè)試框架搭建在分布式集群環(huán)境下,選取了Apache Spark Streaming 作為待測(cè)系統(tǒng),從數(shù)據(jù)輸入速率和系統(tǒng)并行度兩個(gè)方面設(shè)計(jì)實(shí)驗(yàn),得到延遲、吞吐量、GC 時(shí)間等測(cè)試指標(biāo),以圖表的形式進(jìn)行分析,發(fā)現(xiàn)流式大數(shù)據(jù)處理系統(tǒng)中出現(xiàn)的性能問(wèn)題.實(shí)驗(yàn)結(jié)果表明,隨著數(shù)據(jù)輸入速率的提高,系統(tǒng)性能保持相對(duì)穩(wěn)定,當(dāng)輸入速率達(dá)到一定閾值,系統(tǒng)會(huì)出現(xiàn)性能下降,資源利用率增加的現(xiàn)象;系統(tǒng)并行度的增加對(duì)吞吐量的影響較小,但系統(tǒng)延遲會(huì)大幅度降低,GC 時(shí)間有所增加,提高了系統(tǒng)資源的利用率.

未來(lái)將在以下幾個(gè)方面進(jìn)行深入研究.一是可以將基準(zhǔn)測(cè)試框架應(yīng)用到不同的處理系統(tǒng)中,分析系統(tǒng)之間的差異,進(jìn)行對(duì)比研究.二是對(duì)流式大數(shù)據(jù)處理系統(tǒng)的基準(zhǔn)測(cè)試不再僅限于對(duì)獨(dú)立的系統(tǒng),而是與第三方工具結(jié)合,如使用Kafka、Flume 等高級(jí)數(shù)據(jù)源產(chǎn)生數(shù)據(jù),模擬現(xiàn)實(shí)環(huán)境下的應(yīng)用.