您好,登錄后才能下訂單哦!
本篇內(nèi)容主要講解“Flink與Storm的性能對比”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Flink與Storm的性能對比”吧!
一、背景
Apache Flink 和 Apache Storm 是當前業(yè)界廣泛使用的兩個分布式實時計算框架。其中 Apache Storm(以下簡稱“Storm”)在美團點評實時計算業(yè)務中已有較為成熟的運用,有管理平臺、常用 API 和相應的文檔,大量實時作業(yè)基于 Storm 構(gòu)建。
Apache Storm參考鏈接:http://storm.apache.org/
而 Apache Flink(以下簡稱“Flink”)在近期倍受關(guān)注,具有高吞吐、低延遲、高可靠和精確計算等特性,對事件窗口有很好的支持,目前在美團點評實時計算業(yè)務中也已有一定應用。
Apache Flink參考鏈接:https://flink.apache.org/
為深入熟悉了解 Flink 框架,驗證其穩(wěn)定性和可靠性,評估其實時處理性能,識別該體系中的缺點,找到其性能瓶頸并進行優(yōu)化,給用戶提供最適合的實時計算引擎,我們以實踐經(jīng)驗豐富的 Storm 框架作為對照,進行了一系列實驗測試 Flink 框架的性能。
計算 Flink 作為確?!爸辽僖淮巍焙汀扒『靡淮巍闭Z義的實時計算框架時對資源的消耗,為實時計算平臺資源規(guī)劃、框架選擇、性能調(diào)優(yōu)等決策及 Flink 平臺的建設提出建議并提供數(shù)據(jù)支持,為后續(xù)的 SLA 建設提供一定參考。
Flink 與 Storm 兩個框架對比:
二、測試目標
評估不同場景、不同數(shù)據(jù)壓力下 Flink 和 Storm 兩個實時計算框架目前的性能表現(xiàn),獲取其詳細性能數(shù)據(jù)并找到處理性能的極限;了解不同配置對 Flink 性能影響的程度,分析各種配置的適用場景,從而得出調(diào)優(yōu)建議。
1、測試場景
1)“輸入-輸出”簡單處理場景
通過對“輸入-輸出”這樣簡單處理邏輯場景的測試,盡可能減少其它因素的干擾,反映兩個框架本身的性能。
同時測算框架處理能力的極限,處理更加復雜的邏輯的性能不會比純粹“輸入-輸出”更高。
2)用戶作業(yè)耗時較長的場景
如果用戶的處理邏輯較為復雜,或是訪問了數(shù)據(jù)庫等外部組件,其執(zhí)行時間會增大,作業(yè)的性能會受到影響。因此,我們測試了用戶作業(yè)耗時較長的場景下兩個框架的調(diào)度性能。
3)窗口統(tǒng)計場景
實時計算中常有對時間窗口或計數(shù)窗口進行統(tǒng)計的需求,例如一天中每五分鐘的訪問量,每 100 個訂單中有多少個使用了優(yōu)惠等。Flink 在窗口支持上的功能比 Storm 更加強大,API 更加完善,但是我們同時也想了解在窗口統(tǒng)計這個常用場景下兩個框架的性能。
4)精確計算場景(即消息投遞語義為“恰好一次”)
Storm 僅能保證“至多一次” (At Most Once) 和“至少一次” (At Least Once) 的消息投遞語義,即可能存在重復發(fā)送的情況。
有很多業(yè)務場景對數(shù)據(jù)的精確性要求較高,希望消息投遞不重不漏。Flink 支持“恰好一次” (Exactly Once) 的語義,但是在限定的資源條件下,更加嚴格的精確度要求可能帶來更高的代價,從而影響性能。
因此,我們測試了在不同消息投遞語義下兩個框架的性能,希望為精確計算場景的資源規(guī)劃提供數(shù)據(jù)參考。
2、性能指標
1)吞吐量(Throughput)
單位時間內(nèi)由計算框架成功地傳送數(shù)據(jù)的數(shù)量,本次測試吞吐量的單位為:條/秒。
反映了系統(tǒng)的負載能力,在相應的資源條件下,單位時間內(nèi)系統(tǒng)能處理多少數(shù)據(jù)。
吞吐量常用于資源規(guī)劃,同時也用于協(xié)助分析系統(tǒng)性能瓶頸,從而進行相應的資源調(diào)整以保證系統(tǒng)能達到用戶所要求的處理能力。假設商家每小時能做二十份午餐(吞吐量 20 份/小時),一個外賣小哥每小時只能送兩份(吞吐量 2 份/小時),這個系統(tǒng)的瓶頸就在小哥配送這個環(huán)節(jié),可以給該商家安排十個外賣小哥配送。
2)延遲(Latency)
數(shù)據(jù)從進入系統(tǒng)到流出系統(tǒng)所用的時間,本次測試延遲的單位為:毫秒。
反映了系統(tǒng)處理的實時性。
金融交易分析等大量實時計算業(yè)務對延遲有較高要求,延遲越低,數(shù)據(jù)實時性越強。
假設商家做一份午餐需要 5 分鐘,小哥配送需要 25 分鐘,這個流程中用戶感受到了 30 分鐘的延遲。如果更換配送方案后延遲變成了 60 分鐘,等送到了飯菜都涼了,這個新的方案就是無法接受的。
三、測試環(huán)境
為 Storm 和 Flink 分別搭建由 1 臺主節(jié)點和 2 臺從節(jié)點構(gòu)成的 Standalone 集群進行本次測試。其中為了觀察 Flink 在實際生產(chǎn)環(huán)境中的性能,對于部分測內(nèi)容也進行了 on Yarn 環(huán)境的測試。
1、集群參數(shù)
2、框架參數(shù)
四、測試方法
1、測試流程
1)數(shù)據(jù)生產(chǎn)
Data Generator 按特定速率生成數(shù)據(jù),帶上自增的 id 和 eventTime 時間戳寫入 Kafka 的一個 Topic(Topic Data)。
2)數(shù)據(jù)處理
Storm Task 和 Flink Task (每個測試用例不同)從 Kafka Topic Data 相同的 Offset 開始消費,并將結(jié)果及相應 inTime、outTime 時間戳分別寫入兩個 Topic(Topic Storm 和 Topic Flink)中。
3)指標統(tǒng)計
Metrics Collector 按 outTime 的時間窗口從這兩個 Topic 中統(tǒng)計測試指標,每五分鐘將相應的指標寫入 MySQL 表中。
Metrics Collector 按 outTime 取五分鐘的滾動時間窗口,計算五分鐘的平均吞吐(輸出數(shù)據(jù)的條數(shù))、五分鐘內(nèi)的延遲(outTime - eventTime 或 outTime - inTime)的中位數(shù)及 99 線等指標,寫入 MySQL 相應的數(shù)據(jù)表中。最后對 MySQL 表中的吞吐計算均值,延遲中位數(shù)及延遲 99 線選取中位數(shù),繪制圖像并分析。
2、默認參數(shù)
Storm 和 Flink 默認均為 At Least Once語義。
Storm 開啟 ACK,ACKer 數(shù)量為 1。
Flink 的 Checkpoint 時間間隔為 30 秒,默認 StateBackend 為 Memory。
保證 Kafka 不是性能瓶頸,盡可能排除 Kafka 對測試結(jié)果的影響。
測試延遲時數(shù)據(jù)生產(chǎn)速率小于數(shù)據(jù)處理能力,假設數(shù)據(jù)被寫入 Kafka 后立刻被讀取,即 eventTime 等于數(shù)據(jù)進入系統(tǒng)的時間。
測試吞吐量時從 Kafka Topic 的最舊開始讀取,假設該 Topic 中的測試數(shù)據(jù)量充足。
3、測試用例
1)Identity
Identity 用例主要模擬“輸入-輸出”簡單處理場景,反映兩個框架本身的性能。
輸入數(shù)據(jù)為“msgId, eventTime”,其中 eventTime 視為數(shù)據(jù)生成時間。單條輸入數(shù)據(jù)約 20 B。
進入作業(yè)處理流程時記錄 inTime,作業(yè)處理完成后(準備輸出時)記錄 outTime。
作業(yè)從 Kafka Topic Data 中讀取數(shù)據(jù)后,在字符串末尾追加時間戳,然后直接輸出到 Kafka。
輸出數(shù)據(jù)為“msgId, eventTime, inTime, outTime”。單條輸出數(shù)據(jù)約 50 B。
Identity 流程圖
2)Sleep
Sleep 用例主要模擬用戶作業(yè)耗時較長的場景,反映復雜用戶邏輯對框架差異的削弱,比較兩個框架的調(diào)度性能。
輸入數(shù)據(jù)和輸出數(shù)據(jù)均與 Identity 相同。
讀入數(shù)據(jù)后,等待一定時長(1 ms)后在字符串末尾追加時間戳后輸出。
Sleep 流程圖
3)Windowed Word Count
Windowed Word Count 用例主要模擬窗口統(tǒng)計場景,反映兩個框架在進行窗口統(tǒng)計時性能的差異。
此外,還用其進行了精確計算場景的測試,反映 Flink 恰好一次投遞的性能。
輸入為 JSON 格式,包含 msgId、eventTime 和一個由若干單詞組成的句子,單詞之間由空格分隔。單條輸入數(shù)據(jù)約 150 B。
讀入數(shù)據(jù)后解析 JSON,然后將句子分割為相應單詞,帶 eventTime 和 inTime 時間戳發(fā)給 CountWindow 進行單詞計數(shù),同時記錄一個窗口中最大最小的 eventTime 和 inTime,最后帶 outTime 時間戳輸出到 Kafka 相應的 Topic。
Spout/Source 及 OutputBolt/Output/Sink 并發(fā)度恒為 1,增大并發(fā)度時僅增大 JSONParser、CountWindow 的并發(fā)度。
由于 Storm 對 window 的支持較弱,CountWindow 使用一個 HashMap 手動實現(xiàn),F(xiàn)link 用了原生的 CountWindow 和相應的 Reduce 函數(shù)。
Windowed Word Count 流程圖
五、測試結(jié)果
① Identity 單線程吞吐量
Identity 單線程吞吐量
上圖中藍色柱形為單線程 Storm 作業(yè)的吞吐,橙色柱形為單線程 Flink 作業(yè)的吞吐。
Identity 邏輯下,Storm 單線程吞吐為 8.7萬條/秒,F(xiàn)link 單線程吞吐可達35萬條/秒。
當 Kafka Data 的 Partition 數(shù)為 1 時,F(xiàn)link 的吞吐約為 Storm 的 3.2 倍;當其 Partition 數(shù)為 8 時,F(xiàn)link 的吞吐約為 Storm 的 4.6 倍。
由此可以看出,F(xiàn)link 吞吐約為 Storm 的 3-5 倍。
② Identity 單線程作業(yè)延遲
Identity 單線程作業(yè)延遲
采用 outTime - eventTime 作為延遲,圖中藍色折線為 Storm,橙色折線為 Flink。虛線為 99 線,實線為中位數(shù)。
從圖中可以看出隨著數(shù)據(jù)量逐漸增大,Identity 的延遲逐漸增大。其中 99 線的增大速度比中位數(shù)快,Storm 的 增大速度比 Flink 快。
其中 QPS 在 80000 以上的測試數(shù)據(jù)超過了 Storm 單線程的吞吐能力,無法對 Storm 進行測試,只有 Flink 的曲線。
對比折線最右端的數(shù)據(jù)可以看出,Storm QPS 接近吞吐時延遲中位數(shù)約 100 毫秒,99 線約 700 毫秒,F(xiàn)link 中位數(shù)約 50 毫秒,99 線約 300 毫秒。Flink 在滿吞吐時的延遲約為 Storm 的一半。
③ Sleep吞吐量
Sleep 吞吐量
從圖中可以看出,Sleep 1 毫秒時,Storm 和 Flink 單線程的吞吐均在 900 條/秒左右,且隨著并發(fā)增大基本呈線性增大。
對比藍色和橙色的柱形可以發(fā)現(xiàn),此時兩個框架的吞吐能力基本一致。
④ Sleep 單線程作業(yè)延遲(中位數(shù))
Sleep 單線程作業(yè)延遲(中位數(shù))
依然采用 outTime - eventTime 作為延遲,從圖中可以看出,Sleep 1 毫秒時,F(xiàn)link 的延遲仍低于 Storm。
⑤ Windowed Word Count 單線程吞吐量
Windowed Word Count 單線程吞吐量
單線程執(zhí)行大小為 10 的計數(shù)窗口,吞吐量統(tǒng)計如圖。
從圖中可以看出,Storm 吞吐約為 1.2 萬條/秒,F(xiàn)link Standalone 約為 4.3 萬條/秒。Flink 吞吐依然為 Storm 的 3 倍以上。
⑥ Windowed Word Count Flink At Least Once 與 Exactly Once 吞吐量對比
Windowed Word Count Flink At Least Once 與 Exactly Once 吞吐量對比
由于同一算子的多個并行任務處理速度可能不同,在上游算子中不同快照里的內(nèi)容,經(jīng)過中間并行算子的處理,到達下游算子時可能被計入同一個快照中。這樣一來,這部分數(shù)據(jù)會被重復處理。因此,F(xiàn)link 在 Exactly Once 語義下需要進行對齊,即當前最早的快照中所有數(shù)據(jù)處理完之前,屬于下一個快照的數(shù)據(jù)不進行處理,而是在緩存區(qū)等待。當前測試用例中,在 JSON Parser 和 CountWindow、CountWindow 和 Output 之間均需要進行對齊,有一定消耗。為體現(xiàn)出對齊場景,Source/Output/Sink 并發(fā)度的并發(fā)度仍為 1,提高了 JSONParser/CountWindow 的并發(fā)度。具體流程細節(jié)參見前文 Windowed Word Count 流程圖。
上圖中橙色柱形為 At Least Once 的吞吐量,黃色柱形為 Exactly Once 的吞吐量。對比兩者可以看出,在當前并發(fā)條件下,Exactly Once 的吞吐較 At Least Once 而言下降了 6.3%。
⑦ Windowed Word Count Storm At Least Once 與 At Most Once 吞吐量對比
Windowed Word Count Storm At Least Once 與 At Most Once 吞吐量對比
Storm 將 ACKer 數(shù)量設置為零后,每條消息在發(fā)送時就自動 ACK,不再等待 Bolt 的 ACK,也不再重發(fā)消息,為 At Most Once 語義。
上圖中藍色柱形為 At Least Once 的吞吐量,淺藍色柱形為 At Most Once 的吞吐量。對比兩者可以看出,在當前并發(fā)條件下,At Most Once 語義下的吞吐較 At Least Once 而言提高了 16.8%。
⑧ Windowed Word Count 單線程作業(yè)延遲
Windowed Word Count 單線程作業(yè)延遲
Identity 和 Sleep 觀測的都是 outTime - eventTime,因為作業(yè)處理時間較短或 Thread.sleep 精度不高,outTime - inTime 為零或沒有比較意義;Windowed Word Count 中可以有效測得 outTime - inTime 的數(shù)值,將其與 outTime - eventTime 畫在同一張圖上,其中 outTime - eventTime 為虛線,outTime - InTime 為實線。
觀察橙色的兩條折線可以發(fā)現(xiàn),F(xiàn)link 用兩種方式統(tǒng)計的延遲都維持在較低水平;觀察兩條藍色的曲線可以發(fā)現(xiàn),Storm 的 outTime - inTime 較低,outTime - eventTime 一直較高,即 inTime 和 eventTime 之間的差值一直較大,可能與 Storm 和 Flink 的數(shù)據(jù)讀入方式有關(guān)。
藍色折線表明 Storm 的延遲隨數(shù)據(jù)量的增大而增大,而橙色折線表明 Flink 的延遲隨著數(shù)據(jù)量的增大而減小(此處未測至 Flink 吞吐量,接近吞吐時 Flink 延遲依然會上升)。
即使僅關(guān)注 outTime - inTime(即圖中實線部分),依然可以發(fā)現(xiàn),當 QPS 逐漸增大的時候,F(xiàn)link 在延遲上的優(yōu)勢開始體現(xiàn)出來。
⑨ Windowed Word Count Flink At Least Once 與 Exactly Once 延遲對比
Windowed Word Count Flink At Least Once 與 Exactly Once 延遲對比
圖中黃色為 99 線,橙色為中位數(shù),虛線為 At Least Once,實線為 Exactly Once。圖中相應顏色的虛實曲線都基本重合,可以看出 Flink Exactly Once 的延遲中位數(shù)曲線與 At Least Once 基本貼合,在延遲上性能沒有太大差異。
⑩ Windowed Word Count Storm At Least Once 與 At Most Once 延遲對比
Windowed Word Count Storm At Least Once 與 At Most Once 延遲對比
圖中藍色為 99 線,淺藍色為中位數(shù),虛線為 At Least Once,實線為 At Most Once。QPS 在 4000 及以前的時候,虛線實線基本重合;QPS 在 6000 時兩者已有差異,虛線略高;QPS 接近 8000 時,已超過 At Least Once 語義下 Storm 的吞吐,因此只有實線上的點。
可以看出,QPS 較低時 Storm At Most Once 與 At Least Once 的延遲觀察不到差異,隨著 QPS 增大差異開始增大,At Most Once 的延遲較低。
?Windowed Word Count Flink 不同 StateBackends 吞吐量對比
Windowed Word Count Flink 不同 StateBackends 吞吐量對比
Flink 支持 Standalone 和 on Yarn 的集群部署模式,同時支持 Memory、FileSystem、RocksDB 三種狀態(tài)存儲后端(StateBackends)。由于線上作業(yè)需要,測試了這三種 StateBackends 在兩種集群部署模式上的性能差異。其中,Standalone 時的存儲路徑為 JobManager 上的一個文件目錄,on Yarn 時存儲路徑為 HDFS 上一個文件目錄。
對比三組柱形可以發(fā)現(xiàn),使用 FileSystem 和 Memory 的吞吐差異不大,使用 RocksDB 的吞吐僅其余兩者的十分之一左右。
對比兩種顏色可以發(fā)現(xiàn),Standalone 和 on Yarn 的總體差異不大,使用 FileSystem 和 Memory 時 on Yarn 模式下吞吐稍高,使用 RocksDB 時 Standalone 模式下的吞吐稍高。
?Windowed Word Count Flink 不同 StateBackends 延遲對比
Windowed Word Count Flink 不同 StateBackends 延遲對
使用 FileSystem 和 Memory 作為 Backends 時,延遲基本一致且較低。
使用 RocksDB 作為 Backends 時,延遲稍高,且由于吞吐較低,在達到吞吐瓶頸前的延遲陡增。其中 on Yarn 模式下吞吐更低,接近吞吐時的延遲更高。
六、結(jié)論及建議
1、框架本身性能
由①、⑤的測試結(jié)果可以看出,Storm 單線程吞吐約為 8.7 萬條/秒,F(xiàn)link 單線程吞吐可達 35 萬條/秒。Flink 吞吐約為 Storm 的 3-5 倍。
由②、⑧的測試結(jié)果可以看出,Storm QPS 接近吞吐時延遲(含 Kafka 讀寫時間)中位數(shù)約 100 毫秒,99 線約 700 毫秒,F(xiàn)link 中位數(shù)約 50 毫秒,99 線約 300 毫秒。Flink 在滿吞吐時的延遲約為 Storm 的一半,且隨著 QPS 逐漸增大,F(xiàn)link 在延遲上的優(yōu)勢開始體現(xiàn)出來。
綜上可得,F(xiàn)link 框架本身性能優(yōu)于 Storm。
2、復雜用戶邏輯對框架差異的削弱
對比①和③、②和④的測試結(jié)果可以發(fā)現(xiàn),單個 Bolt Sleep 時長達到 1 毫秒時,F(xiàn)link 的延遲仍低于 Storm,但吞吐優(yōu)勢已基本無法體現(xiàn)。
因此,用戶邏輯越復雜,本身耗時越長,針對該邏輯的測試體現(xiàn)出來的框架的差異越小。
3、不同消息投遞語義的差異
由⑥、⑦、⑨、⑩的測試結(jié)果可以看出,F(xiàn)link Exactly Once 的吞吐較 At Least Once 而言下降 6.3%,延遲差異不大;Storm At Most Once 語義下的吞吐較 At Least Once 提升 16.8%,延遲稍有下降。
由于 Storm 會對每條消息進行 ACK,F(xiàn)link 是基于一批消息做的檢查點,不同的實現(xiàn)原理導致兩者在 At Least Once 語義的花費差異較大,從而影響了性能。而 Flink 實現(xiàn) Exactly Once 語義僅增加了對齊操作,因此在算子并發(fā)量不大、沒有出現(xiàn)慢節(jié)點的情況下對 Flink 性能的影響不大。Storm At Most Once 語義下的性能仍然低于 Flink。
4、Flink 狀態(tài)存儲后端選擇
Flink 提供了內(nèi)存、文件系統(tǒng)、RocksDB 三種 StateBackends,結(jié)合?、?的測試結(jié)果,三者的對比如下:
5、推薦使用 Flink 的場景
綜合上述測試結(jié)果,以下實時計算場景建議考慮使用 Flink 框架進行計算:
要求消息投遞語義為 Exactly Once的場景;
數(shù)據(jù)量較大,要求高吞吐低延遲的場景;
需要進行狀態(tài)管理或窗口統(tǒng)計的場景。
七、展望
本次測試中尚有一些內(nèi)容沒有進行更加深入的測試,有待后續(xù)測試補充。例如:
Exactly Once 在并發(fā)量增大的時候是否吞吐會明顯下降?
用戶耗時到 1ms 時框架的差異已經(jīng)不再明顯(Thread.sleep() 的精度只能到毫秒),用戶耗時在什么范圍內(nèi) Flink 的優(yōu)勢依然能體現(xiàn)出來?
到此,相信大家對“Flink與Storm的性能對比”有了更深的了解,不妨來實際操作一番吧!這里是億速云網(wǎng)站,更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢,關(guān)注我們,繼續(xù)學習!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。