基于HDFS的創新知識云平臺存儲架構的研究與設計

馬建紅　霍振奇

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

?

基于HDFS的創新知識云平臺存儲架構的研究與設計

馬建紅霍振奇

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

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

創新知識HDFS小文件存儲單點故障

0　引　言

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

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

圖1　創新知識云平臺架構

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

1　相關工作

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

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

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

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

2　系統優化方法及實現

2.1小文件存儲優化

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

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

圖2　小文件存儲服務架構

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

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

圖3　小文件寫入流程

需要注意以下三點：

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

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

3) 數據結點附加操作完成后，需要調用小文件附加服務更新相應的索引文件。

索引文件主要記錄對應塊文件中小文件的路徑及文件結束位置，其結構示意如下：

example1.jpg

example2.jpg

……

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

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

圖4　小文件讀取流程

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

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

2.2Namenode單點問題改進

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

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

圖5　備份集群架構

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

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

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

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

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

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

1) 首先，Zookeeper直接將故障信息發布到該命名空間的其他Namenode。同時，在Datanode進行心跳包的返回數據中通知所有的數據節點當前的故障信息，以便其將相應的塊池設定為故障恢復狀態。

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

3) 最后，通過Zookeeper通知集群中所有Namenode代替主機的產生，以調整新的集群拓撲結構。同時在Datanode的心跳回復信息中通知它們將對應故障恢復狀態的塊池綁定到新的Namenode。相關Datanode嘗試聯系新的Namenode，如果連接成功則將狀態轉換為正常狀態。否則，通知Zookeeper集群新主機失敗，Zookeeper會將這臺主機標注為失敗，再次啟動故障恢復流程。

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

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

3　系統實現及驗證

為測試以上兩個方面改進后對HDFS的海量創新知識存取效率和服務可用性的提升，將其作為基礎存儲服務應用到創新知識云平臺的設計中，結構如圖6所示。

圖6　系統整體架構

3.1系統配置

系統中包含一臺Web服務器用于向用戶提供基于創新知識服務；一臺關系數據庫服務器用于提供簡單的關系數據存儲服務；三臺Namenode節點組建的備份集群，其中兩臺提供命名服務，一臺僅提供備份服務；四臺Datanode節點。服務器間以1000 Mbps交換機連接。其中各主機采用雙核2.1 GHz的CPU，以及3 GB的內存。

3.2小文件存儲優化

為了排除不相關因素的影響，先將測試結構簡化，只使用一臺Namenode和四臺Datanode。用隨機產生的50 KB左右的大量小文件進行實驗。寫入文件前先記錄Namenode和各Datanode內存占用量，然后將一定數量的小文件順序寫入集群，分別記錄寫入總時間、Namenode和各Datanode內存占用量。接著連續讀取這些文件記錄總時間。多次試驗最后，計算出Namenode內存平均增加量，Datanode內存平均增加量，平均寫入時間和平均讀取時間。具體的統計數據如圖7、圖8所示。

圖7　小文件存儲優化內存占用對比圖8　小文件存儲優化時間消耗對比

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

3.3高可用性

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

表1　備份集群實驗數據

數據表明，該方案實現了集群的故障熱備份及自動恢復，同時故障恢復的時間與文件數量相關，主要原因在于文件恢復時需要將FSImage文件讀取到相應命名結點的內存結構。但是由于小文件存儲中大大減少了命名空間數據量，因此恢復時間受到的影響較小在系統可接受的范圍。而且恢復期間其他命名空間訪問不受影響，可以提供部分命名服務。

4　結　語

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

[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的區域醫學影像分布式存儲架構設計[J].南方醫科大學學報,2011,31(3):495-498.

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

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

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

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

[9] 廖彬,于炯,張陶,等.基于分布式文件系統 HDFS的節能算法[J].計算機學報,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].西安交通大學學報,2011,45(6):59-63.

[12] 朱媛媛,王曉京.基于GE碼的HDFS優化方案[J].計算機應用,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。馬建紅，教授，主研領域：軟件工程，計算機輔助創新設計過程與方法?；粽衿妫T士生。

TP311

A

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