1.概述
Hadoop已被公認為大數據分析領域無可爭辯的王者，它專注與批處理。這種模型對許多情形（比如：為網頁建立索引）已經足夠，但還存在其他一些使用模型，它們需要來自高度動態的來源的實時信息。為了解決這個問題，就得借助Twitter推出得Storm。Storm不處理靜態數據，但它處理預計會連續的流數據。考慮到Twitter用戶每天生成1.4億條推文，那么就很容易看到此技術的巨大用途。
但Storm不只是一個傳統的大數據分析系統：它是復雜事件處理（CEP）系統的一個示例。CEP系統通常分類為計算和面向檢測，其中每個系統都是通過用戶定義的算法在Storm中實現。舉例而言，CEP可用於識別事件洪流中有意義的事件，然后實時的處理這些事件。
2.為什么Hadoop不適合實時計算
這里說的不適合,是一個相對的概念。如果業務對時延要求較低,那么這個 問題就不存在了;但事實上企業中的有些業務要求是對時延有高要求的。下面我 就來說說:
2.1時延
Storm 的網絡直傳與內存計算,其時延必然比 Hadoop 的 HDFS 傳輸低得多;當計算模型比較適合流式時,Storm 的流試處理,省去了批處理的收集數據的時 間;因為 Storm 是服務型的作業,也省去了作業調度的時延。所以從時延的角 度來看,Storm 要快於 Hadoop,因而 Storm 更適合做實時流水數據處理。下面用一個業務場景來描述這個時延問題。
2.1.1業務場景
幾千個日志生產方產生日志文件,需要對這些日志文件進行一些 ETL 操作存 入數據庫。
我分別用 Hadoop 和 Storm 來分析下這個業務場景。假設我們用 Hadoop 來 處理這個業務流程,則需要先存入 HDFS,按每一分鍾(達不到秒級別,分鍾是最小緯度)切一個文件的粒度來計算。這個粒度已經極端的細了,再小的話 HDFS 上會一堆小文件。接着 Hadoop 開始計算時,一分鍾已經過去了,然后再開始 調度任務又花了一分鍾,然后作業運行起來,假設集群比較大,幾秒鍾就計算完 成了,然后寫數據庫假設也花了很少時間(理想狀況下);這樣,從數據產生到 最后可以使用已經過去了至少兩分多鍾。
而我們來看看流式計算則是數據產生時,則有一個程序一直監控日志的產生, 產生一行就通過一個傳輸系統發給流式計算系統,然后流式計算系統直接處理, 處理完之后直接寫入數據庫,每條數據從產生到寫入數據庫,在資源充足(集群 較大)時可以在毫秒級別完成。
2.1.2吞吐
在吞吐量方面,Hadoop 卻是比 Storm 有優勢;由於 Hadoop 是一個批處理計算,相比 Storm 的流式處理計算,Hadoop 的吞吐量高於 Storm。
2.2應用領域
Hadoop 是基於 MapReduce 模型的,處理海量數據的離線分析工具,而 Storm是分布式的,實時數據流分析工具,數據是源源不斷產生的,比如:Twitter 的 Timeline。另外,M/R 模型在實時領域很難有所發揮,它自身的設計特點決定了 數據源必須是靜態的。
2.3硬件
Hadoop 是磁盤級計算,進行計算時,數據在磁盤上,需要讀寫磁盤;Storm是內存級計算,數據直接通過網絡導入內存。讀寫內存比讀寫磁盤速度快 N 個 數量級。根據行業結論,磁盤訪問延遲約為內存訪問延遲的 7.5w 倍,所以從這 個方面也可以看出,Storm 從速度上更快。
3.詳細分析
在分析之前,我們先看看兩種計算框架的模型，首先我們看下MapReduce的模型，以WordCount為例，如下圖所示：
閱讀過Hadoop源碼下的hadoop-mapreduce-project工程中的代碼應該對這個流程會熟悉，我這里就不贅述這個流程了。
接着我們在來看下Storm的模型，如下圖所示：
然后下面我們就會涉及到2個指標問題：延時和吞吐。
- 延時:指數據從產生到運算產生結果的時間。與“速度”息息相關。
- 吞吐:指系統單位時間處理的數據量。
另外,在資源相同的情況下;一般 Storm 的延時要低於 MapReduce,但是
吞吐吞吐也要低於 MapReduce,下面我描述下流計算和批處理計算的流程。 整個數據處理流程來說大致可以分為三個階段:
1. 數據采集階段
2. 數據計算(涉及計算中的中間存儲)
3. 數據結果展現(反饋)
3.1.1數據采集階段
目前典型的處理策略:數據的產生系統一般出自 Web 日志和解析 DB 的 Log,流計算數據采集是獲取的消息隊列(如:Kafka,RabbitMQ)等。批處理系統一 般將數據采集到分布式文件系統(如:HDFS),當然也有使用消息隊列的。我們 暫且把消息隊列和文件系統稱為預處理存儲。二者在這個階段的延時和吞吐上沒 太大的區別,接下來從這個預處理存儲到數據計算階段有很大的區別。流計算一 般在實時的讀取消息隊列進入流計算系統(Storm)的數據進行運算,批處理系 統一般回累計大批數據后,批量導入到計算系統(Hadoop),這里就有了延時的 區別。
3.1.2數據計算階段
流計算系統(Storm)的延時主要有以下幾個方面:
-
Storm 進程是常駐的,有數據就可以進行實時的處理。MapReduce 數據累 計一批后由作業管理系統啟動任務,Jobtracker 計算任務分配,Tasktacker 啟動相關的運算進程。
-
Storm 每個計算單元之間數據通過網絡(ZeroMQ)直接傳輸。MapReduce Map 任務運算的結果要寫入到 HDFS,在 Reduce 任務通過網絡拖過去運算。 相對來說多了磁盤讀寫,比較慢。
-
對於復雜運算,Storm的運算模型直接支持DAG(有向無環圖,多個應用程 序存在依賴關系,后一個應用程序的 輸入為前一個的輸出),MapReduce 需 要多個 MR 過程組成,而且有些 Map 操作沒有意義。
3.1.3數據展現
流計算一般運算結果直接反饋到最終結果集中(展示頁面,數據庫,搜索引擎的索引)。而 MapReduce 一般需要整個運算結束后將結果批量導入到結果集中。
4.總結
Storm 可以方便的在一個計算機集群中編寫與擴展復雜的實時計算,Storm 之於實時,就好比 Hadoop 之於批處理。Storm 保證每個消息都會得到處理,而 且速度很快,在一個小集群中,每秒可以處理數以百萬計的消息。
Storm 的主要特點如下:
-
簡單的編程模型。類似於MR降低了並行批處理的復雜行,Storm降低了實時處理的復雜行。
-
可以使用各種編程語言。只要遵守實現Storm的通信協議即可。
-
容錯性。Storm會管理工作進程和節點故障。
-
水平擴展。計算是在多個線程,進程和服務器之間並行進行的。
-
可靠的消息處理。Storm保證每個消息至少能得到處理一次完整的處理,使用 MQ 作為其底層消息隊列。
-
本地模式。Storm 有一個“本地模式”,可以在處理過程中完全模擬Storm集群。這讓你可以快速進行開發和單元測試。
最后總結出:Hadoop 的 MR 基於 HDFS,需要切分輸入數據,產生中間數據文件,排序,數據壓縮,多分復制等,效率地下。而 Storm 基於 ZeroMQ 這個高 性能的消息通訊庫,不能持久化數據。這篇文章就分享到這里，若有疑問，可以加入QQ群或發送郵件給我，我會盡我所能給予幫助，與君共勉！