文檔目錄

• 什么是小文件
• 小文件產(chǎn)生的原因
• 小文件引起的問題
• 小文件解決方案
• 如何選擇小文件解決方案

什么是小文件

???? 小文件的定義和hadoop中定義的block大小有關(guān)，這里把所有遠(yuǎn)遠(yuǎn)小于hadoop block大小的文件稱為小文件。hadoop block塊大小通常設(shè)置為128MB、256MB，趨向于越來越大。根據(jù)不同的需求，對小文件具體的判定規(guī)則也會(huì)不一樣，這里假設(shè)為hadoop block 大小的75%，即大小小于hadoop block的大小的75%的文件都是小文件。

小文件產(chǎn)生的原因

• 數(shù)據(jù)采集過程中產(chǎn)生的小文件：
  1. 公司對實(shí)時(shí)數(shù)據(jù)的渴望，獲取數(shù)據(jù)的時(shí)間間隔的縮短，導(dǎo)致采集進(jìn)入hadoop的數(shù)據(jù)文件偏小
  2. 延遲的數(shù)據(jù)
• 源系統(tǒng)生成很多個(gè)小文件，這些文件無需修改即可直接復(fù)制到Hadoop中。
• MapReduce job的配置使用超過必要數(shù)量的reducer，每個(gè)reducer輸出自己的文件。同樣，如果數(shù)據(jù)傾斜導(dǎo)致大部分?jǐn)?shù)據(jù)轉(zhuǎn)到一個(gè)reducer，那么剩余的reducer將處理非常少的數(shù)據(jù)并產(chǎn)生小的輸出文件。

小文件引起的問題

????hadoop 需要處理小文件問題的主要原因有：

1. NameNode的內(nèi)存管理

????NameNode的內(nèi)存問題Hadoop中的每個(gè)目錄，文件和塊都表示為NameNode內(nèi)存中的對象。根據(jù)經(jīng)驗(yàn)，每個(gè)對象需要150個(gè)字節(jié)的內(nèi)存。如果你有2000萬個(gè)文件，每個(gè)文件需要1個(gè)塊，你的NameNode需要6GB的內(nèi)存。這顯然是可行的，但隨著系統(tǒng)的擴(kuò)展，最終會(huì)達(dá)到NameNode可以處理的文件（塊）數(shù)量的實(shí)際限制。假設(shè)所有文件都在同一個(gè)文件夾中，十億個(gè)文件需要300GB的內(nèi)存。讓我們考慮300GB NameNode內(nèi)存要求的影響。

• 當(dāng)NameNode重新啟動(dòng)時(shí)，它必須從本地磁盤上的緩存中讀取每個(gè)文件的元數(shù)據(jù)。這意味著從磁盤讀取300GB的數(shù)據(jù) - 可能會(huì)導(dǎo)致啟動(dòng)時(shí)間延遲。
• 在正常操作中，NameNode必須不斷跟蹤并檢查群集中每個(gè)數(shù)據(jù)塊的存儲(chǔ)位置。這是通過監(jiān)聽數(shù)據(jù)節(jié)點(diǎn)來報(bào)告其所有數(shù)據(jù)塊來完成的。數(shù)據(jù)節(jié)點(diǎn)必須報(bào)告的塊越多，它將消耗的網(wǎng)絡(luò)帶寬就越多。即使節(jié)點(diǎn)之間存在高速互連，這種規(guī)模的簡單塊報(bào)告也可能會(huì)造成破壞性。

優(yōu)化很明顯。如果可以減少群集上的小文件數(shù)，則可以減少NameNode內(nèi)存占用，啟動(dòng)時(shí)間和網(wǎng)絡(luò)影響。

2. MapReduce性能

????擁有大量小文件會(huì)降低MapReduce處理的性能，無論是Hive，Pig，Cascading，Pentaho MapReduce還是Java MapReduce。第一個(gè)原因是大量的小文件意味著大量的隨機(jī)磁盤IO。磁盤IO通常是MapReduce性能的最大限制因素之一。一次大的順序讀取總是優(yōu)于通過幾次隨機(jī)讀取讀取相同數(shù)量的數(shù)據(jù)。如果可以將數(shù)據(jù)存儲(chǔ)在更少、更大的塊中，則可以減輕磁盤IO的性能影響。

????性能下降的第二個(gè)原因有點(diǎn)復(fù)雜，需要了解MapReduce如何處理文件和調(diào)度資源。我將在此解釋中使用MapReduce V1術(shù)語，因?yàn)樗仁褂肶arn更容易解釋，但相同的概念適用于Yarn。當(dāng)MapReduce作業(yè)啟動(dòng)時(shí)，它會(huì)為每個(gè)正在處理的數(shù)據(jù)塊分配一個(gè)Mapper任務(wù)。存儲(chǔ)在Hadoop中的每個(gè)文件至少有一個(gè)塊。如果有10,000個(gè)文件，每個(gè)文件包含10 MB的數(shù)據(jù)，則MapReduce作業(yè)將安排10,000個(gè)Map任務(wù)。通常配置Hadoop，以便每個(gè)Mapper任務(wù)在其自己的JVM中運(yùn)行。繼續(xù)我們的例子，你將有10,000個(gè)JVM的開銷！

????Hadoop集群只有這么多資源。在MapReduce v1中，為避免節(jié)點(diǎn)過載，請指定節(jié)點(diǎn)可以處理的最大并發(fā)Mapper數(shù)。通常，并發(fā)Mapper的最大數(shù)量在5到20范圍內(nèi)。因此，要同時(shí)運(yùn)行10,000個(gè)Mapper，必須擁有500到2000個(gè)節(jié)點(diǎn)。大多數(shù)Hadoop集群比這小得多，導(dǎo)致JobTracker在等待slot時(shí)候時(shí)對Mapper任務(wù)進(jìn)行排隊(duì)。如果有一個(gè)總共有100個(gè)slot的20個(gè)節(jié)點(diǎn)群集，那么隊(duì)列將變得非常大并且過程將花費(fèi)很長時(shí)間。不要忘記，這個(gè)工作可能不是競爭群集資源的唯一工作。

????如果擁有800個(gè)128 MB的文件而不是10,000個(gè)10MB文件，那么您只需要800個(gè)Mapper任務(wù)。這將需要少一個(gè)數(shù)量級的JVM維護(hù)時(shí)間，并將導(dǎo)致更好的磁盤IO。即使處理128MB的單個(gè)Map任務(wù)將花費(fèi)比處理10MB的Map任務(wù)更長的時(shí)間，但是當(dāng)處理800個(gè)更大的文件時(shí)，所有處理時(shí)間的總和幾乎總是要快幾個(gè)數(shù)量級。

小文件解決方案

解決NameNode內(nèi)存問題

????Hadoop中每個(gè)塊的元數(shù)據(jù)必須存儲(chǔ)在NameNode的內(nèi)存中。這導(dǎo)致實(shí)際限制Hadoop中可以存儲(chǔ)的對象數(shù)量，并且還會(huì)影響啟動(dòng)時(shí)間和網(wǎng)絡(luò)帶寬。有兩種解決方案，減少Hadoop集群中的對象數(shù)量或以某種方式使NameNode更多地使用內(nèi)存 - 但不會(huì)導(dǎo)致過多的啟動(dòng)時(shí)間。解決此內(nèi)存問題的最常見方法Hadoop Archive (HAR) Files 和 Federated NameNodes。

Hadoop Archive (HAR) Files

????Hadoop Archive Files 通過將許多小文件打包到更大的HAR文件來緩解NameNode的內(nèi)存問題，類似于Linux上的TAR文件。這導(dǎo)致NameNode保留單個(gè)HAR文件的信息，而不是數(shù)十個(gè)或者數(shù)百個(gè)小文件?？梢允褂胔ar://前綴而不是hdfs://來訪問HAR文件中的文件。HAR文件是HDFS中存在的文件創(chuàng)建的。因此，一個(gè)HAR文件可以合并攝取的數(shù)據(jù)和通過普通MapReduce處理創(chuàng)建的數(shù)據(jù)。。HAR文件可以獨(dú)立于用于創(chuàng)建小文件的技術(shù)使用。除了HDFS之外，沒有其他常見的依賴關(guān)系。

???? 雖然HAR文件會(huì)降低由于小文件產(chǎn)生的內(nèi)存占用，但是訪問和處理HAR文件內(nèi)容的效率也有可能降低。HAR文件依然隨機(jī)存儲(chǔ)在磁盤上，訪問一個(gè)HAR內(nèi)的文件要經(jīng)過兩次索引：第一次是在NameNode中找到HAR文件；第二次是在HAR文件中找到目標(biāo)文件。讀取一個(gè)HAR中的文件實(shí)際上可能要比讀取沒有經(jīng)過處理的存儲(chǔ)在hdfs中同樣的文件要慢。MapReduce作業(yè)會(huì)加劇這個(gè)性能問題，因?yàn)樗鼈內(nèi)匀粫?huì)在HAR中為每個(gè)文件啟動(dòng)一個(gè)map任務(wù)。

????最后，需要衡量一下：HAR文件可以解決NameNode內(nèi)存問題，但可能會(huì)降低處理性能。如果集群中的小文件主要是用于存檔，并且很少訪問，那么HAR文件是處理小文件問題的很好的方案。如果小文件是常規(guī)數(shù)據(jù)處理流程中的一部分，則可能需要重新考慮設(shè)計(jì)。

Federated NameNode

????Fedeated NameNode 允許在集群中擁有多個(gè)NameNode,每個(gè)NameNode存儲(chǔ)對象元數(shù)據(jù)的一個(gè)子集。Federated NameNode解決了把對象元數(shù)據(jù)都存儲(chǔ)在一臺機(jī)器上的問題，為存儲(chǔ)元數(shù)據(jù)的內(nèi)存使用提供了更好的擴(kuò)展性。表面看起來，使用這種技術(shù)來解決小文件問題很有吸引力，但是稍加思考你就會(huì)意識到這個(gè)技術(shù)的局限性。

????Federated NameNodes隔離對象的元數(shù)據(jù)-只有一個(gè)NameNode知道某個(gè)特定的對象的元數(shù)據(jù)。這就意味這如果你要獲取一個(gè)文件，你得先確定文件對應(yīng)的對象的元數(shù)據(jù)存放在那個(gè)NameNode。如果集群中包含多個(gè)租戶、多個(gè)單獨(dú)的應(yīng)用，或兩者的組合，那么Federated NameNode是很合適的方案。

????由于Federated NameNode實(shí)際上并不會(huì)改變集群中對象或塊的數(shù)量，因此它不能解決Mapreduce性能問題。相反，F(xiàn)ederated NameNode會(huì)給Hadoop的安裝和管理增加很多必要的復(fù)雜性。當(dāng)Federated NameNode用于解決小文件問題的時(shí)候，更多是因此小文件問題的機(jī)制。

解決MapReduce性能問題

????MapReduce性能問題是由隨機(jī)磁盤IO和啟動(dòng)/管理太多map任務(wù)的組合引起的。解決方案似乎很明顯 - 擁有更少，更大的文件或啟動(dòng)更少的map任務(wù); 然而，這說起來容易做起來難。一些常見的解決方案包括：

• 改變攝取過程/間隔
• 批處理文件合并
• 序列文件
• HBase
• S3DistCp（如果使用Amazon EMR）
• 使用CombineFileInputFormat
• Hive配置設(shè)置
• 使用Hadoop的append功能

改變攝取過程/間隔

????擺脫小文件的最簡單方法就是盡量不生成它們。如果源系統(tǒng)生成數(shù)千個(gè)復(fù)制到Hadoop的小文件，請更改源系統(tǒng)以生成一些大文件，或者在攝取到HDFS時(shí)進(jìn)行連接文件。如果每小時(shí)僅攝取10 MB數(shù)據(jù)，請確定是否每天只能攝取一次。將創(chuàng)建1x240MB文件而不是24x10MB文件。但是，可能無法控制創(chuàng)建文件的源系統(tǒng)或業(yè)務(wù)需求要求以間隔頻率攝取數(shù)據(jù)，以便小文件不可避免。如果小文件確實(shí)是不可避免的，那么應(yīng)該考慮其他解決方案。

批處理文件合并

????當(dāng)小文件不可避免的時(shí)候，文件合并是最常用的解決方案。使用這個(gè)方案，可以定期運(yùn)行一個(gè)簡單的合并MapReduce的作業(yè)來讀取文件夾中的所有小文件，并將它們重寫為更大的文件。如果文件夾中有1000個(gè)文件，MapReduce合并作業(yè)里指定的文件數(shù)為5，則1000個(gè)輸入文件將合并為5個(gè)輸出文件。在一些簡單的HDFS的文件\文件夾操作后，將內(nèi)存占用減少了200：1，并且可能提高對相同數(shù)據(jù)未來MapReduce處理的性能。

????在Hive或Java MapReduce中實(shí)現(xiàn)它同樣容易。這些MapReduce作業(yè)在執(zhí)行時(shí)需要集群資源，通常安排在非工作時(shí)間內(nèi)。但是，它們應(yīng)該足夠頻繁得運(yùn)行，因此小文件的性能影響不會(huì)變得太極端。通常會(huì)在這些作業(yè)內(nèi)置其他邏輯，以便僅合并文件夾內(nèi)的文件，這些文件會(huì)對性能有顯著的影響。合并僅包含三個(gè)文件的文件夾不會(huì)像在包含500個(gè)小文件的文件夾中進(jìn)行合并那樣帶來性能的優(yōu)勢。

????檢查文件夾以確定合并哪些文件夾可以通過多種方式完成。有一個(gè)專門為此任務(wù)設(shè)計(jì)的預(yù)編寫應(yīng)用程序名為File Crush，這是一個(gè)由Edward Capriolo編寫的開源項(xiàng)目。File Crush不受專業(yè)支持，因此不保證它將繼續(xù)與未來版本的Hadoop一起使用(可以參考其實(shí)現(xiàn)思路)。

????批處理文件合并不會(huì)保留原始文件名。如果文件的原始文件名對于處理或者了解數(shù)據(jù)來源非常重要，則批處理合并將不會(huì)起作用。但是，大多數(shù)HDFS設(shè)計(jì)在文件夾級別而不是在每個(gè)文件中嵌入命名語義。采用這種方法會(huì)將文件名依懶性作為一個(gè)問題刪除。

序列文件(Sequence File)

????當(dāng)需要維護(hù)原始文件名的時(shí)候，一種非常常見的方法就是使用序列文件。在此解決方案中，文件名作為密鑰存儲(chǔ)在序列文件中,文件內(nèi)容作為值存儲(chǔ)。下表給出了如何將小文件存儲(chǔ)在序列文件中的示例：

如果有1000個(gè)文件，則序列文件將包含1000個(gè)密鑰，每個(gè)文件一個(gè)。序列文件支持塊壓縮，并且是可拆分，這意味著MapReduce作業(yè)只能為每個(gè)128M的文件啟動(dòng)一個(gè)Map任務(wù)，而不是每個(gè)小文件啟動(dòng)一個(gè)映射任務(wù)。當(dāng)需要維護(hù)輸入文件名，并且同時(shí)大量的小文件時(shí)候，這個(gè)方案非常有效。

????但是，如果一次只需要攝取少量的文件，則序列文件不能正常工作，因?yàn)镠adoop文件是不可變更且無法追加的。三個(gè)10MB產(chǎn)生的30MB的序列文件，根據(jù)我們的定義，還是屬于小文件。另外一個(gè)挑戰(zhàn)就是檢查序列文件的文件名列表需要處理整個(gè)文件。

????此外，Hive與此結(jié)構(gòu)中的序列文件不兼容。Hive將值中所有的數(shù)據(jù)視為單行。使用Hive查詢此數(shù)據(jù)并不容易，因?yàn)槲募恼麄€(gè)內(nèi)容將是Hive中的單行。最后，創(chuàng)建的Hive表將無法訪問序列文件中的密鑰(文件名),只能訪問值(文件內(nèi)容)。可以編寫自定義的Hive Serde 來解決這些挑戰(zhàn)，但這是一個(gè)超過了Hadoop本身功能的高級話題了。

HBase

????如果要生產(chǎn)大量的小文件，將數(shù)據(jù)作為文件存儲(chǔ)在HDFS中可能不是最佳解決方案。此時(shí)，可以考慮使用HBase進(jìn)行存儲(chǔ)。如果使用HBase可以將攝取過程從生成許多小型的文件更改為將單個(gè)記錄寫入HBase表。如果數(shù)據(jù)訪問模式基于明確定義的隨機(jī)訪問查找，則HBase可能是一個(gè)很好的選擇。它在架構(gòu)上針對高速的數(shù)據(jù)插入、大容量、單個(gè)記錄查找和基于流的分析進(jìn)行了調(diào)整。但是，如果訪問模式傾向于完整文件\表掃描，那么HBase可能不是一個(gè)很好的選擇。

????可以創(chuàng)建映射到HBase數(shù)據(jù)的Hive表，但是，這種設(shè)計(jì)中的查詢性能會(huì)有所不同。當(dāng)選擇單行或者一系列行時(shí)候，HBase上的Hive的表現(xiàn)會(huì)讓你眼前一亮，當(dāng)你的查詢傾向全表掃描時(shí)候，則HBase的效率非常低。大多數(shù)就分析，尤其是那些使用分組查詢的查詢，都需要進(jìn)行全表掃描。

????HBase提供了獎(jiǎng)數(shù)據(jù)流式傳輸?shù)紿adoop并使其可實(shí)時(shí)處理的能力。但是，平衡HBase與其他集群進(jìn)程的需求可能具有挑戰(zhàn)性，并且需要高級系統(tǒng)管理。此外，HBase的訪問性能很大程度上取決于數(shù)據(jù)的訪問模式，在選擇HBase處理小文件問題時(shí)候，應(yīng)仔細(xì)考慮這些。

S3DistCp

????此解決方案僅適用于Amazon EMR的用戶。Amazon EMR集群設(shè)計(jì)為短期存儲(chǔ)，并在Amazon S3中保留其數(shù)據(jù)。即使使用Amazon S3，處理大量小文件仍會(huì)導(dǎo)致啟動(dòng)比必要更多的Map任務(wù) - 降低性能。輸入S3DistCp ...

????S3DistCp是Amazon提供的一種實(shí)用程序，用于將數(shù)據(jù)從S3分發(fā)復(fù)制到臨時(shí)HDFS甚至其他S3存儲(chǔ)桶。該實(shí)用程序提供了通過使用groupBy和targetSize選項(xiàng)將文件連接在一起的功能。當(dāng)S3中存儲(chǔ)了數(shù)千個(gè)要使用Amazon EMR處理的小文件時(shí)，這非常有用。S3DistCp通過連接許多小文件并使它們出現(xiàn)在更快，短暫的HDFS存儲(chǔ)中，一舉兩得。據(jù)報(bào)道，使用這種機(jī)制可以提高15倍的性能。

????目的，S3DistCp執(zhí)行與之前提到的批處理文件合并方法相同的任務(wù)。如果使用Amazon EMR，請注意您有一個(gè)預(yù)先構(gòu)建的工具來完成此任務(wù)。

使用CombineFileInputFormat

????CombineFileInputFormat是Hadoop提供的抽象類，它在MapReduce讀取時(shí)合并小文件。合并的文件并不會(huì)保存到磁盤。相反，該過程讀取多個(gè)文件并“動(dòng)態(tài)”合并它們以供單個(gè)Mapper任務(wù)使用?？梢垣@得不為每個(gè)文件啟動(dòng)一個(gè)Map任務(wù)的好處，并且不需要將多個(gè)文件合并到一個(gè)持久的文件作為準(zhǔn)備步驟的一部分。這解決了MapReduce作業(yè)啟動(dòng)太多Map任務(wù)的問題，但是由于作業(yè)仍然需要讀取多個(gè)小文件，隨機(jī)磁盤的IO仍然是一個(gè)問題。此外，大多數(shù)CombineFileInputFormat實(shí)現(xiàn)不考慮數(shù)據(jù)局部性，通常會(huì)從網(wǎng)絡(luò)上的各種數(shù)據(jù)節(jié)點(diǎn)提取數(shù)據(jù)。

????為了實(shí)現(xiàn)這一點(diǎn)，必須在Java中為不同的文件類型擴(kuò)展CombineFileInputFormat。這需要大量的開發(fā)專業(yè)知識來開發(fā)對應(yīng)的自定義輸入格式。但是，一旦編寫完成，可以配置一個(gè)最大分割大小，它將合并文件，直到滿足這個(gè)大小。

????請注意：由于合并的文件并不會(huì)在磁盤中保留，因此CombineFileInputFormat不會(huì)環(huán)境NameNode的內(nèi)存問題。

自定義CombineFileInputFormat

Hive Configuration

????如果有注意到Hive通過“create table as”和“insert overwrite”語句在Hadoop集群中創(chuàng)建小文件，則可以調(diào)整一些Hive的特定的配置來減輕影響。使用時(shí)，這些設(shè)置會(huì)告訴Hive將創(chuàng)建的任何小文件合并到大文件中。但是，這樣是有懲罰的，Hive將在查詢后額外啟動(dòng)一個(gè)MapReduce作業(yè)來完成合并任務(wù)。此外，合并是在Hive向用戶指示查詢已經(jīng)完成處理而不是異步發(fā)生之前完成的。

????應(yīng)該注意，這些設(shè)置僅適用于由Hive創(chuàng)建的文件。例如，如果使用其他工具（如Sqoop）在Hive外部創(chuàng)建文件，則使用hdfs fs -mv命令將其復(fù)制到Hive表中，Hive將不會(huì)合并文件。因此，當(dāng)攝入Hadoop的文件很小時(shí)，此解決方案不起作用。此解決方案僅建議在以Hive為中心的體系結(jié)構(gòu)中，其中insert overwrite和create table as語句中的小性能損失是可接受的。需要使用的配置是：

使用Hadoop的append功能

?????在Hadoop中append功能的故事相當(dāng)崎嶇。作為Hadoop 0.19的一部分，附加在2008年7月添加。但是，在實(shí)施之后（早在2008年10月），發(fā)現(xiàn)了許多問題，并在0.19.1中禁用了追加。但是，為了支持HBase而沒有數(shù)據(jù)丟失的風(fēng)險(xiǎn)，附加功能在0.20.2中被添加回Hadoop。所以，最后，在0.20.2之后，技術(shù)上可以在Hadoop中執(zhí)行追加。

?????append可能是可用的，但Hadoop生態(tài)系統(tǒng)中的主要工具都不支持它：Flume，Sqoop，Pig，Hive，Spark和Java MapReduce。MapReduce強(qiáng)制執(zhí)行一條規(guī)則，即MapReduce作業(yè)的輸出位置在執(zhí)行之前不得存在。由于這個(gè)規(guī)則，MapReduce顯然不可能通過其輸出追加到預(yù)先存在的文件。由于Sqoop，Pig和Hive都使用了MapReduce，因此這些工具也不可能支持追加。Flume不支持追加主要是因?yàn)樗僭O(shè)經(jīng)過一段時(shí)間（無論是秒，字節(jié)，事件數(shù)或不活動(dòng)秒），F(xiàn)lume將關(guān)閉文件而不再打開它。Flume社區(qū)認(rèn)為這足夠，不需要追加支持。

?????如果真的必須在Hadoop中使用append，必須編寫的系統(tǒng)來執(zhí)行攝取并附加到現(xiàn)有文件。此外，如果您的任何群集內(nèi)處理需要追加到現(xiàn)有文件，將無法使用Spark或MapReduce。因此，使用HDFS append功能非常復(fù)雜，只能由技術(shù)最精湛的組織使用。如果沒有重要的工程團(tuán)隊(duì)和支持承諾，建議不要使用此選項(xiàng)。

如何選擇小文件解決方案

選擇使用小文件的最佳解決方案取決于各種問題?？赡苡斜匾鶕?jù)訪問模式和數(shù)據(jù)要求使用這些解決方案的組合。應(yīng)該考慮的問題包括：

• 數(shù)據(jù)流中的哪一點(diǎn)是生成的小文件？是在攝取時(shí)還是通過群集內(nèi)處理創(chuàng)建小文件?

• 生成小文件的工具是什么？更改工具配置可以減少小文件的數(shù)量嗎？

• 組織內(nèi)存在哪些技術(shù)技能？是否有能力維護(hù)輸入格式或編寫自己的攝取引擎？

• 生成小文件的頻率是多少？為了創(chuàng)建大文件，可以多久合并一次小文件？

• 這些小文件需要什么樣的數(shù)據(jù)訪問？是否需要通過Hive訪問文件？

• 可以在集群內(nèi)部運(yùn)行流程以減輕小文件的管理周期類型？

• MapReduce流程可接受的延遲級別是多少？注意：這里的MapReduce流程不單單指的是編寫的MapReduce程序，也可以是在其他計(jì)算引擎中使用到MapReduce的Api