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群或傳送郵件給我，我會盡我所能給予幫助，與君共勉！
MapReduce 不適合處理實時資料的原因剖析
hadoop已被公認為大資料分析領域無可爭辯的王者，它專注與批處理。這種模型對許多情形 比如 為網頁建立索引 已經足夠，但還存在其他一 些使用模型，它們需要來自高度動態的 的實時資訊。為了解決這個問題，就得借助twitter推出得storm。storm不處理靜態資料，但它處理預 計會連續的流資料。考...
資料庫索引及不適合建立索引的情況
2 資料庫索引是通過b樹和變形的b 樹實現的。3 什麼情況下不適合建立索引？1.對於在查詢過程中很少使用或參考的列，不應該建立索引。2.對於那些只有很少資料值的列，不應該建立索引。3.對於那些定義為image，text和bit資料型別的列，不應該建立索引。4.當修改效能遠大於檢索效能，不應該建立索引...
什麼樣的資料集不適合用深度學習
什麼樣的資料集不適合用深度學習?資料集太小，資料樣本不足時，深度學習相對其它機器學習演算法，沒有明顯優勢。資料集沒有區域性相關特性，目前深度學習表現比較好的領域主要是影象 語音 自然語言處理等領域，這些領域的乙個共性是區域性相關性。影象中畫素組成物體，語音頻號中音位組合成單詞，文字資料中單詞組合成句...