Spark Streaming，Flink，Storm，Kafka Streams，Samza：如何選擇流處理框架

根據最新的統計顯示，僅在過去的兩年中，當今世界上90％的數據都是在新產生的，天天建立2.5萬億字節的數據，而且隨着新設備，傳感器和技術的出現，數據增加速度可能會進一步加快。
從技術上講，這意味着咱們的大數據處理將變得更加複雜且更具挑戰性。並且，許多用例（例如，移動應用廣告，欺詐檢測，出租車預訂，病人監護等）都須要在數據到達時進行實時數據處理，以便作出快速可行的決策。這就是爲何分佈式流處理在大數據世界中變得很是流行的緣由。

現在，有許多可用的開源流框架。有趣的是，幾乎全部它們都是至關新的，僅在最近幾年纔開發出來。所以，對於新手來講，很容易混淆流框架之間的理解和區分。在本文中，我將首先大體討論流處理的類型和方面，而後比較最受歡迎的開源流框架：Flink，SparkStreaming，Storm，KafkaStream。我將嘗試（簡要地）解釋它們的工做原理，它們的用例，優點，侷限性，異同。

什麼是流/流處理：

流處理的最優雅的定義是：一種數據處理引擎，其設計時考慮了無限的數據集。

與批處理不一樣，批處理以工做中的開始和結束爲界，而工做是在處理有限數據以後完成的，而流處理則是指接二連三地處理天，月，年和永久到來的無邊界數據。所以，流媒體應用程序始終須要啓動和運行，所以難以實現且難以維護。

流處理的重要方面：

爲了理解任何Streaming框架的優勢和侷限性，咱們應該瞭解與Stream處理相關的一些重要特徵和術語：

• 交付保證：
  這意味着不管如何，流引擎中的特定傳入記錄都將獲得處理的保證。能夠是at least once（至少一次）（即便發生故障也至少處理一次），at most once : 至多一次（若是發生故障則可能不處理）或Exactly-once（即便失敗在這種狀況下也只能處理一次））。顯然，只處理一次是最好的，可是很難在分佈式系統中實現，而且須要權衡性能。
• 容錯：
  若是發生諸如節點故障，網絡故障等故障，框架應該可以恢復，而且應該從其離開的位置開始從新處理。這是經過不時檢查流向某些持久性存儲的狀態來實現的。例如，從Kafka獲取記錄並對其進行處理後，將Kafka檢查點偏移給Zookeeper。
• 狀態管理：在有狀態處理需求的狀況下，咱們須要保持某種狀態（例如，記錄中每一個不重複單詞的計數），框架應該可以提供某種機制來保存和更新狀態信息。
• 性能：
  這包括延遲（能夠多久處理一條記錄），吞吐量（每秒處理的記錄數）和可伸縮性。延遲應儘量小，而吞吐量應儘量大。很難同時得到二者。
• 高級功能：事件時間處理，水印，窗口化
  若是流處理要求很複雜，這些是必需的功能。例如，根據在源中生成記錄的時間來處理記錄（事件時間處理）。
• 成熟度：從採用的角度來看很重要，若是框架已通過大公司的驗證和大規模測試，那就太好了。更有可能得到良好的社區支持並在堆棧溢出方面提供幫助。

流處理的兩種類型：

如今瞭解了咱們剛剛討論的術語，如今很容易理解，有兩種方法能夠實現Streaming框架：

原生流處理：
這意味着每條到達的記錄都會在到達後當即處理，而無需等待其餘記錄。有一些連續運行的過程（根據框架，咱們稱之爲操做員/任務/螺栓），這些過程將永遠運行，每條記錄都將經過這些過程進行處理。示例：Storm，Flink，Kafka Streams，Samza。

微批處理：
也稱爲快速批處理。這意味着每隔幾秒鐘就會將傳入的記錄分批處理，而後以單個小批處理的方式處理，延遲幾秒鐘。例如：Spark Streaming, Storm-Trident。

兩種方法都有其優勢和缺點。
原生流傳輸感受很天然，由於每條記錄都會在到達記錄後當即進行處理，從而使框架可以實現最小的延遲。但這也意味着在不影響吞吐量的狀況下很難實現容錯，由於對於每條記錄，咱們都須要在處理後跟蹤和檢查點。並且，狀態管理很容易，由於有長時間運行的進程能夠輕鬆維護所需的狀態。

另外一方面，微批處理則徹底相反。容錯是免費提供的，由於它本質上是一個批處理，吞吐量也很高，由於處理和檢查點將在一組記錄中一次性完成。但這會花費必定的等待時間，而且感受不天然。高效的狀態管理也將是維持的挑戰。

流框架對比：

Storm :

Storm是流處理世界的強者。它是最古老的開源流框架，也是最成熟和可靠的框架之一。這是真正的流傳輸，適合基於簡單事件的用例。

優勢：

• 極低的延遲，真正的流，成熟和高吞吐量
• 很是適合簡單的流媒體用例

缺點

• 沒有狀態管理
• 沒有高級功能，例如事件時間處理，聚合，開窗，會話，水印等
• 一次保證

Spark Streaming :

Spark已成爲批處理中hadoop的真正繼任者，而且是第一個徹底支持Lambda架構的框架（在該框架中，實現了批處理和流傳輸；實現了正確性的批處理；實現了流傳輸的速度）。它很是受歡迎，成熟並被普遍採用。Spark Streaming是隨Spark免費提供的，它使用微批處理進行流媒體處理。在2.0版本以前，Spark Streaming有一些嚴重的性能限制，可是在新版本2.0+中，它被稱爲結構化流，並具備許多良好的功能，例如自定義內存管理（相似flink），水印，事件時間處理支持等。另外，結構化流媒體更加抽象，在2.3.0版本之後，能夠選擇在微批量和連續流媒體模式之間進行切換。連續流模式有望帶來像Storm和Flink這樣的子延遲，可是它仍處於起步階段，操做上有不少限制。

優勢：

• 支持Lambda架構，Spark免費提供
• 高吞吐量，適用於不須要亞延遲的許多使用狀況
• 因爲微批量性質，默認狀況下具備容錯能力
• 簡單易用的高級API
• 龐大的社區和積極的改進
• 剛好一次

缺點

• 不是真正的流，不適合低延遲要求

• 要調整的參數太多。很難作到正確。

• 天生無國籍

• 在許多高級功能方面落後於Flink

Flink :

Flink也來自相似Spark這樣的學術背景。Spark來自加州大學伯克利分校，而Flink來自柏林工業大學。像Spark同樣，它也支持Lambda架構。可是實現與Spark徹底相反。雖然Spark本質上是一個批處理，其中Spark流是微批處理，而且是Spark Batch的特例，但Flink本質上是一個真正的流引擎，將批處理視爲帶邊界數據流的特例。儘管這兩個框架中的API都是類似的，可是它們在實現上沒有任何類似性。在Flink中，諸如map，filter，reduce等的每一個函數都實現爲長時間運行的運算符（相似於Storm中的Bolt）

Flink看起來像是Storm的真正繼承者，就像Spark批量繼承了hadoop同樣。

優勢：

• 開源流媒體領域創新的領導者
• 具備全部高級功能（例如事件時間處理，水印等）的第一個True流框架
• 低延遲，高吞吐量，可根據要求進行配置
• 自動調整，無需調整太多參數
• 剛好一次
• 被Uber，阿里巴巴等大型公司普遍接受。

缺點

• 起步較晚，最初缺少採用

• 社區不如Spark大，但如今正在快速發展

Kafka Streams :

與其餘流框架不一樣，Kafka Streams是一個輕量級的庫。對於從Kafka流式傳輸數據，進行轉換而後發送回kafka頗有用。咱們能夠將其理解爲相似於Java Executor服務線程池的庫，但具備對Kafka的內置支持。它能夠與任何應用程序很好地集成，而且能夠當即使用。

因爲其重量輕的特性，可用於微服務類型的體系結構。Flink在性能方面沒有匹配之處，並且不須要運行單獨的集羣，很是方便而且易於部署和開始工做。

Kafka Streams的一個主要優勢是它的處理是徹底精確的端到端。多是由於來源和目的地均爲Kafka以及從2017年6月左右發佈的Kafka 0.11版本開始，僅支持一次。要啓用此功能，咱們只須要啓用一個標誌便可使用。

優勢：

• 重量很輕的庫，適合微服務，IOT應用
• 不須要專用集羣
• 繼承卡夫卡的全部優良特性
• 支持流鏈接，內部使用rocksDb維護狀態。
• 剛好一次（從Kafka 0.11開始）。

缺點

• 與卡夫卡緊密結合，在沒有卡夫卡的狀況下沒法使用
• 嬰兒期還很新，尚待大公司測試
• 不適用於繁重的工做，例如Spark Streaming，Flink。

Samza :

簡短介紹一下Samza。（Samza）看上去就像是（Kafka Streams）。有不少類似之處。這兩個框架都是由同一位開發人員開發的，這些開發人員在LinkedIn上實現了Samza，而後在他們建立Kafka Streams的地方成立了Confluent。這兩種技術都與Kafka緊密結合，從Kafka獲取原始數據，而後將處理後的數據放回Kafka。使用相同的Kafka Log哲學。Samza是Kafka Streams的縮放版本。Kafka Streams是一個用於微服務的庫，而Samza是在Yarn上運行的完整框架集羣處理。
優勢 ：

• 使用rocksDb和kafka日誌能夠很好地維護大量信息狀態（適合於鏈接流的用例）。
• 使用Kafka屬性的容錯和高性能
• 若是已在處理管道中使用Yarn和Kafka，則要考慮的選項之一。
• 低延遲，高吞吐量，成熟並通過大規模測試

缺點：

• 與Kafka和Yarn緊密結合。若是這些都不在您的處理管道中，則不容易使用。
• 至少一次加工保證。我不肯定它是否像Kafka 0.11以後的Kafka Streams如今徹底支持一次
• 缺乏高級流功能，例如水印，會話，觸發器等

流框架比較：

咱們只能將技術與相似產品進行比較。儘管Storm，Kafka Streams和Samza如今對於更簡單的用例頗有用，但具備最新功能的重量級產品之間的真正競爭顯而易見：Spark vs Flink

當咱們談論比較時，咱們一般會問：給我看數字

基準測試是僅當第三方進行比較時比較的好方法。

例如，但這是在Spark Streaming 2.0以前的某個時期，當時它受RDD的限制。
如今，隨着Structured Streaming 2.0版本的發佈，Spark Streaming試圖遇上不少潮流，並且彷佛還會面臨艱鉅的挑戰。

最近，基準測試已成爲Spark和Flink之間的一場激烈爭吵。

最好不要相信這些天的基準測試，由於即便很小的調整也能夠徹底改變數字。沒有什麼比決定以前嘗試和測試本身更好。
到目前爲止，很明顯，Flink在流分析領域處於領先地位，它具備大多數所需的方面，例如精確一次，吞吐量，延遲，狀態管理，容錯，高級功能等。

Flink的一個重要問題是成熟度和採用水平，直到一段時間以前，可是如今像Uber，Alibaba，CapitalOne這樣的公司正在大規模使用Flink流傳輸，證實了Flink Streaming的潛力。

最近，Uber開源了其最新的流分析框架AthenaX，該框架基於Flink引擎構建。

若是您已經注意到，須要注意的重要一點是，全部支持狀態管理的原生流框架（例如Flink，Kafka Streams，Samza）在內部都使用RocksDb。RocksDb從某種意義上說是獨一無二的，它在每一個節點上本地保持持久狀態，而且性能很高。它已成爲新流系統的關鍵部分。

如何選擇最佳的流媒體框架：

這是最重要的部分。誠實的答案是：這取決於 :

必須牢記，對於每一個用例，沒有一個單一的處理框架能夠成爲萬靈丹。每一個框架都有其優勢和侷限性。儘管如此，根據一些經驗，他們仍然會分享一些有助於作出決定的建議：

1. 取決於用例：
   若是用例很簡單，那麼若是學習和實現起來很複雜，則無需尋求最新，最好的框架。在很大程度上取決於咱們願意投資多少來換取咱們想要的回報。例如，若是它是基於事件的簡單IOT事件警報系統，那麼Storm或Kafka Streams很是適合使用。
2. 將來考慮因素：
   同時，咱們還須要對將來可能的用例進行自覺考慮。未來可能會出現對諸如事件時間處理，聚合，流加入等高級功能的需求嗎？若是答案是確定的，則最好繼續使用高級流框架（例如Spark Streaming或Flink）。一旦對一項技術進行了投資和實施，其變動的困難和巨大成本將在之後改變。例如，在以前的公司中，從過去的兩年開始，Storm管道就已經啓動並運行，而且在要求統一輸入事件並僅報告惟一事件以前，它一直運行良好。如今，這須要狀態管理，而Storm自己並不支持這種狀態管理。雖然我使用基於時間的內存哈希表實現，可是在重啓時狀態會消失是有限制的。
3. 我要提出的觀點是，若是咱們嘗試自行實現框架未明確提供的某些內容，則勢必會遇到未知問題。
4. 現有技術堆棧：
   另外一重要點是考慮現有技術堆棧。若是現有堆棧的首尾相連是Kafka，則Kafka Streams或Samza可能更容易安裝。一樣，若是處理管道基於Lambda架構，而且Spark Ba​​tch或Flink Batch已經到位，則考慮使用Spark Streaming或Flink Streaming是有意義的。例如，在我之前的項目中，我已經在管道中添加了Spark Ba​​tch，所以，當流需求到來時，選擇須要幾乎相同的技能和代碼庫的Spark Streaming很是容易。

簡而言之，若是咱們很好地瞭解框架的優勢和侷限性以及用例，那麼選擇或至少過濾掉可用的選項就更加容易。最後，一旦選擇了幾個選項。畢竟每一個人都有不一樣的選擇。

Streaming的發展速度如此之快，以致於在信息方面，此帖子可能在幾年後已通過時。目前，Spark和Flink在開發方面是領先的重量級人物，但仍有一些新手能夠加入比賽。Apache Apex是其中之一。還有一些我沒有介紹的專有流解決方案，例如Google Dataflow。個人這篇文章的目的是幫助剛接觸流技術的人以最少的術語理解流技術的一些核心概念，以及流行的開源流框架的優勢，侷限性和用例。但願該文章對您有所幫助。

更多實時數據分析相關博文與科技資訊，歡迎關注 「實時流式計算」