一、hadoop、Storm該選哪一個(gè)?

為了區(qū)別hadoop和Storm，該部分將回答如下問(wèn)題：

1.hadoop、Storm各是什么運(yùn)算

2.Storm為什么被稱之為流式計(jì)算系統(tǒng)

3.hadoop適合什么場(chǎng)景，什么情況下使用hadoop

4.什么是吞吐量

首先整體認(rèn)識(shí)：Hadoop是磁盤級(jí)計(jì)算，進(jìn)行計(jì)算時(shí)，數(shù)據(jù)在磁盤上，需要讀寫磁盤;Storm是內(nèi)存級(jí)計(jì)算，數(shù)據(jù)直接通過(guò)網(wǎng)絡(luò)導(dǎo)入內(nèi)存。讀寫內(nèi)存比讀寫磁盤速度快n個(gè)數(shù)量級(jí)。根據(jù)Harvard CS61課件，磁盤訪問(wèn)延遲約為內(nèi)存訪問(wèn)延遲的75000倍。所以Storm更快。

注釋：

1. 延時(shí) ， 指數(shù)據(jù)從產(chǎn)生到運(yùn)算產(chǎn)生結(jié)果的時(shí)間，“快”應(yīng)該主要指這個(gè)。

2. 吞吐， 指系統(tǒng)單位時(shí)間處理的數(shù)據(jù)量。

storm的網(wǎng)絡(luò)直傳、內(nèi)存計(jì)算，其時(shí)延必然比hadoop的通過(guò)hdfs傳輸?shù)偷枚?當(dāng)計(jì)算模型比較適合流式時(shí)，storm的流式處理，省去了批處理的收集數(shù)據(jù)的時(shí)間;因?yàn)閟torm是服務(wù)型的作業(yè)，也省去了作業(yè)調(diào)度的時(shí)延。所以從時(shí)延上來(lái)看，storm要快于hadoop。

從原理角度來(lái)講：

· Hadoop M/R基于HDFS，需要切分輸入數(shù)據(jù)、產(chǎn)生中間數(shù)據(jù)文件、排序、數(shù)據(jù)壓縮、多份復(fù)制等，效率較低。

· Storm 基于ZeroMQ這個(gè)高性能的消息通訊庫(kù)，不持久化數(shù)據(jù)。

為什么storm比hadoop快，下面舉一個(gè)應(yīng)用場(chǎng)景

說(shuō)一個(gè)典型的場(chǎng)景，幾千個(gè)日志生產(chǎn)方產(chǎn)生日志文件，需要進(jìn)行一些ETL操作存入一個(gè)數(shù)據(jù)庫(kù)。

假設(shè)利用hadoop，則需要先存入hdfs，按每一分鐘切一個(gè)文件的粒度來(lái)算(這個(gè)粒度已經(jīng)極端的細(xì)了，再小的話hdfs上會(huì)一堆小文件)，hadoop開始計(jì)算時(shí)，1分鐘已經(jīng)過(guò)去了，然后再開始調(diào)度任務(wù)又花了一分鐘，然后作業(yè)運(yùn)行起來(lái)，假設(shè)機(jī)器特別多，幾鈔鐘就算完了，然后寫數(shù)據(jù)庫(kù)假設(shè)也花了很少的時(shí)間，這樣，從數(shù)據(jù)產(chǎn)生到最后可以使用已經(jīng)過(guò)去了至少兩分多鐘。

而流式計(jì)算則是數(shù)據(jù)產(chǎn)生時(shí)，則有一個(gè)程序去一直監(jiān)控日志的產(chǎn)生，產(chǎn)生一行就通過(guò)一個(gè)傳輸系統(tǒng)發(fā)給流式計(jì)算系統(tǒng)，然后流式計(jì)算系統(tǒng)直接處理，處理完之后直接寫入數(shù)據(jù)庫(kù)，每條數(shù)據(jù)從產(chǎn)生到寫入數(shù)據(jù)庫(kù)，在資源充足時(shí)可以在毫秒級(jí)別完成。

同時(shí)說(shuō)一下另外一個(gè)場(chǎng)景：

如果一個(gè)大文件的wordcount，把它放到storm上進(jìn)行流式的處理，等所有已有數(shù)據(jù)處理完才讓storm輸出結(jié)果，這時(shí)候，你再把它和hadoop比較快慢，這時(shí)，其實(shí)比較的不是時(shí)延，而是比較的吞吐了。

-------------------------------------------------------------------------------

最主要的方面：Hadoop使用磁盤作為中間交換的介質(zhì)，而storm的數(shù)據(jù)是一直在內(nèi)存中流轉(zhuǎn)的。

兩者面向的領(lǐng)域也不完全相同，一個(gè)是批量處理，基于任務(wù)調(diào)度的;另外一個(gè)是實(shí)時(shí)處理，基于流。

以水為例，Hadoop可以看作是純凈水，一桶桶地搬;而Storm是用水管，預(yù)先接好(Topology)，然后打開水龍頭，水就源源不斷地流出來(lái)了。

-------------------------------------------------------------------------------

Storm的主工程師Nathan Marz表示： Storm可以方便地在一個(gè)計(jì)算機(jī)集群中編寫與擴(kuò)展復(fù)雜的實(shí)時(shí)計(jì)算，Storm之于實(shí)時(shí)處理，就好比Hadoop之于批處理。Storm保證每個(gè)消息都會(huì)得到處理，而且它很快——在一個(gè)小集群中，每秒可以處理數(shù)以百萬(wàn)計(jì)的消息。更棒的是你可以使用任意編程語(yǔ)言來(lái)做開發(fā)。

Storm的主要特點(diǎn)如下：

1.簡(jiǎn)單的編程模型。類似于MapReduce降低了并行批處理復(fù)雜性，Storm降低了進(jìn)行實(shí)時(shí)處理的復(fù)雜性。

2.可以使用各種編程語(yǔ)言。你可以在Storm之上使用各種編程語(yǔ)言。默認(rèn)支持Clojure、Java、Ruby和Python。要增加對(duì)其他語(yǔ)言的支持，只需實(shí)現(xiàn)一個(gè)簡(jiǎn)單的Storm通信協(xié)議即可。

3.容錯(cuò)性。Storm會(huì)管理工作進(jìn)程和節(jié)點(diǎn)的故障。

4.水平擴(kuò)展。計(jì)算是在多個(gè)線程、進(jìn)程和服務(wù)器之間并行進(jìn)行的。

5.可靠的消息處理。Storm保證每個(gè)消息至少能得到一次完整處理。任務(wù)失敗時(shí)，它會(huì)負(fù)責(zé)從消息源重試消息。

6.快速。系統(tǒng)的設(shè)計(jì)保證了消息能得到快速的處理，使用MQ作為其底層消息隊(duì)列。

7.本地模式。Storm有一個(gè)“本地模式”，可以在處理過(guò)程中完全模擬Storm集群。這讓你可以快速進(jìn)行開發(fā)和單元測(cè)試。

-------------------------------------------------------------------------------

在消耗資源相同的情況下，一般來(lái)說(shuō)storm的延時(shí)低于mapreduce。但是吞吐也低于mapreduce。storm是典型的流計(jì)算系統(tǒng)，mapreduce是典型的批處理系統(tǒng)。下面對(duì)流計(jì)算和批處理系統(tǒng)流程

這個(gè)個(gè)數(shù)據(jù)處理流程來(lái)說(shuō)大致可以分三個(gè)階段：

1. 數(shù)據(jù)采集與準(zhǔn)備

2. 數(shù)據(jù)計(jì)算(涉及計(jì)算中的中間存儲(chǔ))， 題主中的“那些方面決定”應(yīng)該主要是指這個(gè)階段處理方式。

3. 數(shù)據(jù)結(jié)果展現(xiàn)(反饋)

1)數(shù)據(jù)采集階段，目前典型的處理策略：數(shù)據(jù)的產(chǎn)生系統(tǒng)一般出自頁(yè)面打點(diǎn)和解析DB的log，流計(jì)算將數(shù)據(jù)采集中消息隊(duì)列(比如kafaka,metaQ,timetunle)等。批處理系統(tǒng)一般將數(shù)據(jù)采集進(jìn)分布式文件系統(tǒng)(比如HDFS)，當(dāng)然也有使用消息隊(duì)列的。我們暫且把消息隊(duì)列和文件系統(tǒng)稱為預(yù)處理存儲(chǔ)。二者在延時(shí)和吞吐上沒太大區(qū)別，接下來(lái)從這個(gè)預(yù)處理存儲(chǔ)進(jìn)入到數(shù)據(jù)計(jì)算階段有很大的區(qū)別，流計(jì)算一般在實(shí)時(shí)的讀取消息隊(duì)列進(jìn)入流計(jì)算系統(tǒng)(storm)的數(shù)據(jù)進(jìn)行運(yùn)算，批處理一系統(tǒng)一般會(huì)攢一大批后批量導(dǎo)入到計(jì)算系統(tǒng)(hadoop)，這里就有了延時(shí)的區(qū)別。

2)數(shù)據(jù)計(jì)算階段，流計(jì)算系統(tǒng)(storm)的延時(shí)低主要有以下幾個(gè)方面(針對(duì)題主的問(wèn)題)

A： storm 進(jìn)程是常駐的，有數(shù)據(jù)就可以進(jìn)行實(shí)時(shí)的處理

mapreduce 數(shù)據(jù)攢一批后由作業(yè)管理系統(tǒng)啟動(dòng)任務(wù)，Jobtracker計(jì)算任務(wù)分配，tasktacker啟動(dòng)相關(guān)的運(yùn)算進(jìn)程

B： stom每個(gè)計(jì)算單元之間數(shù)據(jù)之間通過(guò)網(wǎng)絡(luò)(zeromq)直接傳輸。

mapreduce map任務(wù)運(yùn)算的結(jié)果要寫入到HDFS，在于reduce任務(wù)通過(guò)網(wǎng)絡(luò)拖過(guò)去運(yùn)算。相對(duì)來(lái)說(shuō)多了磁盤讀寫，比較慢

C： 對(duì)于復(fù)雜運(yùn)算

storm的運(yùn)算模型直接支持DAG(有向無(wú)環(huán)圖)
mapreduce 需要肯多個(gè)MR過(guò)程組成，有些map操作沒有意義的

3)數(shù)據(jù)結(jié)果展現(xiàn)

流計(jì)算一般運(yùn)算結(jié)果直接反饋到最終結(jié)果集中(展示頁(yè)面，數(shù)據(jù)庫(kù)，搜索引擎的索引)。而mapreduce一般需要整個(gè)運(yùn)算結(jié)束后將結(jié)果批量導(dǎo)入到結(jié)果集中。

實(shí)際流計(jì)算和批處理系統(tǒng)沒有本質(zhì)的區(qū)別，像storm的trident也有批概念，而mapreduce可以將每次運(yùn)算的數(shù)據(jù)集縮小(比如幾分鐘啟動(dòng)一次)，facebook的puma就是基于hadoop做的流計(jì)算系統(tǒng)。

二、高性能并行計(jì)算引擎Storm和Spark比較

(一)、spark與storm的比較

 

 

(二)、Spark Streaming與Storm的應(yīng)用場(chǎng)景

適用Storm的場(chǎng)景：

1、需要純實(shí)時(shí)，不能忍受1秒以上延遲的場(chǎng)景下使用，比如實(shí)時(shí)金融系統(tǒng)，要求純實(shí)時(shí)進(jìn)行金融交易和分析

2、對(duì)于實(shí)時(shí)計(jì)算的功能中，要求可靠的事務(wù)機(jī)制和可靠性機(jī)制，即數(shù)據(jù)的處理完全精準(zhǔn)，一條也不能多，一條也不能少，也可以考慮使用Storm

3、若還需要針對(duì)高峰低峰時(shí)間段，動(dòng)態(tài)調(diào)整實(shí)時(shí)計(jì)算程序的并行度，以最大限度利用集群資源(通常是在小型公司，集群資源緊張的情況)，也可以考慮用Storm

4、如果一個(gè)大數(shù)據(jù)應(yīng)用系統(tǒng)，它就是純粹的實(shí)時(shí)計(jì)算，不需要在中間執(zhí)行SQL交互式查詢、復(fù)雜的transformation算子等，那么用Storm是比較好的選擇

適用Spark Streaming的場(chǎng)景：

1、如果對(duì)上述適用于Storm的三點(diǎn)，一條都不滿足的實(shí)時(shí)場(chǎng)景，即：不要求純實(shí)時(shí)，不要求強(qiáng)大可靠的事務(wù)機(jī)制，不要求動(dòng)態(tài)調(diào)整并行度，那么可以考慮使用Spark Streaming

2、考慮使用Spark Streaming最主要的一個(gè)因素，應(yīng)該是針對(duì)整個(gè)項(xiàng)目進(jìn)行宏觀的考慮，即：如果一個(gè)項(xiàng)目除了實(shí)時(shí)計(jì)算之外，還包括了離線批處理、交互式查詢等業(yè)務(wù)功能，而且實(shí)時(shí)計(jì)算中，可能還會(huì)牽扯到高延遲批處理、交互式查詢等功能，那么就應(yīng)該首選Spark生態(tài)，用Spark Core開發(fā)離線批處理，用Spark SQL開發(fā)交互式查詢，用Spark Streaming開發(fā)實(shí)時(shí)計(jì)算，三者可以無(wú)縫整合，給系統(tǒng)提供非常高的可擴(kuò)展性 Spark Streaming與Storm的優(yōu)劣分析事實(shí)上，Spark Streaming絕對(duì)談不上比Storm優(yōu)秀。

總之，這兩個(gè)框架在實(shí)時(shí)計(jì)算領(lǐng)域都很優(yōu)秀，只是擅長(zhǎng)的細(xì)分場(chǎng)景并不相同。Spark Streaming僅僅在吞吐量上比Storm要優(yōu)秀，而吞吐量這一點(diǎn)，也是歷來(lái)挺Spark Streaming貶Storm的人著重強(qiáng)調(diào)的。但是問(wèn)題是，是不是在所有的實(shí)時(shí)計(jì)算場(chǎng)景下，都那么注重吞吐量?不盡然。因此，通過(guò)吞吐量說(shuō)Spark Streaming強(qiáng)于Storm，不靠譜。事實(shí)上，Storm在實(shí)時(shí)延遲度上，比Spark Streaming就好多了，前者是純實(shí)時(shí)，后者是準(zhǔn)實(shí)時(shí)。而且，Storm的事務(wù)機(jī)制、健壯性 / 容錯(cuò)性、動(dòng)態(tài)調(diào)整并行度等特性，都要比Spark Streaming更加優(yōu)秀。Spark Streaming，有一點(diǎn)是Storm絕對(duì)比不上的，就是：它位于Spark生態(tài)技術(shù)棧中，因此Spark Streaming可以和Spark Core、Spark SQL無(wú)縫整合，也就意味著，我們可以對(duì)實(shí)時(shí)處理出來(lái)的中間數(shù)據(jù)，立即在程序中無(wú)縫進(jìn)行延遲批處理、交互式查詢等操作。這個(gè)特點(diǎn)大大增強(qiáng)了Spark Streaming的優(yōu)勢(shì)和功能。

標(biāo)簽： 大數(shù)據(jù) 大數(shù)據(jù)應(yīng)用 服務(wù)器 金融 數(shù)據(jù)庫(kù) 搜索 搜索引擎 通信 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。