許多分布式計算系統(tǒng)都可以實時或接近實時地處理大數(shù)據(jù)流。本文將對三種Apache框架分別進(jìn)行簡單介紹,然后嘗試快速、高度概述其異同。
Apache Storm
在Storm中,先要設(shè)計一個用于實時計算的圖狀結(jié)構(gòu),我們稱之為拓?fù)洌╰opology)。這個拓?fù)鋵惶峤唤o集群,由集群中的主控節(jié)點(master node)分發(fā)代碼,將任務(wù)分配給工作節(jié)點(worker node)執(zhí)行。一個拓?fù)渲邪╯pout和bolt兩種角色,其中spout發(fā)送消息,負(fù)責(zé)將數(shù)據(jù)流以tuple元組的形式發(fā)送出去;而bolt則負(fù)責(zé)轉(zhuǎn)換這些數(shù)據(jù)流,在bolt中可以完成計算、過濾等操作,bolt自身也可以隨機(jī)將數(shù)據(jù)發(fā)送給其他bolt。由spout發(fā)射出的tuple是不可變數(shù)組,對應(yīng)著固定的鍵值對。
Apache Spark
Spark Streaming是核心Spark API的一個擴(kuò)展,它并不會像Storm那樣一次一個地處理數(shù)據(jù)流,而是在處理前按時間間隔預(yù)先將其切分為一段一段的批處理作業(yè)。Spark針對持續(xù)性數(shù)據(jù)流的抽象稱為DStream(DiscretizedStream),一個DStream是一個微批處理(micro-batching)的RDD(彈性分布式數(shù)據(jù)集);而RDD則是一種分布式數(shù)據(jù)集,能夠以兩種方式并行運作,分別是任意函數(shù)和滑動窗口數(shù)據(jù)的轉(zhuǎn)換。
Apache Samza
Samza處理數(shù)據(jù)流時,會分別按次處理每條收到的消息。Samza的流單位既不是元組,也不是Dstream,而是一條條消息。在Samza中,數(shù)據(jù)流被切分開來,每個部分都由一組只讀消息的有序數(shù)列構(gòu)成,而這些消息每條都有一個特定的ID(offset)。該系統(tǒng)還支持批處理,即逐次處理同一個數(shù)據(jù)流分區(qū)的多條消息。Samza的執(zhí)行與數(shù)據(jù)流模塊都是可插拔式的,盡管Samza的特色是依賴Hadoop的Yarn(另一種資源調(diào)度器)和Apache Kafka。

共同之處
以上三種實時計算系統(tǒng)都是開源的分布式系統(tǒng),具有低延遲、可擴(kuò)展和容錯性諸多優(yōu)點,它們的共同特色在于:允許你在運行數(shù)據(jù)流代碼時,將任務(wù)分配到一系列具有容錯能力的計算機(jī)上并行運行。此外,它們都提供了簡單的API來簡化底層實現(xiàn)的復(fù)雜程度。
三種框架的術(shù)語名詞不同,但是其代表的概念十分相似:
對比圖
下面表格總結(jié)了一些不同之處:

數(shù)據(jù)傳遞形式分為三大類:
1.最多一次(At-most-once):消息可能會丟失,這通常是最不理想的結(jié)果。
2.最少一次(At-least-once):消息可能會再次發(fā)送(沒有丟失的情況,但是會產(chǎn)生冗余)。在許多用例中已經(jīng)足夠。
3.恰好一次(Exactly-once):每條消息都被發(fā)送過一次且僅僅一次(沒有丟失,沒有冗余)。這是情況,盡管很難保證在所有用例中都實現(xiàn)。
另一個方面是狀態(tài)管理:對狀態(tài)的存儲有不同的策略,Spark Streaming將數(shù)據(jù)寫入分布式文件系統(tǒng)中(例如HDFS);Samza使用嵌入式鍵值存儲;而在Storm中,或者將狀態(tài)管理滾動至應(yīng)用層面,或者使用更高層面的抽象Trident。
用例
這三種框架在處理連續(xù)性的大量實時數(shù)據(jù)時的表現(xiàn)均出色而高效,那么使用哪一種呢?選擇時并沒有什么硬性規(guī)定,最多就是幾個指導(dǎo)方針。
如果你想要的是一個允許增量計算的高速事件處理系統(tǒng),Storm會是選擇。它可以應(yīng)對你在客戶端等待結(jié)果的同時,進(jìn)一步進(jìn)行分布式計算的需求,使用開箱即用的分布式RPC(DRPC)就可以了。最后但同樣重要的原因:Storm使用Apache Thrift,你可以用任何編程語言來編寫拓?fù)浣Y(jié)構(gòu)。如果你需要狀態(tài)持續(xù),同時/或者達(dá)到恰好一次的傳遞效果,應(yīng)當(dāng)看看更高層面的Trdent API,它同時也提供了微批處理的方式。

使用Storm的公司有:Twitter,雅虎,Spotify還有The Weather Channel等。
說到微批處理,如果你必須有狀態(tài)的計算,恰好一次的遞送,并且不介意高延遲的話,那么可以考慮Spark Streaming,特別如果你還計劃圖形操作、機(jī)器學(xué)習(xí)或者訪問SQL的話,Apache Spark的stack允許你將一些library與數(shù)據(jù)流相結(jié)合(Spark SQL,Mllib,GraphX),它們會提供便捷的一體化編程模型。尤其是數(shù)據(jù)流算法(例如:K均值流媒體)允許Spark實時決策的促進(jìn)。
使用Spark的公司有:亞馬遜,雅虎,NASA JPL,eBay還有百度等。
如果你有大量的狀態(tài)需要處理,比如每個分區(qū)都有許多十億位元組,那么可以選擇Samza。由于Samza將存儲與處理放在同一臺機(jī)器上,在保持處理高效的同時,還不會額外載入內(nèi)存。這種框架提供了靈活的可插拔API:它的默認(rèn)execution、消息發(fā)送還有存儲引擎操作都可以根據(jù)你的選擇隨時進(jìn)行替換。此外,如果你有大量的數(shù)據(jù)流處理階段,且分別來自不同代碼庫的不同團(tuán)隊,那么Samza的細(xì)顆粒工作特性會尤其適用,因為它們可以在影響最小化的前提下完成增加或移除的工作。
使用Samza的公司有:LinkedIn,Intuit,Metamarkets,Quantiply,F(xiàn)ortscale等。
結(jié)論
本文中我們只對這三種Apache框架進(jìn)行了簡單的了解,并未覆蓋到這些框架中大量的功能與更多細(xì)微的差異。同時,文中這三種框架對比也是受到限制的,因為這些框架都在一直不斷的發(fā)展,這一點是我們應(yīng)當(dāng)牢記的。