Apache Storm

在Storm中，先要設(shè)計(jì)一個(gè)用于實(shí)時(shí)計(jì)算的圖狀結(jié)構(gòu)，我們稱之為拓?fù)洌╰opology）。這個(gè)拓?fù)鋵?huì)被提交給集群，由集群中的主控節(jié)點(diǎn)（master node）分發(fā)代碼，將任務(wù)分配給工作節(jié)點(diǎn)（worker node）執(zhí)行。一個(gè)拓?fù)渲邪╯pout和bolt兩種角色，其中spout發(fā)送消息，負(fù)責(zé)將數(shù)據(jù)流以tuple元組的形式發(fā)送出去；而bolt則負(fù)責(zé)轉(zhuǎn)發(fā)數(shù)據(jù)流，在bolt中可以完成計(jì)算、過(guò)濾等操作，bolt自身也可以隨機(jī)將數(shù)據(jù)發(fā)送給其他bolt。在storm中，每個(gè)都是tuple是不可變數(shù)組，對(duì)應(yīng)著固定的鍵值對(duì)。 

Apache Spark

是核心Spark API的一個(gè)擴(kuò)展，它并不會(huì)像Storm那樣一次一個(gè)地處理數(shù)據(jù)流，而是在處理前按時(shí)間間隔預(yù)先將其切分為一段一段的批處理作業(yè)。Spark針對(duì)持續(xù)性數(shù)據(jù)流的抽象稱為DStream（DiscretizedStream），一個(gè)DStream是一個(gè)微批處理（micro-batching）的RDD（彈性分布式數(shù)據(jù)集）；而RDD則是一種分布式數(shù)據(jù)集，能夠以兩種方式并行運(yùn)作，分別是任意函數(shù)和滑動(dòng)窗口數(shù)據(jù)的轉(zhuǎn)換。 

Apache Samza 

處理數(shù)據(jù)流時(shí)，會(huì)分別按次處理每條收到的消息。Samza的流單位既不是元組，也不是Dstream，而是一條條消息。在Samza中，數(shù)據(jù)流被切分開來(lái)，每個(gè)部分都由一組只讀消息的有序數(shù)列構(gòu)成，而這些消息每條都有一個(gè)特定的ID（offset）。該系統(tǒng)還支持批處理，即逐次處理同一個(gè)數(shù)據(jù)流分區(qū)的多條消息。Samza的執(zhí)行與數(shù)據(jù)流模塊都是可插拔式的，盡管Samza的特色是依賴Hadoop的Yarn（另一種資源調(diào)度器）和Apache Kafka。 

共同之處

以上三種實(shí)時(shí)計(jì)算系統(tǒng)都是開源的分布式系統(tǒng)，具有低延遲、可擴(kuò)展和容錯(cuò)性諸多優(yōu)點(diǎn)，它們的共同特色在于：允許你在運(yùn)行數(shù)據(jù)流代碼時(shí)，將任務(wù)分配到一系列具有容錯(cuò)能力的計(jì)算機(jī)上并行運(yùn)行。此外，它們都提供了簡(jiǎn)單的API來(lái)簡(jiǎn)化底層實(shí)現(xiàn)的復(fù)雜程度。 

三種框架的術(shù)語(yǔ)名詞不同，但是其代表的概念十分相似：

不同之處

下面表格總結(jié)了一些不同之處：

數(shù)據(jù)傳遞形式分為三大類：

• 最多一次（At-most-once）：消息可能會(huì)丟失，這通常是最不理想的結(jié)果。
• 最少一次（At-least-once）：消息可能會(huì)再次發(fā)送（沒(méi)有丟失的情況，但是會(huì)產(chǎn)生冗余）。在許多用例中已經(jīng)足夠。 
• 恰好一次（Exactly-once）：每條消息都被發(fā)送過(guò)一次且僅僅一次（沒(méi)有丟失，沒(méi)有冗余）。這是最佳情況，盡管很難保證在所有用例中都實(shí)現(xiàn)。 

另一個(gè)方面是狀態(tài)管理：對(duì)狀態(tài)的存儲(chǔ)有不同的策略，Spark Streaming將數(shù)據(jù)寫入分布式文件系統(tǒng)中（例如HDFS）；Samza使用嵌入式鍵值存儲(chǔ)；而在Storm中，或者將狀態(tài)管理滾動(dòng)至應(yīng)用層面，或者使用更高層面的抽象Trident。 

用例

這三種框架在處理連續(xù)性的大量實(shí)時(shí)數(shù)據(jù)時(shí)的表現(xiàn)均出色而高效，那么使用哪一種呢？選擇時(shí)并沒(méi)有什么硬性規(guī)定，最多就是幾個(gè)指導(dǎo)方針。 

如果你想要的是一個(gè)允許增量計(jì)算的高速事件處理系統(tǒng)，Storm會(huì)是最佳選擇。它可以應(yīng)對(duì)你在客戶端等待結(jié)果的同時(shí)，進(jìn)一步進(jìn)行分布式計(jì)算的需求，使用開箱即用的分布式RPC（DRPC）就可以了。最后但同樣重要的原因：Storm使用Apache Thrift，你可以用任何編程語(yǔ)言來(lái)編寫拓?fù)浣Y(jié)構(gòu)。如果你需要狀態(tài)持續(xù)，同時(shí)/或者達(dá)到恰好一次的傳遞效果，應(yīng)當(dāng)看看更高層面的Trdent API，它同時(shí)也提供了微批處理的方式。 

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

說(shuō)到微批處理，如果你必須有狀態(tài)的計(jì)算，恰好一次的遞送，并且不介意高延遲的話，那么可以考慮Spark Streaming，特別如果你還計(jì)劃圖形操作、機(jī)器學(xué)習(xí)或者訪問(wèn)SQL的話，Apache Spark的stack允許你將一些library與數(shù)據(jù)流相結(jié)合（Spark SQL，Mllib，GraphX），它們會(huì)提供便捷的一體化編程模型。尤其是數(shù)據(jù)流算法（例如：K均值流媒體）允許Spark實(shí)時(shí)決策的促進(jìn)。 

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

如果你有大量的狀態(tài)需要處理，比如每個(gè)分區(qū)都有許多十億位元組，那么可以選擇Samza。由于Samza將存儲(chǔ)與處理放在同一臺(tái)機(jī)器上，在保持處理高效的同時(shí)，還不會(huì)額外載入內(nèi)存。這種框架提供了靈活的可插拔API：它的默認(rèn)execution、消息發(fā)送還有存儲(chǔ)引擎操作都可以根據(jù)你的選擇隨時(shí)進(jìn)行替換。此外，如果你有大量的數(shù)據(jù)流處理階段，且分別來(lái)自不同代碼庫(kù)的不同團(tuán)隊(duì)，那么Samza的細(xì)顆粒工作特性會(huì)尤其適用，因?yàn)樗鼈兛梢栽谟绊懽钚』那疤嵯峦瓿稍黾踊蛞瞥墓ぷ鳌?nbsp;

使用Samza的公司有：LinkedIn，Intuit，Metamarkets，Quantiply，F(xiàn)ortscale等。

結(jié)論

本文中我們只對(duì)這三種Apache框架進(jìn)行了簡(jiǎn)單的了解，并未覆蓋到這些框架中大量的功能與更多細(xì)微的差異。同時(shí)，文中這三種框架對(duì)比也是受到限制的，因?yàn)檫@些框架都在一直不斷的發(fā)展，這一點(diǎn)是我們應(yīng)當(dāng)牢記的。 

本文轉(zhuǎn)載自，原文：