為什麼 Storm 比 Hadoop 快？是由哪幾個方面決定的？

12-26

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

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

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

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

首先要明白Storm和Hadoop的應用領域，注意加粗、標紅的關鍵字。
Hadoop是基於Map/Reduce模型的，處理海量數據的離線分析工具。
Storm是分散式的、實時數據流分析工具，數據是源源不斷產生的，例如Twitter的Timeline。
再回到你說的速度問題，只能說Storm更適用於實時數據流，Map/Reduce模型在實時領域很難有所發揮，不能簡單粗暴的說誰快誰慢。

「快」這個詞是不明確的，專業屬於點有兩個層面：
1. 延時，指數據從產生到運算產生結果的時間，題主的「快」應該主要指這個。
2. 吞吐，指系統單位時間處理的數據量。

首先明確一點，在消耗資源相同的情況下，一般來說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做的流計算系統。

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

您好，我是Jstorm的committer 延年（目前創業創辦延雲YDB，http://ycloud.net.cn/）
我們阿里的團隊將Storm的開發語言更換為java版本，阿里的Jstorm目前已經正式被Apache所接受，成為apache Storm的子版本。本人對storm還是有一定的了解的。下面說說我本人的看法。

首先快是相對的，您說的hadoop不快，應該知的是hadoop下的mapreduce慢，因為還有很多跑在hadoop之上的業務他也快，比如說Hbase，以及我們的延雲YDB。
另這個快其實您的本意是時效性好，而不是說計算速度快。這個地方要加以區分。
因為如果從計算速度上來看,mapreduce的計算速度不見得就慢，比如說算一個pi.

首先第一點：storm的數據在內存中，不落地，IO消耗很小。
storm因為本身是流式計算的特性，數據從產生到最終能看到結果，也就是秒，甚至是毫秒的延遲。流計算，您可以想像成一個流水線，各種數據在流水線上源於流動，而其中的Bolt就是流水線上的工人，不同的Bolt負責不同流程上產品的處理，每條數據經過一個人處理完畢後，會交給第二個作業的人去處理，這期間數據不會落地，而是直接在流水線上傳輸著，也就是說，數據一直在內存裡面，不會像mapreduce在計算的過程中，map的處理結果，落地到磁碟上，reduce在去下載map的結果，計算完畢後還要放到磁碟上，多次mapreduce要反反覆復的多次數據落地，IO肯定特別大。

第二點：他時效性好，是因為是預計算-不留原始數據,只能看特定的維度、粒度。
如果數據經過預先匯總，原始數據沒有保留，在未來某一時間如果想查看其它維度或者粒度的數據數據將無法實現。
hadoop則保存了原始數據的明細，可以根據任何需要，來來回回的反覆查詢，但是他的mapreduce屬於，暴力掃描的方式，不用多說，性能很差，需要狂堆機器，成本也太高。而這類系統一般的並發也不大，如果數據量在百億級別，千台的集群規模，一天也就能進行幾十萬次的查詢而已。
順便說下我得創業項目，YDB則採用大索引技術，通過索引技術直接定位到相關記錄，避免記錄的逐條掃描，即使只有50幾台的機器，百億數據也能查詢個幾百萬次。所以通過索引來擬補mapreduce的不足。YDB也是保存數據明細，查詢的時候根據大索引技術以及獨特的標籤技術，在幾秒的時間，返回任意維度，任意篩選條件的結果，靈活性很好，多維鑽取，全文檢索都是YDB的強項。

第三，hadoop上文件時效性較差，因為namenode不能有太多的小文件，數據要經過聚集幾分鐘，甚至一小時，一天，集中導入到hdfs裡面，也就導致了數據時效性很差。流系統數據時實時流入的，時效性本身就好。

同時也PS下，上面吐槽storm穩定性的同學。
storm真的很穩定，阿里的jstorm每天處理超過萬億條的消息，這個是真的。但是有一定的開發成本，所以想寫好，不是特別的容易。

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

簡單的編程模型。類似於MapReduce降低了並行批處理複雜性，Storm降低了進行實時處理的複雜性。
可以使用各種編程語言。你可以在Storm之上使用各種編程語言。默認支持Clojure、Java、Ruby和Python。要增加對其他語言的支持，只需實現一個簡單的Storm通信協議即可。
容錯性。Storm會管理工作進程和節點的故障。
水平擴展。計算是在多個線程、進程和伺服器之間並行進行的。
可靠的消息處理。Storm保證每個消息至少能得到一次完整處理。任務失敗時，它會負責從消息源重試消息。
快速。系統的設計保證了消息能得到快速的處理，使用?MQ作為其底層消息隊列。
本地模式。Storm有一個「本地模式」，可以在處理過程中完全模擬Storm集群。這讓你可以快速進行開發和單元測試。

source: http://www.infoq.com/news/2011/09/twitter-storm-real-time-hadoop

個人總結：

Hadoop M/R基於HDFS，需要切分輸入數據、產生中間數據文件、排序、數據壓縮、多份複製等，效率較低。
Storm 基於ZeroMQ這個高性能的消息通訊庫，不持久化數據。

兩者屬於不同的計算範式，批處理v.s.實時，不存在可比性。相反，對於一個大型的大數據系統，要兼顧批處理和實時性要求，在架構上會將Hadoop和Storm結合起來。在Storm主工程師Nathan Marz的Big Data一書中，有介紹。

我不講你能知道么？你還以為Storm能解決過車查詢和在線實時統計分析呢！

但實際上storm和hadoop的根本完全就是不同的應用領域。

storm只能處理數據入庫、超速判斷、網站在線用戶特別多之類的問題，與大數據查詢毫無關係。

它所能處理的「大」是指實時在線請求量的「大」。

我認為這兩個東西就不應該做對比。是不同領域的東西。它們之間快慢比較根本沒有意義。

引用一段話：
爬犁和寶劍哪個快？要看是用來耕地，還是砍人——hadoop像個爬犁，耕地很兇悍；storm像把寶劍，砍人鋒利無比。

爬犁和寶劍哪個快？要看是用來耕地，還是砍人——hadoop像個爬犁，耕地很兇悍；storm像把寶劍，砍人鋒利無比。

@kenny 的水的例子很形象，我再發揮一下。例如給純凈水消毒需要經過27道工序，hadoop差不多是每一道工序都把桶裝水倒出來消毒，完了再裝回去，下一道工序再倒出來；而storm相當於把水倒入管道中，流經不同的消毒池，完成所有工序，然後再流回桶里。所以storm比hadoop快，尤其是需要多次迭代的場景，不用每次都把中間數據寫回磁碟。

差點看成spark的問題，最近拿spark和hadoop比的問題太多了。

其實@張雲聰的回答已經說明了原因。
這裡再次強調根本原因，Hadoop是磁碟級計算，進行計算時，數據在磁碟上，需要讀寫磁碟；Storm是內存級計算，數據直接通過網路導入內存。讀寫內存比讀寫磁碟速度快n個數量級。根據Harvard CS61課件，磁碟訪問延遲約為內存訪問延遲的75000倍。所以Storm更快。

謝邀不會謝謝

MapReduce是批處理，先準備好數據，再進行處理，期間還有磁碟會參與運算，比較適合大量數據的離線處理。
Storm整個計算都在內存中完成，不需要任何磁碟參與，所以十分適合實時計算。

做個搬運工：

原文鏈接： Apache Storm Introduction

簡單翻譯一下，大數據處理有兩個領域，一個是批處理，一個是實時處理。簡單來說，批處理就好比是白天數據量特別多，來不及處理，先存起來，晚上慢慢處理，確保當天能處理完當天的數據量。實時處理就是用戶並發有大量的數據，這些數據則是必須及時處理並返回結果的。所以機制就不太一樣。

storm 針對實時處理，hadoop針對批處理。你直接比較快慢。我覺得這不合適。也沒法回答。

Storm - 大數據 - 服務軟體 - 代碼樹

兩者是互補關係，不好這麼比較

場景不一樣沒有比較的必要……

Storm系列文章 Storm介紹(一)理解Storm並發

說storm快的為何都忽略了取數據這個過程，大數據分析這個取數據過程很關鍵，取數據磁碟網路帶寬都有限制；若說數據已經拿回來計算MR中間會有大量回寫磁碟的操作，速度肯定上不來，這是storm必定快