賀建英
電子政務平臺下HDFS中高效存儲上傳文件的方法
賀建英
在Hadoop的電子政務平臺中針對存儲成千上萬的用戶上傳文件,利用HDFS提高文件的存儲效率。設計了一個在云存儲過程中小文件上傳存儲的處理方案。設定臨時容器來暫存上傳的小文件,使用定時器或臨時容器滿為臨界條件進行文件的合并組合。通過增加NFS服務器和分離NameNode節(jié)點的職責,建立相關(guān)子類來存儲和云同步服務信息,降低客戶端訪問數(shù)據(jù)的壓力。設計一個簡單的預測系統(tǒng)負荷的算法,使文件的合并組合在系統(tǒng)負荷較小時進行,減少等待時間,提高效率。通過實驗表明合理的設置臨時容器的大小和增加NFS服務器,在系統(tǒng)負荷低時能有效地提高HDFS存儲小文件的效率。
臨時容器;NFS;系統(tǒng)負荷;HDFS;存儲效率;云存儲;
由于國家對電子政務建設的大力支持和投資,電子政務平臺的規(guī)化也逐漸趨于成熟。電子政務平臺中的數(shù)據(jù)也日趨龐大,除了需要存儲基本的數(shù)據(jù)外,為讓政務公開化、透明化、無紙化,系統(tǒng)還提供了電子辦公和在線交流等業(yè)務,這些都是電子數(shù)據(jù),必須存儲在電子政務平臺中。但還有一些很重要的數(shù)據(jù)也必須要存儲在該平臺中,如需要通過掃描或者以附件上傳的文檔,這些文檔事先以紙質(zhì)或者電子的形式進行傳遞,但最終還是會以電子數(shù)據(jù)的形式存儲到電子政務平臺中,方便存檔和后期的訪問。在目前的設計中對這類數(shù)據(jù)的存儲較慢,有一定的瓶頸,將直接影響到整個電子政務平臺的存儲效率。在 Hadoop云平臺的電子政務系統(tǒng)中可以分布式處理這些數(shù)據(jù),提高數(shù)據(jù)的存儲和訪問能力。
在大數(shù)據(jù)環(huán)境下Hadoop中的分布式文件系統(tǒng)HDFS已經(jīng)得到了廣泛的應用,大大地提高了數(shù)據(jù)訪問的吞吐量,但HDFS本身適合GB級甚至TB級的文件系統(tǒng),適用于處理大文件。在HDFS中處理大文件時會以64MB為單位進行劃分,每64MB為一個分塊(block),并且這些文件是按
對Hadoop的HDFS存儲小文件效率低下的問題,目前還沒有一個通用的解決方案。當前主要是從兩個方面來考慮:一方面是利用 HDFS本身提供了四種解決方案[1]:Hadoop Archive、 Sequence File、 CombineFileInputFormat和TextInputFormat。 其 中 CombineFileInputFormat 和TextInputFormat是一種以類封裝的方式進行存儲,需要考慮數(shù)據(jù)具體的存儲位置,且會造成空間上的浪費。另一方面是根據(jù)具體的應用而對存儲模塊進行處理組合的方式。
1.1 Hadoop Archive
Hadoop Archive[2]的思想是將小文件放在一個文件存儲容器中,將多個小文件打包成一個HAR文件,這樣多個小文件的block就減少成一個block,同時也減少了NameNode在內(nèi)存中的使用,但它仍然可以向客戶端提供對文件的透明訪問。其缺點在于:一是HAR文件一旦創(chuàng)建,便不能再對打包的文件進行更改。二是在創(chuàng)建Archive是會創(chuàng)建對應的副本,會浪費同樣多的存儲空間,造成存儲空間的浪費等。
1.2 Sequence File
Sequence File[3]的思想是以
1.3 相關(guān)應用的組合方式
WebGIS(地理信息系統(tǒng))是利用HAR技術(shù)結(jié)合系統(tǒng)數(shù)據(jù)的相關(guān)特性,將小文件合并成 64MB的大文件,并建立索引[4]的方式。在 BlueSky(中國電子教學共享系統(tǒng))中把同屬于一個分類的 PPT課件打包合并存儲在一個大文件中,提供解決存儲和讀取小文件效率的方法[5]。
以上的研究都是基于 HDFS提供的原理——文件的合并或者組合來解決小文件存儲效率的問題。然而還存在如下的問題:(1)在存儲時小文件的元數(shù)據(jù)信息以名字節(jié)點存儲時對內(nèi)存的壓力問題。(2)在組合或合并文件時的界限值如何界定,能使效率達到最優(yōu)。(3)在系統(tǒng)運行時其負載能否承受文件的合并組合并存儲。文獻[6][7]中分別提到在 HDFS中對小文件的存儲效率的方法,本文結(jié)合電子政務的實際情況,利用文獻[6][7]的思想,進一步改進HDFS中高效存儲文件的方法來提高文件存儲的效率。
在電子政務平臺中,文件是由不同的用戶上傳到云平臺中。在HDFS中是以NameNode來作為系統(tǒng)中唯一的管理者。文件在上傳合并時將會考慮到文件的實際大小、文件是否允許合并、文件合并時是以什么為界定條件等?;谶@些因素的考慮,提出系統(tǒng)架構(gòu)如圖1所示:
圖1 系統(tǒng)架構(gòu)圖
在本系統(tǒng)架構(gòu)中,當用戶上傳文件到云存儲器時(過程1),在云存儲服務器內(nèi)部為了不使 HDFS中唯一的管理者NameNode節(jié)點負荷過重,造成效率低下,在文件和目錄的處理時將兩種事務分開,分別進行處理。故增加 Access NameNode節(jié)點和Master NameNode節(jié)點,增加NFS服務器。服務器在對用戶上傳的文件進行處理時會借助于 NFS服務器(過程2),通過Access NameNode節(jié)點判斷用戶上傳的文件是否為小文件(過程 3),則將該小文件的索引號按先到先入的順序放入設定的容器中(過程 4)。當容器被裝滿時,則發(fā)送容器已滿的信號到控制中心(過程 5),另外設定定時器,當達到指定的時間,不管容器中的小文件個數(shù)如何,則發(fā)送時間已到的信號到控制中心(過程5’)。此后控制中心將讀取容器內(nèi)的文件及相關(guān)信息,并對系統(tǒng)當前的負荷進行相關(guān)計算(過程 6),其算法將在后面介紹。通過對應的算法對系統(tǒng)負荷的計算判斷是否進行小文件的合并組合操作(過程 7)。當小文件根據(jù)需要合并組合后將完成所上傳的文件和已合并的大文件之間的映射(過程 8),此映射將放在Access NameNode中。在系統(tǒng)中設計的Access NameNode節(jié)點和 Master NameNode節(jié)點都是繼承于NameNode節(jié)點,都是文件系統(tǒng)的管理者,其目的是為了分擔由單一的NameNode節(jié)點管理整個系統(tǒng)的壓力。這兩個節(jié)點之間的元數(shù)據(jù)和相關(guān)信息都必須保持同步,同步分兩部分:一部分是數(shù)據(jù)塊的同步,是通過同時向兩個NameNode中匯報元數(shù)據(jù)來保持一致;二部分是目錄的同步,只要是依靠新增加的NFS服務器,通過Master NameNode將日志同步到NFS服務器上,而Access NameNode節(jié)點則實時讀取NFS服務器的日志來保持目錄樹信息的一致。本系統(tǒng)架構(gòu)的執(zhí)行邏輯如圖2所示:
圖2 執(zhí)行邏輯圖
通過邏輯結(jié)構(gòu)圖可以看出,對系統(tǒng)中用戶上傳的文件,在系統(tǒng)負荷不大,且容器裝滿或者已經(jīng)達到規(guī)定的時間,均可以把小文件合并成大文件,放在NFS服務器中。
系統(tǒng)的負荷預測主要是通過對已有的CPU的利用率和實時CPU的利用率的計算,推導出下一時刻系統(tǒng)CPU的利用率的方法。Analytic Hierarchy Process(層次分析法)[8]的思想就是把與決策有關(guān)的信息分解成目標、方案和準則的方法,并以此為基礎(chǔ)進行分析,得到?jīng)Q策方法的一種有效方法。本系統(tǒng)在設計時借助于AHP的思想,把每一時刻的系統(tǒng)負荷屬性值分解成單一的屬性值,并以單一的屬性值建立對應的矩陣,通過矩陣的相關(guān)變換,推導出用于計算的比較矩陣,通過原矩陣和變換矩陣的比較操作,計算出相對的最優(yōu)矩陣,進而計算出決策屬性值,通過決策屬性值預測出下一時刻可能的系統(tǒng)負荷,其具體過程如下所示:
1)創(chuàng)建矩陣X,X中有元素bi(i=1,2,3…,n),是由從系統(tǒng)中提取的系統(tǒng)屬性的值構(gòu)成,則矩陣 X中的元素定義如公式(1):
2)設X矩陣中每行的和為sj,那么sj的值如公式(2):
設和的最大值為smax,最小值為smin, 則smax=max(sj),smin=min(sj)。設最大值和最小值相比較的結(jié)果為rb=smax/smin,把矩陣X進行變換,得到對應的矩陣X*,此時把X* 稱為判斷矩陣,當xi>=sj時,判斷矩陣的值如公式(3):
其中m,n是常量,在計算時為了計算的方便可以設定m=1,n=1。m表示一個小于rb的常量,而n則表示偏移量。偏移量是上兩次系統(tǒng)負荷預測值的比值。
當xi 特殊情況下,當smax=smin時,xij*=1。 3)由X矩陣和X*進行比較得到最優(yōu)矩陣Y,矩陣Y中的值如公式(5): 其中i,j,k∈(1,2,3……k)。從而得到系統(tǒng)負荷的權(quán)值tj,如公式(6): 4)通過矩陣X和系統(tǒng)負荷權(quán)值得到系統(tǒng)決策屬性值pi,如公式(7): 5)要得到系統(tǒng)在下一刻的負荷值,只需要根據(jù)時間順序來構(gòu)建矩陣 X,并分別根據(jù)公式(1)到公式(7),設在不同的時刻 time1,time2,time3…timem 所對應的決策屬性值p1,p2,p3…pm所對應的權(quán)重值分別為t1,t2,t3…tm,則可以推導出在timem+1時刻的系統(tǒng)負荷為pm+1,如公式(8): 通過算法可以順利的預測到系統(tǒng)下一時刻的負荷情況,方便地使小文件的合并組合在系統(tǒng)均衡的時刻進行操作,從而避免了在系統(tǒng)負荷過大時等待文件的合并造成時間上的浪費,使得操作的效率低下。 為提高電子政務平臺中對用戶上傳的小文件的存儲效率,依據(jù)本文設計的系統(tǒng)架構(gòu),為每一上傳文件的用戶建立對應的操作小文件的臨時容器。通過對用戶上傳文件的時間的測試(與網(wǎng)絡性能有關(guān))、合并組合文件的時間和上傳文件到 NFS服務器的時間等進行分析。因讀取文件、合并文件及上傳文件都和存儲的NFS服務器有關(guān),只要提高了文件合并組合和存儲的效率,那么整個系統(tǒng)的效率也隨之提高。故在實驗中分別測試為:(1)各個小文件讀取存放在容器中的時間。(2)小文件合并組合的時間;(3)合并組合后的文件上傳到云服務器的時間。 本文通過在IBM的服務器(Intel Xeon Processor E5405 2.0GHZ 12MB L2 1333MHZ 80W),操作系統(tǒng)為Ubuntu14.04,Hadoop版本為0.23.1。在服務器上使用Vmrare安裝好一臺虛擬機后再克隆出其余的4臺虛擬機建立一個集群,在每個虛擬機上分別安裝JDK1.8,Hadoop和ssh到集群中的主從節(jié)點,設置一個主節(jié)點,其余的為從節(jié)點,設置對應的網(wǎng)絡配置,保證各虛擬機之間能正常通信。 實驗1中分別設置不同的容器大小,分別能存儲100,300,500,700,900,1100,1300,1500各文件,并測試在不同的容器中采用先進先入得方式進行操作,并按文件的大小升序排列。實驗中文件的上傳跟網(wǎng)絡的性能有很大的關(guān)系,這里將忽略掉網(wǎng)絡對系統(tǒng)的影響,測試得到的平均時間如圖3所示: 圖3 平均耗時圖 從圖3可知,容器長度越長,其相對耗時反而減少 ,故臨時存儲文件可以減少每次上傳的耗時。 實驗2主要是針不同容器長度,分別對里面存放的文件進行20次合并組合,在4臺虛擬機器上得到平均耗時的實驗數(shù)據(jù)如圖4所示: 圖4 組合平均耗時圖 在20次的組合中,容器的大小并沒有讓合并組合的耗時成比例的增加,從結(jié)果來看,容器的大小越大,其相對耗時反而減少。實驗3中,當文件被合并組合,將上傳到服務器中,根據(jù)系統(tǒng)架構(gòu),將先啟動Master NameNode節(jié)點,創(chuàng)建對應的Access NameNode節(jié)點,啟動網(wǎng)絡服務器,同時啟動創(chuàng)建的Access NameNode節(jié)點。再使Master NameNode和Access NameNode節(jié)點接收來自Client的上傳請求。根據(jù)容器的大小,設置合并組合后的文件大小分別為 40MB,130MB,200MB,280MB,360MB,440MB,520MB,600MB。不同合并組合的文件上傳操作耗時與最原始的 HDFS比較的結(jié)果如圖5所示: 通過實驗可見,在合并文件時,容器的長度在有效范圍內(nèi),如果容器長度越長,上傳文件所需的時間相對越短,并且合并文件耗時相對也越少。借助于 NFS服務器,增加Master NameNode和Access NameNode節(jié)點,把合并組合后的文件上傳到云服務器的耗時比傳統(tǒng)的 HDFS方式耗時更少。實驗證明,根據(jù)電子政務平臺設計的解決云存儲用戶上傳的小文件的存儲效率的系統(tǒng)架構(gòu)的設計有一定的合理性。 本文根據(jù)電子政務平臺中需要接收成千上萬用戶上傳的小文件的實際情況出發(fā),設計了一套解決小文件在云存儲中提高效率的解決方案。該方案在HDFS合并文件的基礎(chǔ)上進一步改進,一方面利用容器存儲足夠的文件進行合并;另一方面在云存儲中新增加 NFS服務器,并把請求從NameNode中分離出來,利用Master NameNode和Access NameNode節(jié)點與NFS服務器同步存儲合并組合的文件。通過實驗表明,該方法有一定的實用性。但本系統(tǒng)架構(gòu)也有需要改進的地方。如存儲的臨時容器的最優(yōu)大小是多少?文件合并成大文件時的最優(yōu)值是多少?在容器內(nèi)部采用什么樣的算法才能最優(yōu)的為文件的合并服務?這些問題還需進一步研究。 [1] 李三淼, 李龍澍.Hadoop 中處理小文件的四種方法的性能分析[J].計算機工程與應用.2014.12.30http://www. cnki.net/kcms/detail/11.2127.TP.20141230.1656.014.html [2] Rajeev Gupta, Himanshu Gupta, Ullas Nambiar, etal. Efficiently querying archived data using Hadoop[C].// 19th ACM conference on Information and Knowledge Management.2010:1301-1304. [3] Zhao Xiaoyong.Yang Yang,Sun Lili.et al.Metadata-aware small files storage architecture on Hadoop[C] .//Web Information Systems and Mining.2012:136-143. [4] Liu Xuhui.Han Jizhong.Zhong Yunqin.et al.Implementing WebGIS on Hadoop:A case study of imporving small file I/O performance on HDFS[C].//IEEE International Conference on Cluster Computing and Wordshops .2009:429-436. [5] Bluesky’s integraed LiDAR imaging system[J].Highwags. 2012.81(7):76. [6] 尹穎.林慶.林涵陽.HDFS中高效存儲小文件的方法[J].計算機工程與設計.2015(2):406-409. [7] 余思.桂小林.黃汝維.莊威.一種提高云存儲中小文件存儲效率的方案[J].西安交通大學學報.2011(6):59-63. [8] SATTY T L.Axiomatic foundation o f the analytic hierarchy process [J] .Management Scie nce, 1986 , 32(7):841-855. TP311 文獻標志碼:A 2015.04.16) 1007-757X(2015)08-0076-04 四川省教育廳項目(15ZB0324) 賀建英(1979-),女,四川簡陽人,四川文理學院,計算機學院,碩士,講師,研究方向:軟件技術(shù),數(shù)據(jù)挖掘,物聯(lián)網(wǎng),成都,6350004 實驗
5 總結(jié)