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

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

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

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