基于HDFS的創(chuàng)新知識云平臺存儲架構(gòu)的研究與設(shè)計(jì)

馬建紅　霍振奇

(河北工業(yè)大學(xué)計(jì)算機(jī)科學(xué)與軟件學(xué)院　天津 300401)

?

基于HDFS的創(chuàng)新知識云平臺存儲架構(gòu)的研究與設(shè)計(jì)

馬建紅霍振奇

(河北工業(yè)大學(xué)計(jì)算機(jī)科學(xué)與軟件學(xué)院天津 300401)

針對現(xiàn)有存儲結(jié)構(gòu)無法滿足海量創(chuàng)新知識帶來的存儲及服務(wù)需求的問題，提出一種改進(jìn)的HDFS(Hadoop Distributed File System)分布式存儲系統(tǒng)并應(yīng)用到創(chuàng)新知識云平臺。首先引入包文件及分布式索引服務(wù)，改進(jìn)HDFS小文件存儲的效率問題，然后通過優(yōu)化HDFS的命名空間備份及故障恢復(fù)服務(wù)，實(shí)現(xiàn)可用性更強(qiáng)、資源利用率更高的HDFS高可用架構(gòu)。通過系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)證明優(yōu)化工作大大降低了命名節(jié)點(diǎn)的內(nèi)存壓力，提高了集群的可用性，并且改進(jìn)的HDFS存儲系統(tǒng)可以滿足創(chuàng)新知識云平臺的存儲需求。

創(chuàng)新知識HDFS小文件存儲單點(diǎn)故障

0　引　言

一直以來創(chuàng)新都是國內(nèi)外各行各業(yè)在場競爭中關(guān)注的重點(diǎn)之一，我國更是將科技創(chuàng)新作為國家的基本戰(zhàn)略。其中，建立創(chuàng)新平臺對創(chuàng)新知識進(jìn)行全社會共享是促進(jìn)創(chuàng)新發(fā)展過程中一個(gè)必不可少的環(huán)節(jié)。創(chuàng)新知識[1]的復(fù)雜性以及其量級帶來的是計(jì)算的復(fù)雜性和服務(wù)的動態(tài)性要求，這正與云計(jì)算的特性相契合。因此將云計(jì)算的概念引入到創(chuàng)新知識平臺的建設(shè)也是一種必然的發(fā)展要求。

創(chuàng)新知識云平臺旨在幫助創(chuàng)新設(shè)計(jì)人員解決創(chuàng)新過程中的問題。其結(jié)構(gòu)主要包含對創(chuàng)新知識的收集積累、加工整合和知識再利用等過程。該平臺由一個(gè)創(chuàng)新知識云平臺總站和多個(gè)創(chuàng)新基地組成。創(chuàng)新基地是知識產(chǎn)生的地方，也是運(yùn)用創(chuàng)新知識的地方。創(chuàng)新平臺總站負(fù)責(zé)所有基地?cái)?shù)據(jù)的加工，整理和元數(shù)據(jù)提取，然后將具有邏輯關(guān)系的高實(shí)用性知識分發(fā)到各個(gè)基地，從而提高知識的可達(dá)性實(shí)現(xiàn)創(chuàng)新知識的社會共享。如圖1所示。

圖1　創(chuàng)新知識云平臺架構(gòu)

應(yīng)當(dāng)注意創(chuàng)新知識數(shù)據(jù)的一些獨(dú)特特性。首先是創(chuàng)新知識的多元性。創(chuàng)造發(fā)明的內(nèi)在規(guī)律和原理必須通過大量的數(shù)據(jù)支撐才能體現(xiàn)其價(jià)值，而這些數(shù)據(jù)必然是多樣性的，且數(shù)據(jù)之間的聯(lián)系也是復(fù)雜多變的。其次，創(chuàng)新知識條目眾多但是每條知識的數(shù)據(jù)量較小。發(fā)明創(chuàng)新的過程需要大量的思考和時(shí)間，但是其結(jié)論表達(dá)往往歸納為少量的文字或圖像。然而創(chuàng)新領(lǐng)域中各種奇妙的解決思路紛繁復(fù)雜，數(shù)量可觀。最后，這些創(chuàng)新知識的運(yùn)用過程中必然要求有清晰可用的工具能夠讓用戶了解自身真實(shí)需求，進(jìn)而以準(zhǔn)確知識推理為用戶呈現(xiàn)有啟發(fā)思維作用的創(chuàng)新知識。所以，創(chuàng)新平臺必然要解決的問題就是對創(chuàng)新知識的有效關(guān)聯(lián)管理及大數(shù)據(jù)量高效存取。因此本文在優(yōu)化和改進(jìn)HDFS小文件存儲和單點(diǎn)故障問題的基礎(chǔ)上，將其引入到創(chuàng)新知識云平臺的存儲系統(tǒng)。

1　相關(guān)工作

Hadoop[2]是在大數(shù)據(jù)需求下產(chǎn)生的一種對海量數(shù)據(jù)存儲和計(jì)算的分布式云計(jì)算系統(tǒng)基礎(chǔ)架構(gòu)。HDFS[3]作為Hadoop系統(tǒng)下的文件存儲服務(wù)，因其穩(wěn)定性和高效性而得到廣泛應(yīng)用。文獻(xiàn)[4]將其應(yīng)用到醫(yī)學(xué)影像存儲領(lǐng)域，文獻(xiàn)[5]將其應(yīng)用到MapGIS K9瓦片地圖集數(shù)據(jù)存儲，文獻(xiàn)[6]則在其基礎(chǔ)上建立了云數(shù)據(jù)備份系統(tǒng)。同時(shí)，許多學(xué)者也對HDFS本身進(jìn)行了研究，如HDFS的安全問題[7]、下載效率[8]以及集群的節(jié)能問題[9]等。因此本文基于較新的Hadoop 2.2.0 版本，為創(chuàng)新知識云平臺搭建了高容錯(cuò)、高吞吐的基礎(chǔ)存儲架構(gòu)。但由于創(chuàng)新知識表達(dá)具有的特性及創(chuàng)新知識存取方式的特性，必須對HDFS的適用性作出改進(jìn)。

對于HDFS對存儲大量小文件時(shí)表現(xiàn)出的性能上的不足[10]，文獻(xiàn)[11]在Sequence File的基礎(chǔ)上實(shí)現(xiàn)小文件的合并存儲，文獻(xiàn)[12]則結(jié)合格雷碼實(shí)現(xiàn)了海量音樂特征數(shù)據(jù)管理。這些解決方案或多或少都是針對特定的數(shù)據(jù)解決方案,難以推廣應(yīng)用。Hadoop本身提供了Har、SequenceFile和MapFile三種整合存儲的結(jié)構(gòu)，但是SequenceFile和MapFile是Append Only，也就是只能對添加新的數(shù)據(jù)而不能對已有的數(shù)據(jù)進(jìn)行更新或刪除，而Har甚至是完全只讀的，也就是創(chuàng)建文件之后便不能再做任何改變。Hadoop自身在其2.0版本中引入YARN(Yet Another Resource Negotiator)和HDFS Federation，以改進(jìn)現(xiàn)有的不足并適應(yīng)新的需求。其中用于解決Nanenode內(nèi)存問題的HDFS Federation只是對命名空間進(jìn)行了拆分，并不能完全解決性能問題。本文提出了一種較為通用的具有可改寫能力的方案。該方案在保留原始存儲方式的基礎(chǔ)上添加了靈活的包文件存儲形式，用戶自行在兩者之間選擇。其中包文件存儲形式可以大量減少存儲小文件時(shí)Namenode的內(nèi)存壓力，提升存儲性能。

同時(shí)由于Namenode單點(diǎn)設(shè)計(jì)會降低整個(gè)集群的可用性問題上，也有很多文獻(xiàn)進(jìn)行了改進(jìn)優(yōu)化。其中文獻(xiàn)[13]中介紹了多種優(yōu)化方案，并指出它們在數(shù)據(jù)丟失、故障恢復(fù)時(shí)間和自動恢復(fù)等方面的不足。同時(shí)給出了一種改進(jìn)方案，但是這種改進(jìn)方案沒有考慮到對新版本中多命名空間的適應(yīng)，可能會造成大量的計(jì)算資源浪費(fèi)。文獻(xiàn)[14]中也比較了多種優(yōu)化方案，指出這些方案以及Hadoop本身提出的HA方案的不足。在其給出的解決方案中采用了扁平化的命名空間設(shè)計(jì)，以方便將metadata均勻的分布到命名節(jié)點(diǎn)中。但是這種方式無法完成層次結(jié)構(gòu)化的文件定位。本文在解決Namenode單點(diǎn)問題時(shí)，借鑒了Hadoop 2.0的高可用方案，引入Zookeeper[15]管理的備份集群，但是沒有引入外部存儲可能帶來的新的缺陷，同時(shí)充分考慮了HDFS Federation特性，實(shí)現(xiàn)了資源利用率更高的自動故障恢復(fù)功能。

本文基于實(shí)際項(xiàng)目需求，在HDFS的小文件存儲問題和主節(jié)點(diǎn)高可用問題上給出了新的解決思路，從而搭建了更加高效高可靠的云存儲平臺。需要指出的是文中的優(yōu)化策略雖然是為滿足創(chuàng)新知識云平臺的需求而設(shè)計(jì)的，但是解決方案具有很強(qiáng)的通用性，可以方便地運(yùn)用到其他云存儲設(shè)計(jì)當(dāng)中。

2　系統(tǒng)優(yōu)化方法及實(shí)現(xiàn)

2.1小文件存儲優(yōu)化

在HDFS的主從結(jié)構(gòu)設(shè)計(jì)中命名結(jié)點(diǎn)內(nèi)存中存儲了所有的命名空間元數(shù)據(jù)。由于HDFS主要被設(shè)計(jì)用于存儲超大文件，因此在系統(tǒng)內(nèi)部將文件分割為多個(gè)Block文件(默認(rèn)為64 MB，新版本中為128 MB)，Namenode直接管理這些Block信息。所以，當(dāng)系統(tǒng)中存在大量小文件的時(shí)候Namenode的內(nèi)存壓力變成了整個(gè)系統(tǒng)的瓶頸。HDFS Federation的引入在一定程度上使該問題得到了緩解，但是創(chuàng)新知識以大量小文件形式存在，小文件存儲問題仍然需要解決。

本文主要采用了將小文件合并存儲的策略，將小文件合并成一個(gè)或多個(gè)包文件，以減小命名結(jié)點(diǎn)內(nèi)存壓力；同時(shí)為了解決合并帶來的讀取性能問題，引入了索引策略及索引服務(wù)從而提高文件的存取效率。整體結(jié)構(gòu)如圖2所示。

圖2　小文件存儲服務(wù)架構(gòu)

首先在客戶端(Client)API中添加了小文件存儲服務(wù)(SmallFileStoringService)及讀取服務(wù)(SmallFileRetrieveService)分別處理小文件的寫入和讀取任務(wù)，輔助原有HDFS的API完成更高效的存儲服務(wù)。在Namenode中的小文件部署服務(wù)(SmallFileLocatingService)主要負(fù)責(zé)添加小文件時(shí)包文件所在數(shù)據(jù)塊的創(chuàng)建、增加和定位，以及包文件塊中的數(shù)據(jù)重新排布工作的協(xié)調(diào)。在Datanode中新增了兩個(gè)新的服務(wù)：小文件索引服務(wù)(SmallFileIndexingService)為小文件讀取提供索引；小文件附加服務(wù)(SmallFileAppendingService)在小文件附加刪除修改等操作的時(shí)候修改索引文件及配合小文件部署服務(wù)更新數(shù)據(jù)塊。索引文件及索引服務(wù)都是在數(shù)據(jù)結(jié)點(diǎn)上的，因此可以將大量的命名服務(wù)分散到數(shù)量較多的數(shù)據(jù)結(jié)點(diǎn)上，從而大幅減少命名結(jié)點(diǎn)的壓力。

在HDFS文件處理過程中主要包含了讀、寫和修改三個(gè)操作。其中寫操作相當(dāng)于將小文件合并(采用的HDFS的Append操作)到指定的包文件中，因此其基本步驟與Append操作流程相同，如圖3所示。

圖3　小文件寫入流程

需要注意以下三點(diǎn)：

1) 客戶端需要指定文件是否需要存儲到包文件中，在不指定的情況下，小文件也可以存儲為單獨(dú)的文件。

2) 包文件的建立時(shí)間設(shè)定在Namenode在查找目的塊的時(shí)候。此時(shí)Namenode先檢查命名空間中是否存在該包文件。如果不存在則先新建該包文件，Datanode在建立相應(yīng)的塊文件和塊元數(shù)據(jù)文件時(shí)調(diào)用小文件附加服務(wù)一并建立索引文件。

3) 數(shù)據(jù)結(jié)點(diǎn)附加操作完成后，需要調(diào)用小文件附加服務(wù)更新相應(yīng)的索引文件。

索引文件主要記錄對應(yīng)塊文件中小文件的路徑及文件結(jié)束位置，其結(jié)構(gòu)示意如下：

example1.jpg

example2.jpg

……

實(shí)例數(shù)據(jù)表示exampl1.jpg的數(shù)據(jù)位置為0～7150，而exampl2.jpg的數(shù)據(jù)位置為7151～12 540。寫文件時(shí)，讀取上一個(gè)文件的位置再加上當(dāng)前文件大小可得當(dāng)前文件結(jié)束位置。

下面介紹小文件讀取過程，如圖4所示。改進(jìn)后的文件讀取操作與原有的文件讀取操作相比，在服務(wù)器數(shù)據(jù)交互數(shù)量上是相同的，區(qū)別是改進(jìn)的過程同時(shí)讀取多個(gè)數(shù)據(jù)結(jié)點(diǎn)以真正取得所需文件。客戶端并行的向所有目的塊所在的Datanode發(fā)送讀請求。只有包含該文件的Datanode返回文件數(shù)據(jù)，其他的返回查找失敗，客戶端選擇最先返回的文件數(shù)據(jù)接收，并終止其他線程。

圖4　小文件讀取流程

對于小文件的修改和刪除操作來說，直接進(jìn)行數(shù)據(jù)塊的修改會造成性能的急劇下降。因此引入標(biāo)識位的方式避免頻繁的數(shù)據(jù)修改。在文件修改或刪除的時(shí)候，首先和讀取操作相似確定數(shù)據(jù)塊的位置，并通過小文件附加服務(wù)修改索引文件的標(biāo)識位以標(biāo)識該文件當(dāng)前的狀態(tài)。當(dāng)文件讀取的時(shí)候，小文件索引服務(wù)會將已經(jīng)標(biāo)識為刪除的文件忽略，返回索引失敗。

標(biāo)志位方式的引入會造成大量的無用文件保存在集群中。所以在命名結(jié)點(diǎn)中設(shè)計(jì)的小文件部署服務(wù)以定期任務(wù)的方式(管理員也可以手動調(diào)用)，將包文件塊中的數(shù)據(jù)重新排布并更新索引文件。當(dāng)新文件寫入時(shí)，Namenode中的小文件部署服務(wù)會根據(jù)適配算法將文件適配到合適的包文件數(shù)據(jù)塊中，以充分利用數(shù)據(jù)塊。

2.2Namenode單點(diǎn)問題改進(jìn)

Hadoop之前的主要結(jié)構(gòu)中Master主機(jī)中運(yùn)行著所有MapReduce的JobTracker同時(shí)維護(hù)著所有Datanode的Meta數(shù)據(jù)。因此當(dāng)Master結(jié)點(diǎn)出現(xiàn)問題，整個(gè)集群將處于一種不可用的狀態(tài)。這種問題被稱為Master結(jié)點(diǎn)的單點(diǎn)問題，也稱高可用問題即High Availability。Hadoop 2.0 對該現(xiàn)象有所改善。首先引入YARN后Master的計(jì)算壓力會降低很多，同時(shí)HDFS Federation可以分擔(dān)Namenode上保存所有Datanode的Meta數(shù)據(jù)所造成的主節(jié)點(diǎn)壓力。但是每個(gè)Federation中的Namenode還是存在單點(diǎn)問題。

本文引入一種備份集群的概念，將所有的備份服務(wù)器集中管理以獲得更高的資源利用率。命名空間NS中存在兩種角色：活動結(jié)點(diǎn)AN和備份結(jié)點(diǎn)SNN。整個(gè)Namenode Federation 使用同一個(gè)備份集群進(jìn)行熱備份，運(yùn)用Zookeeper[16]作為一致性協(xié)調(diào)處理和自動故障恢復(fù)工具。結(jié)構(gòu)如圖5所示。本文將備份結(jié)點(diǎn)設(shè)計(jì)為虛擬服務(wù)以增加靈活性，即備份服務(wù)可以運(yùn)行在單獨(dú)服務(wù)器上，也可以和其他Namenode甚至Datanode共用一臺服務(wù)器。

圖5　備份集群架構(gòu)

Namenode中需要備份的數(shù)據(jù)包括文件系統(tǒng)元數(shù)據(jù)和數(shù)據(jù)塊分布信息。其中文件系統(tǒng)元數(shù)據(jù)是Namenode內(nèi)存中維護(hù)其命名空間的數(shù)據(jù)結(jié)構(gòu)，但是為了保證數(shù)據(jù)的可持久性，Namenode將這些數(shù)據(jù)以FSImage文件的形式序列化到硬盤或其他可持久化的存儲介質(zhì)上。為防止文件系統(tǒng)元數(shù)據(jù)的每次修改都直接改寫FSImage文件，HDFS引入了EditLog日志文件，將每次修改都記錄到日志文件中，等到一定時(shí)機(jī)再將EditLog和FSImage文件進(jìn)行合并。塊分布信息是由每次Datanode的心跳數(shù)據(jù)實(shí)時(shí)維護(hù)的數(shù)據(jù)結(jié)構(gòu)，主要是為了對Datanode中數(shù)據(jù)塊信息的實(shí)時(shí)監(jiān)控和查詢。因此需要對這三種數(shù)據(jù)進(jìn)行熱備份，過程如下：

1) 初始化。集群啟動時(shí)先進(jìn)行一次FSImage文件同步操作。如果Namenode尚未格式化，則在先進(jìn)行格式化再同步。設(shè)定Namenode寫EditLog的目錄為備份集群路徑。

2) EditLog寫入所有備份結(jié)點(diǎn)。利用Zookeeper服務(wù)處理EditLog一致性寫入問題，即只有集群中所有備份服務(wù)全部寫入成功，該操作才生效，否則返回錯(cuò)誤并回滾。

3) FSImage與EditLog合并。該任務(wù)由備份集群處理。合并操作被觸發(fā)后，備份集群先選擇一個(gè)備份結(jié)點(diǎn)開始合并任務(wù)，該服務(wù)器通知相應(yīng)Namenode建立檢查點(diǎn)，然后該結(jié)點(diǎn)開始進(jìn)行合并任務(wù)。合并完成后，將新的FSImage文件同步到相應(yīng)的Namenode和其他備份結(jié)點(diǎn)中，并通知它們進(jìn)行FSImage文件替換和已合并EditLog文件刪除的操作。

4) 心跳數(shù)據(jù)管理。為了保持所有數(shù)據(jù)塊分布信息實(shí)時(shí)同步，以便故障恢復(fù)時(shí)及時(shí)使用，所有的Datanode的心跳數(shù)據(jù)報(bào)不僅要向所有Namenode匯報(bào)還要向備份集群匯報(bào)。匯報(bào)數(shù)據(jù)由Zookeeper服務(wù)統(tǒng)一的一致性的記錄到備份集群中。

解決單點(diǎn)故障的第二個(gè)階段是故障恢復(fù)。當(dāng)Namenode出現(xiàn)故障的時(shí)候，Zookeeper便會監(jiān)測到它的心跳數(shù)據(jù)的異常，在超時(shí)策略下判定其是否出現(xiàn)故障，如果出現(xiàn)故障則開始故障恢復(fù)過程：

1) 首先，Zookeeper直接將故障信息發(fā)布到該命名空間的其他Namenode。同時(shí)，在Datanode進(jìn)行心跳包的返回?cái)?shù)據(jù)中通知所有的數(shù)據(jù)節(jié)點(diǎn)當(dāng)前的故障信息，以便其將相應(yīng)的塊池設(shè)定為故障恢復(fù)狀態(tài)。

2) 然后，通過Zookeeper的選舉算法，在當(dāng)前備份集群中可用的服務(wù)器中選舉出一臺代替故障服務(wù)器的主機(jī)。通知該主機(jī)將FSImage及數(shù)據(jù)塊分布信息加載到內(nèi)存中，設(shè)置為等待狀態(tài)。

3) 最后，通過Zookeeper通知集群中所有Namenode代替主機(jī)的產(chǎn)生，以調(diào)整新的集群拓?fù)浣Y(jié)構(gòu)。同時(shí)在Datanode的心跳回復(fù)信息中通知它們將對應(yīng)故障恢復(fù)狀態(tài)的塊池綁定到新的Namenode。相關(guān)Datanode嘗試聯(lián)系新的Namenode，如果連接成功則將狀態(tài)轉(zhuǎn)換為正常狀態(tài)。否則，通知Zookeeper集群新主機(jī)失敗，Zookeeper會將這臺主機(jī)標(biāo)注為失敗，再次啟動故障恢復(fù)流程。

需要注意的是，當(dāng)一個(gè)Namenode被備份集群判定為出現(xiàn)故障之后，它可能處于沒有完全停止或只是無法與其他Namenode聯(lián)系等狀態(tài)而繼續(xù)提供服務(wù)，此時(shí)會出現(xiàn)兩個(gè)Namenode管理同一個(gè)命名空間，這種可能引起混亂現(xiàn)象被稱為“腦裂”現(xiàn)象。為解決該問題，當(dāng)備份集群在判定Namenode失敗之后會在內(nèi)部標(biāo)識其狀態(tài)為宕機(jī)狀態(tài)，拒絕處于宕機(jī)狀態(tài)的結(jié)點(diǎn)對日志的操作，從而防止命名空間錯(cuò)誤改動。同時(shí)在判定Namenode失敗后嘗試向其發(fā)送停機(jī)命令，以防止錯(cuò)誤讀取。

為實(shí)現(xiàn)命名結(jié)點(diǎn)動態(tài)拓展，在備份集群中引入動態(tài)添加Namenode的功能。新加入的Namenode向當(dāng)前集群發(fā)送初始化請求，備份集群收到請求后通知所有Namenode新節(jié)點(diǎn)的加入，然后初始化該結(jié)點(diǎn)并使之共同擔(dān)負(fù)備份集群的任務(wù)。這樣新的命名結(jié)點(diǎn)或者先前出現(xiàn)故障的Namenode都可以很輕松地加入到集群當(dāng)中，實(shí)現(xiàn)命名結(jié)點(diǎn)的動態(tài)拓展。

3　系統(tǒng)實(shí)現(xiàn)及驗(yàn)證

為測試以上兩個(gè)方面改進(jìn)后對HDFS的海量創(chuàng)新知識存取效率和服務(wù)可用性的提升，將其作為基礎(chǔ)存儲服務(wù)應(yīng)用到創(chuàng)新知識云平臺的設(shè)計(jì)中，結(jié)構(gòu)如圖6所示。

圖6　系統(tǒng)整體架構(gòu)

3.1系統(tǒng)配置

系統(tǒng)中包含一臺Web服務(wù)器用于向用戶提供基于創(chuàng)新知識服務(wù)；一臺關(guān)系數(shù)據(jù)庫服務(wù)器用于提供簡單的關(guān)系數(shù)據(jù)存儲服務(wù)；三臺Namenode節(jié)點(diǎn)組建的備份集群，其中兩臺提供命名服務(wù)，一臺僅提供備份服務(wù)；四臺Datanode節(jié)點(diǎn)。服務(wù)器間以1000 Mbps交換機(jī)連接。其中各主機(jī)采用雙核2.1 GHz的CPU，以及3 GB的內(nèi)存。

3.2小文件存儲優(yōu)化

為了排除不相關(guān)因素的影響，先將測試結(jié)構(gòu)簡化，只使用一臺Namenode和四臺Datanode。用隨機(jī)產(chǎn)生的50 KB左右的大量小文件進(jìn)行實(shí)驗(yàn)。寫入文件前先記錄Namenode和各Datanode內(nèi)存占用量，然后將一定數(shù)量的小文件順序?qū)懭爰海謩e記錄寫入總時(shí)間、Namenode和各Datanode內(nèi)存占用量。接著連續(xù)讀取這些文件記錄總時(shí)間。多次試驗(yàn)最后，計(jì)算出Namenode內(nèi)存平均增加量，Datanode內(nèi)存平均增加量，平均寫入時(shí)間和平均讀取時(shí)間。具體的統(tǒng)計(jì)數(shù)據(jù)如圖7、圖8所示。

圖7　小文件存儲優(yōu)化內(nèi)存占用對比圖8　小文件存儲優(yōu)化時(shí)間消耗對比

當(dāng)采用包文件策略后，數(shù)據(jù)塊數(shù)量大大減少，估算值為(默認(rèn)數(shù)據(jù)塊體積/文件平均大小=64 MB/50 KB≈1310)，測試數(shù)據(jù)顯示為1200倍左右，與預(yù)期基本相符。Datanode的內(nèi)存下降應(yīng)該與Namenode相似，但是引入的小文件索引服務(wù)會占用部分內(nèi)存，所以整體內(nèi)存占用容量減少比例較低，約為20%。而存取時(shí)間因?yàn)槭艿絻?nèi)存占用、索引等多方面影響，所以效率有所提升，文件量小的時(shí)候提升不明顯，由于需要計(jì)算一次包內(nèi)定位，所以效率可能會有所降低，但是文件量大的情況下有較好的表現(xiàn)。

3.3高可用性

配置好三個(gè)Namenode組成的備份集群，其中兩臺提供命名服務(wù)和備份服務(wù)，另一臺只提供備份服務(wù)。選擇其中一臺命名服務(wù)器將其主進(jìn)程結(jié)束，并記錄時(shí)間。此時(shí)訪問該命名空間的資源出現(xiàn)不可用的狀態(tài)，而另一個(gè)命名空間的服務(wù)依然可以訪問。連續(xù)嘗試訪問失敗的命名空間，直至資源可以重新訪問，記錄時(shí)間。試驗(yàn)集群中文件數(shù)量不同的情況，數(shù)據(jù)統(tǒng)計(jì)如表1所示。

表1　備份集群實(shí)驗(yàn)數(shù)據(jù)

數(shù)據(jù)表明，該方案實(shí)現(xiàn)了集群的故障熱備份及自動恢復(fù)，同時(shí)故障恢復(fù)的時(shí)間與文件數(shù)量相關(guān)，主要原因在于文件恢復(fù)時(shí)需要將FSImage文件讀取到相應(yīng)命名結(jié)點(diǎn)的內(nèi)存結(jié)構(gòu)。但是由于小文件存儲中大大減少了命名空間數(shù)據(jù)量，因此恢復(fù)時(shí)間受到的影響較小在系統(tǒng)可接受的范圍。而且恢復(fù)期間其他命名空間訪問不受影響，可以提供部分命名服務(wù)。

4　結(jié)　語

隨著創(chuàng)新知識數(shù)量上不斷膨脹，應(yīng)用需求不斷增加的情況下，構(gòu)建海量數(shù)據(jù)的創(chuàng)新知識云平臺的重要性日益凸顯。本文提出了包文件結(jié)構(gòu)的概念使得命名節(jié)點(diǎn)的內(nèi)存占用大大減少進(jìn)而提升HDFS的存儲效率。在此基礎(chǔ)上引入的備份集群為集群帶來熱備份及自動恢復(fù)特性的同時(shí)提高了系統(tǒng)可用性。通過整體系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)可以看出，優(yōu)化工作基本滿足預(yù)期效果，可以為創(chuàng)新知識云平臺提供良好的分布式存儲服務(wù)。

[1] Ding Zhikun,Jiayuan Wang,et al.Innovation and Patent Knowledge Management in the Construction Industry[C]//Proceedings of the 17th International Symposium.on Advancement of Construction Manage-ment and Real Estate,Berlin,2014:833-842.

[2] Shvachko K,Kuang H,Radia S,et al.The hadoop distributed file system[C]//Proceeding of IEEE 26th Symposium.on Mass Storage Systems and Technologies (MSST),Lake Tahoe,2010:1-10.

[3] The Apache Software Foundation.HDFS architecture guide[EB/OL].[2011-05-04].http://hadoop.apache.org/ common/ docs/ current/ hdfs_design.pdf.

[4] 李彭軍,陳光杰,郭文明.基于HDFS的區(qū)域醫(yī)學(xué)影像分布式存儲架構(gòu)設(shè)計(jì)[J].南方醫(yī)科大學(xué)學(xué)報(bào),2011,31(3):495-498.

[5] 萬波,黨琦,楊林.基于HDFS管理MapGISK9瓦片地圖集的研究與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用與軟件,2013,30(12):232-235.

[6] 郭東,杜勇,胡亮.基于HDFS的云數(shù)據(jù)備份系統(tǒng)[J].吉林大學(xué)學(xué)報(bào):理學(xué)版,2012,50(1):101-105.

[7] 余琦,凌捷.基于HDFS的云存儲安全技術(shù)研究[J].計(jì)算機(jī)工程與設(shè)計(jì),2013,34(8):2700-2705.

[8] 曹寧,吳中海,劉宏志,等.HDFS下載效率的優(yōu)化[J].計(jì)算機(jī)應(yīng)用,2010,30(8):2060-2065.

[9] 廖彬,于炯,張?zhí)?等.基于分布式文件系統(tǒng) HDFS的節(jié)能算法[J].計(jì)算機(jī)學(xué)報(bào),2013,36(5):1047-1064.

[10] Chandrasekar S,Dakshinamurthy R,Seshakumar P G,et al.A novel indexing scheme for efficient handling of small files in Hadoop Distributed File System[C]//Computer Communication and Informatics (ICCCI),2013 International Conference on,2013:1-8.

[11] 余思,桂小林,黃汝維,等.一種提高云存儲中小文件存儲效率的方案[J].西安交通大學(xué)學(xué)報(bào),2011,45(6):59-63.

[12] 朱媛媛,王曉京.基于GE碼的HDFS優(yōu)化方案[J].計(jì)算機(jī)應(yīng)用,2013,33(3):730-733.

[13] 鄧鵬,李枚毅,何誠.Namenode單點(diǎn)故障解決方案研究[J].計(jì)算機(jī)工程,2012(21):40-44.

[14] Huang Z.DNN:A Distributed Namenode File System for Hadoop[D].University of Nebraska,2014.

[15] Patrick Hunt,Mahadev Konar,Flavio P.Junqueira,Benjamin Reed.ZooKeeper:Wait-free coordination for Internet-scale systems[EB/OL].[2010].http://www.usenix.org/events/usenix10/tech/full_papers/Hunt.pdf.

RESEARCH AND DESIGN OF HDFS-BASED STORAGE ARCHITECTURE FOR INNOVATIVE KNOWLEDGE CLOUD PLATFORM

Ma JianhongHuo Zhenqi

(SchoolofComputerScienceandEngineering,HebeiUniversityofTechnology,Tianjin300401,China)

Because current storage structure cannot meet the storage and service demands brought by massive innovative knowledge, we presented an improved HDFS distributed storage system and applied it to the innovative knowledge cloud platform. First, we introduced the package file and distributed indexing service, thus improved the efficiency of HDFS small files storage problem. Then by optimising the naming space backup and failure recovery services in HDFS we achieved high availability architecture of HDFS with stronger availability and higher resource utilisation. By designing and implementation of the system we proved that the optimisation work greatly reduced the memory pressure of naming node and enhanced the availability of cluster, and the improved HDFS storage system could meet the storage needs of innovative knowledge cloud platform.

Innovative knowledgeHadoop Distributed File System (HDFS)Small files storageSingle point of failure

2014-08-27。馬建紅，教授，主研領(lǐng)域：軟件工程，計(jì)算機(jī)輔助創(chuàng)新設(shè)計(jì)過程與方法。霍振奇，碩士生。

TP311

A

10.3969/j.issn.1000-386x.2016.03.013