流式大資料處理的三種架構：Storm，Spark和Samza

標籤：

流式大資料處理的三種架構：Storm，Spark和Samza

許多分散式運算系統都可以即時或接近即時地處理大資料流。本文將對Storm、Spark和Samza等三種Apache架構分別進行簡單介紹，然後嘗試快速、高度概述其異同。

許多分散式運算系統都可以即時或接近即時地處理大資料流。本文將對三種Apache架構分別進行簡單介紹，然後嘗試快速、高度概述其異同。

Apache Storm

在Storm中，先要設計一個用於即時計算的圖狀結構，我們稱之為拓撲（topology）。這個拓撲將會被提交給叢集，由叢集中的主控節點（master node）分發代碼，將任務分配給工作節點（worker node）執行。一個拓撲中包括spout和bolt兩種角色，其中spout發送訊息，負責將資料流以tuple元組的形式發送出去；而bolt則負責轉換這些資料流，在bolt中可以完成計算、過濾等操作，bolt自身也可以隨機將資料發送給其他bolt。由spout發射出的tuple是不可變數組，對應著固定的索引值對。

 

Apache Spark

Spark Streaming是核心Spark API的一個擴充，它並不會像Storm那樣一次一個地處理資料流，而是在處理前按時間間隔預先將其切分為一段一段的批次工作。Spark針對持久性資料流的抽象稱為DStream（DiscretizedStream），一個DStream是一個微批處理（micro-batching）的RDD（彈性分布式資料集）；而RDD則是一種分布式資料集，能夠以兩種方式並行運作，分別是任意函數和滑動視窗資料的轉換。

 

Apache Samza

Samza處理資料流時，會分別按次處理每條收到的訊息。Samza的流單位既不是元組，也不是Dstream，而是一條條訊息。在Samza中，資料流被切分開來，每個部分都由一組唯讀訊息的有序數列構成，而這些訊息每條都有一個特定的ID（offset）。該系統還支援批處理，即逐次處理同一個資料流分區的多條訊息。Samza的執行與資料流模組都是可插拔式的，儘管Samza的特色是依賴Hadoop的Yarn（另一種資源調度器）和Apache Kafka。

 

共同之處

以上三種即時計算系統都是開源的分布式系統，具有低延遲、可擴充和容錯性諸多優點，它們的共同特色在於：允許你在運行資料流代碼時，將任務分配到一系列具有容錯能力的電腦上並行運行。此外，它們都提供了簡單的API來簡化底層實現的複雜程度。

三種架構的術語名詞不同，但是其代表的概念十分相似：

 

對比圖

下面表格總結了一些不同之處：

 

資料傳遞形式分為三大類：

 

1. 最多一次（At-most-once）：訊息可能會丟失，這通常是最不理想的結果。
2. 最少一次（At-least-once）：訊息可能會再次發送（沒有丟失的情況，但是會產生冗餘）。在許多用例中已經足夠。
3. 恰好一次（Exactly-once）：每條訊息都被發送過一次且僅僅一次（沒有丟失，沒有冗餘）。這是最佳情況，儘管很難保證在所有用例中都實現。

 

另一個方面是狀態管理：對狀態的儲存有不同的策略，Spark Streaming將資料寫入Distributed File System中（例如HDFS）；Samza使用嵌入式KVStore for Redis；而在Storm中，或者將狀態管理滾動至應用程式層面，或者使用更高層面的抽象Trident。

用例

這三種架構在處理連續性的大量即時資料時的表現均出色而高效，那麼使用哪一種呢？選擇時並沒有什麼硬性規定，最多就是幾個指導方針。

如果你想要的是一個允許增量計算的高速事件處理系統，Storm會是最佳選擇。它可以應對你在用戶端等待結果的同時，進一步進行分散式運算的需求，使用開箱即用的分布式RPC（DRPC）就可以了。最後但同樣重要的原因：Storm使用Apache Thrift，你可以用任何程式設計語言來編寫拓撲結構。如果你需要狀態持續，同時/或者達到恰好一次的傳遞效果，應當看看更高層面的Trdent API，它同時也提供了微批處理的方式。

 

使用Storm的公司有：Twitter，雅虎，Spotify還有The Weather Channel等。

說到微批處理，如果你必須有狀態的計算，恰好一次的遞送，並且不介意高延遲的話，那麼可以考慮Spark Streaming，特別如果你還計劃圖形操作、機器學習或者訪問SQL的話，Apache Spark的stack允許你將一些library與資料流相結合（Spark SQL，Mllib，GraphX），它們會提供便捷的一體化編程模型。尤其是資料流演算法（例如：K均值流媒體）允許Spark即時決策的促進。

使用Spark的公司有：亞馬遜，雅虎，NASA JPL，eBay還有百度等。

如果你有大量的狀態需要處理，比如每個分區都有許多十億位元組，那麼可以選擇Samza。由於Samza將儲存與處理放在同一台機器上，在保持處理高效的同時，還不會額外載入記憶體。這種架構提供了靈活的可插拔API：它的預設execution、訊息發送還有儲存引擎操作都可以根據你的選擇隨時進行替換。此外，如果你有大量的資料流處理階段，且分別來自不同程式碼程式庫的不同團隊，那麼Samza的細顆粒工作特性會尤其適用，因為它們可以在影響最小化的前提下完成增加或移除的工作。

使用Samza的公司有：LinkedIn，Intuit，Metamarkets，Quantiply，Fortscale等。

結論

本文中我們只對這三種Apache架構進行了簡單的瞭解，並未覆蓋到這些架構中大量的功能與更多細微的差異。同時，文中這三種架構對比也是受到限制的，因為這些架構都在一直不斷的發展，這一點是我們應當牢記的。

原文連結：Streaming Big Data: Storm, Spark and Samza （編譯/孫薇 責編/周建丁 ）

流式大資料處理的三種架構：Storm，Spark和Samza