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

劉揚(yáng) 劉冰

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

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

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

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

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

實(shí)驗(yàn)選取功能相對(duì)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部署后啟動(dòng)hadoop將預(yù)先準(zhǔn)備好的75K個(gè)文件從本地存儲(chǔ)到hdfs分布式文件系統(tǒng)中，在一次性存儲(chǔ)如此大量文件時(shí)，虛擬機(jī)出現(xiàn)了短暫性死機(jī)情況，幾分鐘后，shell出現(xiàn)大量警告，如圖1。

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

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

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

既然如此，之前遇到的警告就是因?yàn)閮?nèi)存的原因使得件沒(méi)有全部都存儲(chǔ)到hdfs分布式文件系統(tǒng)中，有一部分存儲(chǔ)成功，很容易讓人聯(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ù)目為一，忽略文件名長(zhǎng)度對(duì)計(jì)算結(jié)果的影響，分步計(jì)算過(guò)程如下：

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

75000*100*1000B≈750MB

塊所占內(nèi)存：

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

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

750MB+750MB≈1.5GB

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

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

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

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

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

參考文獻(xiàn)

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

作者簡(jiǎn)介

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

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

作者單位

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