面向大數(shù)據(jù)處理的Hadoop與MongoDB整合技術(shù)研究

曾　強(qiáng)　繆　力　秦　拯

(湖南大學(xué)信息科學(xué)與工程學(xué)院　湖南 長(zhǎng)沙 410086)

?

面向大數(shù)據(jù)處理的Hadoop與MongoDB整合技術(shù)研究

曾強(qiáng)繆力秦拯

(湖南大學(xué)信息科學(xué)與工程學(xué)院湖南 長(zhǎng)沙 410086)

摘要隨著數(shù)據(jù)種類(lèi)的增多和數(shù)據(jù)規(guī)模的增大，NoSQL技術(shù)與MapReduce并行處理思想越來(lái)越受到重視。MongoDB作為NoSQL數(shù)據(jù)庫(kù)的典型代表，支持對(duì)海量數(shù)據(jù)進(jìn)行索引和查詢，但MongoDB提供的MapReduce還不能滿足復(fù)雜的數(shù)據(jù)分析和計(jì)算。而Hadoop雖然提供了強(qiáng)大的MapReduce并行計(jì)算框架,卻在實(shí)時(shí)服務(wù)方面存在較高延時(shí)。針對(duì)這種情況，綜合考慮擴(kuò)展性,數(shù)據(jù)本地化，I/O性能等因素，提出并實(shí)現(xiàn)Hadoop與MongoDB四種不同的整合方案。通過(guò)設(shè)計(jì)三種具有代表性的應(yīng)用作為性能的測(cè)量基準(zhǔn)，對(duì)不同的整合方案進(jìn)行性能對(duì)比實(shí)驗(yàn)，得出不同應(yīng)用場(chǎng)景下的最優(yōu)整合方案。實(shí)驗(yàn)表明，在MongoDB與Hadoop的折衷使用過(guò)程中，若對(duì)不同的應(yīng)用采用合理的方案，性能最多可以提高3倍。

關(guān)鍵詞整合MongoDBHadoop大數(shù)據(jù)

ON MONGODB AND HADOOP INTEGRATION TECHNOLOGY FOR BIG DATA PROCESSING

Zeng QiangMiao LiQin Zheng

(College of Computer Science and Electronic Engineering,Hunan University,Changsha 410086,Hunan,China)

AbstractWith the exponential growth in data variety and data volumes, NoSQL technology and MapReduce for scalable parallel analysis have garnered a lot of attentions. MongoDB, as a typical representative of NoSQL database, supports both scalable index and flexible query for massive data, but the MapReduce provided by MongoDB cannot meet the need of complex data analysis and computation. While Hadoop offers a powerful MapReduce framework for parallel computing, it performs high latency in real-time services. In view of this, we propose and implement four different integration schemes of Hadoop and MongoDB by considering comprehensively the factors of scalability, data locality and I/O performance. The optimal integration schemes under different scenarios are derived by designing three kinds of representative applications as the measuring benchmarks of performances and by performance contrastive experiments on different integration schemes. Experiments show that in the process of trade-off use of MongoDB and Hadoop, if reasonable integration schemes are applied to different applications, the performance can be improved up to 3 times.

KeywordsIntegrationMongoDBHadoopBig data

0引言

隨著互聯(lián)網(wǎng)的發(fā)展和科技的進(jìn)步，不論企業(yè)，政府，科研機(jī)構(gòu)還是個(gè)人，所產(chǎn)生的數(shù)據(jù)量越來(lái)越大。面對(duì)種類(lèi)繁多的半結(jié)構(gòu)化和非結(jié)構(gòu)化海量數(shù)據(jù)，顯然，傳統(tǒng)的數(shù)據(jù)分析和存儲(chǔ)技術(shù)已力不從心。在大數(shù)據(jù)時(shí)代的背景下，海量數(shù)據(jù)的存儲(chǔ)和分析計(jì)算技術(shù)應(yīng)運(yùn)而生。對(duì)于海量數(shù)據(jù)的處理，應(yīng)包括三個(gè)部分：存儲(chǔ)、計(jì)算和查詢。而要同時(shí)實(shí)現(xiàn)存儲(chǔ)和計(jì)算的可擴(kuò)展性以及查詢的高效性成為大數(shù)據(jù)處理面臨的一個(gè)挑戰(zhàn)。

現(xiàn)今涌現(xiàn)出的很多云計(jì)算和云存儲(chǔ)技術(shù)在不同程度上滿足了大數(shù)據(jù)的處理要求。MapReduce[1]框架的提出，將龐大的計(jì)算任務(wù)分布在成千上萬(wàn)的廉價(jià)的無(wú)共享低端服務(wù)器上并行運(yùn)行，從而大大提高了運(yùn)行效率，Hadoop[2,3]作為MapReduce的一個(gè)開(kāi)源實(shí)現(xiàn)，具有良好的擴(kuò)展性和容錯(cuò)性，并在Facebook、Yahoo等公司得到了廣泛的應(yīng)用。Hadoop的設(shè)計(jì)初衷是針對(duì)大規(guī)模數(shù)據(jù)的批量處理，需要對(duì)整個(gè)數(shù)據(jù)集進(jìn)行掃描，也因此Hadoop對(duì)于小范圍內(nèi)查詢、實(shí)時(shí)插入等服務(wù)存在較高延時(shí)。而NoSQL[4]數(shù)據(jù)庫(kù)的誕生，打破了傳統(tǒng)數(shù)據(jù)庫(kù)的關(guān)系型數(shù)據(jù)模式，能夠以鍵值對(duì)的形式輕松處理和存儲(chǔ)半結(jié)構(gòu)化海量數(shù)據(jù)，在滿足分布式存儲(chǔ)和高可擴(kuò)展性的前提下，還支持索引的建立，因而能夠?qū)崿F(xiàn)對(duì)數(shù)據(jù)的快速定位和高性能查詢。在眾多的NoSQL數(shù)據(jù)庫(kù)中，像DynamoDB[5]、MongoDB[6,7]、BigTable[8]和Cassandra[9]專門(mén)針對(duì)大數(shù)據(jù)存儲(chǔ)而設(shè)計(jì)，通過(guò)橫向擴(kuò)展的方式將服務(wù)部署在廉價(jià)的服務(wù)器上，相比傳統(tǒng)數(shù)據(jù)庫(kù)通過(guò)硬件升級(jí)的方式提高數(shù)據(jù)庫(kù)性能和存儲(chǔ)能力，大大節(jié)約了成本。由于MapReduce的流行，NoSQL數(shù)據(jù)庫(kù)也紛紛引入MapReduce模型作為其聚合計(jì)算強(qiáng)有力的一個(gè)工具，其中的典型代表是MongoDB，MongoDB通過(guò)內(nèi)置的MapReduce處理一些簡(jiǎn)單的聚合計(jì)算，但還不能滿足較為復(fù)雜的數(shù)據(jù)分析。因此，結(jié)合MongoDB強(qiáng)大的存儲(chǔ)能力和Hadoop MapReduce分析計(jì)算能力，搭建一個(gè)高可用、高性能的云計(jì)算和云存儲(chǔ)平臺(tái)成為本文的一個(gè)研究重點(diǎn)。

關(guān)于單方面評(píng)估和提高M(jìn)apReduce和MongoDB性能的研究有很多[10-14]，而關(guān)于MongoDB與MapReduce的整合應(yīng)用的研究相對(duì)較少。文獻(xiàn)[15]通過(guò)搭建MongoDB集群對(duì)網(wǎng)絡(luò)日志進(jìn)行分析，對(duì)于網(wǎng)絡(luò)日志的聚合計(jì)算采用的是MongoDB內(nèi)置的MapReduce，由于MongoDB內(nèi)置MapReduce采用JavaScript編寫(xiě)且采用SpiderMonkey[16]引擎，與Hadoop MapReduce相比存在性能低下的問(wèn)題[17]。文獻(xiàn)[18]描述了MongoDB中MapReduce算法如何提高大數(shù)據(jù)的處理效率，但并沒(méi)有提供量化的結(jié)果。本文通過(guò)MongoDB服務(wù)器和Hadoop計(jì)算節(jié)點(diǎn)重疊部署的方式實(shí)現(xiàn)數(shù)據(jù)本地化，在實(shí)現(xiàn)Hadoop與MongoDB的整合應(yīng)用的基礎(chǔ)上，通過(guò)配置不同的整合方案來(lái)應(yīng)對(duì)不同應(yīng)用的數(shù)據(jù)處理，并通過(guò)實(shí)驗(yàn)對(duì)比的方式對(duì)二者在不同方案下的性能進(jìn)行評(píng)估和分析，得出Hadoop與MongoDB在不同應(yīng)用下的折衷使用策略和最優(yōu)整合方案。

1基于MongoDB和Hadoop的整合方案

1.1Hadoop

Hadoop MapReduce直接誕生于搜索領(lǐng)域，能夠?qū)嫶蟮挠?jì)算量分布到集群的各個(gè)節(jié)點(diǎn)進(jìn)行并行處理。它主要由兩部分組成:編程模型和運(yùn)行時(shí)環(huán)境。其中編程模型為用戶提供了可編程組件，分別是InputFormat、Mapper、Partitioner、Reducer和OutputFormat，運(yùn)行時(shí)環(huán)境則將用戶MapReduce程序部署到集群的各個(gè)節(jié)點(diǎn)上，并通過(guò)各種機(jī)制保證其成功運(yùn)行。Hadoop MapReduce處理的數(shù)據(jù)位于底層分布式文件系統(tǒng)HDFS，HDFS將用戶的文件切分成若干個(gè)固定大小的Block存儲(chǔ)到不同節(jié)點(diǎn)上，并且不同節(jié)點(diǎn)上保存同一Block的多個(gè)副本以實(shí)現(xiàn)容錯(cuò)。Mapreduce的執(zhí)行過(guò)程分為分為兩個(gè)階段:Map和Reduce，每個(gè)Map任務(wù)以key-value鍵值對(duì)的形式，從分布式文件系統(tǒng)HDFS中讀取相關(guān)的數(shù)據(jù)，再經(jīng)過(guò)用戶定義的Map程序，并將產(chǎn)生的結(jié)果合并排序，生成新的key-value鍵值對(duì)，將其保存到本地磁盤(pán)等待Reduce的讀取。Reduce任務(wù)主要根據(jù)鍵值從Map讀取其產(chǎn)生的中間結(jié)果，合并排序后交由用戶定義的Reduce程序，最后將產(chǎn)生的結(jié)果保存至HDFS文件系統(tǒng)中。

1.2MongoDB

MongoDB是10gen公司開(kāi)發(fā)的一個(gè)高性能，開(kāi)源，無(wú)模式的文檔型數(shù)據(jù)庫(kù)，他是最像傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的NoSQL數(shù)據(jù)庫(kù)，實(shí)現(xiàn)了關(guān)系數(shù)據(jù)庫(kù)的很多特點(diǎn)，比如排序、二級(jí)索引、范圍查詢、MongoDB是面向文檔型的數(shù)據(jù)庫(kù)，其中每個(gè)文檔(Document)相當(dāng)于關(guān)系型數(shù)據(jù)庫(kù)中的一條記錄，每個(gè)集合(Collection)對(duì)應(yīng)于關(guān)系型數(shù)據(jù)庫(kù)中的一張表，每個(gè)文檔中的數(shù)據(jù)是以key-value對(duì)的形式自由組織，他支持的數(shù)據(jù)結(jié)構(gòu)非常松散，是類(lèi)似Json的Bson格式，因此可以存儲(chǔ)比較復(fù)雜的數(shù)據(jù)類(lèi)型。圖1展示了MongoDB的數(shù)據(jù)組織結(jié)構(gòu)。

圖1　MongoDB數(shù)據(jù)組織結(jié)構(gòu)

同時(shí)Mongodb也是一個(gè)基于分布式存儲(chǔ)的數(shù)據(jù)庫(kù)。MongoDB本身實(shí)現(xiàn)的自動(dòng)分片機(jī)制能夠?qū)⒋髷?shù)據(jù)集平均分配到多個(gè)節(jié)點(diǎn)存儲(chǔ)。在實(shí)際的開(kāi)發(fā)當(dāng)中，一個(gè)簡(jiǎn)單的分片集群由三部分組成:分片、配置服務(wù)器、路由服務(wù)器。其中分片存儲(chǔ)了實(shí)際的數(shù)據(jù)，這些數(shù)據(jù)以固定大小的數(shù)據(jù)塊(Chunck)組織，每個(gè)分片都是一個(gè)副本集，副本集是自帶故障轉(zhuǎn)移功能的主從復(fù)制?？蛻舳嗽L問(wèn)路由節(jié)點(diǎn)來(lái)進(jìn)行數(shù)據(jù)讀寫(xiě)，配置服務(wù)器保存了兩個(gè)映射關(guān)系，一個(gè)是鍵值的區(qū)間對(duì)應(yīng)哪一個(gè)Chunk的映射關(guān)系，另一個(gè)是Chunk存在哪一個(gè)分片節(jié)點(diǎn)的映射關(guān)系。路由節(jié)點(diǎn)通過(guò)配置服務(wù)器獲取數(shù)據(jù)信息，通過(guò)這些信息，找到真正存放數(shù)據(jù)的分片節(jié)點(diǎn)進(jìn)行對(duì)應(yīng)操作，路由節(jié)點(diǎn)還會(huì)在寫(xiě)操作時(shí)判斷當(dāng)前Chunk是否超出限定大小。如果超出，就分列成兩個(gè)Chunk、Mongodb分片集群結(jié)構(gòu)如圖2所示。

圖2　MongoDB簡(jiǎn)單分片集群

1.3整合框架

Hadoop擅長(zhǎng)對(duì)海量數(shù)據(jù)進(jìn)行分析計(jì)算，MongoDB主要用于大數(shù)據(jù)的分布式存儲(chǔ)和查詢。通過(guò)二者的整合可以同時(shí)滿足海量數(shù)據(jù)的查詢，存儲(chǔ)和計(jì)算要求。具體整合框架如圖3所示。

圖3　整合框架Mongo-Hadoop

對(duì)于MongoDB和Hadoop的整合用到了中間件:MongoDB Hadoop Connector、MongoDB Hadoop Connector是10gen公司提供的一個(gè)免費(fèi)的開(kāi)源插件，該插件的作用是將MongoDB代替Hadoop HDFS作為Hadoop MapReduce的數(shù)據(jù)源，在分布式集群中，集合被分割成固定大小的塊(64 MB)存儲(chǔ)在MongoDB分片上，Hadoop Mappers通過(guò)路由節(jié)點(diǎn)并行讀取塊并解析數(shù)據(jù)，再通過(guò)Reducer合并將結(jié)果回寫(xiě)到MongoDB。在整個(gè)數(shù)據(jù)處理過(guò)程中，Hadoop HDFS并沒(méi)有參與進(jìn)來(lái)，為提高Hadoop與MongoDB二者整合的靈活性以及對(duì)數(shù)據(jù)處理的高效性。本文針對(duì)Mogodb Hadoop Connector做了一些改進(jìn)和擴(kuò)展:在該Connector中添加InputFormat和OutputFormat兩個(gè)類(lèi)。允許HDFS、MongoDB作為Hadoop MapReduce的可選輸入源或輸出目標(biāo)。

從圖3可以看出，基于Hadoop和MongoDB的整合框架Mongo-Hadoop由三部分組成:

Storage System:該部分包括HDFS和MongoDB，用于海量數(shù)據(jù)存儲(chǔ)，其中MonogDB可對(duì)數(shù)據(jù)進(jìn)行索引和查詢。

Mongo-hadoop-connector:該Connector主要包括四個(gè)類(lèi)，其中InputFormat、OutputFormat負(fù)責(zé)HDFS中數(shù)據(jù)的讀取與寫(xiě)入，MongoInput Format、Mongo Output Format負(fù)責(zé)MongoDB中數(shù)據(jù)的讀取與寫(xiě)入。對(duì)MongoDB與Hadoop的整合可通過(guò)配置的方式提供四種方案:

方案一從HDFS讀數(shù)據(jù)，將計(jì)算結(jié)果寫(xiě)入HDFS。

方案二從HDFS讀數(shù)據(jù)，將計(jì)算結(jié)果寫(xiě)入MongoDB。

方案三從MongoDB讀數(shù)據(jù)，將計(jì)算結(jié)果寫(xiě)入HDFS。

方案四從MongoDB讀數(shù)據(jù)，將計(jì)算結(jié)果寫(xiě)入MongoDB。

Hadoop MapReduce Framework:該部分用于對(duì)MongoDB或HDFS中數(shù)據(jù)的并行分析計(jì)算。

Hadoop MapReduce與底層存儲(chǔ)系統(tǒng)的交互只包含讀取數(shù)據(jù)和寫(xiě)入數(shù)據(jù)。因此本文從以下三種應(yīng)用場(chǎng)合對(duì)不同的方案進(jìn)行了性能評(píng)估和測(cè)試:

Read = Write,讀寫(xiě)大致相等。

Read>>Write,讀遠(yuǎn)遠(yuǎn)大于寫(xiě)。

Read<

1.4集群部署策略

整合MongoDB與Hadoop應(yīng)對(duì)大規(guī)模數(shù)據(jù)的查詢和分析計(jì)算，集群部署顯得尤為重要。本文主要從兩個(gè)角度出發(fā)實(shí)現(xiàn)對(duì)Mongo-Hadoop集群的部署:

(1) MongoDB分片讀寫(xiě)分離。MongoDB分片讀寫(xiě)分離通過(guò)副本集來(lái)實(shí)現(xiàn)，在MongoDB集群中一個(gè)副本集一般包括3臺(tái)機(jī)器，其中一臺(tái)作主服務(wù)器，默認(rèn)承擔(dān)數(shù)據(jù)的全部讀寫(xiě)操作。另外兩臺(tái)作為從服務(wù)器，從服務(wù)器在后臺(tái)實(shí)現(xiàn)對(duì)主服務(wù)器數(shù)據(jù)的同步，作為主服務(wù)器的備份。在本文中，為簡(jiǎn)單起見(jiàn)，在一個(gè)副本集中只設(shè)計(jì)了兩臺(tái)機(jī)器，一臺(tái)主服務(wù)器，一臺(tái)從服務(wù)器。通過(guò)參數(shù)設(shè)置，主服務(wù)器只承擔(dān)寫(xiě)操作，而讀則優(yōu)先選擇從服務(wù)器，用以分擔(dān)主服務(wù)器高強(qiáng)度的寫(xiě)壓力。

(2) 數(shù)據(jù)本地化。實(shí)現(xiàn)數(shù)據(jù)本地化是MapReduce框架設(shè)計(jì)的一個(gè)核心部分。數(shù)據(jù)本地化的思想是將數(shù)據(jù)塊放置在計(jì)算節(jié)點(diǎn)的本地磁盤(pán)上，因而在需要對(duì)數(shù)據(jù)進(jìn)行計(jì)算時(shí)實(shí)現(xiàn)對(duì)數(shù)據(jù)的本地獲取，避免由于網(wǎng)絡(luò)傳輸造成的性能下降。在本文實(shí)現(xiàn)的Mongo-Hadoop集群中，數(shù)據(jù)本地化的實(shí)現(xiàn)是通過(guò)Hadoop TaskTrackers和DataNodes與MongoDB分片服務(wù)器的重疊部署來(lái)實(shí)現(xiàn)。但需要注意的是要同時(shí)實(shí)現(xiàn)數(shù)據(jù)本地化和MongoDB分片讀寫(xiě)分離，必須將Hadoop TaskTrackers和DataNodes部署在MongoDB分片的從節(jié)點(diǎn)上。這樣MapReduce可以從本地MongoDB從節(jié)點(diǎn)讀取數(shù)據(jù)，數(shù)據(jù)經(jīng)處理后再寫(xiě)入MongoDB主服務(wù)器。

2實(shí)驗(yàn)

2.1實(shí)驗(yàn)數(shù)據(jù)與實(shí)驗(yàn)基準(zhǔn)

本文采用的實(shí)驗(yàn)測(cè)試數(shù)據(jù)為某國(guó)歷年航班數(shù)據(jù)[19]，該數(shù)據(jù)每條記錄擁有29個(gè)屬性包括起飛時(shí)間、起飛地點(diǎn)、目的地、到達(dá)時(shí)間、航班號(hào)等。在MongoDB中每條記錄約500個(gè)字節(jié)。在Mongo-Hadoop中，通過(guò)對(duì)航班數(shù)據(jù)進(jìn)行三種具有代表性的應(yīng)用來(lái)模擬不同的場(chǎng)景:1 Filter,統(tǒng)計(jì)各個(gè)地方某一時(shí)間段的航班總數(shù),該操作對(duì)數(shù)據(jù)集進(jìn)行統(tǒng)計(jì),得到結(jié)果遠(yuǎn)遠(yuǎn)小于輸入,用來(lái)模擬Read >> Write的應(yīng)用場(chǎng)景。2 Recorder,將航班數(shù)據(jù)中年月日的分隔符“,”改為“-”,如“2000,12,05”改為“2000-12-05”,其余數(shù)據(jù)保持不變,用來(lái)模擬Read==Write的應(yīng)用場(chǎng)景。3 Merge,每條記錄添加一個(gè)備注屬性,該屬性的值為一個(gè)隨機(jī)字符串,大小為1000字節(jié),用來(lái)模擬Read << Write的應(yīng)用場(chǎng)景。

2.2實(shí)驗(yàn)配置

實(shí)驗(yàn)中使用的節(jié)點(diǎn)配置為Pentium(R) Duo-Core CPU T6300,內(nèi)存4 GB,硬盤(pán)30 GB,而運(yùn)行的操作系統(tǒng)為Ubuntu 12.04.2 LTS(64位)。節(jié)點(diǎn)間通過(guò)快速以太網(wǎng)相連。HDFS采用默認(rèn)配置,塊大小設(shè)置為64 MB,副本因數(shù)設(shè)置為2。實(shí)驗(yàn)采用的總節(jié)點(diǎn)數(shù)為19,其中包括NameNode,路由器,配置服務(wù)器各1個(gè),Hadoop DataNode與TaskTrack與MongoDB分片重疊部署的節(jié)點(diǎn)有8個(gè),MongoDB分片從節(jié)點(diǎn)8個(gè)。

2.3實(shí)驗(yàn)結(jié)果與分析

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

圖4、圖5中可以看出HDFS數(shù)據(jù)加載與導(dǎo)出性能要明顯優(yōu)于MongoDB,導(dǎo)致該性能差異的原因?yàn)?HDFS不需要讀取數(shù)據(jù),然后進(jìn)行解析,再進(jìn)行序列化以數(shù)據(jù)庫(kù)內(nèi)部格式存入磁盤(pán),數(shù)據(jù)的加載與導(dǎo)出操作僅僅是文件的復(fù)制或移動(dòng)。HDFS數(shù)據(jù)的導(dǎo)入導(dǎo)出性能與數(shù)據(jù)的大小大致呈正比,基本上穩(wěn)定在25 000條記錄/秒左右,而MongoDB的數(shù)據(jù)導(dǎo)入導(dǎo)出性能則隨著數(shù)據(jù)集的增大,其導(dǎo)入導(dǎo)出速率都有所下降,導(dǎo)入速率表現(xiàn)得尤為明顯,當(dāng)數(shù)據(jù)為兩百萬(wàn)的時(shí)候其速率為8620條記錄/秒,隨著數(shù)據(jù)集增大到800萬(wàn)時(shí),其速率下降到3532條記錄/秒,其原因?yàn)镸ongoDB對(duì)數(shù)據(jù)的存儲(chǔ)采用內(nèi)存映射機(jī)制,當(dāng)數(shù)據(jù)量增大,內(nèi)存占用過(guò)大,數(shù)據(jù)導(dǎo)致導(dǎo)入導(dǎo)出速率下降。

圖4　HDFS、MongoDB加載不同記錄數(shù)量耗時(shí)對(duì)比　　　圖5　HDFS、MongoDB導(dǎo)出不同記錄數(shù)量耗時(shí)對(duì)比

2.3.2不同應(yīng)用在不同整合方案下的性能對(duì)比分析

圖6展示了當(dāng)輸入遠(yuǎn)大于輸出時(shí)(約1萬(wàn)∶1)數(shù)據(jù)的處理情況,如圖可知,處理400萬(wàn)條記錄時(shí),方案一比方案四快了0.3倍,而當(dāng)記錄達(dá)到3200萬(wàn)條時(shí),快了0.6倍,隨著記錄的增大,該差距也逐漸增大。方案三與方案一相比,只是數(shù)據(jù)的輸入源不同,后者比前者平均快了0.4倍,因此可以判斷,從MongoDB讀取數(shù)據(jù)要比從HDFS中讀取數(shù)據(jù)開(kāi)銷(xiāo)大。對(duì)于方案一與方案二以及方案三與方案四,其性能相差很小,原因是輸出數(shù)據(jù)非常小,數(shù)據(jù)寫(xiě)入位置對(duì)性能造成的影響極小。

圖7展示了當(dāng)輸入等于輸出的數(shù)據(jù)處理情況,其中在不同數(shù)據(jù)集下方案一比方案四快了1.1到2.7倍,比方案二快了0.9到2.3倍,而相比方案三只快了0.16到0.3倍,與圖6不同,在同樣的輸入下輸出結(jié)果的寫(xiě)入位置對(duì)性能造成較大的影響,因此對(duì)同樣的數(shù)據(jù)集作同樣的處理但在不同的Mongo-Hadoop整合方案下,方案三在性能上最為接近方案一。

圖8展示了寫(xiě)密集型的作業(yè),輸出為輸入的四倍。從圖中可以看出,數(shù)據(jù)的寫(xiě)入位置對(duì)性能起了決定性的作用,將數(shù)據(jù)寫(xiě)入到HDFS比將數(shù)據(jù)寫(xiě)入到MongoDB整體性能平均將近快了5倍。因此,相比HDFS來(lái)說(shuō)將數(shù)據(jù)寫(xiě)入MongoDB開(kāi)銷(xiāo)非常大。

在圖9中,由于3種不同類(lèi)型的操作是對(duì)同一數(shù)據(jù)集作不同的處理,因此圖中顯示讀取數(shù)據(jù)集所花費(fèi)的時(shí)間也一樣。而數(shù)據(jù)處理所花費(fèi)的時(shí)間只占整個(gè)開(kāi)銷(xiāo)中很小的一部分,因此寫(xiě)是引起性能差異的主要因素。對(duì)比Filter操作和Merge操作,處理1600萬(wàn)條數(shù)據(jù),采用方案四,讀密集型作業(yè)比寫(xiě)密集型作業(yè)在性能上高出了11倍。而采用方案三,在性能上則只高出3.3倍。在Recorder操作中,將數(shù)據(jù)寫(xiě)入MongoDB的開(kāi)銷(xiāo)是寫(xiě)入HDFS的4倍,在Merge操作中達(dá)到了6.2倍。

圖9中的方案一表示從HDFS讀/寫(xiě)入HDFS,方案二表示從HDFS讀/寫(xiě)入MongoDB,方案三表示從MongoDB讀/寫(xiě)入HDFS,方案四表示從MongoDB讀/寫(xiě)入MongoDB。

2.3.3不同整合方案配置下的可擴(kuò)展性測(cè)試

從圖10可以看出,當(dāng)集群規(guī)模從4核擴(kuò)展到8核時(shí),方案一、方案二、方案三、方案四在整體性能上分別提高了94%、77%、99%、89%,從圖中可以明顯看出,各個(gè)方案下的讀寫(xiě)時(shí)間和處理時(shí)間都接近減半。而從8核擴(kuò)展到16核時(shí),各方案下的性能分別只提高了59%、14%、55%、15%,其中數(shù)據(jù)寫(xiě)入MongoDB的性能僅僅提高10%~15%,而從MongoDB讀取數(shù)據(jù)的性能提高55%~60%。集群規(guī)模為4核時(shí),對(duì)1600萬(wàn)條數(shù)據(jù)作不同的處理,通過(guò)對(duì)CPU和內(nèi)存的監(jiān)控發(fā)現(xiàn),其利用率都達(dá)到了90%~98%,如前所述,Mongo-Hadoop采用的是Hadoop TaskTracker、DataNode與MongoDB服務(wù)器重疊部署的方式來(lái)實(shí)現(xiàn),因而在CPU和內(nèi)存緊張的情況下,容易形成彼此之間對(duì)內(nèi)存和CPU的競(jìng)爭(zhēng),從而使性能降低,當(dāng)集群擴(kuò)展到8核時(shí),內(nèi)存和CPU的利用率下降到55%~60%,因而緩解了CPU和內(nèi)存的制約,性能獲得非常大的提高,由此可知對(duì)于內(nèi)存和CPU的占用率過(guò)大造成的性能損失,Mongo-Hadoop可以很容易地通過(guò)橫向擴(kuò)展添加節(jié)點(diǎn)的方式來(lái)彌補(bǔ)。集群規(guī)模從8核擴(kuò)展到16核,從上面分析得知其性能提高得相對(duì)較少,原因是充足CPU和內(nèi)存對(duì)性能的制約大大減少。在CPU和內(nèi)存充足的情況下,方案四通過(guò)擴(kuò)大集群規(guī)模能夠顯著減少讀取時(shí)間,其原因是隨著集群規(guī)模的增大,擁有更多的Map并發(fā)讀取本地MongoDB中的數(shù)據(jù)。而對(duì)于寫(xiě)的情況,發(fā)生在Reduce階段,雖然擴(kuò)大集群規(guī)模同樣能過(guò)增加Reduce的并發(fā)數(shù),但是將數(shù)據(jù)分發(fā)到MongoDB各個(gè)分片服務(wù)器占用了很大的開(kāi)銷(xiāo),因此寫(xiě)性能的提高相對(duì)很少。

圖10中的方案一表示從HDFS讀/寫(xiě)入HDFS,方案二表示從HDFS讀/寫(xiě)入MongoDB,方案三表示從MongoDB讀/寫(xiě)入HDFS,方案四表示從MongoDB讀/寫(xiě)入MongoDB。

圖10　Mongo-Hadoop進(jìn)行Recorder操作的可擴(kuò)展性測(cè)試

2.3.4整合方案的折衷使用

由上分析可知,將MongoDB代替HDFS成為數(shù)據(jù)的輸入源和輸出目標(biāo),都會(huì)引起讀寫(xiě)性能的下降,而寫(xiě)表現(xiàn)得最為明顯。在CPU和內(nèi)存充足的情況下,通過(guò)橫向擴(kuò)展的方式可以顯著提高數(shù)據(jù)的讀取性能,但對(duì)于寫(xiě)性能的提高相對(duì)很少。由前面實(shí)驗(yàn)推導(dǎo),在利用Mongo-Hadoop對(duì)數(shù)據(jù)進(jìn)行處理時(shí),可得出以下結(jié)論:若采用方案一,對(duì)MongoDB中的數(shù)據(jù)進(jìn)行處理時(shí),必須先將數(shù)據(jù)導(dǎo)出到本地,然后再上傳到HDFS,經(jīng)Hadoop處理后,再將結(jié)果從HDFS導(dǎo)入到MongoDB,這樣,數(shù)據(jù)的導(dǎo)入導(dǎo)出將引起巨大的開(kāi)銷(xiāo),因此該方案下對(duì)MongoDB中的數(shù)據(jù)作處理性能最低。若采用方案二,對(duì)于非MongoDB中的數(shù)據(jù),或該數(shù)據(jù)集已存在于HDFS,需要對(duì)該數(shù)據(jù)進(jìn)行讀密集型操作且數(shù)據(jù)處理結(jié)果需要靈活查詢時(shí),該配置提供了最優(yōu)性能,原因是數(shù)據(jù)導(dǎo)入HDFS性能比MongoDB快了4~5倍,且Mongo-Hadoop從HDFS讀取數(shù)據(jù)要優(yōu)于從MongoDB讀取數(shù)據(jù)。若采用方案三,對(duì)于已經(jīng)存在于MongoDB中的數(shù)據(jù)進(jìn)行寫(xiě)密集型操作,且結(jié)果集需要MapReduce作后續(xù)處理時(shí),該方案提供了最優(yōu)性能。原因是將相對(duì)較大的結(jié)果集直接寫(xiě)入MongoDB帶來(lái)的開(kāi)銷(xiāo)巨大。若采用方案四,對(duì)于已經(jīng)存在于MongoDB中的數(shù)據(jù),需要對(duì)數(shù)據(jù)進(jìn)行統(tǒng)計(jì)和聚合計(jì)算且對(duì)結(jié)果集進(jìn)行靈活查詢時(shí),該方案提供了最優(yōu)性能。其原因是對(duì)于讀密集型操作,Mongo-Hadoop具備良好的擴(kuò)展性,能夠快捷讀取MongoDB分片中的數(shù)據(jù)經(jīng)MapReduce處理后將相對(duì)較小的結(jié)果集輕松寫(xiě)回到MongoDB。

3結(jié)語(yǔ)

整合MongoDB與Hadoop應(yīng)對(duì)大型數(shù)據(jù)集的處理,使得MongoDB可以利用Hadoop MapRecue對(duì)自身數(shù)據(jù)進(jìn)行復(fù)雜的分析計(jì)算,同時(shí)MongoDB可以對(duì)結(jié)果進(jìn)行檢索和查詢。將MongoDB代替Hadoop HDFS作為Hadoop MapReduce的數(shù)據(jù)輸入源和輸出目標(biāo),針對(duì)不同的應(yīng)用,其性能都會(huì)有所下降,對(duì)于讀密集型的操作,MongoDB作為數(shù)據(jù)源的性能略低于HDFS,其性能大致相當(dāng),但對(duì)于寫(xiě)密集型作業(yè),其性能差異表現(xiàn)得非常明顯。針對(duì)此種情況,本文將HDFS,MongoDB配置成Hadoop MapReduce的可選輸入源和輸出目標(biāo),對(duì)不同的應(yīng)用可以通過(guò)靈活配置來(lái)獲取最優(yōu)性能。

參考文獻(xiàn)

[1] Dean J,Ghemawat S.MapReduce:simplified data processing on large clusters[J].CACM,2008,51(1):107-113.

[2] Apache Hadoop[EB/OL].(2014-06-30).http://hadoop.apache.org.

[3] White T.Hadoop:the Definitive Guide[M].California:O’Reilly Media,2012.

[4] Pokorny J.Nosql databases:a step to database scalability in web environment[J].International Journal of Web Information Systems,2013,9(1):69-82.

[5] Amazon DynamoDB[EB/OL].http://aws.amazon.com/dynamodb/.

[6] MongoDB[EB/OL].http://www.mongodb.org.

[7] Plugge E,Hawkins T,Membrey P.The Definitive Guide to MongoDB:the NoSQL Database for Cloud and Desktop Computing[M].Berkely,CA,USA:Apress,2010.

[8] Chang F,Dean J,Ghemawat S,et al.Bigtable:A distributed storage system for structured data[J].ACM Transactions on Computer Systems,2008,26(2):4.

[9] Dede E,Sendir B,Kuzlu P,et al.An evaluation of Cassandra for Hadoop[C]//Cloud Computing (CLOUD),2013 IEEE Sixth International Conference on. IEEE,2013:494-501.

[10] Fadika Z,Dede E,Govindaraju M,et al.Benchmarking MapReduce implementations for application usage scenarios[C]//Grid Computing (GRID),2011 12th IEEE/ACM International Conference on.IEEE,2011:90-97.

[11] Liu Yimeng,Wang Yizhi,Jin Yi.Research on the improvement of MongoDB auto-sharding in cloud environment[C]//Computer Science & Education (ICCSE),2012 7th International Conference on.IEEE,2012:851-854.

[12] Fadika Z,Dede E,Hartog J,et al.MARLA:MapReduce for heterogeneous clusters[C]//Cluster,Cloud and Grid Computing (CCGrid),2012 12th IEEE/ACM International Symposium on.IEEE,2012:49-56.

[13] Fadika Z,Govindaraju M.DELMA:dynamically elastic MapReduce framework for CPU-intensive applications.Cluster[C]//Cloud and Grid Computing (CCGrid),2011 11th IEEE/ACM International Symposium on.IEEE,2011:454-463.

[14] Fadika Z,Govindaraju M,Canon R,et al.Evaluating Hadoop for data-intensive scientific operations[C]//Cloud Computing (CLOUD),2012 IEEE 5th International Conference on.IEEE,2012:67-74.

[15] Wei Jianwen,Zhao Yusu,Jiang Kaida,et al.Analysis farm:a cloud-based scalable aggregation and query platform for network log analysis[C]//Cloud and Service Computing (CSC),2011 International Conference on.IEEE,2011:354-359.

[16] SpiderMonkey[EB/OL].https://developer.mozilla.org/en/SpiderMonkey.

[17] Dede E,Govindaraju M,Gunter D,et al.Performance evaluation of a MongoDB and Hadoop platform for scientific data analysis[C]//Proceedings of the 4th ACM workshop on Scientific cloud computing,2013:13-20.

[18] Bonnet L,Laurent A,Sala M,et al.Reduce,you say:what NoSQL can do for data aggregation and BI in large repositories[C]//Database and Expert Systems Applications (DEXA),2011 22nd International Workshop on.IEEE,2011:483-488.

[19] Hacking Airline DataSet with H2O[EB/OL].(2013-04-12).https://github.com/0xdata/po/wiki/Hacking-Airline-DataSet-with-H2O.

中圖分類(lèi)號(hào)TP311.5

文獻(xiàn)標(biāo)識(shí)碼A

DOI:10.3969/j.issn.1000-386x.2016.02.005

收稿日期：2014-06-20。國(guó)家自然科學(xué)基金項(xiàng)目(61272546)。曾強(qiáng)，碩士生，主研領(lǐng)域：分布式，云計(jì)算?？娏Γ苯淌?。秦拯，教授。