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)的延時主要有以下幾個方面:
流計算一般運算結果直接反饋到最終結果集中(展示頁面,資料庫,搜尋引擎的索引)。而 mapreduce 一般需要整個運算結束後將結果批量匯入到結果集中。
storm 可以方便的在乙個計算機集群中編寫與擴充套件複雜的實時計算,storm 之於實時,就好比 hadoop 之於批處理。storm 保證每個訊息都會得到處理,而 且速度很快,在乙個小集群中,每秒可以處理數以百萬計的訊息。
storm 的主要特點如下:
最後總結出:hadoop 的 mr 基於 hdfs,需要切分輸入資料,產生中間資料檔案,排序,資料壓縮,多分複製等,效率地下。而 storm 基於 zeromq 這個高 效能的訊息通訊庫,不能持久化資料。這篇文章就分享到這裡，若有疑問，可以加入qq群或傳送郵件給我，我會盡我所能給予幫助，與君共勉！
真的不適合
1 做事情的時候聽 真的不適合我。曾經嘗試了很多次，甚至現在有時候也會想著寫 的時候聽 看書的時候聽 但是，真的，這不適合我。以後有這種想法的時候，及時告誡自己，真的不行，效率奇低！2 宿舍不是適合我學習的地方。從實驗室把電腦扛回宿舍，一本正經想要學習。最後都以跟室友聊天 吃零食 東摸摸西看看結束。...
開源不適合VMware
2008 10 14 12 08 julie 51cto.com ipo的巨大成功也使vmware承擔了重大的責任，同時，很多沒有意義的事情接踵而來。vmware也許可以忍受在辦公室內做些無意義的事情，但是它卻不容忍著發生在其技術的源 上。我們詢問公司是不是可以做些不同尋常地舉措比如將其旗艦技術源 ...
適合建索引？不適合建索引？分析
資料庫建立索引常用的規則如下 1 表的主鍵 外來鍵必須有索引 2 資料量超過300的表應該有索引 3 經常與其他表進行連線的表，在連線欄位上應該建立索引 4 經常出現在where子句中的字段，特別是大表的字段，應該建立索引 5 索引應該建在選擇性高的字段上 6 索引應該建在小字段上，對於大的文字字段...