Flink,Storm,SparkStreaming性能對比

Yahoo 的 Storm 團隊曾發表了一篇博客文章 ，並在其中展現了 Storm、Flink 和 Spark Streaming 的性能測試結果。該測試對於業界而言極 具價值，由於它是流處理領域的第一個基於真實應用程序的基準測試。

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

在最初的性能 測評中，由於 Storm 是無狀態流處理器（即它不能定義和維護狀態），因此 Flink 做業也按照無狀態模式編寫。全部狀態都被存儲在 Redis 中。

在性能測評中，Spark Streaming 遇到了吞吐量和延遲性難 兩全的問題。隨着批處理做業規模的增長，延遲升高。若是爲了下降延遲而縮減規模，吞吐量就會減小。Storm 和 Flink 則能夠在吞吐量增長時維持低延遲。

爲了進一步測試 Flink 的性能，測試人員設置了一系列不一樣的場景，並逐步測試。

最初的性能測評專一於在相對較低的吞吐量下，測量端到端的延遲，即 使在極限狀態下，也不關注容錯性。此外，應用程序中的 key 基數很是小 （100），這使得測試結果沒法反映用戶量大的狀況，或者 key 空間隨着時間增加的狀況.

因爲最初的測試結果顯示 Spark Streaming 的性能欠佳，所以此次的測試對 象只有 Storm 和 Flink，它們在最初的測試中有着相似的表現。

第 1 個變化是利用 Flink 提供的狀態容錯特性從新實現應用程序，如圖 5-15 所示。這使得應用程序能保證 exactly-once。

第 2 個變化是經過用每秒能夠生成數百萬事件的數據生成器來增長輸入流 的數據量。

結果以下：

使用高吞吐數據生成器的結果：（A）當Storm 與 Kafka 一塊兒使用時，應用程序能夠保持每秒 40 萬事件的處理速度，而且瓶頸在於 CPU；當 Flink 與 Kafka 一塊兒使用時，應用程序能夠保持每秒300 萬事件的處理速度，而且瓶頸在於網絡；（B）當消除網絡瓶頸時，Flink 應用程序能夠保持每秒1500 萬事件的處理速度；（C）在額外的測試中，消息隊列由MapR Streams 提供，而且採用10 個高性能網絡節點（硬件與前兩種狀況中的不一樣）；Flink 應用程序能夠保持每秒1000 萬事件的處理速度.Storm 可以承受每秒 40 萬事件，但受限於 CPU；Flink 則能夠達到每秒 300 萬事件（7.5 倍），但受限於 Kafka 集羣和 Flink 集羣之間的網絡。

爲了看看在沒有網絡瓶頸問題時 Flink 的性能如何，咱們將數據生成器移到 Flink 應用程序的內部。在這樣的條件下，Flink 能夠保持每秒 1500 萬事件的處理速度（這是 Storm 的 37.5 倍）

將數據生成器整合到 Flink 應用程序中，能夠測試性能極限，但這種 作法並不現實，由於現實世界中的數據必須從應用程序的外部流入。

值得注意的是，這絕對不是 Kafka 的極限（Kafka 能夠支撐比這更大的吞吐量），而僅僅是測試所用的硬件環境的極限——Kafka 集羣和 Flink 集羣 之間的網絡鏈接太慢。

最後一個變化是增長 key 基數（廣告宣傳活動的數量）。在最初的測試中， key 基數只有 100。這些 key 每秒都會被寫入 Redis，以供查詢。當 key 基數 增長到 100 萬時，系統的總體吞吐量減小到每秒 28 萬事件，由於向 Redis寫入成了系統瓶頸。使用 Flink 可查詢狀態的一個早期原型能夠消除這種瓶頸，使系統的處理速度恢復到每秒 1500 萬事件，並 且有 100 萬個 key 可供查詢.

經過將查詢功能移入Flink 可查詢狀態的一個原型，系統甚至能夠在key 基數很是大的狀況下仍然維持每秒 1500 萬事件的處理速度.

本例說明了什麼呢？經過避免流處理瓶頸，同時利用 Flink 的有狀態流處理 能力，可使吞吐量達到Storm 的 30 倍左右，同時還能保證exactly-once 和高可用性。大體來講，這意味着與 Storm 相比，Flink 的硬件成本或雲計算成本僅爲前者的 1/30，一樣的硬件能處理的數據量則是前者的 30 倍。

更多Flink相關文章：

穿梭時空的實時計算框架——Flink對時間的處理

Flink快速入門--安裝與示例運行

大數據實時處理的王者-Flink

更多實時計算，Flink,Kafka的技術文章歡迎關注實時流式計算