如何實(shí)現(xiàn)Flink,Storm,SparkStreaming的性能對(duì)比

如何實(shí)現(xiàn)Flink,Storm,SparkStreaming的性能對(duì)比，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

之前有團(tuán)隊(duì)曾發(fā)表了一篇博客文章 ，并在其中展示了 Storm、Flink 和 Spark Streaming 的性能測試結(jié)果。該測試對(duì)于業(yè)界而言極 具價(jià)值，因?yàn)樗橇魈幚眍I(lǐng)域的第一個(gè)基于真實(shí)應(yīng)用程序的基準(zhǔn)測試。

該應(yīng)用程序從 Kafka 消費(fèi)廣告曝光消息，從 Redis 查找每個(gè)廣告對(duì)應(yīng)的廣 告宣傳活動(dòng)，并按照廣告宣傳活動(dòng)分組，以 10 秒為窗口計(jì)算廣告瀏覽量。10 秒窗口的最終結(jié)果被存儲(chǔ)在 Redis 中，這些窗口的狀態(tài)也按照每秒記錄 一次的頻率被寫入 Redis，以方便用戶對(duì)它們進(jìn)行實(shí)時(shí)查詢。

在最初的性能 測評(píng)中，因?yàn)?Storm 是無狀態(tài)流處理器（即它不能定義和維護(hù)狀態(tài)），所以 Flink 作業(yè)也按照無狀態(tài)模式編寫。所有狀態(tài)都被存儲(chǔ)在 Redis 中。

在性能測評(píng)中，Spark Streaming 遇到了吞吐量和延遲性難 兩全的問題。隨著批處理作業(yè)規(guī)模的增加，延遲升高。如果為了降低延遲而縮減規(guī)模，吞吐量就會(huì)減少。Storm 和 Flink 則可以在吞吐量增加時(shí)維持低延遲。

為了進(jìn)一步測試 Flink 的性能，測試人員設(shè)置了一系列不同的場景，并逐步測試。

最初的性能測評(píng)專注于在相對(duì)較低的吞吐量下，測量端到端的延遲，即 使在極限狀態(tài)下，也不關(guān)注容錯(cuò)性。此外，應(yīng)用程序中的 key 基數(shù)非常小 （100），這使得測試結(jié)果無法反映用戶量大的情況，或者 key 空間隨著時(shí)間增長的情況.

由于最初的測試結(jié)果顯示 Spark Streaming 的性能欠佳，因此這次的測試對(duì) 象只有 Storm 和 Flink，它們在最初的測試中有著類似的表現(xiàn)。

第 1 個(gè)變化是利用 Flink 提供的狀態(tài)容錯(cuò)特性重新實(shí)現(xiàn)應(yīng)用程序，如圖 5-15 所示。這使得應(yīng)用程序能保證 exactly-once。

第 2 個(gè)變化是通過用每秒可以生成數(shù)百萬事件的數(shù)據(jù)生成器來增加輸入流 的數(shù)據(jù)量。

結(jié)果如下：

使用高吞吐數(shù)據(jù)生成器的結(jié)果：（A）當(dāng)Storm 與 Kafka 一起使用時(shí)，應(yīng)用程序可以保持每秒 40 萬事件的處理速度，并且瓶頸在于 CPU；當(dāng) Flink 與 Kafka 一起使用時(shí)，應(yīng)用程序可以保持每秒300 萬事件的處理速度，并且瓶頸在于網(wǎng)絡(luò)；
（B）當(dāng)消除網(wǎng)絡(luò)瓶頸時(shí)，F(xiàn)link 應(yīng)用程序可以保持每秒1500 萬事件的處理速度；
（C）在額外的測試中，消息隊(duì)列由MapR Streams 提供，并且采用10 個(gè)高性能網(wǎng)絡(luò)節(jié)點(diǎn)（硬件與前兩種情況中的不同）；Flink 應(yīng)用程序可以保持每秒1000 萬事件的處理速度.
Storm 能夠承受每秒 40 萬事件，但受限于 CPU；Flink 則可以達(dá)到每秒 300 萬事件（7.5 倍），但受限于 Kafka 集群和 Flink 集群之間的網(wǎng)絡(luò)。

為了看看在沒有網(wǎng)絡(luò)瓶頸問題時(shí) Flink 的性能如何，我們將數(shù)據(jù)生成器移到 Flink 應(yīng)用程序的內(nèi)部。在這樣的條件下，F(xiàn)link 可以保持每秒 1500 萬事件的處理速度（這是 Storm 的 37.5 倍）

將數(shù)據(jù)生成器整合到 Flink 應(yīng)用程序中，可以測試性能極限，但這種 做法并不現(xiàn)實(shí)，因?yàn)楝F(xiàn)實(shí)世界中的數(shù)據(jù)必須從應(yīng)用程序的外部流入。

值得注意的是，這絕對(duì)不是 Kafka 的極限（Kafka 可以支撐比這更大的吞吐量），而僅僅是測試所用的硬件環(huán)境的極限——Kafka 集群和 Flink 集群 之間的網(wǎng)絡(luò)連接太慢。

最后一個(gè)變化是增加 key 基數(shù)（廣告宣傳活動(dòng)的數(shù)量）。在最初的測試中， key 基數(shù)只有 100。這些 key 每秒都會(huì)被寫入 Redis，以供查詢。當(dāng) key 基數(shù) 增加到 100 萬時(shí)，系統(tǒng)的整體吞吐量減少到每秒 28 萬事件，因?yàn)橄?Redis寫入成了系統(tǒng)瓶頸。使用 Flink 可查詢狀態(tài)的一個(gè)早期原型可以消除這種瓶頸，使系統(tǒng)的處理速度恢復(fù)到每秒 1500 萬事件，并 且有 100 萬個(gè) key 可供查詢.

通過將查詢功能移入Flink 可查詢狀態(tài)的一個(gè)原型，系統(tǒng)甚至可以在key 基數(shù)非常大的情況下仍然維持每秒 1500 萬事件的處理速度.

本例說明了什么呢？通過避免流處理瓶頸，同時(shí)利用 Flink 的有狀態(tài)流處理 能力，可以使吞吐量達(dá)到Storm 的 30 倍左右，同時(shí)還能保證exactly-once 和高可用性。大致來說，這意味著與 Storm 相比，F(xiàn)link 的硬件成本或云計(jì)算成本僅為前者的 1/30，同樣的硬件能處理的數(shù)據(jù)量則是前者的 30 倍。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。