基于Hadoop與nongoDB整合技術的大數據處理分析

史小英 楊浩

摘要：在數據類型不斷增加，規模逐漸擴大的趨勢下，NO SQL技術與MapReduce并行處理理念開始備受關注。而作為N0SQL數據庫典型代表，MongoDB可索引并查詢大量數據，但是其所提供的MapReduce無法滿足太過繁雜的數據分析與并行計算。而Hadoop具備強大的MapReduce計算能力，但實時服務延時較長。對此，可基于擴展性、數據本地化等相關要素分析，整合Hadoop與MongoDB，針對不同應用場景，尋求最優整合方式，以提高大數據處理效率與質量。

關鍵詞：Hadoop;MongoDB;整合;大數據處理

中圖分類號：TP311 文獻標識碼：A

文章編號：1009-3044（2019）29-0001-02

1Hadoop與MongoDB概述

1.1Hadoop

Hadoop包含大量元素，最底部為HDFS，作用是存儲所有節點文件，其上層為MapReduce引擎，以及數據倉庫Hive、數據庫Hbase。Hadoop在大數據處理中實現廣泛應用的關鍵在于，其數據提取、變形、加載等極具優勢。Hadoop分布式框架推動大數據處理引擎盡量接近存儲，比較適合批處理操作，所以，批處理結果可直接存儲。Had oop的Map Reduce功能可碎片化單項任務，并實時傳輸到各節點，然后以單數據集形式向數據倉庫加載。

1.2MongoDB

MongoDB是針對Web應用程序與互聯網基礎設施所設計的數據庫管理系統，是典型的No SQL數據庫。MongoDB以BSON為數據模型結構，其可促使MongoDB在生產環境下提高讀寫能力，吞吐量明顯較強。而且，MongoDB還具備分片能力，可分片數據集，以此將數據存儲壓力分攤到多臺服務器上。MongoDB還可檢測主節點的存活狀態，在失活的時候，可自動將從節點轉變為主節點，以轉移故障。由于BSON數據模型主要面向對象，因此可表征十分豐富，層次化分明的數據結構。

2Hadoop與MongoDB整合框架

Hadoop善于分析計算海量數據，MongoDB擅長分布式存儲與查詢數據。有機整合可發揮雙重優勢，同時滿足數據分析、計算、查詢、存儲等多項要求。整合框架具體如圖1所示。

就Hadoop與MongoDB整合而言，使用了中間件，即Mon-goDB Hadoop Connector，作用是利用MongoDB替換HDFS，作為Map Reduce數據源，在分布式集群中，集合劃分為固定形狀的塊基于MongoDB儲存，而Hadoop Mappers以路由節點為載體并行讀取塊，解析數據，然后利用Reducer合并，傳輸結果于Mon-goDB。在數據處理中，HDFS并未發揮作用，為保證Hadoop與MongoDB整合的有效性、靈活性，以及數據處理的實效性。就MongoDB Hadoop Connector進行了優化擴展，即在Connector中添加Input Format與Output Format類，以HDFS與MongoDB為Map Reduce可選擇輸入源或者輸出目標。

Hadoop與MongoDB整合方案以配置方式不同劃分為四類，即：一是基于HDFS讀取數據，并編入計算結果;二是基于HDFS讀取數據，在MongoDB中編寫計算結果;三是基于Mon_goDB讀取數據，在HDFS編寫計算結果;四是基于MongoDB讀取數據，并編入計算結果。針對三種不同應用場合對各方案性能進行評估與測試，即：一是Read=Write，讀寫大致相同;Read>>Write，讀明顯大于寫;Read<

3集群部署策略

Hadoop與MongoDB整合框架計算與查詢海量大數據時，集群部署環節十分關鍵。

3.1MongoDB分片

為方便操作，在副本集只設計了兩臺機器，即主服務器與從服務器。通過科學合理設置參數，其中主服務器的任務是寫，從服務器的作用是讀，以此分攤主服務器寫的壓力。

3.2數據本地化

在Hadoop與MongoDB整合集群中，數據本地化主要基于Hadoop Task Trackers、Data Nodes與MongoDB分片服務器相互交叉重疊加以實現。但是，需要同時實現數據本地化與Mon-goDB分片讀寫相分離，需要把Hadoop Task Trackers和DataNodes分配于MongoDB分片從節點。如此一來，Map Reduce便可從MongoDB分片從節點中進行數據讀取，在經過處理之后，將數據再次編寫于MongoDB主服務器。

4實驗分析

4.1數據

選用某數據進行實驗。在Hadoop與MongoDB整合框架中，針對數據進行極具代表性的三種應用進行場景模擬。其一，Filter，以模擬Read>>Write場景;其二，Recorder，以模擬Read=Write場景;其三，Merge，以模擬Read<

4.2配置

實驗選用總節點數是19，包含Name Node、路由器、服務器;Hadoop Data Node、Task Track、MongoDB分片進行交叉部署的主節點數為8，從節點數為8。

4.3結果分析

4.3.1數據加載與導出性能

相比MongoDB，HDFS數據加載與導出性能更好，這主要是由于HDFS不需讀取數據，解析并序列化，然后基于數據庫格式于磁盤進行存儲，數據加載與導出操作只是簡單地復制或者移動文件。HDFS數據導人與導出性能和數據大小之間為正相關關系，MongoDB數據導入與導出性能則是在數據集逐漸加大的趨勢下，速率快速下降，尤其是導入速率。

4.3.2不同方案下的不同應用性能

在輸入遠遠超出輸出時，數據處理情況具體如表1所示。其中方案三與方案一對比分析，就數據輸人源不同，但是方案一速率更高，所以，基于MongoDB讀取數據的成本耗費比較大。而四個方案對比分析，可知彼此間性能差異較小，主要是由于輸出數據很小，寫入數據的位置難以很大程度上對性能造成影響。

在輸入與輸出相等時，數據處理情況具體如表2所示。不同的數據集中，方案一速率最高，時間最短，相同輸入時，輸出結果的編寫位置直接影響著性能，所以，相同數據集在進行相同處理，但是選擇不同整合方案時，方案三的性能與方案一最相近間。

4.3.3不同方案配置的可擴展性

不同方案配置的可擴展性具體如表3所示。其中，集群規模通過4核向8核擴展時，四個方案整體性能都有顯著提升，而且從表可看出，各方案的讀、寫、處理時間都有十分明顯地縮減。

Hadoop與MongoDB整合集群擴展到8核的時候，內存與CPU利用率都會降低，可緩解二者制約性，從而使得性能快速優化提升，所以可知內存與CPU占用率太大，會導致性能嚴重損失，而Hadoop與MongoDB整合可橫向擴展添加節點，從而有效彌補?；趦却媾cCPU充分狀態，方案四以集群規模不斷擴大的方式，可快速縮減讀取時間，這主要是由于集群規模擴大，Map增多，可同時并行讀取數據。但是寫發生于Reduce階段，盡管擴大集群規模，也可促使Reduce并發數增多，然而把數據分發于MongoDB分片服務器需要耗費過多成本，所以寫的性能并未出現顯著提升。

5結論

綜述，通過實驗，基于Hadoop與MongoDB整合處理大數據，得出結論：選擇方案一，處理MongoDB數據，需先導出并傳輸于HDFS，在Hadoop處理之后，把結果導回MongoDB，以此反復導人導出，成本消耗過大，所以此方案數據處理性能最差;選擇方案二，針對非MongoDB數據或已儲存于HDFS數據，需密集型讀，需查詢處理結果時，此配置可提供最優化性能;選擇方案三，針對已儲存于MongoDB的數據，需密集型寫，結果集應基于Map Reduce進行后續處理，此方案可提供最優化性能;選擇方案四，針對已儲存于MongoDB的數據，統計并聚合計算，需查詢結果集時，此方案可提供最優性能。