作者：夢瑤
1. 背景
Apache Flink 和 Apache Storm 是當(dāng)前業(yè)界廣泛使用的兩個分布式實時計算框架。其中?Apache Storm（以下簡稱“Storm”）在美團(tuán)點(diǎn)評實時計算業(yè)務(wù)中已有較為成熟的運(yùn)用（可參考?Storm 的可靠性保證測試），有管理平臺、常用 API 和相應(yīng)的文檔，大量實時作業(yè)基于 Storm 構(gòu)建。而?Apache Flink（以下簡稱“Flink”）在近期倍受關(guān)注，具有高吞吐、低延遲、高可靠和精確計算等特性，對事件窗口有很好的支持，目前在美團(tuán)點(diǎn)評實時計算業(yè)務(wù)中也已有一定應(yīng)用。
為深入熟悉了解 Flink 框架，驗證其穩(wěn)定性和可靠性，評估其實時處理性能，識別該體系中的缺點(diǎn)，找到其性能瓶頸并進(jìn)行優(yōu)化，給用戶提供最適合的實時計算引擎，我們以實踐經(jīng)驗豐富的 Storm 框架作為對照，進(jìn)行了一系列實驗測試 Flink 框架的性能，計算 Flink 作為確?！爸辽僖淮巍焙汀扒『靡淮巍闭Z義的實時計算框架時對資源的消耗，為實時計算平臺資源規(guī)劃、框架選擇、性能調(diào)優(yōu)等決策及 Flink 平臺的建設(shè)提出建議并提供數(shù)據(jù)支持，為后續(xù)的 SLA 建設(shè)提供一定參考。
Flink 與 Storm 兩個框架對比：
2. 測試目標(biāo)
評估不同場景、不同數(shù)據(jù)壓力下 Flink 和 Storm 兩個實時計算框架目前的性能表現(xiàn)，獲取其詳細(xì)性能數(shù)據(jù)并找到處理性能的極限；了解不同配置對 Flink 性能影響的程度，分析各種配置的適用場景，從而得出調(diào)優(yōu)建議。
2.1 測試場景
“輸入-輸出”簡單處理場景
通過對“輸入-輸出”這樣簡單處理邏輯場景的測試，盡可能減少其它因素的干擾，反映兩個框架本身的性能。
同時測算框架處理能力的極限，處理更加復(fù)雜的邏輯的性能不會比純粹“輸入-輸出”更高。
用戶作業(yè)耗時較長的場景
如果用戶的處理邏輯較為復(fù)雜，或是訪問了數(shù)據(jù)庫等外部組件，其執(zhí)行時間會增大，作業(yè)的性能會受到影響。因此，我們測試了用戶作業(yè)耗時較長的場景下兩個框架的調(diào)度性能。
窗口統(tǒng)計場景
實時計算中常有對時間窗口或計數(shù)窗口進(jìn)行統(tǒng)計的需求，例如一天中每五分鐘的訪問量，每 100 個訂單中有多少個使用了優(yōu)惠等。Flink 在窗口支持上的功能比 Storm 更加強(qiáng)大，API 更加完善，但是我們同時也想了解在窗口統(tǒng)計這個常用場景下兩個框架的性能。
精確計算場景（即消息投遞語義為“恰好一次”）
Storm 僅能保證“至多一次” (At Most Once) 和“至少一次” (At Least Once) 的消息投遞語義，即可能存在重復(fù)發(fā)送的情況。有很多業(yè)務(wù)場景對數(shù)據(jù)的精確性要求較高，希望消息投遞不重不漏。Flink 支持“恰好一次” (Exactly Once) 的語義，但是在限定的資源條件下，更加嚴(yán)格的精確度要求可能帶來更高的代價，從而影響性能。因此，我們測試了在不同消息投遞語義下兩個框架的性能，希望為精確計算場景的資源規(guī)劃提供數(shù)據(jù)參考。
2.2 性能指標(biāo)
吞吐量（Throughput）
單位時間內(nèi)由計算框架成功地傳送數(shù)據(jù)的數(shù)量，本次測試吞吐量的單位為：條/秒。反映了系統(tǒng)的負(fù)載能力，在相應(yīng)的資源條件下，單位時間內(nèi)系統(tǒng)能處理多少數(shù)據(jù)。吞吐量常用于資源規(guī)劃，同時也用于協(xié)助分析系統(tǒng)性能瓶頸，從而進(jìn)行相應(yīng)的資源調(diào)整以保證系統(tǒng)能達(dá)到用戶所要求的處理能力。假設(shè)商家每小時能做二十份午餐（吞吐量 20 份/小時），一個外賣小哥每小時只能送兩份（吞吐量 2 份/小時），這個系統(tǒng)的瓶頸就在小哥配送這個環(huán)節(jié)，可以給該商家安排十個外賣小哥配送。延遲（Latency）
數(shù)據(jù)從進(jìn)入系統(tǒng)到流出系統(tǒng)所用的時間，本次測試延遲的單位為：毫秒。反映了系統(tǒng)處理的實時性。金融交易分析等大量實時計算業(yè)務(wù)對延遲有較高要求，延遲越低，數(shù)據(jù)實時性越強(qiáng)。假設(shè)商家做一份午餐需要 5 分鐘，小哥配送需要 25 分鐘，這個流程中用戶感受到了 30 分鐘的延遲。如果更換配送方案后延遲變成了 60 分鐘，等送到了飯菜都涼了，這個新的方案就是無法接受的。3. 測試環(huán)境
為 Storm 和 Flink 分別搭建由 1 臺主節(jié)點(diǎn)和 2 臺從節(jié)點(diǎn)構(gòu)成的 Standalone 集群進(jìn)行本次測試。其中為了觀察 Flink 在實際生產(chǎn)環(huán)境中的性能，對于部分測內(nèi)容也進(jìn)行了 on Yarn 環(huán)境的測試。
3.1 集群參數(shù)
3.2 框架參數(shù)
4. 測試方法
4.1 測試流程
數(shù)據(jù)生產(chǎn)
Data Generator 按特定速率生成數(shù)據(jù)，帶上自增的 id 和 eventTime 時間戳寫入 Kafka 的一個 Topic（Topic Data）。
數(shù)據(jù)處理
Storm Task 和 Flink Task （每個測試用例不同）從 Kafka Topic Data 相同的 Offset 開始消費(fèi)，并將結(jié)果及相應(yīng) inTime、outTime 時間戳分別寫入兩個 Topic（Topic Storm 和 Topic Flink）中。
指標(biāo)統(tǒng)計
Metrics Collector 按 outTime 的時間窗口從這兩個 Topic 中統(tǒng)計測試指標(biāo)，每五分鐘將相應(yīng)的指標(biāo)寫入 MySQL 表中。
Metrics Collector 按 outTime 取五分鐘的滾動時間窗口，計算五分鐘的平均吞吐（輸出數(shù)據(jù)的條數(shù)）、五分鐘內(nèi)的延遲（outTime – eventTime 或 outTime – inTime）的中位數(shù)及 99 線等指標(biāo)，寫入 MySQL 相應(yīng)的數(shù)據(jù)表中。最后對 MySQL 表中的吞吐計算均值，延遲中位數(shù)及延遲 99 線選取中位數(shù)，繪制圖像并分析。
4.2 默認(rèn)參數(shù)
Storm 和 Flink 默認(rèn)均為?At Least Once?語義。Storm 開啟 ACK，ACKer 數(shù)量為 1。Flink 的 Checkpoint 時間間隔為 30 秒，默認(rèn) StateBackend 為 Memory。保證 Kafka 不是性能瓶頸，盡可能排除 Kafka 對測試結(jié)果的影響。測試延遲時數(shù)據(jù)生產(chǎn)速率小于數(shù)據(jù)處理能力，假設(shè)數(shù)據(jù)被寫入 Kafka 后立刻被讀取，即 eventTime 等于數(shù)據(jù)進(jìn)入系統(tǒng)的時間。測試吞吐量時從 Kafka Topic 的最舊開始讀取，假設(shè)該 Topic 中的測試數(shù)據(jù)量充足。4.3 測試用例
Identity
Identity 用例主要模擬“輸入-輸出”簡單處理場景，反映兩個框架本身的性能。輸入數(shù)據(jù)為“msgId, eventTime”，其中 eventTime 視為數(shù)據(jù)生成時間。單條輸入數(shù)據(jù)約 20 B。進(jìn)入作業(yè)處理流程時記錄 inTime，作業(yè)處理完成后（準(zhǔn)備輸出時）記錄 outTime。作業(yè)從 Kafka Topic Data 中讀取數(shù)據(jù)后，在字符串末尾追加時間戳，然后直接輸出到 Kafka。輸出數(shù)據(jù)為“msgId, eventTime, inTime, outTime”。單條輸出數(shù)據(jù)約 50 B。
Sleep
Sleep 用例主要模擬用戶作業(yè)耗時較長的場景，反映復(fù)雜用戶邏輯對框架差異的削弱，比較兩個框架的調(diào)度性能。輸入數(shù)據(jù)和輸出數(shù)據(jù)均與 Identity 相同。讀入數(shù)據(jù)后，等待一定時長（1 ms）后在字符串末尾追加時間戳后輸出
Windowed Word Count
Windowed Word Count 用例主要模擬窗口統(tǒng)計場景，反映兩個框架在進(jìn)行窗口統(tǒng)計時性能的差異。此外，還用其進(jìn)行了精確計算場景的測試，反映 Flink?恰好一次投遞的性能。輸入為 JSON 格式，包含 msgId、eventTime 和一個由若干單詞組成的句子，單詞之間由空格分隔。單條輸入數(shù)據(jù)約 150 B。讀入數(shù)據(jù)后解析 JSON，然后將句子分割為相應(yīng)單詞，帶 eventTime 和 inTime 時間戳發(fā)給 CountWindow 進(jìn)行單詞計數(shù)，同時記錄一個窗口中最大最小的 eventTime 和 inTime，最后帶 outTime 時間戳輸出到 Kafka 相應(yīng)的 Topic。Spout/Source 及 OutputBolt/Output/Sink 并發(fā)度恒為 1，增大并發(fā)度時僅增大 JSONParser、CountWindow 的并發(fā)度。由于 Storm 對 window 的支持較弱，CountWindow 使用一個 HashMap 手動實現(xiàn)，F(xiàn)link 用了原生的 CountWindow 和相應(yīng)的 Reduce 函數(shù)。
5. 測試結(jié)果5.1 Identity 單線程吞吐量
5.2 Identity 單線程作業(yè)延遲
5.3 Sleep 吞吐量
5.4 Sleep 單線程作業(yè)延遲（中位數(shù)）
5.5 Windowed Word Count 單線程吞吐量
單線程執(zhí)行大小為 10 的計數(shù)窗口，吞吐量統(tǒng)計如圖。從圖中可以看出，Storm 吞吐約為 1.2 萬條/秒，F(xiàn)link Standalone 約為 4.3 萬條/秒。Flink 吞吐依然為 Storm 的 3 倍以上。5.6 Windowed Word Count Flink At Least Once 與 Exactly Once 吞吐量對比
5.7 Windowed Word Count Storm At Least Once 與 At Most Once 吞吐量對比
5.8 Windowed Word Count 單線程作業(yè)延遲
5.9 Windowed Word Count Flink At Least Once 與 Exactly Once 延遲對比
5.10 Windowed Word Count Storm At Least Once 與 At Most Once 延遲對比
5.11 Windowed Word Count Flink 不同 StateBackends 吞吐量對比
5.12 Windowed Word Count Flink 不同 StateBackends 延遲對比
6. 結(jié)論及建議6.1 框架本身性能
由 5.1、5.5 的測試結(jié)果可以看出，Storm 單線程吞吐約為 8.7 萬條/秒，F(xiàn)link 單線程吞吐可達(dá) 35 萬條/秒。Flink 吞吐約為 Storm 的 3-5 倍。由 5.2、5.8 的測試結(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)出來。綜上可得，Flink 框架本身性能優(yōu)于 Storm。6.2 復(fù)雜用戶邏輯對框架差異的削弱
對比 5.1 和 5.3、5.2 和 5.4 的測試結(jié)果可以發(fā)現(xiàn)，單個 Bolt Sleep 時長達(dá)到 1 毫秒時，F(xiàn)link 的延遲仍低于 Storm，但吞吐優(yōu)勢已基本無法體現(xiàn)。因此，用戶邏輯越復(fù)雜，本身耗時越長，針對該邏輯的測試體現(xiàn)出來的框架的差異越小。6.3 不同消息投遞語義的差異
由 5.6、5.7、5.9、5.10 的測試結(jié)果可以看出，F(xiàn)link Exactly Once 的吞吐較 At Least Once 而言下降 6.3%，延遲差異不大；Storm At Most Once 語義下的吞吐較 At Least Once 提升 16.8%，延遲稍有下降。由于 Storm 會對每條消息進(jìn)行 ACK，F(xiàn)link 是基于一批消息做的檢查點(diǎn)，不同的實現(xiàn)原理導(dǎo)致兩者在 At Least Once 語義的花費(fèi)差異較大，從而影響了性能。而 Flink 實現(xiàn) Exactly Once 語義僅增加了對齊操作，因此在算子并發(fā)量不大、沒有出現(xiàn)慢節(jié)點(diǎn)的情況下對 Flink 性能的影響不大。Storm At Most Once 語義下的性能仍然低于 Flink。6.4 Flink 狀態(tài)存儲后端選擇
Flink 提供了內(nèi)存、文件系統(tǒng)、RocksDB 三種 StateBackends，結(jié)合 5.11、5.12 的測試結(jié)果，三者的對比如下：
6.5 推薦使用 Flink 的場景
綜合上述測試結(jié)果，以下實時計算場景建議考慮使用 Flink 框架進(jìn)行計算：
要求消息投遞語義為?Exactly Once?的場景；數(shù)據(jù)量較大，要求高吞吐低延遲的場景；需要進(jìn)行狀態(tài)管理或窗口統(tǒng)計的場景。7. 展望本次測試中尚有一些內(nèi)容沒有進(jìn)行更加深入的測試，有待后續(xù)測試補(bǔ)充。例如：Exactly Once 在并發(fā)量增大的時候是否吞吐會明顯下降？用戶耗時到 1ms 時框架的差異已經(jīng)不再明顯（Thread.sleep() 的精度只能到毫秒），用戶耗時在什么范圍內(nèi) Flink 的優(yōu)勢依然能體現(xiàn)出來？本次測試僅觀察了吞吐量和延遲兩項指標(biāo)，對于系統(tǒng)的可靠性、可擴(kuò)展性等重要的性能指標(biāo)沒有在統(tǒng)計數(shù)據(jù)層面進(jìn)行關(guān)注，有待后續(xù)補(bǔ)充。Flink 使用 RocksDBStateBackend 時的吞吐較低，有待進(jìn)一步探索和優(yōu)化。關(guān)于 Flink 的更高級 API，如 Table API & SQL 及 CEP 等，需要進(jìn)一步了解和完善。8. 參考內(nèi)容分布式流處理框架——功能對比和性能評估.intel-hadoop/HiBench: HiBench is a big data benchmark suite.Yahoo的流計算引擎基準(zhǔn)測試.Extending the Yahoo! Streaming Benchmark.
- 合合信息與中科曙光簽署合作協(xié)議，AI賦能信創(chuàng)產(chǎn)業(yè)升級
- 英特爾火力全開炮轟AMD和英偉達(dá)：漏洞數(shù)量及危害性“遙遙領(lǐng)先”
- SUSE發(fā)布SUSE Edge Suite 與Edge 3.2 ，助力零售企業(yè)實現(xiàn)無縫化運(yùn)營
- Gartner：2025年全球IT支出將達(dá)到5.61億美元，同比增長9.8%
- 消息稱去年全球IT支出超過5萬億美元 數(shù)據(jù)中心系統(tǒng)支出大幅增加
- 2025年全球數(shù)據(jù)中心：數(shù)字基礎(chǔ)設(shè)施的演變
- 谷歌押注多模態(tài)AI，BigQuery湖倉一體是核心支柱
- 數(shù)字化轉(zhuǎn)型支出將飆升：到2027年將達(dá)到4萬億美元
- 量子與人工智能：數(shù)字化轉(zhuǎn)型的力量倍增器
- 華為OceanStor Dorado全閃存存儲榮獲CC認(rèn)證存儲設(shè)備最高認(rèn)證級別證書
免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。
