基于Hadoop的云存儲系統(tǒng)文件處理與安全研究

摘 要： 由于公有云存儲中存在數(shù)據(jù)泄露、丟失、存儲不穩(wěn)定等不安全因素，私有云存儲成為解決當前企業(yè)安全存儲需求的最佳選擇。針對單點內(nèi)存負載過高，寫入效率低下的問題，設(shè)計了一套處理大量小文件的模塊，通過緩存多個小文件合并，再合并文件元數(shù)據(jù)放置索引表，通過索引表中的偏移量尋找塊中小文件數(shù)據(jù)的方式，提高HDFS寫入大量小文件的系統(tǒng)性能，經(jīng)過測試驗證了優(yōu)化方案的有效性。

關(guān)鍵詞： Hadoop； HDFS； 私有云存儲； 小文件優(yōu)化

中圖分類號： TN911?34； TM417 文獻標識碼： A 文章編號： 1004?373X（2016）21?0112?04

Research on file processing and security of cloud storage system based on Hadoop

LI Yingchao

（Beihua University Teacher′s College， Jilin 132013， China）

Abstract： Since the public cloud storage exisits the unsafe factors of data leakage， data lose and unstable storage， the private cloud storage becomes the best choice to meet the current safety storage demands of the enterprises. To solve the too high load of the single point memory and low writing efficiency， a module to deal with the massive small files was designed. Multiple small files are merged through the cache， and the index table is placed into the metadata of the emerged file. The method of finding small file data in the block by means of the offset in the index table can improve the HDFS performance of writing massive small files. The validity of the optimization scheme was verified with an experiment.

Keywords： Hadoop； HDFS； private cloud storage； small file optimization

0 引 言

在HDFS中，所有文件的寫入和讀取都需要通過NameNode控制，接收用戶對文件操作的請求，定位文件位置和分配文件存儲的DataNode節(jié)點，并且所有文件的信息都存儲在NameNode中的元數(shù)據(jù)里。在文件處理中，HDFS在NameNode中為每一個文件都建立了元數(shù)據(jù)，用來存儲該文件信息，這樣的做法對大文件是十分合理的[1]。但問題是當系統(tǒng)中存儲大量的小文件時，這樣的做法就在時間開銷和性能上有了嚴重的問題，在小文件的存儲過程中，向NameNode發(fā)出請求分配DataNode節(jié)點的時間消耗甚至超過了存儲過程本身的時間，NameNode中海量小文件的元數(shù)據(jù)會占用大量的內(nèi)存，影響系統(tǒng)性能[2]。

面對小文件存儲的瓶頸，設(shè)計小文件存儲的優(yōu)化過程，并且針對原生HDFS小文件存儲優(yōu)化的過程，在減少系統(tǒng)負載的同時保證小文件存儲的正確性和穩(wěn)定性是當前面臨的問題。

1 文件存儲優(yōu)化方案設(shè)計

HDFS作為時下流行的分布式存儲系統(tǒng)，自身不擅長處理小文件的寫入，在處理小文件上存在瓶頸，但是面對當前小文件數(shù)量急劇增長的現(xiàn)狀，應(yīng)該緊跟時代需求的腳步，在小文件處理方面進行相關(guān)優(yōu)化，從單一面向大型數(shù)據(jù)的儲存轉(zhuǎn)向更加符合時代的方向，更好地兼容大小文件的存儲。

1.1 合并及寫入

合并及寫入在合并的過程中，第一步是要保證小文件能夠在緩存中等待，一直合并到合并塊大小接近BlockSize時，再向HDFS發(fā)送寫入的請求。在用戶上傳小文件時，首先新建一個合并文件，返回到DFSClient中新設(shè)計的MergeStream流對象，其功能就是循環(huán)等待并讀取用戶上傳的小文件，直到緩存大小達到BlockSize的大小[3]。為對象分配Buffer空間，空間大小和BlockSize大小相同，同時RPC通信在NameNode中建立對應(yīng)的元數(shù)據(jù)結(jié)構(gòu)MergeNode，在MergeNode中保存filemap，其中包含了小文件名和其在本塊中的偏移量等信息。

1.2 小文件映射

NameSpace主要維護文件元數(shù)據(jù)，正是根據(jù)元數(shù)據(jù)記錄的文件存儲信息，用戶才能將在DataNode中分散存儲的文件塊找到并且組合成原本完整的文件。文件元數(shù)據(jù)包括文件的文件名、文件大小等基本的文件信息，還保存了文件被分割成多少塊，分別放在哪些Block中，分別在哪個DataNode上映射信息，而這些映射信息都是通過INode的對象維護的。

在小文件處理中，本系統(tǒng)設(shè)計了MergeNode繼承自INode對象，MergeNode維護了小文件名到BlockId、偏移表的映射FileMap，而FileMap是MergeINodeFile的一個屬性成員，MergeINodeFile繼承至INodeFile，主要添加了FileMap一個屬性成員，F(xiàn)ileMap管理了文件名到Block的映射關(guān)系，其中包括該小文件所在塊的BlockId以及MergeBlock中的偏移量Index索引，MergeBlock同樣是新建的結(jié)構(gòu)體，其中包括Blockinfo和Index兩個成員。在合并過程中NameNode會根據(jù)合并的大文件名找到對應(yīng)的MergeINodeFile結(jié)構(gòu)，然后將小文件名到BlockId和Index映射添加到FileMap結(jié)構(gòu)中，這就完成了對FileMap信息的更新。

1.3 讀取

客戶端提取小文件時，首先要向NameNode發(fā)出提取文件的請求，并且發(fā)送該文件的文件名和合并文件名等基本信息，NameNode接收請求和文件信息后，在命名空間搜索該文件的信息，根據(jù)合并文件名查找目錄樹，找到該合并文件的MergeINode節(jié)點，然后在FileMap上搜索該小文件，最后返回該小文件存儲的BlockId，DataNode信息和在該合并數(shù)據(jù)塊上的小文件偏移表index會與該DataNode建立連接，發(fā)送請求數(shù)據(jù)，數(shù)據(jù)中包含BlockId和塊中的偏移量。DataNode收到信息后首先根據(jù)BlockId在本地目錄上定位該數(shù)據(jù)塊，找到并打開該數(shù)據(jù)塊，得到小文件在索引表中的偏移量和文件長度，根據(jù)偏移信息，在數(shù)據(jù)塊中的讀指針定位到正確的偏移地址上，開始進行讀入操作，讀入的同時記錄讀取的數(shù)據(jù)總量，直到大小和文件大小相同則停止讀取[4]。最后將讀取的數(shù)據(jù)發(fā)送給客戶端，至此完成對小文件的提取。

2 云存儲系統(tǒng)分析與設(shè)計

2.1 系統(tǒng)架構(gòu)

本系統(tǒng)的設(shè)計主要是實現(xiàn)一個基于HDFS分布式文件系統(tǒng)為底層，配合MySQL數(shù)據(jù)庫，以JSP為開發(fā)語言的Web項目，主要功能是實現(xiàn)企業(yè)內(nèi)部的私有云存儲功能[5]。在功能方面建立兩大塊，其中一塊是用戶功能的模塊，另一塊就是該系統(tǒng)的核心，即文件功能模塊。在用戶模塊中，要包含普通用戶的注冊登錄退出，還要有管理員角色的功能，不但能夠管理用戶的基本信息，設(shè)置權(quán)限，刪除用戶等，還能有更進一步的功能，就是在公共文件區(qū)中添加公共文件。而在文件功能模塊中，要包含普通上傳，加密上傳，分段上傳，下載，解秘下載，用戶點對點分享，熱點文件功能，簡單文件預(yù)覽，公共文件功能等。系統(tǒng)功能模塊如圖1所示。

系統(tǒng)的架構(gòu)需要四個方面的設(shè)備共同完成整個系統(tǒng)，需要有用戶端，服務(wù)器端處理客戶端請求，需要數(shù)據(jù)庫存儲用戶信息和少量的文件信息，最后是HDFS的集群設(shè)備，負責對文件進行分布式存儲。

2.2 用戶端設(shè)計

用戶端主要包括系統(tǒng)的登錄注冊功能模塊，負責控制普通用戶和管理員用戶的用戶角色模塊。登錄注冊是用戶角色檢測的前置條件，在登錄注冊的前提下進行用戶角色檢測，連接數(shù)據(jù)庫中的用戶表對比和提取用戶數(shù)據(jù)，在對比成功的前提下，根據(jù)用戶信息判斷是否為普通用戶或者管理員，從而加載不同的用戶界面[6]。在角色登入的狀態(tài)上，用戶提交輸入信息進行比對進入登錄狀態(tài)，系統(tǒng)向數(shù)據(jù)庫發(fā)送數(shù)據(jù)請求，然后進行比對驗證，若驗證成功則進入界面處理狀態(tài)，根據(jù)不同角色最后呈現(xiàn)給用戶相應(yīng)的界面，如圖2所示。

2.3 文件基本功能設(shè)計

文件的基本功能包括文件上傳、文件下載和文件的列表展示三個方面。用戶使用存儲系統(tǒng)，最常用的就是這三個基本的文件功能。在本系統(tǒng)中，由于上傳下載包括了多種擴展功能，在擴展功能中有加密上傳、解密下載、公共文件下載、熱點文件下載，但是基本的上傳下載流程是固定不變的，在不同功能中，對文件的處理是在專門的文件處理類中進行操作，而操作的結(jié)果依然是根據(jù)文件的基本流程進行。

文件上傳的核心流程主要為：系統(tǒng)接收到文件上傳的請求后，提交給上傳控制的不同類中，不同的類對文件進行操作后，開始和HDFS相連，寫入文件，寫完后更新數(shù)據(jù)庫，最后刷新用戶文件列表。

文件下載的基本流程是：下載處理類接收到用戶對某個文件的具體功能下載請求，該類首先與數(shù)據(jù)庫連接獲取該文件的路徑信息，然后進入HDFS中，根據(jù)文件路徑找到該文件并且轉(zhuǎn)移文件數(shù)據(jù)到服務(wù)器上，下載處理類對轉(zhuǎn)移到服務(wù)器中的文件進行相應(yīng)處理，同時更新數(shù)據(jù)庫，最后遞交給用戶[8]。用戶先在Web端操作選擇目標文件，并且點擊相應(yīng)的下載操作，接著服務(wù)器將請求交給下載處理類，下載處理類接收請求并連接數(shù)據(jù)庫取得文件信息，連接HDFS進行文件讀取，然后將轉(zhuǎn)移到服務(wù)器上的文件交給處理類進行文件處理，最后將處理好的文件流式返回給用戶。

3 系統(tǒng)實現(xiàn)過程

3.1 用戶模塊

在用戶模塊中，主要涉及到的是數(shù)據(jù)庫的操作和jsp前臺與后臺servlet的數(shù)據(jù)處理過程，對HDFS的操作涉及比較少。而針對用戶模塊操作主要是在后臺的UserBean和UserBeanCl文件中，UserBean定義了新用戶的建立方法，獲取用戶名等信息的各種方法。在新用戶建立主要和數(shù)據(jù)庫進行數(shù)據(jù)更新的過程，首先獲取到servlet傳輸來的控件內(nèi)容，然后連接數(shù)據(jù)庫，更新user表，新建兩張表分別是該用戶的文件表和分享表。

3.2 管理員模塊

管理員身份的檢測是在JSP前段Body中的onload事件觸發(fā)admincheck腳本方法。

onload=\"admincheck（）\"

通過jsp特性，將后臺的變量引用到前臺中。變量<%=username%>就是當前系統(tǒng)session獲取的用戶名的字符串，通過匹配管理員的用戶名，判斷是否是管理員身份，進而激活管理員頁面。該腳本函數(shù)的作用就是控制前段的管理員界面的顯示與否，當檢測到是管理員身份時，就屏蔽普通用戶的操作界面，激活管理員操作。在管理員的操作中主要設(shè)置用戶權(quán)限值和刪除用戶兩個方面。這兩個功能的實現(xiàn)是在AdminServlet類中。在jsp傳參的過程中加入了check變量，前臺是deleteuser（a）的javascript函數(shù)控制傳參，確保選擇的用戶是正確的。

3.3 文件上傳和下載

系統(tǒng)中引入了加密上傳的方式，在上傳過程中要在servlet傳輸中讓其識別出是普通上傳還是加密上傳，這里在Web中設(shè)計了checkstringchange（）的javascript方法，該方法主要是在加密選項中觸發(fā)，一旦被觸發(fā)，則需要更改form中的action內(nèi)容，將不同的參數(shù)傳遞給UploadServlet，而在Servlet中是通過checkstring的值來判斷是否為加密方式，<%checkstring=\"jiami\"；%>是jsp的使用方式，更改checkstring的標識變量，并且更新jiamikey的內(nèi)容，傳遞加密指令。

文件下載是從HDFS定位到該文件，然后傳輸至服務(wù)器，然后服務(wù)器轉(zhuǎn)交給用戶的過程。由于系統(tǒng)采用MySQL記錄用戶文件的上傳信息，其中包括每一個文件所處的文件位置，所以，對每一個文件的定位工作需要訪問數(shù)據(jù)庫得到文件的路徑信息。文件下載中出現(xiàn)的難點在于，由于下載方式不同，有公共文件，也有加密文件，還有普通文件，首先要保證文件按照其自身下載方式下載，如加密文件就要通過加密通道，進行解密過程然后再傳遞給用戶，所以這里就需要在下載過程中傳遞多種標識量進行邏輯判斷，這就需要在向servlet傳參時設(shè)置不同的識別標記。本系統(tǒng)中，結(jié)合前臺javascript函數(shù)，用jiemikey和publiccheck兩個Parameter共同控制，使得DownloadServlet能夠區(qū)分三種不同的下載方式。

3.4 文件展示

文件展示其實就是將用戶存儲的文件信息展示出來，并非真正的文件展示，所以在獲取用戶存儲在HDFS上的文件信息，就是文件展示的核心。而上文提到由于在系統(tǒng)中加入了數(shù)據(jù)庫，用戶的文件信息同樣會被寫入數(shù)據(jù)庫中，所以數(shù)據(jù)庫同樣作為提供文件信息的來源。在本系統(tǒng)中，不同頁面中采取了兩種不同的展示方式：一種是直接通過連接HDFS獲取最新的文件狀態(tài)；而第二種就是不經(jīng)過HDFS，通過讀取數(shù)據(jù)庫的文件信息提供給用戶。在用戶的首頁部分，因為展示的是用戶自身所有的文件信息，所以本頁面對數(shù)據(jù)的準確性要求較高，并且由于用戶可以對首頁的每一個文件進行操作，一旦列表中的文件和HDFS中的文件有出入，則很容易造成用戶操作失敗，影響用戶的使用。所以在首頁采用的是及時更新的方式，即每當用戶連接首頁時，就連接HDFS獲取最新的文件狀態(tài)，返回給用戶。

4 性能測試和分析

在針對系統(tǒng)的內(nèi)存監(jiān)測和文件提取中，使用隨機生成的100個，500個，1 000個，2 000個小文件進行測試對比。分別進行5次實驗，取五次實驗中的平均時間進行展示。在NameNode元數(shù)據(jù)占用內(nèi)存方面，從測試結(jié)果中可以看出，在原生的HDFS中，隨著上傳文件數(shù)目的增長，NameNode對無論大文件還是小文件采取一樣的元數(shù)據(jù)保存方式，要為每一個小文件都分配一個和大文件相同的INODE數(shù)據(jù)類型存儲其元數(shù)據(jù)，隨著小文件的不斷增多，小文件元數(shù)據(jù)在系統(tǒng)中占用的空間越來越多。內(nèi)存消耗量的對比見圖3。

而在修改后的HDFS中，由于采用了小文件合并的方式，所以NameNode中只需要保存合并的大文件塊元數(shù)據(jù)，并且在其元數(shù)據(jù)中增添空間占用十分小的索引信息，相比之下，規(guī)模小了很多，所以隨著文件數(shù)目的增加，眾多小文件在NameNode中消耗的內(nèi)存增長緩慢，內(nèi)存占用平均節(jié)省至少30%，這樣的對比可以看出，通過合并的方式能夠在集群存儲大量小文件時，減少NameNode的內(nèi)存開銷，達到緩解HDFS小文件存儲帶來的內(nèi)存開銷問題。內(nèi)存消耗的對比折線圖見圖4。

針對文件讀寫過程中的時間開銷，則使用data命令，每次上傳文件前和上傳完畢后，獲取時間差值。由于設(shè)備硬件水平限制，使用Linux文件生成指令自動生成的100個，200個，300個，400個大小在10 MB以內(nèi)的小文件，而具體的操作方法則是使用Hadoop中copyFromLocal方法，將小文件循環(huán)上傳到HDFS中，并且在上傳前后設(shè)置data的觸發(fā)函數(shù)，記錄時間，計算出時間差。小文件寫入消耗的時間見圖5。

從圖5中可以看出，隨著[x]軸上的小文件數(shù)量從100，200，300到400不斷遞增，無論是原生HDFS還是修改后的HDFS都出現(xiàn)了非線性的快速增長。但相對而言，修改后的HDFS在小文件的上傳中花費的時間更少，文件的平均上傳時間縮短了20%，能夠證明寫入小文件時，優(yōu)化后的HDFS能夠更快速地對小文件進行處理。

5 結(jié) 論

本文針對HDFS處理大量小文件寫入時面臨的NameNode內(nèi)存負載和時間開銷大的問題，設(shè)計了一套優(yōu)化的小文件處理模塊。對多個寫入的小文件進行文件合并，形成大的合并文件塊，在合并文件的元數(shù)據(jù)中加入小文件索引表，該索引表記錄了每個小文件的基本文件信息和文件在合并塊中的偏移量，讀取小文件時通過索引表定位小文件塊中的地址，一個合并文件塊將多個小文件的數(shù)據(jù)存儲在DataNode中，而NameNode中只保存合并文件的元數(shù)據(jù)。同時，基于當前中小企業(yè)的數(shù)據(jù)存儲需求，設(shè)計并且實現(xiàn)了一套針對中小型企業(yè)的私有云存儲系統(tǒng)，不但保證了文件存儲的安全性和穩(wěn)定性，而且實現(xiàn)了很多實用的文件功能，方便企業(yè)用戶的數(shù)據(jù)處理。

參考文獻

[1] 洪旭升，林世平.基于MapFile的HDFS小文件存儲效率問題[J].計算機系統(tǒng)應(yīng)用，2012（11）：179?182.

[2] 郝樹魁.Hadoop HDFS和MapReduce架構(gòu)淺析[J].郵電設(shè)計技術(shù)，2012（7）：37?42.

[3] BORTHAKUR D. The Hadoop distributed file system： architecture and design [J]. Hadoop project website， 2007， 11： 1?10.

[4] 張峰，李基亮.校園私有云存儲方案的探索[J].華東師范大學學報（自然科學版），2015（z1）：139?145.

[5] MOHANDAS N， THAMPI S M. Improving Hadoop performance in handling small files [C]// Proceedings of 2011 International Conference on Advances in Computing and Communications. Kochi： Springer Berlin Heidelberg， 2011： 187?194.

[6] 鄧鵬，李枚毅，何誠.NameNode單點故障解決方案研究[J].計算機工程，2012，38（21）：40?44.

[7] 李菊.基于私有云安全平臺的網(wǎng)絡(luò)安全部署研究與實施[J].信息網(wǎng)絡(luò)安全，2013（8）：48?51.

[8] SHVACHKO K， KUANG H， RADIA S， et al. The Hadoop distributed file system [C]// Proceedings of 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies. [S.l.]： IEEE， 2010： 1?10.