馬建紅　霍振奇

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

?

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

馬建紅霍振奇

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

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

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

0　引　言

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

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

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

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

1　相關(guān)工作

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

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

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

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

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

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

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

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

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

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

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

圖3　小文件寫入流程

需要注意以下三點：

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

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

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

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

example1.jpg

example2.jpg

……

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

下面介紹小文件讀取過程，如圖4所示。改進后的文件讀取操作與原有的文件讀取操作相比，在服務(wù)器數(shù)據(jù)交互數(shù)量上是相同的，區(qū)別是改進的過程同時讀取多個數(shù)據(jù)結(jié)點以真正取得所需文件?？蛻舳瞬⑿械南蛩心康膲K所在的Datanode發(fā)送讀請求。只有包含該文件的Datanode返回文件數(shù)據(jù)，其他的返回查找失敗，客戶端選擇最先返回的文件數(shù)據(jù)接收，并終止其他線程。

圖4　小文件讀取流程

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

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

2.2Namenode單點問題改進

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為測試以上兩個方面改進后對HDFS的海量創(chuàng)新知識存取效率和服務(wù)可用性的提升，將其作為基礎(chǔ)存儲服務(wù)應(yīng)用到創(chuàng)新知識云平臺的設(shè)計中，結(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é)點組建的備份集群，其中兩臺提供命名服務(wù)，一臺僅提供備份服務(wù)；四臺Datanode節(jié)點。服務(wù)器間以1000 Mbps交換機連接。其中各主機采用雙核2.1 GHz的CPU，以及3 GB的內(nèi)存。

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

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

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

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

3.3高可用性

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

表1　備份集群實驗數(shù)據(jù)

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

4　結(jié)　語

隨著創(chuàng)新知識數(shù)量上不斷膨脹，應(yīng)用需求不斷增加的情況下，構(gòu)建海量數(shù)據(jù)的創(chuàng)新知識云平臺的重要性日益凸顯。本文提出了包文件結(jié)構(gòu)的概念使得命名節(jié)點的內(nèi)存占用大大減少進而提升HDFS的存儲效率。在此基礎(chǔ)上引入的備份集群為集群帶來熱備份及自動恢復(fù)特性的同時提高了系統(tǒng)可用性。通過整體系統(tǒng)的設(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].南方醫(yī)科大學(xué)學(xué)報,2011,31(3):495-498.

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

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

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

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

[9] 廖彬,于炯,張?zhí)?等.基于分布式文件系統(tǒng) HDFS的節(jié)能算法[J].計算機學(xué)報,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é)報,2011,45(6):59-63.

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

[13] 鄧鵬,李枚毅,何誠.Namenode單點故障解決方案研究[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)域：軟件工程，計算機輔助創(chuàng)新設(shè)計過程與方法?；粽衿?，碩士生。

TP311

A

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