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

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

中圖分類號(hào)： TN911?34； TM417 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 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控制，接收用戶對(duì)文件操作的請(qǐng)求，定位文件位置和分配文件存儲(chǔ)的DataNode節(jié)點(diǎn)，并且所有文件的信息都存儲(chǔ)在NameNode中的元數(shù)據(jù)里。在文件處理中，HDFS在NameNode中為每一個(gè)文件都建立了元數(shù)據(jù)，用來存儲(chǔ)該文件信息，這樣的做法對(duì)大文件是十分合理的[1]。但問題是當(dāng)系統(tǒng)中存儲(chǔ)大量的小文件時(shí)，這樣的做法就在時(shí)間開銷和性能上有了嚴(yán)重的問題，在小文件的存儲(chǔ)過程中，向NameNode發(fā)出請(qǐng)求分配DataNode節(jié)點(diǎn)的時(shí)間消耗甚至超過了存儲(chǔ)過程本身的時(shí)間，NameNode中海量小文件的元數(shù)據(jù)會(huì)占用大量的內(nèi)存，影響系統(tǒng)性能[2]。

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

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

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

1.1 合并及寫入

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

1.2 小文件映射

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

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

1.3 讀取

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

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

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

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

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

2.2 用戶端設(shè)計(jì)

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

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

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

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

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

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

3.1 用戶模塊

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

3.2 管理員模塊

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

onload=\"admincheck（）\"

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

3.3 文件上傳和下載

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

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

3.4 文件展示

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

4 性能測(cè)試和分析

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

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

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

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

5 結(jié) 論

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

參考文獻(xiàn)

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

[2] 郝樹魁.Hadoop HDFS和MapReduce架構(gòu)淺析[J].郵電設(shè)計(jì)技術(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] 張峰，李基亮.校園私有云存儲(chǔ)方案的探索[J].華東師范大學(xué)學(xué)報(bào)（自然科學(xué)版），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單點(diǎn)故障解決方案研究[J].計(jì)算機(jī)工程，2012，38（21）：40?44.

[7] 李菊.基于私有云安全平臺(tái)的網(wǎng)絡(luò)安全部署研究與實(shí)施[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.