網(wǎng)絡(luò )安全設備聯(lián)動(dòng)中小文件存儲優(yōu)化方法論文
摘要：網(wǎng)絡(luò )系統在運行過(guò)程中會(huì )產(chǎn)生大量日志，采用Java編程技術(shù)將各安全設備日志轉換為XML文件。在對日志文件存儲過(guò)程中，現有的存儲系統硬件成本高，擴展能力差，數據并行訪(fǎng)問(wèn)效率低，難以滿(mǎn)足網(wǎng)絡(luò )安全設備聯(lián)動(dòng)系統的需求。因此，該文采用基于HDFS的云存儲系統對日志文件進(jìn)行存儲。為了提高基于HDFS的云存儲系統中小文件存儲效率，該文設計了云存儲系統中小文件存儲的優(yōu)化方案，主要在小文件合并和小文件檢索方面做了優(yōu)化。該方案結合網(wǎng)絡(luò )安全設備聯(lián)動(dòng)系統中日志文件的特點(diǎn)，首先是根據不同設備的文件進(jìn)行分類(lèi)，然后根據小文件在合并后的大文件中的偏移量進(jìn)行檢索。最后采用3組文件集合對優(yōu)化方案進(jìn)行了測試，實(shí)驗結果表明，在不影響存儲系統運行狀況的基礎上，該方案提高了小文件的存儲效率和讀取效率。
關(guān)鍵詞：網(wǎng)絡(luò )安全；小文件；Hadoop；存儲優(yōu)化
中圖分類(lèi)號：TP393 文獻標識碼：A 文章編號：1009-3044(2015)35-0010-02
1引言
網(wǎng)絡(luò )系統在運行過(guò)程中會(huì )產(chǎn)生大量的系統日志、應用日志、安全日志和網(wǎng)絡(luò )日志，這些日志包含著(zhù)關(guān)于網(wǎng)絡(luò )運行、安全及狀態(tài)的數據。隨著(zhù)采集日志的大規模增長(cháng)，現有的存儲系統硬件成本高，擴展能力差，數據并行訪(fǎng)問(wèn)效率低，難以滿(mǎn)足網(wǎng)絡(luò )安全設備聯(lián)動(dòng)系統的需求。因此，提供一種更高性能、更低成本、更好可靠性的易于管理的存儲平臺，才能夠幫助該系統用盡可能低的成本應對日益增長(cháng)的數據存儲需求。HDFS采用主從式架構設計模式(master/slave)，一個(gè)名稱(chēng)節點(diǎn)(NameNode)和若干數據節點(diǎn)(DataNode)構成HDFS集群[1]。HDFS的這種單名稱(chēng)節點(diǎn)的設計極大地簡(jiǎn)化了文件系統的結構，然而也因此引發(fā)了HDFS的小文件存儲效率低的問(wèn)題。HDFS設計之初的目的是存儲大量的大文件，所以需要采用分塊策略先將每個(gè)文件分塊，保存機制是每個(gè)文件都占用一個(gè)或多個(gè)塊。因為HDFS中的每個(gè)目錄和文件的元數據信息都存放在名稱(chēng)節點(diǎn)的內存中，如果系統中存在大量的小文件(指那些比HDFS數據塊(默認為64MB)小得多的文件)，則無(wú)疑會(huì )降低整個(gè)存儲系統的存儲效率和存儲能力。然而，在網(wǎng)路安全設備聯(lián)動(dòng)系統[2]存在著(zhù)大量的小文件。大量的小文件存在于云存儲系統中無(wú)疑會(huì )降低整個(gè)系統的I/O性能。針對這一問(wèn)題，本文提出云存儲中小文件的合并處理方法，以提高小文件的存儲效率，提高整個(gè)系統的I/O性能。
2整體方案優(yōu)化設計
文件的優(yōu)化方案主要包括4個(gè)部分：數據預存儲節點(diǎn)的功能設計，小文件合并方案，小文件索引結構的設計以及小文件合并過(guò)程的整體設計。
2.1數據預存儲節點(diǎn)功能設計
數據預存儲節點(diǎn)是在HDFS架構的基礎上新增的節點(diǎn)，它位于客戶(hù)端與名稱(chēng)節點(diǎn)和數據節點(diǎn)之間，主要實(shí)現對存儲的文件進(jìn)行預處理，根據文件大小，判斷是否屬于小文件，對于小文件主要完成存儲前的合并，生成索引以及小文件檢索時(shí)的文件分離等功能。增加數據預存儲節點(diǎn)之后，在數據存儲的過(guò)程中，數據的流向由從客戶(hù)端直接到數據節點(diǎn)變成了由客戶(hù)端先到預存儲節點(diǎn)再到數據節點(diǎn)。
2.2小文件合并算法設計
當客戶(hù)端寫(xiě)入小文件時(shí)，首先根據小文件的類(lèi)型對數據預存儲節點(diǎn)進(jìn)行分組。然后分別將每個(gè)分組中的小文件合并成大文件，此時(shí)，生成相關(guān)小文件索引信息及元數據信息。最后將合并后的文件和相關(guān)的元數據，按照原HDFS寫(xiě)入文件的方式一同上傳至HDFS中，其中第二類(lèi)元數據信息由數據預存儲節點(diǎn)進(jìn)行存儲，第一類(lèi)元數據信息由名稱(chēng)節點(diǎn)進(jìn)行存儲，數據節點(diǎn)存儲合并成的大文件[3]當客戶(hù)端需要讀取某個(gè)小文件時(shí)，從名稱(chēng)節點(diǎn)獲取小文件所在大文件的元數據信息，然后從數據預存儲節點(diǎn)獲取第二類(lèi)元數據信息，從數據節點(diǎn)獲取小文件所在的大文件，并在接口中將大文件解檔為若干小文件，并將這些小文件緩存在客戶(hù)端。為了便于算法描述，對算法里的符號進(jìn)行定義：File[type][MD5][key]——緩沖區中待合并的文件；type——日志文件的類(lèi)型（1：主機日志；2：sort日志；3：防火墻日志；4：交換機日志）；MD5——文件的MD5值；fi——要合并的第i個(gè)文件；xj——合并第j類(lèi)文件個(gè)數。分組合并算法描述如下：（1）初始化，定義一個(gè)三維數組File[type][MD5][key]，type初始化為1，key值初始化為文件的大��；（2）讀入緩沖區的所有文件大小，更新數組File[type][MD5][key]，根據文件的`類(lèi)型更新數組的type值，初始化i=1；（3）采用冒泡排序，分別將數組File[i][MD5][key]從大到小進(jìn)行排序。首先判斷File[i][MD5][key]的大小，如果所有文件的總大小大于64M，開(kāi)始進(jìn)行合并，否則退出程序，i++，等待下次分組合并調度；（4）從最大的文件fi開(kāi)始分組。如果放入文件fi后，此類(lèi)文件的總大小小于64M，則存放下一個(gè)文件，從數組中把文件fi的記錄刪除，循環(huán)這個(gè)過(guò)程，直到所有的File[i][MD5][key]文件都合并到一起；（5）計算每類(lèi)文件合并后的大小，文件大小達到63M的調用HDFS命令將文件上傳到HDFS上，大小小于63M的文件，再從緩沖區中查找文件進(jìn)行裝入，返回（2）；（6）上傳成功；主要是考慮到用戶(hù)的訪(fǎng)問(wèn)效率，算法中采用將同類(lèi)日志文件進(jìn)行分組，無(wú)論從寫(xiě)入小文件，還是從讀取小文件方面，都能大大提高HDFS的性能：首先減輕了名稱(chēng)節點(diǎn)的負擔，在讀取小文件方面，不用連接數據節點(diǎn)讀取，減少文件讀寫(xiě)的I/O操作，節約大量數據傳輸時(shí)間，極大地節省了網(wǎng)絡(luò )通信開(kāi)銷(xiāo)，降低了HDFS的訪(fǎng)問(wèn)壓力，提高客戶(hù)端訪(fǎng)問(wèn)文件的速率和性能。當用戶(hù)刪除數據時(shí)，把合并后的文件取回數據預存儲節點(diǎn)，進(jìn)行分解，刪除指定文件，再與緩存區中已有的文件進(jìn)行合并。用戶(hù)查詢(xún)文件時(shí)，需要對HDFS索引進(jìn)行查詢(xún)，同時(shí)也需要查詢(xún)緩沖區里面的文件。
2.3小文件索引結構的設計
在小文件合并之后，僅僅根據名稱(chēng)節點(diǎn)中存儲的元數據信息不能檢索到小文件，為了提高檢索效率，需要為所有小文件構建相應的索引，使用戶(hù)能夠通過(guò)索引快速的檢索到小文件。小文件索引信息是在小文件合并成大文件之后生成的，保存在數據預存儲節點(diǎn)中，通過(guò)此類(lèi)元數據信息，再結合名稱(chēng)節點(diǎn)中的第一類(lèi)元數據信息，才能正確找到小文件的存儲位置。所以小文件的索引信息對于后期的小文件檢索極其重要，其中要包含小文件的一些重要信息：File_name類(lèi)型為String，表示小文件名稱(chēng)；File_size類(lèi)型為int，表示小文件大��；File_type類(lèi)型為int，表示小文件類(lèi)型；Merge_file_nam類(lèi)型為string，表示小文件合并成大文件后的名稱(chēng)；File_offset類(lèi)型為int，當前小文件在合并文件中的偏移量；time類(lèi)型為long，表示文件的寫(xiě)入時(shí)間；If_use類(lèi)型為bool，表示文件是否存在。
2.4小文件合并過(guò)程的整體設計
大致流程如下：當需要寫(xiě)入文件時(shí)，首先將數據傳輸到數據預存儲節點(diǎn)，判斷文件大小，如果文件大小超過(guò)了HDFS數據塊的大小，則直接存入數據節點(diǎn)，并將元數據信息寫(xiě)入到名稱(chēng)節點(diǎn)；如果需要寫(xiě)入的文件屬于小文件，則先判斷小文件的類(lèi)型，然后根據2.2中設計的小文件合并算法將小文件合并，生成索引信息，在這個(gè)合并的過(guò)程中，不斷地將正在合并的小文件索引信息插入到小文件索引信息列表中，當合并文件塊達到合適的大小時(shí)，客戶(hù)端將寫(xiě)文件請求發(fā)送到名稱(chēng)節點(diǎn)將合并后的文件存儲到相應的數據節點(diǎn)中。
3實(shí)驗驗證
實(shí)驗需要搭建Hadoop集群，集群中包括4個(gè)節點(diǎn)：一臺Na-meNode，二臺DataNode，以及客戶(hù)端用來(lái)提交數據的NameNode。使用VMware7.0來(lái)模擬Linux環(huán)境[4,5臺機器上模擬海量小文件的存儲和訪(fǎng)問(wèn)操作。本文隨機選取了10000個(gè)xml日志數據文件，文件大小分布情況為：200kB占1%，300kB占2%，400kB占10%，500kB占20%，600kB占30%，700kB占20%，800kB占10%，900kB占4%，1000kB占3%，可見(jiàn)文件大小集中在400kb到1000kb之間。為了直觀(guān)的反應優(yōu)化方案在處理小文件和大文件時(shí)的系統性能，本文在測試數據中分別選取了100、1000、10000組數據，按照以上測試和執行程序步驟，對文件寫(xiě)入時(shí)間進(jìn)行測試，測試結果如圖1所示。實(shí)驗結果表明，隨著(zhù)文件數量的增多，寫(xiě)入文件所用時(shí)間增長(cháng)趨勢的變化緩慢，說(shuō)明本文設計的Hadoop小文件存儲優(yōu)化方案在寫(xiě)入海量小文件時(shí)性能更高。
4結論
本文首先對網(wǎng)絡(luò )安全設備聯(lián)動(dòng)系統的數據轉化為XML文檔，然后對文件的特點(diǎn)及文件大小的分布進(jìn)行了分析。針對HDFS對小文件存儲效率低的問(wèn)題，對小文件存儲方案進(jìn)行了優(yōu)化，設計了小文件分組合并的算法。最后搭建了Hadoop集群環(huán)境，對改進(jìn)的方案進(jìn)行測試，實(shí)驗結果表明，本文設計的Hadoop小文件存儲優(yōu)化方案在寫(xiě)入文件所用時(shí)間增長(cháng)趨勢的變化緩慢，說(shuō)明本方案在寫(xiě)入海量小文件時(shí)具有很高的性能，在不影響存儲系統運行狀況的基礎上，該方案提高了小文件的存儲效率和讀取效率。
參考文獻：
[1]廖彬,于炯,張陶,楊興耀.基于分布式文件系統HDFS的節能算法[J].計算機學(xué)報,2013(05):1047-1064.
[2]傅穎勛,羅圣美，舒繼武．安全云存儲系統與關(guān)鍵技術(shù)綜述[J]．計算機研究與發(fā)展，2013，50(1):136-145
[3]DLTennenhouse,JMSmith,WDSincoskie,etal.ASurveyofActiveNetworksResearch[J].IEEECommunicationsMagazine,1997,35(l):80-86.
[4]許春玲,張廣泉.分布式文件系統HadoopHDFS與傳統文件系統LinuxFS的比較與分析[J].蘇州大學(xué)學(xué)報(工科版),2010,04:5-9+19.
[5]崔杰,李陶深,蘭紅星.基于Hadoop的海量數據存儲平臺設計與開(kāi)發(fā)[J].計算機研究與發(fā)展,2012(S1):12-18.
【網(wǎng)絡(luò )安全設備聯(lián)動(dòng)中小文件存儲優(yōu)化方法論文】相關(guān)文章：
網(wǎng)絡(luò )存儲技術(shù)論文03-29
gsm網(wǎng)絡(luò )優(yōu)化論文02-25
淺談通過(guò)文件的網(wǎng)絡(luò )存儲培養學(xué)生信息管理意識的能力論文10-28
網(wǎng)絡(luò )存儲技術(shù)比較研究論文11-07
移動(dòng)網(wǎng)絡(luò )優(yōu)化論文03-10
探析網(wǎng)絡(luò )存儲技術(shù)研究論文11-07
《管理已存儲的文件》教學(xué)設計01-07
優(yōu)化設計方法的數值研究論文11-03