1、hadoop、Storm該選哪一個？

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

首先整體認識：Hadoop是磁碟級計算，進行計算時，資料在磁碟上，需要讀寫磁碟；Storm是記憶體級計算，資料直接通過網路匯入記憶體。讀寫記憶體比讀寫磁碟速度快n個數量級。根據Harvard CS61課件，磁碟訪問延遲約為記憶體訪問延遲的75000倍。所以Storm更快。

註釋： 
1. 延時 ， 指資料從產生到運算產生結果的時間

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），而後者需要自己去維護這個視窗。