外文翻譯（中文）--對于hadoop處理小文件的性能優(yōu)化

1、<p><b>　　中文4310字</b></p><p>　　對于Hadoop處理小文件的性能優(yōu)化</p><p>　　Neethu Mohandas 和Sabu M. Thampi</p><p>　　印度科欽Rajagiri工程與技術(shù)學(xué)院</p><p><b>　　摘 要</b>

2、;</p><p>　　Hadoop是由Dong Cutting提出的，一個(gè)頂級的Apache項(xiàng)目。用于支持千級別的龐大數(shù)據(jù)的分布式應(yīng)用。它是一個(gè)開源的軟件框架，靈感來自于谷歌的MapReduce編程模型和谷歌的系統(tǒng)文件。它是由全球社區(qū)的開發(fā)者用java共同研發(fā)的。Hadoop被廣泛地應(yīng)用與世界各地的各種學(xué)術(shù)科研機(jī)構(gòu)和商業(yè)組織，還包括了common hadoop，hadoop文件系統(tǒng)(HDFS)和MapReduc

3、e作為其子項(xiàng)目。common hadoop包含了支持其他子項(xiàng)目的通用工具。HDFS是一個(gè)高性能的分布式文件系統(tǒng)，Hadoop給予了HDFS高度的訪問程序數(shù)據(jù)的性能。它還通過數(shù)據(jù)復(fù)制提高了可靠性，并同時(shí)保持?jǐn)?shù)據(jù)的完整性。MapReduce的是基于MapReduce算法的一個(gè)能在集群上進(jìn)行大量的分布式數(shù)據(jù)計(jì)算的軟件框架。雖然Hadoop被廣泛的使用，但是由于種種問題，它的潛力還沒有被充分發(fā)揮出來，小文件的問題就是其中之一。在hadoop的0

4、.18.0版本開始，hadoop歸檔被作為處理小文件的解決方案被引入hadoop。文件序列化也可以作為一種解決方案。這兩種解決方案各自有自己的優(yōu)點(diǎn)和缺點(diǎn)。我們提出的與建</p><p>　　關(guān)鍵詞：hadoop，hadoop分布式文件系統(tǒng)（HDFS）,MapReduce，小文件問題，hadoop歸檔，文件序列化</p><p><b>　　1緒 論</b></

5、p><p>　　在分布式計(jì)算的時(shí)代，hadoop飛速發(fā)展起來，它在涉及TB和PB級別的計(jì)算處理中，表現(xiàn)出極佳的性能和高效的處理能力。這些成就可能源于一個(gè)名為MapReduce的底層軟件架構(gòu)和一個(gè)名為HDFS的分布式文件系統(tǒng)。MapReduce正像它的名字表現(xiàn)的，是一個(gè)基于Map和Reduce兩步的支持大量計(jì)算的軟件框架。Map和Reduce兩個(gè)步驟的概念都源于函數(shù)是編程語言。在2004年的OSDI中，谷歌提交了一份關(guān)

6、于MapReduce的文件，標(biāo)志著這項(xiàng)工程的動(dòng)工。Hadoop是基于java的MapReduce實(shí)現(xiàn)，它的基本概念即為將一個(gè)巨大的難以管理的計(jì)算分成更小的可管理的塊。HDFS，從另一方面來說，是受了谷歌文件系統(tǒng)的啟發(fā)。它依靠它的可靠的數(shù)據(jù)存儲，數(shù)據(jù)的高完整性，以及最重要的高吞吐量，來支持hadoop高性能的大型計(jì)算。因此，Hadoop廣泛地受到了網(wǎng)絡(luò)，搜索，金融，科研機(jī)構(gòu)等市場的青睞。</p><p><b

7、>　　2研究背景</b></p><p>　　2.1MapReduce</p><p>　　程序員們從這個(gè)框架中受益良多，因?yàn)樗麄兛梢员苊饪紤]應(yīng)用程序復(fù)雜的分布式運(yùn)算所帶來的頭痛。這是因?yàn)榉植际竭\(yùn)算可能需要將輸入分片，分配給集群中一組計(jì)算節(jié)點(diǎn)，管理系統(tǒng)的故障，節(jié)點(diǎn)間的通信都需要實(shí)時(shí)考慮。程序員可以方便地運(yùn)用分布式框架進(jìn)行分布式編程， 即使他們沒有多少分布式計(jì)算經(jīng)驗(yàn)，而ha

8、doop就是其中最受程序選喜愛的一個(gè)分布式編程框架?；镜木幊棠Ｐ涂梢悦枋鰹橐粋€(gè)Map任務(wù)和一個(gè)Reduce任務(wù)的組合。要執(zhí)行計(jì)算，就需要提供的一組鍵值對作為最初的輸入。然后計(jì)算完成后，最終產(chǎn)生一組鍵值對作為輸出。在具有MapReduce庫的情況下，計(jì)算可以被看做是兩個(gè)函數(shù)，Map和Reduce。Map和Reduce函數(shù)都會被用戶重寫。Map函數(shù)將接受一組鍵值對作輸入，并且將一組鍵值對作為中間輸出。然后，MapReduce庫根據(jù)鍵的唯一

9、性將這些值組合起來，然后將它傳遞給Reduce函數(shù)。如果鍵值對的列表過大，為了適應(yīng)內(nèi)存的容量，可能會進(jìn)行迭代操作。更新這些從屬于一個(gè)特有鍵的值的集合使它們變?yōu)橐粋€(gè)更小的值的集合是Reduce函數(shù)的任務(wù)。如果用戶希望得到一個(gè)更小的輸出值的集合，他/她通過將這個(gè)輸出作為下一個(gè)輸入，</p><p>　　舉個(gè)簡單的例子，我們可以算一組URL的訪問頻率，如果我們給網(wǎng)頁請求的日志作為輸入到MapReduce計(jì)算。該Map函

10、數(shù)產(chǎn)生<URL; 1>。Reduce函數(shù)總結(jié)的值 相同的URL，并生成一個(gè)<URL;總計(jì)數(shù)>對，從而計(jì)算出該URL訪問頻率。</p><p>　　在圖1中，我們可以看到Map和Reduce任務(wù)被master節(jié)點(diǎn)分配道不同的節(jié)點(diǎn)，而且將輸入劃分給不同的節(jié)點(diǎn)來分配不同的Map作業(yè)，從而產(chǎn)生各自的中間值。master節(jié)點(diǎn)將被每個(gè)節(jié)點(diǎn)告知中間值產(chǎn)生的位置。在獲取這些信息的時(shí)候，master節(jié)點(diǎn)將它

11、傳遞給指定的節(jié)點(diǎn)與reduce任務(wù)終于完成了合并工作，產(chǎn)生輸出 </p><p><b>　　文件。</b></p><p>　　圖1：MapReduce執(zhí)行概要</p><p>　　2.2 Hadoop分布式文件系統(tǒng)</p><p>　　hadoop分布式文件系統(tǒng)是被hadoop使用的文件系統(tǒng)。它與UNIX的文件系統(tǒng)非

12、常類似，并且被開發(fā)來支持的Hadoop在數(shù)據(jù)密集型分布式計(jì)算。在Hadoop實(shí)現(xiàn)一個(gè)集群的情況下， 根據(jù)雅虎，Apache Hadoop項(xiàng)目最大的貢獻(xiàn)者目前的設(shè)計(jì)，每個(gè)集群作為NameNode的一個(gè)節(jié)點(diǎn)，它存儲所有的文件的元數(shù)據(jù)。應(yīng)用程序的數(shù)據(jù)將被存儲在的DataNodes之中。 </p><p>　　如果用戶希望執(zhí)行讀操作，則該請求將被NameNode處理并且它會提供數(shù)據(jù)塊構(gòu)成的位置的文件。客戶端將從最接近的D

13、ataNode進(jìn)行讀取操作。</p><p>　　對于寫操作，NameNode會選擇一組DataNodes（默認(rèn)情況下），負(fù)責(zé)對每個(gè)文件塊的備份而客戶將以流水閑的方式將這些文件塊寫入那些DataNodes節(jié)點(diǎn)中。</p><p>　　在集群中，當(dāng)一個(gè)DataNode啟動(dòng)時(shí)，他將和NameNode進(jìn)行一次握手，這是為了保證數(shù)據(jù)的完整性。在握手的過程中，命名空間的ID和DataNode軟件的版

14、本將會被檢測。只有命名空間的ID相同且DataNode軟件的版本支持的情況下DataNode才會被允許進(jìn)入集群。每個(gè)DataNode都會定期發(fā)送塊報(bào)告給Namenode，來提供關(guān)于塊拷貝的信息，從而幫助NameNode收集每個(gè)塊拷貝文件的信息。這樣，就保持了數(shù)據(jù)的一致性。此外，DataNode每隔3秒鐘就發(fā)送一次心跳（heartbeats），來確認(rèn)現(xiàn)在可用的節(jié)點(diǎn)，同時(shí)文件塊拷貝他持有的信息。如果NameNode在一段時(shí)間內(nèi)，比如說10分

15、鐘，沒有收到來自DataNode的心跳，那么他將認(rèn)為DataNode以及它的塊拷貝是不可用的，并且在集群中選擇那些可用的塊中重建它們的新拷貝。</p><p><b>　　圖2HDFS結(jié)構(gòu)</b></p><p>　　NameNode會為元數(shù)據(jù)分配空間，并且平衡集群中正在使用包含心跳信息的DataNode之間的負(fù)載。從圖2我們可以看出HDFS體系結(jié)構(gòu)的示意圖，以及讀取

16、和寫入操作。</p><p><b>　　3小文件問題</b></p><p>　　讓我們來討論這個(gè)問題對我們之前討論的hadoop的兩大組件，Hadoop分布式文件系統(tǒng)和MapReduce的影響?？蒲械膽?yīng)用環(huán)境中，如氣候?qū)W，天文學(xué)中，含有大量的小文件。</p><p>　　3.1對HDFS的影響</p><p>　　默

17、認(rèn)情況下，HDFS塊大小為64 MB。任何比這個(gè)空間更小的文件都被認(rèn)為是小文件。我們知道，NameNode會負(fù)責(zé)保持集群中DataNode中的每個(gè)DataNode的元數(shù)據(jù)。如果每一個(gè)DataNode都含有數(shù)量不確定的小文件，顯然NameNode將很難去管理大量的元數(shù)據(jù)。此外，這將導(dǎo)致一個(gè)低效率的數(shù)據(jù)訪問模式，因?yàn)樗鼘⑿枰罅康挠蠨ataNode到DataNode的尋道操作，以搜索和檢索請求的文件塊。</p><p&g

18、t;　　3.2對MapReduce的影響</p><p>　　數(shù)量龐大的小文件將消耗MapReduce的額外開銷，由于Map任務(wù)通常在同一時(shí)刻只讀取一塊的輸入數(shù)據(jù)，并且每個(gè)Map任務(wù)將只處理很少的一點(diǎn)數(shù)據(jù)。這樣就會導(dǎo)致大量的Map任務(wù)。</p><p>　　3.3為什么小文件被制作出來？</p><p>　　無論這些文件時(shí)比較大文件的碎片或者他們是自然產(chǎn)生的。一兩個(gè)

19、這兩種情況會在大多數(shù)環(huán)境中使我們面臨小文件問題。</p><p><b>　　圖3：小文件問題</b></p><p>　　3.4小文件問題的特征</p><p>　　這個(gè)問題中的一個(gè)重要的原因是NameNode不得不管理大量的元數(shù)據(jù)在它的內(nèi)存中。另外一個(gè)問題涉及每個(gè)DataNode啟動(dòng)時(shí)掃描它的文件系統(tǒng)來取得它持有的文件中的數(shù)據(jù)被發(fā)送到的Na

20、meNode所需要的塊報(bào)告所經(jīng)歷的時(shí)間。小文件的數(shù)量越大，需要時(shí)間就越長。在集群中，管理員將對目錄用戶配額提供兩種選擇：</p><p>　　每個(gè)目錄下存放最大數(shù)量的文件</p><p>　　每個(gè)目錄下使用最大的文件空間</p><p>　　在圖3中，允許的最大文件數(shù)是7，并且對于允許一個(gè)用戶目錄最大文件空間是7GB。用戶1既沒有超出 的文件最大限制數(shù)，也沒有超出最

21、大的文件空間的限制。所以傳入一個(gè)新的文件請求馬上處理。但對于用戶2，因?yàn)樗呀?jīng)達(dá)到了的文件限制數(shù)，雖然很多文件允許的空間仍然存在，對于一個(gè)新文件傳入的請求不能被處理。但用戶n具有到達(dá)文件空間限制雖然他還沒有超過第一準(zhǔn)則限制文件的最大數(shù)量對于一個(gè)新文件傳入的請求不能被處理。</p><p><b>　　4．存在的解決方案</b></p><p>　　如果較小的文件是一個(gè)

22、較大的文件的一部分，那么這個(gè)問題可以通過寫一個(gè)連接小文件來產(chǎn)生一個(gè)和默認(rèn)塊大小幾乎一樣的大文件的程序來解決。但是，如果這些文件是本身就小，那么他們就需要通過某些方式進(jìn)行分組。對于這方面的一些現(xiàn)有的解決方案如下。</p><p>　　4.1Hadoop歸檔</p><p>　　Hadoop在后來的版本中，引入了歸檔來作為對小文件問題的解決方案。Hadoop的歸檔文件，總是以*.har作為拓展

23、名，包含了元數(shù)據(jù)和數(shù)據(jù)文件。元數(shù)據(jù)將被組織成索引和主索引文件，而數(shù)據(jù)文件將會以part-*文件的方式存儲。這些歸檔文件的名字和位置信息將會被存儲在索引文件中。用于歸檔的文件系統(tǒng)的修改是對用戶不可見的，然而，對系統(tǒng)性能的提升則是用戶顯著能感受到的。此外，該 在HDFS中的文件數(shù)量已減少導(dǎo)致更好的NameNode性能。該解決方案是只在Hadoop版本0.18.0以后的版本中存在，而以前的版本仍然被廣泛使用。如果一個(gè)MapReduce任務(wù)正被

24、超出配額進(jìn)行處理，那么該任務(wù)將會由調(diào)度中心終止，不管任務(wù)是多么地重要，或者多么接近完成。雖然文件歸檔文件的壓縮是不可能用這種方法。讀操作仍可能會很慢，因?yàn)槊總€(gè)文件的訪問需要兩個(gè)索引文件的讀取和一個(gè)數(shù)據(jù)文件讀取。</p><p>　　圖4：hadoop歸檔格式</p><p><b>　　4.2序列化文件</b></p><p>　　在這個(gè)方法中

25、，現(xiàn)有的數(shù)據(jù)被轉(zhuǎn)化為序列化文件。即，那些小文件被放在一個(gè)文件序列中，并且這個(gè)序列可以被流程化處理。序列化文件還允許被壓縮，不像Hadoop歸檔一樣。此外，序列化文件可以被分成更小的塊，而且MapReduce可以以獨(dú)立的方式來操作它們。轉(zhuǎn)換為序列化文件可能需要一些時(shí)間，并這個(gè)方法主要是依賴于java的，即，它不提供一個(gè)跨平臺方式。</p><p><b>　　5建議的解決方案</b></

26、p><p>　　建議的解決方案維持了上一章所列出的現(xiàn)有解決方案的優(yōu)點(diǎn)，并且試圖去避免它們的缺點(diǎn)。雖然Hadoop的歸檔成功分組小文件，讀操作仍然會很慢，因?yàn)樗枰x取兩個(gè)索引文件和一個(gè)最終的數(shù)據(jù)文件。另一方面，序列化文件是有效的數(shù)據(jù)處理方式，但是它對平臺完全依賴。我們提出了一種自動(dòng)分析輸入數(shù)據(jù)塊大小的方法。如果它小于HDFS的默認(rèn)塊大小，它會自動(dòng)降低的數(shù)量減少任務(wù)到一個(gè)最佳數(shù)目。這是基于Hadoop的每一個(gè)Reduc

27、e任務(wù)的輸出，而不管Reduce任務(wù)可能不會產(chǎn)生任何數(shù)據(jù)這一事實(shí)。此外，壓縮是被允許的。建議在一個(gè)獨(dú)立于平臺的實(shí)現(xiàn)方式上用這種方法。在執(zhí)行MapReduce任務(wù)的時(shí)候，這種方法將跟蹤內(nèi)存剩余空間，保證了一個(gè)文件最低的解壓空間是可用的。因?yàn)橐笤谒麄兊脑嘉募?，未壓縮格式。既然歸檔不是用這種方式完成的，那么讀操作可以用正常的方式進(jìn)行，</p><p>　　雖然寫操作將需要所要求的解壓縮的文件中進(jìn)行。與可能會使用超過

28、所需要的時(shí)間的轉(zhuǎn)換成序列化的文件的方法不同，這種方法有效地分析手頭的輸入任務(wù)，決定了塊的大小，并相應(yīng)設(shè)置的reduce任務(wù)的數(shù)目。并且該方法中，提出了被實(shí)現(xiàn)為工具，可以被用于早些的Hadoop版本中，那些版本沒有歸檔這個(gè)工具。在社交網(wǎng)絡(luò)上進(jìn)行的一項(xiàng)研究發(fā)現(xiàn)，許多地方仍在使用Hadoop的原版本， 這意味著，該方法可以幫助他們提高它們所使用的版本的性能。</p><p><b>　　6結(jié)論</b&g

29、t;</p><p>　　Hadoop的在有效地進(jìn)行大量的計(jì)算中的作用是顯而易見的。Hadoop有很大的潛力。這是因?yàn)楠?dú)特的分布式計(jì)算的方法和最終合并的結(jié)果。伴隨著被定制的高效的文件系統(tǒng)保證全部潛力的發(fā)揮。我們已經(jīng)討論了所面臨的Hadoop的一個(gè)缺點(diǎn)，在某些環(huán)境中，那里有大量的小文件降低Hadoop的性能。簡要解釋了兩種現(xiàn)有的解決方案，以及它們各自的優(yōu)點(diǎn)和缺點(diǎn)。最后，我們提出了結(jié)合現(xiàn)有解決方案的優(yōu)點(diǎn)的解決方案。同

30、時(shí)篩選出他們所面對的缺點(diǎn)。提出的解決方案，完全實(shí)施后，預(yù)計(jì)將提高Hadoop在所謂的小文件問題導(dǎo)致性能下降問題中的性能。</p><p><b>　　7未來的工作</b></p><p>　　在我們的工作的下一個(gè)里程碑將是成功提高輸入文件本質(zhì)上是小的情況下的hadoop運(yùn)算效率。這方面的一個(gè)擴(kuò)展可以是一個(gè)能夠有效地管理小文件，無論是本身就是小文件還是其他的情況，這樣能

31、更加方便程序員編程，使他們減少對分布式復(fù)雜性的考慮。</p><p><b>　　參考文獻(xiàn)</b></p><p>　　1. Dean, J., Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters.</p><p>　　In: Proceedings of

32、the 6th Symposium on Operating Systems Design and</p><p>　　Implementation, San Francisco CA (December 2004)</p><p>　　2. Shvachko, K., Kuang, H., Radia, S., Chansler, R.: The Hadoop Distributed F

33、ile</p><p>　　System. In: Proceedings of the 26th IEEE Symposium on Massive Storage Systems</p><p>　　and Technologies (May 2010)</p><p>　　3. Mackey, G., Sehrish, S.,Wang, J.: Improvi

34、ngMetadata Management for Small Files</p><p>　　in HDFS. In: Proceedings of IEEE International Conference on Cluster Computing</p><p>　　and Workshops, pp. 1–4 (August 2009)</p><p>　　

35、4. Satyanarayanan, M.: A Survey of Distributed File Systems, Technical Report</p><p>　　CMU-CS-89- 116, Department of Computer Science, Carnegie Mellon University</p><p><b>　　(1989)</b&g

36、t;</p><p>　　5. Hadoop Archives: Archives Guide (2010),</p><p>　　http://hadoop.apache.org/core/docs/r0.20.0/hadoop_archives.html</p><p>　　6. Hadoop Distributed File System: HDFS Arch

37、itecture (2010),</p><p>　　http://hadoop.apache.org/common/docs/r0.20.1/hdfsdesign.html</p><p>　　7. The major issues identified: The small files problem (2010),</p><p>　　http://www.c

38、loudera.com/blog/2009/02/02/the-small-files-problem</p><p>　　8. Introduction: What is Hadoop (2010),</p><p>　　http://www.cloudera.com/blog/what-is-hadoop</p><p>　　9. Hadoop Distribu

39、ted File System: Welcome to Hadoop Distributed File System!</p><p>　　(2010), http://hadoop.apache.org/hdfs</p><p>　　10. MapReduce: Welcome to Hadoop MapReduce! (2010),</p><p>　　http