史小英 楊浩

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

關(guān)鍵詞：Hadoop;MongoDB;整合;大數(shù)據(jù)處理

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A

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

1Hadoop與MongoDB概述

1.1Hadoop

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

1.2MongoDB

MongoDB是針對Web應(yīng)用程序與互聯(lián)網(wǎng)基礎(chǔ)設(shè)施所設(shè)計的數(shù)據(jù)庫管理系統(tǒng)，是典型的No SQL數(shù)據(jù)庫。MongoDB以BSON為數(shù)據(jù)模型結(jié)構(gòu)，其可促使MongoDB在生產(chǎn)環(huán)境下提高讀寫能力，吞吐量明顯較強。而且，MongoDB還具備分片能力，可分片數(shù)據(jù)集，以此將數(shù)據(jù)存儲壓力分?jǐn)偟蕉嗯_服務(wù)器上。MongoDB還可檢測主節(jié)點的存活狀態(tài)，在失活的時候，可自動將從節(jié)點轉(zhuǎn)變?yōu)橹鞴?jié)點，以轉(zhuǎn)移故障。由于BSON數(shù)據(jù)模型主要面向?qū)ο螅虼丝杀碚魇重S富，層次化分明的數(shù)據(jù)結(jié)構(gòu)。

2Hadoop與MongoDB整合框架

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

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

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

3集群部署策略

Hadoop與MongoDB整合框架計算與查詢海量大數(shù)據(jù)時，集群部署環(huán)節(jié)十分關(guān)鍵。

3.1MongoDB分片

為方便操作，在副本集只設(shè)計了兩臺機器，即主服務(wù)器與從服務(wù)器。通過科學(xué)合理設(shè)置參數(shù)，其中主服務(wù)器的任務(wù)是寫，從服務(wù)器的作用是讀，以此分?jǐn)傊鞣?wù)器寫的壓力。

3.2數(shù)據(jù)本地化

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

4實驗分析

4.1數(shù)據(jù)

選用某數(shù)據(jù)進(jìn)行實驗。在Hadoop與MongoDB整合框架中，針對數(shù)據(jù)進(jìn)行極具代表性的三種應(yīng)用進(jìn)行場景模擬。其一，F(xiàn)ilter，以模擬Read>>Write場景;其二，Recorder，以模擬Read=Write場景;其三，Merge，以模擬Read<

4.2配置

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

4.3結(jié)果分析

4.3.1數(shù)據(jù)加載與導(dǎo)出性能

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

4.3.2不同方案下的不同應(yīng)用性能

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

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

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

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

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

5結(jié)論

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