分布式NameNode在云存儲(chǔ)平臺(tái)中的應(yīng)用

丘剛瑋 黃欣

摘要：為了解決HDFS單一NameNode處理大批量并發(fā)訪問的瓶頸問題，論文提出了一種基于MongoDB數(shù)據(jù)庫的分布式NameNode節(jié)點(diǎn)架構(gòu)，增強(qiáng)節(jié)點(diǎn)的處理能力，進(jìn)一步提高了HDFS集群的性能。實(shí)驗(yàn)結(jié)果表明：基于MongoDB數(shù)據(jù)庫的分布式NameNode節(jié)點(diǎn)架構(gòu)方案不僅有效擴(kuò)展了HDFS的命名空間，同時(shí)提高了HDFS集群的并發(fā)讀寫能力。

關(guān)鍵詞：MongoDB;分布式存儲(chǔ);單一NameNode節(jié)點(diǎn);HDFS

中圖分類號(hào)：TP393? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2019）28-0040-03

Abstract： Aiming at the bottleneck of concurrent access of HDFS single NameNode， a distributed NameNode architecture based on MongoDB database is proposed. It improves the processing capacity of nodes and the performance of HDFS cluster. The experimental results show that the approach of MongoDB and distributed NameNode not only extends the namespace of HDFS effectively， but also improves the concurrent reading and writing ability of HDFS cluster.

Key words： MongoDB; distributed storage; single NameNode; HDF

HDFS（Hadoop Distributed File System）是Google GFS開源的Hadoop分布式文件系統(tǒng)，可存儲(chǔ)海量大數(shù)據(jù)，由于其具有高可靠性、高可用性、高伸縮性等特性，目前已經(jīng)成功應(yīng)用于航空安全QAR（Quick access recorder）數(shù)據(jù)分析[1]、醫(yī)學(xué)影像存儲(chǔ)[2]、預(yù)測(cè)模型[3]、云儲(chǔ)存系統(tǒng)平臺(tái)實(shí)現(xiàn)[4]等多個(gè)領(lǐng)域。由于單一NameNode限制導(dǎo)致的性能問題，HDFS在實(shí)際應(yīng)用過程中漸漸暴露不足之處。眾多學(xué)者針對(duì)此問題進(jìn)行多方面的改進(jìn)，文獻(xiàn)[5]的改進(jìn)方法是在DataNode 節(jié)點(diǎn)中存儲(chǔ)小文件的元數(shù)據(jù)信息;文獻(xiàn)[6]采用元數(shù)據(jù)壓縮打包方式來減少元數(shù)據(jù)的大小;文獻(xiàn)[7]在另一臺(tái)服務(wù)器存放元數(shù)據(jù)塊到Datanode的映射信息，以降低NameNode的壓力。這些改進(jìn)有效地減少了NameNode節(jié)點(diǎn)的讀寫請(qǐng)求，在一定程度上減緩了單一NameNode性能問題。但是這些改進(jìn)方法的本質(zhì)不變，還是由一個(gè)主節(jié)點(diǎn)NameNode控制訪問交互[8]。隨著文件數(shù)量級(jí)增長(zhǎng)，大批量并發(fā)訪問，單一NameNode節(jié)點(diǎn)的連接數(shù)和處理能力將受到極大的挑戰(zhàn)，導(dǎo)致整個(gè)HDFS集群性能瓶頸。為了從本質(zhì)上解決單一NameNode限制問題，基于MongoDB數(shù)據(jù)庫對(duì)其架構(gòu)進(jìn)行優(yōu)化，以便能夠支持多NameNode節(jié)點(diǎn)。

1 單一NameNode的HDFS分析

現(xiàn)有HDFS使用的是主/從架構(gòu)，一個(gè)HDFS集群包括了單一NameNode節(jié)點(diǎn)及大量DataNode節(jié)點(diǎn)。NameNode節(jié)點(diǎn)管理和維護(hù)所有的命名空間和元數(shù)據(jù)信息。當(dāng)Client訪問HDFS集群時(shí)，由NameNode控制訪問交互，再執(zhí)行實(shí)際數(shù)據(jù)操作，可以說整個(gè)HDFS集群僅僅一個(gè)入口點(diǎn)。所以，NameNode節(jié)點(diǎn)相當(dāng)于是整個(gè)集群的核心和關(guān)鍵。此外，DataNode節(jié)點(diǎn)還可以與Client及另外的DataNode節(jié)點(diǎn)進(jìn)行交互。為了避免單一NameNode節(jié)點(diǎn)限制問題，HDFS盡可能減少了Client對(duì)NameNode節(jié)點(diǎn)的操作。Client在讀寫數(shù)據(jù)時(shí)，首先向NameNode節(jié)點(diǎn)獲知元數(shù)據(jù)信息，然后根據(jù)這些信息直接與DataNode節(jié)點(diǎn)交互，進(jìn)行讀寫數(shù)據(jù)。雖然盡可能使NameNode輕量級(jí)，但元數(shù)據(jù)信息仍然占文件系統(tǒng)超過一半以上。隨著HDFS運(yùn)行的任務(wù)數(shù)量的增加，NameNode的負(fù)荷變得越來越重，必定影響文件系統(tǒng)整體性能。Client對(duì)HDFS的操作都必須先向NameNode節(jié)點(diǎn)請(qǐng)求，雖然客戶端只需獲知較少的元數(shù)據(jù)信息，但如果同一時(shí)間有非常多的請(qǐng)求，NameNode的負(fù)荷非常重，有些Client的操作就無法及時(shí)響應(yīng)，這就是HDFS關(guān)于單一NameNode的性能問題核心所在。

2 可擴(kuò)展的多NameNode節(jié)點(diǎn)優(yōu)化原理

2.1 優(yōu)化難點(diǎn)分析

在現(xiàn)有的HDFS架構(gòu)中單一NameNode節(jié)點(diǎn)是HDFS的主要服務(wù)器，負(fù)責(zé)管理管理和維護(hù)整個(gè)文件系統(tǒng)的命名空間和元數(shù)據(jù)信息，分工明確。Client對(duì)HDFS集群發(fā)送請(qǐng)求時(shí)都必須先和NameNode交互才能與相應(yīng)的DataNode節(jié)點(diǎn)進(jìn)行實(shí)際的數(shù)據(jù)操作。即把單一NaneNode架構(gòu)優(yōu)化為多NameNode節(jié)點(diǎn)的架構(gòu)關(guān)鍵之處主要有以下三點(diǎn)：如何命名分布式NameNode，當(dāng)單一NameNode節(jié)點(diǎn)變?yōu)榈蕉郚ameNode節(jié)點(diǎn)時(shí)，多NameNode節(jié)點(diǎn)該如何命名以及分布;如何定位有關(guān)文件元數(shù)據(jù)信息的位置，當(dāng)Client發(fā)起讀某一文件請(qǐng)求時(shí)，如何快速定位NameNode節(jié)點(diǎn)并獲取其元數(shù)據(jù)信息，進(jìn)一步獲取DataNode節(jié)點(diǎn)信息讀取相關(guān)文件;數(shù)據(jù)一致性問題，當(dāng)Client與某一個(gè)NameNode節(jié)點(diǎn)的對(duì)其元數(shù)據(jù)信息進(jìn)行更改操作，其他的NameNode節(jié)點(diǎn)如何實(shí)時(shí)獲取同樣的更改并作出一樣的更改操作。

2.2 基于MongoDB的解決方案

Mongodb是一種分布式NoSQL數(shù)據(jù)庫，基于C++語言，可支持關(guān)系型數(shù)據(jù)庫的絕大多數(shù)操作，可存儲(chǔ)多種格式的數(shù)據(jù)類型[9]。MongoDB數(shù)據(jù)庫兼具存儲(chǔ)性能高、易部署、易于使用、功能豐富、支持索引等優(yōu)點(diǎn)。非關(guān)系型數(shù)據(jù)庫可在HDFS上部署，相對(duì)于傳統(tǒng)關(guān)系型數(shù)據(jù)庫，NoSQL數(shù)據(jù)庫部署在分布式集群上，增加了可存儲(chǔ)的數(shù)據(jù)量，可以維護(hù)更多的DataNode，擴(kuò)展性更強(qiáng)，并減少了對(duì)單個(gè)節(jié)點(diǎn)的通信壓力。

引入MongoDB的優(yōu)化方案，把整個(gè)文件系統(tǒng)的命名空間以及元數(shù)據(jù)信息的控制由NameNode轉(zhuǎn)化為MongoDB數(shù)據(jù)庫中，采用星型狀將多個(gè)NameNode節(jié)點(diǎn)與MongoDB連接，每個(gè)NameNode節(jié)點(diǎn)相當(dāng)于只是負(fù)責(zé)整個(gè)文件系統(tǒng)一部分命名空間，所有NameNode的元數(shù)據(jù)信息的集合才是整個(gè)文件系統(tǒng)的命名空間和元數(shù)據(jù)信息。當(dāng)啟動(dòng)HDFS集群時(shí)，將重構(gòu)有關(guān)數(shù)據(jù)塊和DataNode節(jié)點(diǎn)間的映射信息，并將其記錄到MongoD數(shù)據(jù)庫。規(guī)定某個(gè)指定的Client只能和某個(gè)指定的NameNode進(jìn)行交互，各個(gè)NameNode間沒有交互，保證文件系統(tǒng)的一致性。其架構(gòu)如圖1所示：

當(dāng)Client發(fā)起請(qǐng)求時(shí)，先與其中一個(gè)NameNode節(jié)點(diǎn)連接，根據(jù)命名空間查看是否存在所需的元數(shù)據(jù)信息，如果無，則對(duì)MongoDB數(shù)據(jù)庫進(jìn)行查詢，獲取相應(yīng)文件名的元數(shù)據(jù)信息（文件名和數(shù)據(jù)塊間映射，數(shù)據(jù)塊和DataNode節(jié)點(diǎn)間映射），將其加載到NameNode節(jié)點(diǎn)內(nèi)存中。當(dāng)Client下次訪問該文件的時(shí)，可直接在NameNode節(jié)點(diǎn)獲取相關(guān)的元數(shù)據(jù)信息，就不用再對(duì)MongoDB進(jìn)行訪問，即“一次加載，多次讀取”，相當(dāng)于原始的單一NameNode節(jié)點(diǎn)同Client和DataNode節(jié)點(diǎn)進(jìn)行交互。

在寫數(shù)據(jù)時(shí)，實(shí)時(shí)更新當(dāng)前NameNode的元數(shù)據(jù)信息，利用延遲寫的策略將系統(tǒng)更改后的元數(shù)據(jù)信息寫入MongoDB數(shù)據(jù)庫中，以便有效減少地寫數(shù)據(jù)庫造成的延時(shí)。

3 MongoDB和分布式NameNode節(jié)點(diǎn)優(yōu)化

設(shè)計(jì)每一個(gè)NameNode的元數(shù)據(jù)信息一開始都是空的，實(shí)際整個(gè)文件的命名看空間和元數(shù)據(jù)信息都在MongoDB數(shù)據(jù)庫中，每個(gè)NameNode在首次使用時(shí)先在MongoDB數(shù)據(jù)庫中加載所需信息，在元數(shù)據(jù)發(fā)生變化時(shí)，該數(shù)據(jù)實(shí)時(shí)更新到數(shù)據(jù)庫中，并通知其他NameNode節(jié)點(diǎn)。

對(duì)于整個(gè)系統(tǒng)的元數(shù)據(jù)信息存儲(chǔ)在MongoDB數(shù)據(jù)庫，分析MongoDB和分布式NameNode節(jié)點(diǎn)優(yōu)化方案的讀寫過程。

3.1 讀文件操作

基于MongoDB數(shù)據(jù)庫和HDFS優(yōu)化方案有關(guān)讀文件操作過程如下：

（1） Client發(fā)送讀請(qǐng)求，通過open（）函數(shù)打開文件，并創(chuàng)建Distributed File System對(duì)象。

（2） Client創(chuàng)建讀取相應(yīng)文件數(shù)據(jù)信息的FSData Input Stream對(duì)象，利用read（）函數(shù)來向FSData Input Stream對(duì)象傳遞用戶的請(qǐng)求信息。

（3） HDFS的FSData Input Stream對(duì)象接收用戶請(qǐng)求后與NameNode節(jié)點(diǎn)交互，獲取該用戶的數(shù)據(jù)塊地址信息。

（4） NameNode根據(jù)FSData Input Stream對(duì)象傳送過來的請(qǐng)求信息判斷該用戶的數(shù)據(jù)塊的信息是否存在，如果存在，則向Client端的FSData Input Stream對(duì)象返回該用戶的數(shù)據(jù)塊的信息;如果不存在，NameNode節(jié)點(diǎn)就去Mongo DB數(shù)據(jù)庫中讀取所需的數(shù)據(jù)塊信息，并將此信息保存在NameNode中，然后再向Client端的FSData Input Stream對(duì)象返回該用戶的信息。

（5） FSData Input Stream對(duì)象接收返回的數(shù)據(jù)塊文件的地址信息后向該用戶的DataNode節(jié)點(diǎn)發(fā)出read（）請(qǐng)求，讀取用戶所需要的元數(shù)據(jù)信息，并呈現(xiàn)給用戶，此時(shí)利用close（）函數(shù)關(guān)閉讀取數(shù)據(jù)流，HDFS讀操作完成。

3.2 寫文件操作

基于MongoDB數(shù)據(jù)庫和HDFS優(yōu)化方案有關(guān)寫文件操作過程如下：

（1） Client發(fā)起寫請(qǐng)求，利用open（）函數(shù)來打開文件，并建立Distributed File System對(duì)象。

（2） 利用create（）方法創(chuàng)建文件上傳的FSData Output Stream數(shù)據(jù)流對(duì)象。

（3） 向特定的NameNode發(fā)送新建文件目錄的請(qǐng)求，該文件條目下是空的。優(yōu)化后的方案存在多個(gè)NameNode，必須事先指定不同的NameNode。

（4） NameNode節(jié)點(diǎn)接收請(qǐng)求信息后根據(jù)Client身份判斷是否有操作權(quán)限，再判斷所需文件條目是否存在，若有則不創(chuàng)建;若無則創(chuàng)建。

（5） 把用戶數(shù)據(jù)與DataNode數(shù)據(jù)節(jié)點(diǎn)對(duì)應(yīng)，并依次寫入相應(yīng)的數(shù)據(jù)塊文件。

（6） 當(dāng)DataNode節(jié)點(diǎn)存儲(chǔ)完成后向FSData Output Stream對(duì)象返回確認(rèn)。

（7） Client的FSData Output Stream對(duì)象將文件名和數(shù)據(jù)塊間映射，數(shù)據(jù)塊和DataNode節(jié)點(diǎn)間映射等元數(shù)據(jù)信息存入相應(yīng)的NameNode節(jié)點(diǎn)，NameNode節(jié)點(diǎn)再將該元數(shù)據(jù)信息持久化到MongoDB數(shù)據(jù)庫中。

（8） 待需要上傳的文件完成后，Client會(huì)執(zhí)行close（）函數(shù)關(guān)閉寫操作流，HDFS寫操作完成。

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

4.1 實(shí)驗(yàn)環(huán)境配置

在單一NameNode節(jié)點(diǎn)限制優(yōu)化測(cè)試方案中，選用兩臺(tái)物理機(jī)上架構(gòu)HDFS系統(tǒng)，即NameNode的配置為Inter（R） Xeon（R） CPU E5-1620 v3 @3.5 GHz，內(nèi)存為512M，分別命名為NameNode1和NameNode2，MongDB所在服務(wù)器的配置為Inter（R） Xeon（R） CPU E5-1620 v3 @3.5 GHz，MEM為2.0GB。

4.2 實(shí)驗(yàn)參數(shù)設(shè)置

針對(duì)并發(fā)訪問處理的實(shí)驗(yàn)設(shè)計(jì)，對(duì)于改進(jìn)前的方案，模擬12個(gè)Client進(jìn)程，對(duì)HDFS并發(fā)讀寫操作;對(duì)于改進(jìn)后的方案，模擬6個(gè)Client進(jìn)程訪問NameNode1，6個(gè)Client進(jìn)程訪問NameNode2。設(shè)定文件讀寫規(guī)模為1000、3000、5000、10000、15000，每個(gè)Client進(jìn)程分別對(duì)改進(jìn)前后的系統(tǒng)并發(fā)讀寫，并分別其記錄寫入時(shí)間。

4.3 結(jié)果分析

4.3.1 并發(fā)讀寫文件速度對(duì)比

改進(jìn)前后的系統(tǒng)并發(fā)寫入文件結(jié)果如圖2所示，改進(jìn)前后的系統(tǒng)并發(fā)讀取文件結(jié)果如圖3。

由圖2、圖3可知，由于改進(jìn)的方案與原始的單一NameNode方案不同，采用了基于MongDB數(shù)據(jù)庫的NameNode1和NameNode2多個(gè)NameNode，使得系統(tǒng)能夠在處理進(jìn)行并發(fā)讀寫請(qǐng)求，尤其是文件數(shù)據(jù)量比較多的情況下，分布式NameNode節(jié)點(diǎn)的處理能力優(yōu)勢(shì)比較明顯。

4.3.2 首次響應(yīng)和元數(shù)據(jù)加載為實(shí)體響應(yīng)

上述實(shí)驗(yàn)是基于所有的元數(shù)據(jù)都存在NameNode中的并發(fā)讀時(shí)間，由于NameNode進(jìn)行首次查詢?cè)獢?shù)據(jù)的時(shí)候，先查詢MongDB數(shù)據(jù)庫的信息。所以，需要測(cè)試首次響應(yīng)和元數(shù)據(jù)加載為實(shí)體后響應(yīng)延遲時(shí)間，文件規(guī)模同上。實(shí)驗(yàn)結(jié)果如圖4。

由圖4可知，隨著文件規(guī)模的不斷增大，首次從MongoDB里加載元數(shù)據(jù)信息延遲比較嚴(yán)重。但是，由于元數(shù)據(jù)信息在首次加載后，之后的操作就不必去查詢數(shù)據(jù)庫，所以，即可以“一次加載，多次讀取”，在實(shí)際應(yīng)用中這些延遲基本是可以忽略不計(jì)的。

綜上，在大規(guī)模文件數(shù)據(jù)下，分布式存儲(chǔ)的優(yōu)勢(shì)比較明顯，分布式NameNode+MongoDB方式響應(yīng)時(shí)間最快，并使得HDFS的命名空間得到擴(kuò)展。

5 結(jié)束語

HDFS分布式文件存儲(chǔ)由單一NameNode節(jié)點(diǎn)控制多個(gè)DataNode節(jié)點(diǎn)的存儲(chǔ)方式容易在單一NameNode節(jié)點(diǎn)出現(xiàn)瓶頸問題。分布式NameNode+MongoDB方案的核心思想將HDFS集群中由原來的一個(gè)NameNode節(jié)點(diǎn)控制的架構(gòu)優(yōu)化成多個(gè)NameNode控制。該方式既保證了整個(gè)集群數(shù)據(jù)信息的完整性又有效地減輕了單一NameNode節(jié)點(diǎn)的負(fù)荷，進(jìn)一步擴(kuò)展了HDFS的命名空間，同時(shí)提高了HDFS集群的并發(fā)讀寫能力。

在以后的工作中，將對(duì)改進(jìn)HDFS進(jìn)行更深入的研究，如解決分布式NameNode負(fù)載均衡的問題。

參考文獻(xiàn)：

[1] 馮興杰， 吳稀鈺. HDFS可視化及其在QAR數(shù)據(jù)中的應(yīng)用研究[J]. 中國民航大學(xué)學(xué)報(bào)，2017，35（01）：56-59.

[2] 方勝吉， 李憶昕， 周姍姍. 探析HDFS在區(qū)域醫(yī)學(xué)影像存儲(chǔ)上的應(yīng)用[J]. 電腦編程技巧與維護(hù)， 2017（22）：89-90.

[3] 于磊春， 陳健美， 劉響， 等. 基于預(yù)測(cè)模型的HDFS集群負(fù)載均衡優(yōu)化與研究[J]. 計(jì)算機(jī)應(yīng)用與軟件， 2018 （05）：155-162.

[4] 陳虎. 基于HDFS的云存儲(chǔ)平臺(tái)的優(yōu)化與實(shí)現(xiàn)[D]. 華南理工大學(xué)， 2012.

[5] Jiang L ， Li B ， Song M . THE optimization of HDFS based on small files[C]// IEEE International Conference on Broadband Network & Multimedia Technology. IEEE， 2011.

[6] Mackey G ， Sehrish S ， Wang J . Improving metadata management for small files in HDFS[C]// IEEE International Conference on Cluster Computing & Workshops. IEEE， 2009.

[7] 欒亞建. 分布式文件系統(tǒng)元數(shù)據(jù)管理研究與優(yōu)化[D]. 華南理工大學(xué)， 2010.

[8] 高考數(shù)據(jù)分布式存儲(chǔ)優(yōu)化的設(shè)計(jì)與實(shí)現(xiàn)[D]. 山東師范大學(xué)，? 2017.

[9] 曾強(qiáng)， 繆力， 秦拯， 等. 面向大數(shù)據(jù)處理的Hadoop與MongoDB整合技術(shù)研究[J]. 計(jì)算機(jī)應(yīng)用與軟件， 2016（2）： 21-24.

【通聯(lián)編輯：代影】