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

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

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

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

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

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

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

7、>　　2研究背景</b></p><p>　　2.1MapReduce</p><p>　　程序員們從這個框架中受益良多，因為他們可以避免考慮應(yīng)用程序復雜的分布式運算所帶來的頭痛。這是因為分布式運算可能需要將輸入分片，分配給集群中一組計算節(jié)點，管理系統(tǒng)的故障，節(jié)點間的通信都需要實時考慮。程序員可以方便地運用分布式框架進行分布式編程， 即使他們沒有多少分布式計算經(jīng)驗，而ha

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

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

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

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

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

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

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

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

17、認情況下，HDFS塊大小為64 MB。任何比這個空間更小的文件都被認為是小文件。我們知道，NameNode會負責保持集群中DataNode中的每個DataNode的元數(shù)據(jù)。如果每一個DataNode都含有數(shù)量不確定的小文件，顯然NameNode將很難去管理大量的元數(shù)據(jù)。此外，這將導致一個低效率的數(shù)據(jù)訪問模式，因為它將需要大量的有DataNode到DataNode的尋道操作，以搜索和檢索請求的文件塊。</p><p&g

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

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

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

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

22、較大的文件的一部分，那么這個問題可以通過寫一個連接小文件來產(chǎ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ù)量已減少導致更好的NameNode性能。該解決方案是只在Hadoop版本0.18.0以后的版本中存在，而以前的版本仍然被廣泛使用。如果一個MapReduce任務(wù)正被

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

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

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

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

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

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

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

31、更加方便程序員編程，使他們減少對分布式復雜性的考慮。</p><p><b>　　參考文獻</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