蔣程　王曉桐　張蓉

摘? 要：隨著對數據處理的實時性要求越來越高，分布式流處理系統(tǒng)應運而生。但是在分布式的集群規(guī)模下，各種軟硬件原因導致的故障很難避免的?，F(xiàn)有的相關基準測試主要關注于分布式流處理系統(tǒng)的處理性能，很少對該類系統(tǒng)處理故障的容錯性能進行評測，以至于關鍵應用在系統(tǒng)選型的時候特別艱難。針對分布式流處理系統(tǒng)的容錯性能，本文設計并實現(xiàn)了一套靈活的基準測試框架。最后，本文在開源數據流處理系統(tǒng)Apache Storm和Apache Flink進行了容錯性能的基準測試，驗證定義的測試基準的正確性和有效性，實驗結果也表明Flink的容錯性能相對較好。

關鍵詞：分布式系統(tǒng);流處理;容錯性能;基準測試

中圖分類號：TP302.8? ? ?文獻標識碼：A

Benchmarking for Fault-tolerant Performance in Distributed

Stream Processing Systems

JIANG Cheng，WANG Xiaotong，ZHANG Rong

（School of Data Science and Engineering，East China Normal University，Shanghai 200062，China）

Abstract：With the increasing real-time requirements for data processing，distributed stream processing systems have emerged.However，under the distributed cluster scale，failures caused by various hardware and software problems are inevitable.The existing related benchmarking mainly focus on the performance of the distributed stream processing system during failure-free time，while rarely evaluating the fault-tolerant performance of the system for handling faults.As a result，it is particularly difficult to select a system for mission-critical applications.This paper designs and implements a flexible benchmarking framework tailored for fault-tolerant performance.Finally，benchmarking the fault-tolerant performance of Apache Storm and Apache Flink verifies the correctness and effectiveness of the benchmark defined in this paper.Experimental results show that fault-tolerant performance of Flink outperforms that of Storm.

Keywords：distributed system;stream processing;fault-tolerant performance;benchmarking

1? ?引言（Introduction）

分布式流計算系統(tǒng)[1]（Distributed Stream Processing Systems，DSPS）是對大規(guī)模流數據進行實時處理的系統(tǒng)，主流的開源系統(tǒng)有：Apache Flink[2]、Apache Storm[3]、Apache Spark Streaming[4]等。流計算的常見應用場景有：電商的商品推薦，IoT設備的監(jiān)控預警，銀行的金融欺詐檢測等。流計算應用具有以下特征：①高性能：系統(tǒng)需要對流入的數據進行實時處理，延遲一般在毫秒級別。而且由于數據的不斷流入，計算需要支持很高的吞吐（例如，推特每天處理5億推文，F(xiàn)acebook有14.5億活躍用戶）;②容錯性：因為流數據的無限性，系統(tǒng)的運行需要支持7×24小時服務。在大規(guī)模分布式計算中像節(jié)點故障，網絡錯誤等故障經常發(fā)生。流處理系統(tǒng)需要使用容錯機制來應對故障的發(fā)生。特別是對于金融領域的關鍵應用而言，快速的故障恢復和計算結果的正確性保證尤其重要，否則將會導致嚴重的財力損失。本文提出了一套針對分布式流處理系統(tǒng)容錯性能的基準測試框架。

2? ?相關工作（Related work）

Linear Road Benchmark[5]最早提出了評測流數據管理系統(tǒng)（Stream Data Management Systems，SDMS）[6]的處理能力。它模擬了高速公路管理系統(tǒng)，該系統(tǒng)能通過實時收集處理公路上汽車傳來的位置數據，提供收費、事故檢測和警報等功能。它用于評測Aurora[7]和關系型數據庫管理系統(tǒng)能滿足該公路系統(tǒng)的最大處理吞吐量。StreamBench[8]針對DSPS設計了七個微型（micro）工作負載和四種工作負載套件，設計了兩種真實的應用場景：實時網站日志處理和網絡流量監(jiān)控。它測試了Storm和Spark Streaming的處理性能、穩(wěn)定性和容錯性能。但在容錯性能的評測方面，StreamBench僅僅比較有無故障發(fā)生時的吞吐和延遲。Yahoo！ Streaming Benchmark[9]模擬了廣告分析應用，測試了Flink、Storm和Spark Streaming的延遲和吞吐。RIoTBench[10]設計了IoT應用場景下的相關負載，含有27種IoT相關的微型負載和四種由微型負載合成的應用負載，使用真實的IoT數據集評測了Storm的處理性能。Jeyhun等人[11]提出了針對含有連接和窗口等復雜操作的延遲計算方法，定義了系統(tǒng)的最大可持續(xù)吞吐量。它模擬了在線視頻游戲應用的相關工作負載，評測了Flink、Storm和Spark Streaming三個系統(tǒng)的處理性能。Steffen等人[12]通過廣告分析、公路管理和出租車業(yè)務查詢這三種工作負載的測試，對比分析了Flink、Storm和Spark Streaming的性能瓶頸。它提出當前的分布式流處理系統(tǒng)存在沒有充分利用硬件資源的問題，并提出了優(yōu)化的設計方案。

現(xiàn)有的DSPS基準測試相關信息統(tǒng)計如表1所示。目前大家關注的還是在系統(tǒng)無錯情況下DSPS的處理性能，而沒有對容錯機制和性能影響做深度調查和研究。StreamBench雖然涉及了容錯度量，但它只是通過性能指標的變化很粗略地估計故障對性能帶來的影響。本文第一次以評測DSPS的容錯機制作為研究對象，定義和實現(xiàn)了考察這些容錯機制關鍵因素的benchmark和測試框架，并定義了評測故障恢復機制優(yōu)劣的性能指標。該測試框架可以有效地評測不同的容錯技術給系統(tǒng)性能帶來的影響，為不同應用場景下流處理系統(tǒng)的選擇提供依據和參考。

3? ?容錯機制（Fault-tolerant mechanism）

本章節(jié)將介紹本文評測的兩個最典型分布式流處理系統(tǒng)的容錯機制。

3.1? ?Apache Flink

Flink根據分布式快照算法Chandy-Lamport Algorithm[13]設計出了分布式輕量級異步快照機制。Flink會定期地發(fā)送一個柵欄標記到輸入的數據流中，從而把源頭的數據流按段切割成版本遞增的快照。當接收到所有輸入流中的柵欄標記后，算子會對當前版本的計算狀態(tài)進行快照操作，把狀態(tài)持久化存儲到HDFS[14]等可靠的分布式存儲系統(tǒng)。一旦所有的算子都確認完成了快照操作，F(xiàn)link會記錄當前版本的全局一致快照已經完成。在恢復期間，F(xiàn)link首先會重新部署整個計算拓撲;接著每個算子從分布式存儲系統(tǒng)中加載各自最近版本的檢查點快照;然后根據快照的版本，數據源需重發(fā)從最近檢查點時刻到故障發(fā)生時刻的數據，從而保證了Exactly-Once消息處理語義[15]。

3.2? ?Apache Storm

Storm的容錯機制由消息管理機制和快照機制共同完成，保證了At-Least-Once消息處理語義。消息管理機制指Storm會追蹤每條流入系統(tǒng)的數據，為其后續(xù)生成的子消息維護一個“消息樹”。當且僅當子消息都被成功處理，消息樹才會被判定為成功處理。否則，系統(tǒng)會重發(fā)對應的輸入源消息。快照機制指Storm會將算子的計算狀態(tài)進行持久化保存。與Flink的容錯機制類似，Storm會定期向數據流中插入“快照事務”的消息;算子接收到快照事務消息后觸發(fā)準備操作與提交操作：收到“準備”事務消息時，算子將當前版本的狀態(tài)臨時持久化;收到“提交”事務消息時，算子將當前版本的狀態(tài)持久化，并刪除臨時狀態(tài)。在恢復期間，算子的狀態(tài)會根據故障發(fā)生時的快照事務狀態(tài)做出相應的恢復。如果快照事務處于“正在準備”狀態(tài)，由于部分算子并沒有臨時持久化準備階段的狀態(tài)，則所有算子回滾至最近穩(wěn)定的快照版本;如果快照事務處于“正在提交”狀態(tài)，由于所有算子都已經臨時持久化準備階段的狀態(tài)，則所有算子繼續(xù)原來的計算任務。故障導致未完全處理的消息會因為消息超時或者算子主動發(fā)送失敗消息而標記成失敗狀態(tài)，由消息管理機制負責重發(fā)。

4? ?基準測試框架（Benchmarking framework）

本章節(jié)介紹本文的基準評測設計，主要按包含的三個部分：容錯相關的度量定義，速率可控的數據實時生成，特征可控的負載設計。評測框架如圖1所示，包括如下四個部分：①數據生成器負責按給定速率實時生成流數據。該框架中的數據生成主要指控制數據流的產生流量和數據分布特征，從而改變DSPS的計算節(jié)點處理量。數據集包括兩類：一是下載的公共數據集，二是合成數據集。②消息隊列Kafka負責輸入數據和結果的存儲。Kafka作為本文的消息傳輸組件，不僅負責實時傳輸生成的數據至DSPS中進行消費，還負責存儲計算產生的結果消息。③DSPS負責運行拓撲任務。DSPS根據負載配置，如算子并行度、狀態(tài)大小等參數，在集群上生成并運行分布式測試工作負載。④度量收集器負責收集并統(tǒng)計度量指標。度量收集器具有獲取集群的資源利用情況、獲取DSPS的實時吞吐和獲取延遲信息并進行統(tǒng)計等功能。

4.1? ?度量定義

根據流計算和容錯機制的特性，我們設計三個相關度量：延遲、資源利用率、故障恢復時間。

延遲：本文采用的是事務時間的延遲。數據產生的時候，該數據會存儲產生時刻的時間戳，這個時間戳稱為生產時間。輸入DSPS系統(tǒng)的數據稱為原始數據。經過DSPS運算，原始數據可能產生多個子數據，子數據的生產時間按照原始數據的生產時間不變。輸出時間定義為子數據經過DSPS計算處理后時間，但是不包含結果傳輸時間。這為了防止由結果存儲組件的不合理配置，性能瓶頸等原因可能造成因傳輸導致延遲增大的問題。一條數據的生產時間和輸出時間差稱為這條數據的事務時間延遲，如圖2所示。

每個元組延遲計算公式：

指結果算子接收到該元組的時間，指數據生成器生成該元組的時間。如果一條元組經過計算產生多個子元組，那么子元組的跟產生該元組的原始元組相同。本文指的延遲是所有元組延遲的平均值。

資源利用率：容錯機制對狀態(tài)的存儲，傳輸等操作會給系統(tǒng)帶來額外的資源使用。本文關注于節(jié)點在任務運行時間段內的平均CPU使用率。

故障恢復時間：本文通過軟件的方法實現(xiàn)在節(jié)點中隨機終止DSPS的運算進程從而達到模擬故障的效果。故障發(fā)生時間定義為故障腳本的啟動時間。故障恢復時間可從宏觀和微觀的角度進行定義。宏觀的角度指：從故障發(fā)生到系統(tǒng)的吞吐恢復到正常數值（無故障情況下）的時間;微觀的角度指：故障恢復時間可具體劃分為重載時間和重播時間。重載時間指從故障發(fā)生后到算子經過重新部署并且從存儲系統(tǒng)中重載快照數據所花費的時間，重播時間指數據源重播到故障前消費的數據所花費的時間。從故障發(fā)生的時刻到系統(tǒng)恢復故障前狀態(tài)的時刻，這一時間段稱為故障恢復時間，如圖3所示。

根據上述定義，在Flink中，故障恢復時間從微觀角度按故障發(fā)生的時間到數據源重新處理到故障前的數據時間計算;而在Storm中，由于快照機制和消息重播機制分離，故障恢復時間只能從宏觀角度按故障發(fā)生的時間到數據源的吞吐恢復穩(wěn)定的時間計算。

4.2? ?數據集與工作負載

本章節(jié)抽象出數據流的數據特征和有狀態(tài)負載的特征，通過調控特征參數，可以模擬并控制系統(tǒng)工作負載。

4.2.1? ?輸入數據流特征

數據流數據本身有三個可調控的特征參數。

輸入速率：為了使系統(tǒng)運行在穩(wěn)定的狀態(tài)，本文控制一個穩(wěn)定并且合適的數據生產速率，防止系統(tǒng)負載過高進入反壓狀態(tài)[16]。

數據傾斜度：數據傾斜是數據集中常見的特性。不均勻的數據分布將會導致大量數據集中在某些節(jié)點，造成節(jié)點的運算負荷不同。本文按Zipf定律生成數據傾斜的合成數據集。

輸入數據大?。簲祿骶哂袩o限性，但是根據實驗需求，可根據輸入的吞吐速率和運行時間修改原始數據集大小，計算公式如下：

其中，L是修改后的數據集總量，P是設定的輸入吞吐速率（條/秒），T是任務運行的時間（秒）。

本文內置數據集含有兩種：第一種是從古登堡計劃（Project Gutenberg）獲取的英文小說集;第二種是根據數據傾斜程度生成的合成數據集。數據生成器根據配置的輸入吞吐速率，實時從數據集中獲取數據并輸入到Kafka中，模擬生產環(huán)境中的實時數據生成。

4.2.2 工作負載設計

本文設計了兩類工作負載：①計算簡單、狀態(tài)大小可調控的Word Count負載[17];②狀態(tài)大小固定、計算密集程度可調控的圓周率計算負載。工作負載的特征如圖4所示。通過分析有狀態(tài)計算的特征，本文的工作負載設有兩個可調控的特征參數。

算子的狀態(tài)大?。河绊懘鎯蛡浞菁磎emory和磁盤

I/O。算子分為有狀態(tài)計算和無狀態(tài)計算。無狀態(tài)計算指不需要依賴歷史數據進行計算的算子，如切分算子，只需對當前數據進行分詞操作。有狀態(tài)計算指當前計算需要根據歷史數據進行計算，如窗口算子，計算需要對到達窗口內的所有數據或者計算的中間結果值等狀態(tài)進行聚合計算或者更新。為了防止因為故障導致狀態(tài)的丟失，保證恢復后計算的準確性，有狀態(tài)的算子需要對狀態(tài)進行持久化存儲。本文使用全歷史計算而不使用窗口算子，因為窗口算子的狀態(tài)大小不可控。在DSPS中，連接操作需要使用窗口算子，本文也不使用。在窗口算子中，觸發(fā)checkpoint操作的時間點在窗口內呈現(xiàn)無規(guī)則分布，這種現(xiàn)象導致每次實驗中checkpoint保存的狀態(tài)大小不一致，無法通過控制變量法研究狀態(tài)大小和checkpoint間隔對系統(tǒng)帶來的影響。本文在2號算子中根據配置參數進行自定義大小的字符串類型狀態(tài)存儲，保證每次存儲的狀態(tài)大小一致，從而研究不同狀態(tài)大小和checkpoint間隔對系統(tǒng)的影響。

算子的計算密集程度：影響CPU。本文研究不同計算密集型的算子受checkpoint操作的影響。本文設計狀態(tài)大小固定的圓周率計算算子，通過傳入配置參數實現(xiàn)控制2號算子中格雷戈里-萊布尼茨級數的運算次數，以此來調控該算子的計算密集程度。格雷戈里-萊布尼茨級數的計算公式如下：

本文通過對抽象出的兩個特征的調控，可以模擬出其他工作負載的特征，比如含有窗口操作的負載需要對到達窗口內的所有數據進行保存，存儲狀態(tài)較大;含有連接操作的負載需要對多條輸入流進行連接操作，連接算子的運算密集程度大，并且需要對多條流的數據都進行保存，存儲狀態(tài)較大。

5? ?實驗（Evaluation）

5.1? ?實驗環(huán)境

本文的實驗在具有五個節(jié)點的集群上進行，節(jié)點的操作系統(tǒng)版本是CentOS v.6.5。測試平臺為Apache Flink 1.7.0，Apache Storm 1.2.2。其中一個節(jié)點配置為24核Intel（R）Xeon（R）CPU E5-2620、頻率2.40GHz、內存31GB，部署非計算組件，如HDFS、Zookeeper、Redis等服務。其余四個節(jié)點配置為8核Intel（R）Xeon（R）CPU E5606，頻率2.13GHz，內存94GB，部署計算組件，如Flink中的Taskmanager，Storm中的Worker等計算進程。計算組件和非計算組件的分開部署能提高度量指標的準確性，如資源利用率。節(jié)點之間通過千兆以太網連接。默認的數據輸入吞吐速率為5000條/秒;數據集使用真實的英文小說集。

5.2? ?無故障性能評測

系統(tǒng)在未發(fā)生故障的時候，容錯機制對性能的影響源自周期性地進行的快照操作，對計算產生的中間狀態(tài)進行持久化存儲。Checkpoint操作的頻率和持久化的狀態(tài)大小均是影響系統(tǒng)性能的重要因素。本組實驗研究不同狀態(tài)大小和checkpoint間隔對延遲和CPU使用率的影響。

從圖5（a）和圖5（b）中可以看出，在Flink中，當狀態(tài)大小保持一致時，checkpoint間隔越短，計算的延遲越大，系統(tǒng)的CPU消耗越多。因為越頻繁的checkpoint操作會導致系統(tǒng)花費更多的資源在狀態(tài)處理上，使得正常的計算暫停的時間越多;當checkpoint間隔保持一致時，狀態(tài)越大，計算的延遲越大，系統(tǒng)的CPU消耗越多。因為狀態(tài)越大，每次對狀態(tài)的持久化操作所需時間更久，對性能造成的影響更大。在Storm平臺上1秒的checkpoint間隔過于頻繁并且較大的狀態(tài)會嚴重影響系統(tǒng)的性能，導致其無法正常運行。故checkpoint間隔始于30s。從圖5（c）和圖5（d）中可以看出，在Storm中，checkpoint間隔的影響和Flink稍有不同。Storm的容錯機制對系統(tǒng)處理的影響主要有兩種操作。第一種操作是對狀態(tài)的存儲，該操作造成的延遲受狀態(tài)大小的影響;第二種是對checkpoint間隔時間內緩存的元組進行消息管理操作，該操作造成的延遲受checkpoint間隔的影響。狀態(tài)較小時（0—5MB）第一種操作的延遲影響比第二種操作小。狀態(tài)較大時（5—15MB）第二種操作的延遲影響比第一種操作小。CPU使用率變化趨勢也是類似的情況，但是平衡點在10MB左右。關于狀態(tài)的影響，當checkpoint間隔保持一致時，狀態(tài)與延遲和CPU使用率成線性關系。因為狀態(tài)越大，狀態(tài)持久化的操作所花費的時間越久，使得正常運算的延遲增大。

觀察Flink和Storm該組實驗，如狀態(tài)大小為10MB，checkpoint間隔為30s時，F(xiàn)link的延遲比Storm低，而且CPU使用率也更低。

Flink通過柵欄的對齊操作來保證Exactly-Once消息處理語義。本文通過生成合成數據來模擬數據傾斜程度的不同，圖6反應不同柵欄到達時間對延遲的影響。本組實驗的研究參數：checkpoint模式為NCP（不開啟checkpoint）、CP+NA（開啟30秒間隔的checkpoint，但是不開啟對齊操作）和CP+A（開啟30秒間隔的checkpoint，并且開啟對齊操作）。

從圖6可以看出，在數據傾斜度較大時，對齊操作對延遲的影響很大。這是因為在數據傾斜程度均勻的時候，每個算子的多個輸入通道中的柵欄到達時間相近，對齊操作導致的堵塞時間較少，所以延遲無明顯增大。但是在數據傾斜程度較大的時候，因為一個算子含有多個輸入通道時，數據量較少的低負載通道中的柵欄會先到達。這時對齊操作會堵塞已到達柵欄的通道，等到數據量較多的高負載通道中的柵欄。不同通道的柵欄到達時間相差越大將會導致該算子的同步堵塞操作時間越長，最終延遲會因此增大。

圖7展示負載計算密集程度受checkpoint操作的影響。越頻繁的checkpoint操作會導致頻繁的線程調度，切換等問題，負載計算密集程度越高受其干擾的影響越大，最終導致計算的延遲增大。

5.3? ?故障實驗

本文模擬的故障實驗是進程級別的故障。由于程序錯誤、計算資源限制等原因，某個計算進程出錯的概率很大。本文在流計算任務穩(wěn)定運行一段時間后，使用軟件腳本隨機終止某個節(jié)點上的某個計算進程，從而模擬計算進程故障。本組實驗設置的固定條件與上組實驗相同。

Flink的故障恢復時間可以根據恢復階段來劃分成重載時間和重播時間。重載時間指從故障發(fā)生的時間到任務重新部署完成的時間。重播時間指任務部署完成到數據源重新消費到故障發(fā)生前數據時間。從圖8中可以看出，故障恢復時間中重載階段的耗時占比較大。因為系統(tǒng)探測到TaskManager故障的時間跟配置參數心跳超時時間成正相關關系。在默認配置下，重載階段花費約45秒左右，總恢復時間在60秒之內。從圖8（b）中可以看出，狀態(tài)的大小和重播時間成正相關關系。因為在Flink的恢復過程中，算子各自進行恢復操作，狀態(tài)大導致算子的平均恢復時間大，數據源的重發(fā)速率受其影響。

Storm中的恢復時間采用從宏觀的角度評測，根據吞吐隨時間變化情況測量恢復時間，如圖9（a）所示。由于Storm的整體處理性能較低，本組實驗中數據輸入吞吐速率降為500條/秒，

從而保證Storm能正常故障恢復。Storm的故障恢復由消息管理機制與快照機制共同完成，二者相互獨立，且前者對性能的影響占主導因素。Storm恢復故障算子的時候不需要部署整個任務，只需重啟故障的計算進程，這部分操作耗時約在10秒。但是消息重發(fā)階段需要等待消息超時后由消息管理機制負責重發(fā)。本實驗在保證實驗正常運行的情況下，研究不同checkpoint間隔對恢復時間的影響。從圖9（b）中可以看出，checkpoint間隔越大，恢復時間越長。因為checkpoint間隔影響了消息超時的時間，越長的checkpoint間隔導致失敗的消息被判定超時并且重發(fā)的所需時間越久，所以恢復時間越久。

對比Flink和Storm的故障實驗，即使在較高的輸入吞吐和較大的狀態(tài)下，F(xiàn)link的恢復時間更低，并且保證的語義更強，總體性能優(yōu)于Storm。

6? ?結論（Conclusion）

本文提出一種針對分布式流處理系統(tǒng)的容錯性能評測框架，使用真實和模擬的數據集，定義了影響容錯性能的負載特征以及容錯評估指標，評測了Flink和Storm的容錯性能。在非故障期間，對容錯機制對系統(tǒng)的性能影響進行了評測;在故障發(fā)生后，對系統(tǒng)的恢復時間進行了評測。實驗結果表明，F(xiàn)link的容錯機制不僅保證了更高級的處理語義，而且對系統(tǒng)的性能影響較小，故障恢復也更快速。未來，我們將在幾方面開展工作：評測其他分布式流處理系統(tǒng);增加輸入流的相關特征控制，如動態(tài)變化的輸入速率、動態(tài)變化的skew分布，更真實地模擬生產環(huán)境;添加復雜工作負載;加入恢復準確性等評測指標。

參考文獻（References）

[1] Cherniack M，Balakrishnan H，Balazinska M，et al.Scalable Distributed Stream Processing[C].CIDR，2003，3：257-268.

[2] Carbone P，Katsifodimos A，Ewen S，et al.Apache flink：Stream and batch processing in a single engine[J].Bulletin of the IEEE Computer Society Technical Committee on Data Engineering，2015，36（4）：28-38.

[3] Toshniwal A，Taneja S，Shukla A，et al.Storm@ twitter[C].Proceedings of the 2014 ACM SIGMOD international conference on Management of data.ACM，2014：147-156.

[4] Zaharia M，Das T，Li H，et al.Discretized streams：Fault-tolerant streaming computation at scale[C].Proceedings of the twenty-fourth ACM symposium on operating systems principles.ACM，2013：423-438.

[5] Arasu A，Cherniack M，Galvez E，et al.Linear road：a stream data management benchmark[C].Proceedings of the Thirtieth international conference on Very large data bases-Volume 30.VLDB Endowment，2004：480-491.

[6] 金澈清，錢衛(wèi)寧，周傲英.流數據分析與管理綜述[J].軟件學報，2004（08）：1172-1181.

[7] Abadi D J，Carney D，?etintemel U，et al.Aurora：a new model and architecture for data stream management[J].the VLDB Journal，2003，12（2）：120-139.

[8] Lu R，Wu G，Xie B，et al.Stream bench：Towards benchmarking modern distributed stream computing frameworks[C].2014 IEEE/ACM 7th International Conference on Utility and Cloud Computing.IEEE，2014：69-78.

[9] Chintapalli S，Dagit D，Evans B，et al.Benchmarking streaming computation engines：Storm，flink and spark streaming[C].2016 IEEE international parallel and distributed processing symposium workshops （IPDPSW）.IEEE，2016：1789-1792.

[10] Shukla A，Chaturvedi S，Simmhan Y.Riotbench：a real-time iot benchmark for distributed stream processing platforms[J].arXiv preprint arXiv：1701.08530，2017.

[11] Karimov J，Rabl T，Katsifodimos A，et al.Benchmarking distributed stream processing engines[J].arXiv preprint arXiv：1802.08496，2018.

[12] Zeuch S，Monte B D，Karimov J，et al.Analyzing efficient stream processing on modern hardware[J].Proceedings of the VLDB Endowment，2019，12（5）：516-530.

[13] Mattern F.Efficient algorithms for distributed snapshots and global virtual time approximation[J].Journal of parallel and distributed computing，1993，18（4）：423-434.

[14] Shvachko K，Kuang H，Radia S，et al.The hadoop distributed file system[C].MSST，2010，10：1-10.

[15] Lopez M A，Lobato A G P，Duarte O C M B.A performance comparison of open-source stream processing platforms[C].2016 IEEE Global Communications Conference （GLOBECOM）.IEEE，2016：1-6.

[16] 熊安萍，朱恒偉，羅宇豪.Storm流式計算框架反壓機制研究[J].計算機工程與應用，2018，54（1）：102-106.

[17] Ranger C，Raghuraman R，Penmetsa A，et al.Evaluating MapReduce for multi-core and multiprocessor systems[C].hpca.2007，7（3）：19.

作者簡介：

蔣? ?程（1995-），男，碩士生.研究領域：數據流基準測試.

王曉桐（1994-），女，博士生.研究領域：分布式數據流處理，數據流基準測試.

張? 蓉（1978-），女，博士，教授.研究領域：分布式數據管理.本文通訊作者.