三個大資料處理框架:Storm,Spark和Samza介紹比較

桃子紅了吶發表於2017-11-15

轉自:http://www.open-open.com/lib/view/open1426065900123.html

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

Apache Storm

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

Storm的流處理可對框架中名為Topology(拓撲)的DAG(Directed Acyclic Graph,有向無環圖)進行編排。這些拓撲描述了當資料片段進入系統後,需要對每個傳入的片段執行的不同轉換或步驟。

三個大資料處理框架:Storm,Spark和Samza 介紹比較

 

Apache Spark

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

三個大資料處理框架:Storm,Spark和Samza 介紹比較

 

Apache Samza

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

三個大資料處理框架:Storm,Spark和Samza 介紹比較

Samza可以使用以本地鍵值儲存方式實現的容錯檢查點系統儲存資料。這樣Samza即可獲得“至少一次”的交付保障,但面對由於資料可能多次交付造成的失敗,該技術無法對彙總後狀態(例如計數)提供精確恢復。

共同之處

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

三種框架的術語名詞不同,但是其代表的概念十分相似:

三個大資料處理框架:Storm,Spark和Samza 介紹比較

 

對比圖

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

三個大資料處理框架:Storm,Spark和Samza 介紹比較

 

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

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

另一個方面是狀態管理:對狀態的儲存有不同的策略,Spark Streaming將資料寫入分散式檔案系統中(例如HDFS);Samza使用嵌入式鍵值儲存;而在Storm中,或者將狀態管理滾動至應用層面,或者使用更高層面的抽象Trident。


本文轉自張昺華-sky部落格園部落格,原文連結:http://www.cnblogs.com/bonelee/p/6295656.html,如需轉載請自行聯絡原作者


相關文章