一、hadoop、Storm該選哪一個?

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

1.hadoop、Storm各是什么運算

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

3.hadoop適合什么場景，什么情況下使用hadoop

4.什么是吞吐量

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

注釋：

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

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

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

從原理角度來講：

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

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

為什么storm比hadoop快，下面舉一個應用場景

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

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

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

同時說一下另外一個場景：

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

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

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

兩者面向的領域也不完全相同，一個是批量處理，基于任務調度的;另外一個是實時處理，基于流。

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

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

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

Storm的主要特點如下：

1.簡單的編程模型。類似于MapReduce降低了并行批處理復雜性，Storm降低了進行實時處理的復雜性。

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

3.容錯性。Storm會管理工作進程和節(jié)點的故障。

4.水平擴展。計算是在多個線程、進程和服務器之間并行進行的。

5.可靠的消息處理。Storm保證每個消息至少能得到一次完整處理。任務失敗時，它會負責從消息源重試消息。

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

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

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

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

這個個數(shù)據(jù)處理流程來說大致可以分三個階段：

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

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

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

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

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

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

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

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

mapreduce map任務運算的結果要寫入到HDFS，在于reduce任務通過網(wǎng)絡拖過去運算。相對來說多了磁盤讀寫，比較慢

C： 對于復雜運算

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

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

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

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

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

(一)、spark與storm的比較

 

 

(二)、Spark Streaming與Storm的應用場景

適用Storm的場景：

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

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

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

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

適用Spark Streaming的場景：

1、如果對上述適用于Storm的三點，一條都不滿足的實時場景，即：不要求純實時，不要求強大可靠的事務機制，不要求動態(tài)調整并行度，那么可以考慮使用Spark Streaming

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

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

標簽： 大數(shù)據(jù) 大數(shù)據(jù)應用 服務器 金融 數(shù)據(jù)庫 搜索 搜索引擎 通信 網(wǎng)絡

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