Hadoop不適合處理實時資料的原因剖析

哥不是小蘿莉發表於2015-02-13
Hadoop

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群或傳送郵件給我，我會盡我所能給予幫助，與君共勉！ 

相關文章