運(yùn)用Hadoo高效存儲海量碎片文件的方法

劉揚(yáng) 劉冰

摘 要學(xué)院綜合管理信息系統(tǒng)，是學(xué)院開展各項(xiàng)工作的信息化方式和途徑，在信息共享的同時(shí)，減少工作數(shù)據(jù)報(bào)送的重復(fù)現(xiàn)象，結(jié)合技術(shù)手段以實(shí)現(xiàn)工作效率的提高。本文從實(shí)際出發(fā)，從技術(shù)的角度，就目前本單位所使用的綜合管理信息系統(tǒng)中存在的問題進(jìn)行了深入研究和剖析，對系統(tǒng)性能進(jìn)行了技術(shù)優(yōu)化和改進(jìn)，減少了碎片化數(shù)據(jù)的產(chǎn)生，提升了系統(tǒng)的整體效能。

【關(guān)鍵詞】Hadoop 碎片化

在目前單位使用的綜合管理信息系統(tǒng)中，應(yīng)用層中體現(xiàn)為多用戶并發(fā)訪問系統(tǒng)出現(xiàn)數(shù)據(jù)傳輸過慢造成大量的數(shù)據(jù)延遲，系統(tǒng)卡死以及用戶掉線的情況。在系統(tǒng)底層體現(xiàn)為CPU和內(nèi)存使用率長時(shí)間保持在較高狀態(tài)。

為了優(yōu)化并提高系統(tǒng)整體效能，從根本上解決系統(tǒng)碎片化處理問題，找到解決碎片化處理的方法和機(jī)制，所以我們進(jìn)行了本次實(shí)驗(yàn)。

實(shí)驗(yàn)環(huán)境如表1所示。

實(shí)驗(yàn)選取功能相對VirtualBox更強(qiáng)的VMware Workstation虛擬機(jī)軟件，以學(xué)院服務(wù)器使用的Ubuntu 16.04作為虛擬機(jī)的操作系統(tǒng)，同時(shí)使用穩(wěn)定的Hadoop-2.7.4部署偽分布式Hadoop實(shí)驗(yàn)環(huán)境，Hadoop的源代碼由Java實(shí)現(xiàn)，故選取穩(wěn)定的Openjdk-8-jdk版本進(jìn)行Java環(huán)境的配置。

在完成偽分布式hadoop部署后啟動hadoop將預(yù)先準(zhǔn)備好的75K個文件從本地存儲到hdfs分布式文件系統(tǒng)中，在一次性存儲如此大量文件時(shí)，虛擬機(jī)出現(xiàn)了短暫性死機(jī)情況，幾分鐘后，shell出現(xiàn)大量警告，如圖1。

著手開始分析出現(xiàn)警告的原因，使用hdfs shell命令查看hdfs分布式文件系統(tǒng)上存儲數(shù)據(jù)的文件，發(fā)現(xiàn)只有部分文件被成功的從本地存儲到分布式文件系統(tǒng)，這說明所執(zhí)行的命令沒有錯誤。那究竟是什么原因?qū)е逻€有大量的文件沒有被成功存儲到分布式文件系統(tǒng)上？帶著這個疑問，開始查詢hdfs分布式文件系統(tǒng)存儲文件的相關(guān)資料。

首先，hdfs分布式文件系統(tǒng)的存儲分為元數(shù)據(jù)存儲和真實(shí)數(shù)據(jù)存儲，元數(shù)據(jù)存儲在namenode節(jié)點(diǎn)上，真實(shí)數(shù)據(jù)則存儲在datanode節(jié)點(diǎn)上，結(jié)合本次實(shí)驗(yàn)環(huán)境，所部署的是ubuntu下的偽分布式hadoop，datanode節(jié)點(diǎn)和namenode節(jié)點(diǎn)在同一臺虛擬機(jī)上，所以元數(shù)據(jù)和真實(shí)的數(shù)據(jù)都是存儲在同一臺虛擬機(jī)上的。在分析原因的過程中，我注意到了一個地方，就是hdfs分布式文件系統(tǒng)不適合做的事——存儲大量小文件。因?yàn)閚amenode要存儲HDFS的metadata（比如目錄的樹狀結(jié)構(gòu)，每個文件的文件名、ACL、長度、owner、文件內(nèi)容存放的位置等等信息）會受到namenode內(nèi)存的限制。分析到這里似乎找到了出現(xiàn)警告的根源。

根據(jù)分析得知namenode節(jié)點(diǎn)的元數(shù)據(jù)需要放在內(nèi)存中。其中，saveFSImage方法的參數(shù)代表內(nèi)存元數(shù)據(jù)將要保存的位置，磁盤確實(shí)有塊空間，對元數(shù)據(jù)進(jìn)行持久化存儲，名為fsimage，如果直接讀取磁盤文件，速度肯定跟不上，內(nèi)存中也要放一些元數(shù)據(jù)信息，雖然很容易丟失，但可以提供查詢服務(wù)，實(shí)際上就是讀寫分離，由讀寫分離就有了數(shù)據(jù)一致性的問題，因?yàn)閷懭霐?shù)據(jù)，沒有寫入內(nèi)存中，最新的元數(shù)據(jù)記錄在哪呢？實(shí)際上是記錄在一個很小的文件中，這個文件不提供修改，只提供追加，以日志的形式記錄，一直都保持著幾十兆大小，名為edits***.log，比如在上傳一個文件時(shí)，先對NAMENODE進(jìn)行詢問，往哪里寫？NAMENODE一邊分配一邊記錄，將空間分配信息記錄edits**.log，當(dāng)完成一個副本的寫入工作后，通知NAMENODE，被認(rèn)為是寫入成功，這時(shí)，將edits**.log的數(shù)據(jù)更新至內(nèi)存，此時(shí)，內(nèi)存中的數(shù)據(jù)是最新的，即使現(xiàn)在斷電，最新的元數(shù)據(jù)在edits**.log也有保存。

既然如此，之前遇到的警告就是因?yàn)閮?nèi)存的原因使得件沒有全部都存儲到hdfs分布式文件系統(tǒng)中，有一部分存儲成功，很容易讓人聯(lián)想到是不是因?yàn)閮?nèi)存不足導(dǎo)致的呢？

Namenode元數(shù)據(jù)在內(nèi)存中所占空間的計(jì)算方法如表2。

元數(shù)據(jù)在內(nèi)存中所占空間包含文件和塊兩部分，由于實(shí)驗(yàn)環(huán)境為偽分布式Hadoop，文件塊的副本數(shù)目為一，忽略文件名長度對計(jì)算結(jié)果的影響，分步計(jì)算過程如下：

文件所占內(nèi)存：

75000*100*1000B≈750MB

塊所占內(nèi)存：

5000*（250*1000B+24*1）≈750MB

計(jì)算元數(shù)據(jù)需要總內(nèi)存：

750MB+750MB≈1.5GB

然而這只是粗略計(jì)算，其中并沒有包含塊信息和其他信息，實(shí)際情況會比所計(jì)算的結(jié)果多出很多。通過使用hdfs的oiv和ls這兩個命令測得namenode實(shí)際使用內(nèi)存大約2.2G，而在實(shí)驗(yàn)環(huán)境中分給虛擬機(jī)內(nèi)存正好是2.5G。一直到現(xiàn)在，之前遇到的問題才真正得到正確的解答。讓我更進(jìn)一步地了解hdfs分布式文件系統(tǒng)存儲的機(jī)制。hdfs分布式文件系統(tǒng)無法高效完成對海量碎片文件的存儲，仔細(xì)想一想真的是這樣，七萬個文件會占據(jù)2.2G內(nèi)存的硬件資源，那七千萬個文件，乃至七億個文件，將會占據(jù)多少的內(nèi)存硬件資源，而一個大型的分布式系統(tǒng)，在存儲大文件時(shí)所產(chǎn)生的“碎片”文件的數(shù)量是不可預(yù)估的，當(dāng)務(wù)之急是針對這個問題提出一種行之有效的解決方法。

在上面提到的Namenode元數(shù)據(jù)所需內(nèi)存的計(jì)算公式中，注意到所需內(nèi)存大小與文件名長度有很大關(guān)系，那么，如果能夠找到一種方法，能夠像windows和linux操作系統(tǒng)那樣實(shí)現(xiàn)對文件的壓縮，是不是能夠有效的解決這個問題呢？

在這里就要探討一種hdfs存儲海量“碎片”文件的解決方法——Hadoop Archive。它是通過archive工具來將多個文件建立為歸檔文件，這種歸檔文件并不同于windows和linux操作系統(tǒng)下的壓縮文件，首先歸檔文件的擴(kuò)展名是*.har，并且在歸檔后還可以直接訪問每一個文件，但是并沒有實(shí)現(xiàn)壓縮的功能，除此之外，archive文件一旦創(chuàng)建就無法改變，這就意味這你要改一些東西的話，你需要重新創(chuàng)建archive文件。在Hadoop archive中包含兩種文件，分別是元數(shù)據(jù)和數(shù)據(jù)文件，元數(shù)據(jù)以兩種形式存在———_index和_masterindex文件，在_index文件中包含了歸檔文件所含文件的文件名和位置信息。

從圖2所示布局圖中可以看出，Masterindex指向index，index的各個部分則指向不同的數(shù)據(jù)，這種布局使得歸檔文件實(shí)現(xiàn)了類似于目錄的功能，而歸檔文件中的數(shù)據(jù)文件對于用戶來說又是透明的，用戶在建立歸檔文件后仍然能夠直接訪問內(nèi)部的數(shù)據(jù)文件，唯一的缺點(diǎn)就是沒有實(shí)現(xiàn)數(shù)據(jù)追加的功能，一旦歸檔文件被創(chuàng)建，如果想要實(shí)現(xiàn)對歸檔文件內(nèi)容的調(diào)整，就只能重新創(chuàng)建歸檔文件。

通過圖4所示效能比對圖我們可以看出在系統(tǒng)底層集成了Hadoop Archive方法后，對照原有系統(tǒng)在碎片哈數(shù)據(jù)處理方面有了較大的提高。并且在系統(tǒng)響應(yīng)和并發(fā)響應(yīng)中也有了很大的提高，這樣一來我們可以看出構(gòu)建歸檔文件方法對于碎片化處理底層數(shù)據(jù)和優(yōu)化十分有效，也是我們找出了這樣一條系統(tǒng)優(yōu)化和提升的新思路。

參考文獻(xiàn)

[1]查禮.基于Hadoop的大數(shù)據(jù)計(jì)算技術(shù)[J].科研信息化技術(shù)與應(yīng)用，2012（06）.

作者簡介

劉揚(yáng)（1982-），男，山東省濟(jì)南市人。大學(xué)本科學(xué)歷，初級職稱。研究方向?yàn)檐浖こ?，現(xiàn)從事一線教學(xué)工作。

劉冰（1997-），男，山東省濰坊市人。山東電子職業(yè)技術(shù)學(xué)院大二學(xué)生。

作者單位

山東電子職業(yè)技術(shù)學(xué)院 山東省濟(jì)南市 250000