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的技術文章歡迎關注實時流式計算

相關推薦