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

麻栗坡ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

之前有團(tuán)隊曾發(fā)表了一篇博客文章 ，并在其中展示了 Storm、Flink 和 Spark Streaming 的性能測試結(jié)果。該測試對于業(yè)界而言極 具價值，因為它是流處理領(lǐng)域的第一個基于真實應(yīng)用程序的基準(zhǔn)測試。

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

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

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

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

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

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

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

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

結(jié)果如下：

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

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

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

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

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

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

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

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。