大規(guī)模流計(jì)算系統(tǒng)的基準(zhǔn)測(cè)試研究.pdf

1、大數(shù)據(jù)正成為一個(gè)熱點(diǎn)名詞被廣泛關(guān)注的同時(shí)，大規(guī)模的流數(shù)據(jù)處理也逐漸興起，涌現(xiàn)出一批分布式流計(jì)算系統(tǒng)。然而流計(jì)算的復(fù)雜性和其應(yīng)用場(chǎng)景的廣泛性給該領(lǐng)域的基準(zhǔn)測(cè)試帶來(lái)很大的挑戰(zhàn)。由于缺乏統(tǒng)一的基準(zhǔn)測(cè)試標(biāo)準(zhǔn)，公正地衡量和比較這些系統(tǒng)困難重重。
　　這篇論文涉足這個(gè)相對(duì)空白的領(lǐng)域。首先，論文指出了在該領(lǐng)域進(jìn)行基準(zhǔn)測(cè)試所需應(yīng)對(duì)的挑戰(zhàn)和所要滿足的必要條件。在此基礎(chǔ)上，該論文給出了自己的基準(zhǔn)測(cè)試標(biāo)準(zhǔn)定義StreamBench。StreamBenc

2、h是一個(gè)概念層面的不依賴具體系統(tǒng)的大規(guī)模流計(jì)算系統(tǒng)的基準(zhǔn)測(cè)試標(biāo)準(zhǔn)，定義包含了數(shù)據(jù)生成方式規(guī)約，程序集選擇，工作流集定義以及度量標(biāo)準(zhǔn)制定。在數(shù)據(jù)生成方式上，StreamBench提出在數(shù)據(jù)生成和數(shù)據(jù)消費(fèi)中間利用一個(gè)消息系統(tǒng)作為中介的方式使得數(shù)據(jù)的生成和消費(fèi)解耦。在程序集合的選擇上，它由流計(jì)算場(chǎng)景中提取的七個(gè)小程序組成，涵蓋了流計(jì)算中比較有代表性的操作。為了衡量除了性能外的諸如故障恢復(fù)能力和持續(xù)響應(yīng)能力等其他指標(biāo)，StreamBench構(gòu)造

3、了四套工作流集針對(duì)系統(tǒng)這些不同的方面進(jìn)行測(cè)量，并且根據(jù)不同的工作流集制定了相應(yīng)的度量標(biāo)準(zhǔn)。
　　最后，筆者在不同大規(guī)模流計(jì)算框架上按照StreamBench的定義將其實(shí)現(xiàn)并進(jìn)行實(shí)驗(yàn)。首先筆者對(duì)比了Apache Spark Streaming和Apache Storm上的各項(xiàng)指標(biāo)的差異，在筆者的實(shí)驗(yàn)環(huán)境和配置下，Spark的吞吐量平均是Storm的5倍左右，但當(dāng)平均每條記錄長(zhǎng)度增大時(shí)，兩者吞吐量的差距會(huì)縮小。Spark的延遲一般在秒

4、級(jí)，而Storm的延遲一般在十幾毫秒以下，但也會(huì)隨著程序復(fù)雜度和輸入數(shù)量級(jí)迅速地提升甚至超過(guò)Spark。單節(jié)點(diǎn)故障對(duì)Spark沒(méi)有明顯的影響，但會(huì)導(dǎo)致Storm的吞吐量下降三分之一，延遲增加了四到五倍。兩個(gè)系統(tǒng)都表現(xiàn)出良好的持續(xù)響應(yīng)能力。另外，筆者還利用StreamBench證實(shí)了Storm版本0.9.3和版本0.9.1相比帶來(lái)的性能提升，在筆者的實(shí)驗(yàn)環(huán)境中，吞吐量平均提升了26％，延遲平均降低了40%。此外，筆者還利用StreamBe