hadoop已被公認為大資料分析領域無可争辯的王者，它專注與批處理。這種模型對許多情形（比如：為網頁建立索引）已經足夠，但還存在其他一
些使用模型，它們需要來自高度動态的來源的實時資訊。為了解決這個問題，就得借助twitter推出得storm。storm不處理靜态資料，但它處理預
計會連續的流資料。考慮到twitter使用者每天生成1.4億條推文，那麼就很容易看到此技術的巨大用途。
但storm不隻是一個傳統的大資料分析系統：它是複雜事件處理（cep）系統的一個示例。cep系統通常分類為計算和面向檢測，其中每個系統都是通過使用者定義的算法在storm中實作。舉例而言，cep可用于識别事件洪流中有意義的事件，然後實時的處理這些事件。
這裡說的不适合,是一個相對的概念。如果業務對時延要求較低,那麼這個 問題就不存在了;但事實上企業中的有些業務要求是對時延有高要求的。下面我 就來說說:
storm 的網絡直傳與記憶體計算,其時延必然比 hadoop 的 hdfs 傳輸低得多;當計算模型比較适合流式時,storm
的流試處理,省去了批處理的收集資料的時 間;因為 storm 是服務型的作業,也省去了作業排程的時延。是以從時延的角 度來看,storm 要快于
hadoop,因而 storm 更适合做實時流水資料處理。下面用一個業務場景來描述這個時延問題。
幾千個日志生産方産生日志檔案,需要對這些日志檔案進行一些 etl 操作存 入資料庫。
我分别用 hadoop 和 storm 來分析下這個業務場景。假設我們用 hadoop 來 處理這個業務流程,則需要先存入
hdfs,按每一分鐘(達不到秒級别,分鐘是最小緯度)切一個檔案的粒度來計算。這個粒度已經極端的細了,再小的話 hdfs 上會一堆小檔案。接着
hadoop 開始計算時,一分鐘已經過去了,然後再開始 排程任務又花了一分鐘,然後作業運作起來,假設叢集比較大,幾秒鐘就計算完
成了,然後寫資料庫假設也花了很少時間(理想狀況下);這樣,從資料産生到 最後可以使用已經過去了至少兩分多鐘。
而我們來看看流式計算則是資料産生時,則有一個程式一直監控日志的産生, 産生一行就通過一個傳輸系統發給流式計算系統,然後流式計算系統直接處理, 處理完之後直接寫入資料庫,每條資料從産生到寫入資料庫,在資源充足(叢集 較大)時可以在毫秒級别完成。
在吞吐量方面,hadoop 卻是比 storm 有優勢;由于 hadoop 是一個批處理計算,相比 storm 的流式處理計算,hadoop 的吞吐量高于 storm。
hadoop 是基于 mapreduce 模型的,處理海量資料的離線分析工具,而
storm是分布式的,實時資料流分析工具,資料是源源不斷産生的,比如:twitter 的 timeline。另外,m/r
模型在實時領域很難有所發揮,它自身的設計特點決定了 資料源必須是靜态的。
hadoop
是磁盤級計算,進行計算時,資料在磁盤上,需要讀寫磁盤;storm是記憶體級計算,資料直接通過網絡導入記憶體。讀寫記憶體比讀寫磁盤速度快 n 個
數量級。根據行業結論,磁盤通路延遲約為記憶體通路延遲的 7.5w 倍,是以從這 個方面也可以看出,storm 從速度上更快。
在分析之前,我們先看看兩種計算架構的模型，首先我們看下mapreduce的模型，以wordcount為例，如下圖所示：
閱讀過hadoop源碼下的hadoop-mapreduce-project工程中的代碼應該對這個流程會熟悉，我這裡就不贅述這個流程了。
接着我們在來看下storm的模型，如下圖所示：
然後下面我們就會涉及到2個名額問題：延時和吞吐。
延時:指資料從産生到運算産生結果的時間。與“速度”息息相關。
吞吐:指系統機關時間處理的資料量。
另外,在資源相同的情況下;一般 storm 的延時要低于 mapreduce,但是
吞吐吞吐也要低于 mapreduce,下面我描述下流計算和批處理計算的流程。 整個資料處理流程來說大緻可以分為三個階段:
1. 資料采集階段
2. 資料計算(涉及計算中的中間存儲)
3. 資料結果展現(回報)
目前典型的處理政策:資料的産生系統一般出自 web 日志和解析 db 的
log,流計算資料采集是擷取的消息隊列(如:kafka,rabbitmq)等。批處理系統一
般将資料采集到分布式檔案系統(如:hdfs),當然也有使用消息隊列的。我們
暫且把消息隊列和檔案系統稱為預處理存儲。二者在這個階段的延時和吞吐上沒 太大的差別,接下來從這個預處理存儲到資料計算階段有很大的差別。流計算一
般在實時的讀取消息隊列進入流計算系統(storm)的資料進行運算,批處理系
統一般回累計大批資料後,批量導入到計算系統(hadoop),這裡就有了延時的 差別。
流計算系統(storm)的延時主要有以下幾個方面:
storm 程序是常駐的,有資料就可以進行實時的處理。mapreduce 資料累 計一批後由作業管理系統啟動任務,jobtracker 計算任務配置設定,tasktacker 啟動相關的運算程序。
storm 每個計算單元之間資料通過網絡(zeromq)直接傳輸。mapreduce map 任務運算的結果要寫入到 hdfs,在 reduce 任務通過網絡拖過去運算。 相對來說多了磁盤讀寫,比較慢。
對于複雜運算,storm的運算模型直接支援dag(有向無環圖,多個應用程 序存在依賴關系,後一個應用程式的 輸入為前一個的輸出),mapreduce 需 要多個 mr 過程組成,而且有些 map 操作沒有意義。
流計算一般運算結果直接回報到最終結果集中(展示頁面,資料庫,搜尋引擎的索引)。而 mapreduce 一般需要整個運算結束後将結果批量導入到結果集中。
storm 可以友善的在一個計算機叢集中編寫與擴充複雜的實時計算,storm 之于實時,就好比 hadoop 之于批處理。storm 保證每個消息都會得到處理,而 且速度很快,在一個小叢集中,每秒可以處理數以百萬計的消息。
storm 的主要特點如下:
簡單的程式設計模型。類似于mr降低了并行批處理的複雜行,storm降低了實時處理的複雜行。
可以使用各種程式設計語言。隻要遵守實作storm的通信協定即可。
容錯性。storm會管理工作程序和節點故障。
水準擴充。計算是在多個線程,程序和伺服器之間并行進行的。
可靠的消息處理。storm保證每個消息至少能得到處理一次完整的處理,使用 mq 作為其底層消息隊列。
本地模式。storm 有一個“本地模式”,可以在處理過程中完全模拟storm叢集。這讓你可以快速進行開發和單元測試。
最後總結出:hadoop 的 mr 基于 hdfs,需要切分輸入資料,産生中間資料檔案,排序,資料壓縮,多分複制等,效率地下。而 storm 基于 zeromq 這個高
性能的消息通訊庫,不能持久化資料。這篇文章就分享到這裡，若有疑問，可以加入qq群或發送郵件給我，我會盡我所能給予幫助，與君共勉！