網(wǎng)絡(luò)安全設(shè)備聯(lián)動系統(tǒng)中小文件存儲優(yōu)化方法研究

程曉榮　李玉進(jìn)　李紫君　劉雨晨

摘要：網(wǎng)絡(luò)系統(tǒng)在運行過程中會產(chǎn)生大量日志，采用Java編程技術(shù)將各安全設(shè)備日志轉(zhuǎn)換為XML文件。在對日志文件存儲過程中，現(xiàn)有的存儲系統(tǒng)硬件成本高，擴(kuò)展能力差，數(shù)據(jù)并行訪問效率低，難以滿足網(wǎng)絡(luò)安全設(shè)備聯(lián)動系統(tǒng)的需求。因此，該文采用基于HDFS的云存儲系統(tǒng)對日志文件進(jìn)行存儲。為了提高基于HDFS的云存儲系統(tǒng)中小文件存儲效率，該文設(shè)計了云存儲系統(tǒng)中小文件存儲的優(yōu)化方案，主要在小文件合并和小文件檢索方面做了優(yōu)化。該方案結(jié)合網(wǎng)絡(luò)安全設(shè)備聯(lián)動系統(tǒng)中日志文件的特點，首先是根據(jù)不同設(shè)備的文件進(jìn)行分類，然后根據(jù)小文件在合并后的大文件中的偏移量進(jìn)行檢索。最后采用3組文件集合對優(yōu)化方案進(jìn)行了測試，實驗結(jié)果表明，在不影響存儲系統(tǒng)運行狀況的基礎(chǔ)上，該方案提高了小文件的存儲效率和讀取效率。

關(guān)鍵詞：網(wǎng)絡(luò)安全；小文件；Hadoop；存儲優(yōu)化

中圖分類號：TP393 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2015）35-0010-02

1 引言

網(wǎng)絡(luò)系統(tǒng)在運行過程中會產(chǎn)生大量的系統(tǒng)日志、應(yīng)用日志、安全日志和網(wǎng)絡(luò)日志，這些日志包含著關(guān)于網(wǎng)絡(luò)運行、安全及狀態(tài)的數(shù)據(jù)。隨著采集日志的大規(guī)模增長，現(xiàn)有的存儲系統(tǒng)硬件成本高，擴(kuò)展能力差，數(shù)據(jù)并行訪問效率低，難以滿足網(wǎng)絡(luò)安全設(shè)備聯(lián)動系統(tǒng)的需求。因此，提供一種更高性能、更低成本、更好可靠性的易于管理的存儲平臺，才能夠幫助該系統(tǒng)用盡可能低的成本應(yīng)對日益增長的數(shù)據(jù)存儲需求。

HDFS采用主從式架構(gòu)設(shè)計模式（master/slave），一個名稱節(jié)點（NameNode）和若干數(shù)據(jù)節(jié)點（DataNode）構(gòu)成HDFS集群[1]。HDFS的這種單名稱節(jié)點的設(shè)計極大地簡化了文件系統(tǒng)的結(jié)構(gòu)，然而也因此引發(fā)了HDFS的小文件存儲效率低的問題。HDFS設(shè)計之初的目的是存儲大量的大文件，所以需要采用分塊策略先將每個文件分塊，保存機(jī)制是每個文件都占用一個或多個塊。因為HDFS中的每個目錄和文件的元數(shù)據(jù)信息都存放在名稱節(jié)點的內(nèi)存中，如果系統(tǒng)中存在大量的小文件（指那些比HDFS數(shù)據(jù)塊（默認(rèn)為64MB）小得多的文件），則無疑會降低整個存儲系統(tǒng)的存儲效率和存儲能力。然而，在網(wǎng)路安全設(shè)備聯(lián)動系統(tǒng)[2]存在著大量的小文件。大量的小文件存在于云存儲系統(tǒng)中無疑會降低整個系統(tǒng)的I/O性能。針對這一問題，本文提出云存儲中小文件的合并處理方法，以提高小文件的存儲效率，提高整個系統(tǒng)的I/O性能。

2 整體方案優(yōu)化設(shè)計

文件的優(yōu)化方案主要包括4個部分：數(shù)據(jù)預(yù)存儲節(jié)點的功能設(shè)計，小文件合并方案，小文件索引結(jié)構(gòu)的設(shè)計以及小文件合并過程的整體設(shè)計。

2.1數(shù)據(jù)預(yù)存儲節(jié)點功能設(shè)計

數(shù)據(jù)預(yù)存儲節(jié)點是在HDFS架構(gòu)的基礎(chǔ)上新增的節(jié)點，它位于客戶端與名稱節(jié)點和數(shù)據(jù)節(jié)點之間，主要實現(xiàn)對存儲的文件進(jìn)行預(yù)處理，根據(jù)文件大小，判斷是否屬于小文件，對于小文件主要完成存儲前的合并，生成索引以及小文件檢索時的文件分離等功能。增加數(shù)據(jù)預(yù)存儲節(jié)點之后，在數(shù)據(jù)存儲的過程中，數(shù)據(jù)的流向由從客戶端直接到數(shù)據(jù)節(jié)點變成了由客戶端先到預(yù)存儲節(jié)點再到數(shù)據(jù)節(jié)點。

2.2小文件合并算法設(shè)計

當(dāng)客戶端寫入小文件時，首先根據(jù)小文件的類型對數(shù)據(jù)預(yù)存儲節(jié)點進(jìn)行分組。然后分別將每個分組中的小文件合并成大文件，此時，生成相關(guān)小文件索引信息及元數(shù)據(jù)信息。最后將合并后的文件和相關(guān)的元數(shù)據(jù)，按照原HDFS寫入文件的方式一同上傳至HDFS中，其中第二類元數(shù)據(jù)信息由數(shù)據(jù)預(yù)存儲節(jié)點進(jìn)行存儲，第一類元數(shù)據(jù)信息由名稱節(jié)點進(jìn)行存儲，數(shù)據(jù)節(jié)點存儲合并成的大文件[3]

當(dāng)客戶端需要讀取某個小文件時，從名稱節(jié)點獲取小文件所在大文件的元數(shù)據(jù)信息，然后從數(shù)據(jù)預(yù)存儲節(jié)點獲取第二類元數(shù)據(jù)信息，從數(shù)據(jù)節(jié)點獲取小文件所在的大文件，并在接口中將大文件解檔為若干小文件，并將這些小文件緩存在客戶端。

為了便于算法描述，對算法里的符號進(jìn)行定義：File[type][MD5][key]——緩沖區(qū)中待合并的文件；type——日志文件的類型（1：主機(jī)日志；2：sort日志；3：防火墻日志；4：交換機(jī)日志）；MD5——文件的MD5值；fi——要合并的第i個文件；xj——合并第j類文件個數(shù)。

分組合并算法描述如下：

（1）初始化，定義一個三維數(shù)組File[type][MD5][key]，type初始化為1，key值初始化為文件的大小；

（2）讀入緩沖區(qū)的所有文件大小，更新數(shù)組File[type][MD5][key]，根據(jù)文件的類型更新數(shù)組的type值，初始化i=1；

（3）采用冒泡排序，分別將數(shù)組File[i][MD5][key]從大到小進(jìn)行排序。首先判斷File[i][MD5][key]的大小，如果所有文件的總大小大于64M，開始進(jìn)行合并，否則退出程序，i++，等待下次分組合并調(diào)度；

（4）從最大的文件fi開始分組。如果放入文件fi后，此類文件的總大小小于64M，則存放下一個文件，從數(shù)組中把文件fi的記錄刪除，循環(huán)這個過程，直到所有的File[i][MD5][key]文件都合并到一起；

（5）計算每類文件合并后的大小，文件大小達(dá)到63M的調(diào)用HDFS命令將文件上傳到HDFS上，大小小于63M的文件，再從緩沖區(qū)中查找文件進(jìn)行裝入，返回（2）；

（6）上傳成功；

主要是考慮到用戶的訪問效率，算法中采用將同類日志文件進(jìn)行分組，無論從寫入小文件，還是從讀取小文件方面，都能大大提高HDFS的性能：首先減輕了名稱節(jié)點的負(fù)擔(dān)，在讀取小文件方面，不用連接數(shù)據(jù)節(jié)點讀取，減少文件讀寫的I/O操作，節(jié)約大量數(shù)據(jù)傳輸時間，極大地節(jié)省了網(wǎng)絡(luò)通信開銷，降低了HDFS的訪問壓力，提高客戶端訪問文件的速率和性能。

當(dāng)用戶刪除數(shù)據(jù)時，把合并后的文件取回數(shù)據(jù)預(yù)存儲節(jié)點，進(jìn)行分解，刪除指定文件，再與緩存區(qū)中已有的文件進(jìn)行合并。

用戶查詢文件時，需要對HDFS索引進(jìn)行查詢，同時也需要查詢緩沖區(qū)里面的文件。

2.3小文件索引結(jié)構(gòu)的設(shè)計

在小文件合并之后，僅僅根據(jù)名稱節(jié)點中存儲的元數(shù)據(jù)信息不能檢索到小文件，為了提高檢索效率，需要為所有小文件構(gòu)建相應(yīng)的索引，使用戶能夠通過索引快速的檢索到小文件。小文件索引信息是在小文件合并成大文件之后生成的，保存在數(shù)據(jù)預(yù)存儲節(jié)點中，通過此類元數(shù)據(jù)信息，再結(jié)合名稱節(jié)點中的第一類元數(shù)據(jù)信息，才能正確找到小文件的存儲位置。所以小文件的索引信息對于后期的小文件檢索極其重要，其中要包含小文件的一些重要信息：File_name類型為String，表示小文件名稱；File_size類型為int，表示小文件大小；File_type類型為int，表示小文件類型；Merge_file_nam類型為string，表示小文件合并成大文件后的名稱；File_offset類型為int，當(dāng)前小文件在合并文件中的偏移量；time類型為long，表示文件的寫入時間；If_use類型為bool，表示文件是否存在。

2.4小文件合并過程的整體設(shè)計

大致流程如下：

當(dāng)需要寫入文件時，首先將數(shù)據(jù)傳輸?shù)綌?shù)據(jù)預(yù)存儲節(jié)點，判斷文件大小，如果文件大小超過了HDFS數(shù)據(jù)塊的大小，則直接存入數(shù)據(jù)節(jié)點，并將元數(shù)據(jù)信息寫入到名稱節(jié)點；如果需要寫入的文件屬于小文件，則先判斷小文件的類型，然后根據(jù)2.2中設(shè)計的小文件合并算法將小文件合并，生成索引信息，在這個合并的過程中，不斷地將正在合并的小文件索引信息插入到小文件索引信息列表中，當(dāng)合并文件塊達(dá)到合適的大小時，客戶端將寫文件請求發(fā)送到名稱節(jié)點將合并后的文件存儲到相應(yīng)的數(shù)據(jù)節(jié)點中。

3 實驗驗證

實驗需要搭建Hadoop集群，集群中包括4個節(jié)點：一臺NameNode，二臺DataNode，以及客戶端用來提交數(shù)據(jù)的NameNode。 使用VMware 7.0 來模擬 Linux 環(huán)境[4，5臺機(jī)器上模擬海量小文件的存儲和訪問操作。本文隨機(jī)選取了10000個xml日志數(shù)據(jù)文件，文件大小分布情況為：200kB占1%，300kB占2%，400kB占10%，500kB占20%，600kB占30%，700kB占20%，800kB占10%，900kB占4%，1000kB占3%，可見文件大小集中在400kb到1000kb之間。

為了直觀的反應(yīng)優(yōu)化方案在處理小文件和大文件時的系統(tǒng)性能，本文在測試數(shù)據(jù)中分別選取了100、1000、10000組數(shù)據(jù)，按照以上測試和執(zhí)行程序步驟，對文件寫入時間進(jìn)行測試，測試結(jié)果如圖1所示。實驗結(jié)果表明，隨著文件數(shù)量的增多，寫入文件所用時間增長趨勢的變化緩慢，說明本文設(shè)計的Hadoop小文件存儲優(yōu)化方案在寫入海量小文件時性能更高。

4 結(jié)論

本文首先對網(wǎng)絡(luò)安全設(shè)備聯(lián)動系統(tǒng)的數(shù)據(jù)轉(zhuǎn)化為XML文檔，然后對文件的特點及文件大小的分布進(jìn)行了分析。針對HDFS對小文件存儲效率低的問題，對小文件存儲方案進(jìn)行了優(yōu)化，設(shè)計了小文件分組合并的算法。最后搭建了Hadoop集群環(huán)境，對改進(jìn)的方案進(jìn)行測試，實驗結(jié)果表明，本文設(shè)計的Hadoop小文件存儲優(yōu)化方案在寫入文件所用時間增長趨勢的變化緩慢，說明本方案在寫入海量小文件時具有很高的性能，在不影響存儲系統(tǒng)運行狀況的基礎(chǔ)上，該方案提高了小文件的存儲效率和讀取效率。

參考文獻(xiàn)：

[1] 廖彬，于炯，張?zhí)?，楊興耀.基于分布式文件系統(tǒng)HDFS的節(jié)能算法[J].計算機(jī)學(xué)報，2013（05）：1047-1064.

[2] 傅穎勛，羅圣美，舒繼武.安全云存儲系統(tǒng)與關(guān)鍵技術(shù)綜述[J].計算機(jī)研究與發(fā)展，2013，50（1）：136-145

[3] D L Tennenhouse，J M Smith，W D Sincoskie，et al.A Survey of Active Networks Research[J].IEEE Communications Magazine，1997，35（l）：80-86.

[4] 許春玲，張廣泉.分布式文件系統(tǒng)HadoopHDFS與傳統(tǒng)文件系統(tǒng)LinuxFS的比較與分析[J].蘇州大學(xué)學(xué)報（工科版），2010，04：5-9+19.

[5] 崔杰，李陶深，蘭紅星.基于Hadoop的海量數(shù)據(jù)存儲平臺設(shè)計與開發(fā)[J].計算機(jī)研究與發(fā)展，2012（S1）：12-18.