Storm和Hadoop哪個快

本篇內容主要講解“Storm和Hadoop哪個快”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Storm和Hadoop哪個快”吧!

“快”這個詞是不明確的，專業屬于點有兩個層面：

1.時延 ， 指數據從產生到運算產生結果的時間，題主的“快”應該主要指這個。

2. 吞吐， 指系統單位時間處理的數據量。

首先明確一點，在消耗資源相同的情況下，一般來說storm的延時低于mapreduce。但是吞吐也低于mapreduce。

storm的網絡直傳、內存計算，其時延必然比hadoop的通過hdfs傳輸低得多;當計算模型比較適合流式時，storm的流式處理，省去了批處理的收集數據的時間;因為storm是服務型的作業，也省去了作業調度的時延。所以從時延上來看，storm要快于hadoop。

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

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

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

當然，跑一個大文件的wordcount，本來就是一個批處理計算的模型，你非要把它放到storm上進行流式的處理，然后又非要讓等所有已有數據處理完才讓storm輸出結果，這時候，你再把它和hadoop比較快慢，這時，其實比較的不是時延，而是比較的吞吐了。

storm是典型的流計算系統，mapreduce是典型的批處理系統。下面對流計算和批處理系統流程。

整個數據處理流程來說大致可以分三個階段：

1. 數據采集與準備

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

3. 數據結果展現(反饋)

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

2)數據計算階段，流計算系統(storm)的時延低主要有一下幾個方面

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

mapreduce 數據攢一批后由作業管理系統啟動任務，Jobtracker計算任務分配，tasktacker啟動相關的運算進程

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

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

C： 對于復雜運算

storm的運算模型直接支持DAG(有向無環圖)

mapreduce 需要肯多個MR過程組成，有些map操作沒有意義的

3)數據結果展現

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

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

到此，相信大家對“Storm和Hadoop哪個快”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！