基于Hadoop與nongoDB整合技術(shù)的大數(shù)據(jù)處理分析

史小英 楊浩

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

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

中圖分類(lèi)號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2019）29-0001-02

1Hadoop與MongoDB概述

1.1Hadoop

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

1.2MongoDB

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

2Hadoop與MongoDB整合框架

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

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

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

3集群部署策略

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

3.1MongoDB分片

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

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

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

4實(shí)驗(yàn)分析

4.1數(shù)據(jù)

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

4.2配置

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

4.3結(jié)果分析

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

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

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

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

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

4.3.3不同方案配置的可擴(kuò)展性

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

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

5結(jié)論

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