hadoop、storm和spark的區別、比較

1、hadoop、Storm該選哪個？

爲了區別hadoop和Storm，該部分將回答以下問題：
1.hadoop、Storm各是什麼運算
2.Storm爲何被稱之爲流式計算系統
3.hadoop適合什麼場景，什麼狀況下使用hadoop
4.什麼是吞吐量


首先總體認識：Hadoop是磁盤級計算，進行計算時，數據在磁盤上，須要讀寫磁盤；Storm是內存級計算，數據直接經過網絡導入內存。讀寫內存比讀寫磁盤速度快n個數量級。根據Harvard CS61課件，磁盤訪問延遲約爲內存訪問延遲的75000倍。因此Storm更快。


註釋：
1. 延時 ， 指數據從產生到運算產生結果的時間，「快」應該主要指這個。
2. 吞吐， 指系統單位時間處理的數據量。


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


從原理角度來說：

• Hadoop M/R基於HDFS，須要切分輸入數據、產生中間數據文件、排序、數據壓縮、多份複製等，效率較低。

• Storm 基於ZeroMQ這個高性能的消息通信庫，不持久化數據。

爲何storm比hadoop快，下面舉一個應用場景
說一個典型的場景，幾千個日誌生產方產生日誌文件，須要進行一些ETL操做存入一個數據庫。

假設利用hadoop，則須要先存入hdfs，按每一分鐘切一個文件的粒度來算（這個粒度已經極端的細了，再小的話hdfs上會一堆小文件），hadoop開始計算時，1分鐘已通過去了，而後再開始調度任務又花了一分鐘，而後做業運行起來，假設機器特別多，幾鈔鍾就算完了，而後寫數據庫假設也花了不多的時間，這樣，從數據產生到最後可使用已通過去了至少兩分多鐘。
而流式計算則是數據產生時，則有一個程序去一直監控日誌的產生，產生一行就經過一個傳輸系統發給流式計算系統，而後流式計算系統直接處理，處理完以後直接寫入數據庫，每條數據從產生到寫入數據庫，在資源充足時能夠在毫秒級別完成。


同時說一下另一個場景：
若是一個大文件的wordcount，把它放到storm上進行流式的處理，等全部已有數據處理完才讓storm輸出結果，這時候，你再把它和hadoop比較快慢，這時，其實比較的不是時延，而是比較的吞吐了。

--------------------------------------------------------------------------------------------------------------------------------
最主要的方面：Hadoop使用磁盤做爲中間交換的介質，而storm的數據是一直在內存中流轉的。
二者面向的領域也不徹底相同，一個是批量處理，基於任務調度的；另一個是實時處理，基於流。
以水爲例，Hadoop能夠看做是純淨水，一桶桶地搬；而Storm是用水管，預先接好（Topology），而後打開水龍頭，水就源源不斷地流出來了。

--------------------------------------------------------------------------------------------------------------------------------
Storm的主工程師Nathan Marz表示： Storm能夠方便地在一個計算機集羣中編寫與擴展複雜的實時計算，Storm之於實時處理，就比如Hadoop之於批處理。Storm保證每一個消息都會獲得處理，並且它很快——在一個小集羣中，每秒能夠處理數以百萬計的消息。更棒的是你可使用任意編程語言來作開發。
Storm的主要特色以下：
1.簡單的編程模型。相似於MapReduce下降了並行批處理複雜性，Storm下降了進行實時處理的複雜性。
2.可使用各類編程語言。你能夠在Storm之上使用各類編程語言。默認支持Clojure、Java、Ruby和Python。要增長對其餘語言的支持，只需實現一個簡單的Storm通訊協議便可。
3.容錯性。Storm會管理工做進程和節點的故障。
4.水平擴展。計算是在多個線程、進程和服務器之間並行進行的。
5.可靠的消息處理。Storm保證每一個消息至少能獲得一次完整處理。任務失敗時，它會負責從消息源重試消息。
6.快速。系統的設計保證了消息能獲得快速的處理，使用MQ做爲其底層消息隊列。
7.本地模式。Storm有一個「本地模式」，能夠在處理過程當中徹底模擬Storm集羣。這讓你能夠快速進行開發和單元測試。

--------------------------------------------------------------------------------------------------------------------------------
在消耗資源相同的狀況下，通常來講storm的延時低於mapreduce。可是吞吐也低於mapreduce。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作的流計算系統。

 

2、高性能並行計算引擎Storm和Spark比較

Spark基於這樣的理念，當數據龐大時，把計算過程傳遞給數據要比把數據傳遞給計算過程要更富效率。每一個節點存儲（或緩存）它的數據集，而後任務被提交給節點。

因此這是把過程傳遞給數據。這和Hadoop map/reduce很是類似，除了積極使用內存來避免I/O操做，以使得迭代算法（前一步計算輸出是下一步計算的輸入）性能更高。

Shark只是一個基於Spark的查詢引擎（支持ad-hoc臨時性的分析查詢）

而Storm的架構和Spark截然相反。Storm是一個分佈式流計算引擎。每一個節點實現一個基本的計算過程，而數據項在互相鏈接的網絡節點中流進流出。和Spark相反，這個是把數據傳遞給過程。

兩個框架都用於處理大量數據的並行計算。

Storm在動態處理大量生成的「小數據塊」上要更好（好比在Twitter數據流上實時計算一些匯聚功能或分析）。

Spark工做於現有的數據全集（如Hadoop數據）已經被導入Spark集羣，Spark基於in-memory管理能夠進行快訊掃描，並最小化迭代算法的全局I/O操做。

不過Spark流模塊（Streaming Module）卻是和Storm相相似（都是流計算引擎），儘管並不是徹底同樣。

Spark流模塊先匯聚批量數據而後進行數據塊分發（視做不可變數據進行處理），而Storm是隻要接收到數據就實時處理並分發。

不肯定哪一種方式在數據吞吐量上要具優點，不過Storm計算時間延遲要小。

總結下，Spark和Storm設計相反，而Spark Steaming才和Storm相似，前者有數據平滑窗口（sliding window），然後者須要本身去維護這個窗口。