文檔目錄
什么是小文件
???? 小文件的定義和hadoop中定義的block大小有關(guān)馍乙，這里把所有遠(yuǎn)遠(yuǎn)小于hadoop block大小的文件稱為小文件堵幽。hadoop block塊大小通常設(shè)置為128MB、256MB瞳腌，趨向于越來越大。根據(jù)不同的需求镜雨，對(duì)小文件具體的判定規(guī)則也會(huì)不一樣嫂侍，這里假設(shè)為hadoop block 大小的75%，即大小小于hadoop block的大小的75%的文件都是小文件荚坞。
小文件產(chǎn)生的原因
- 數(shù)據(jù)采集過程中產(chǎn)生的小文件：
- 公司對(duì)實(shí)時(shí)數(shù)據(jù)的渴望挑宠，獲取數(shù)據(jù)的時(shí)間間隔的縮短，導(dǎo)致采集進(jìn)入hadoop的數(shù)據(jù)文件偏小
- 延遲的數(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 需要處理小文件問題的主要原因有：
- NameNode的內(nèi)存管理
????NameNode的內(nèi)存問題Hadoop中的每個(gè)目錄南捂，文件和塊都表示為NameNode內(nèi)存中的對(duì)象。根據(jù)經(jīng)驗(yàn)旧找，每個(gè)對(duì)象需要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ò)影響。
- 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)過載柱蟀，請(qǐng)指定節(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í)對(duì)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ù)量級(jí)的JVM維護(hù)時(shí)間游昼，并將導(dǎo)致更好的磁盤IO。即使處理128MB的單個(gè)Map任務(wù)將花費(fèi)比處理10MB的Map任務(wù)更長的時(shí)間尝蠕，但是當(dāng)處理800個(gè)更大的文件時(shí)烘豌，所有處理時(shí)間的總和幾乎總是要快幾個(gè)數(shù)量級(jí)。
小文件解決方案
解決NameNode內(nèi)存問題
????Hadoop中每個(gè)塊的元數(shù)據(jù)必須存儲(chǔ)在NameNode的內(nèi)存中看彼。這導(dǎo)致實(shí)際限制Hadoop中可以存儲(chǔ)的對(duì)象數(shù)量廊佩，并且還會(huì)影響啟動(dòng)時(shí)間和網(wǎng)絡(luò)帶寬。有兩種解決方案靖榕，減少Hadoop集群中的對(duì)象數(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è)小文件簸淀∑亢可以使用har://前綴而不是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ǔ)對(duì)象元數(shù)據(jù)的一個(gè)子集冯键。Federated NameNode解決了把對(duì)象元數(shù)據(jù)都存儲(chǔ)在一臺(tái)機(jī)器上的問題，為存儲(chǔ)元數(shù)據(jù)的內(nèi)存使用提供了更好的擴(kuò)展性庸汗。表面看起來琼了，使用這種技術(shù)來解決小文件問題很有吸引力，但是稍加思考你就會(huì)意識(shí)到這個(gè)技術(shù)的局限性夫晌。
????Federated NameNodes隔離對(duì)象的元數(shù)據(jù)-只有一個(gè)NameNode知道某個(gè)特定的對(duì)象的元數(shù)據(jù)雕薪。這就意味這如果你要獲取一個(gè)文件，你得先確定文件對(duì)應(yīng)的對(duì)象的元數(shù)據(jù)存放在那個(gè)NameNode晓淀。如果集群中包含多個(gè)租戶所袁、多個(gè)單獨(dú)的應(yīng)用，或兩者的組合凶掰，那么Federated NameNode是很合適的方案燥爷。
????由于Federated NameNode實(shí)際上并不會(huì)改變集群中對(duì)象或塊的數(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的小文件橙数，請(qǐng)更改源系統(tǒng)以生成一些大文件，或者在攝取到HDFS時(shí)進(jìn)行連接文件帅戒。如果每小時(shí)僅攝取10 MB數(shù)據(jù)灯帮，請(qǐng)確定是否每天只能攝取一次。將創(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锣吼，并且可能提高對(duì)相同數(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ì)對(duì)性能有顯著的影響疹吃。合并僅包含三個(gè)文件的文件夾不會(huì)像在包含500個(gè)小文件的文件夾中進(jìn)行合并那樣帶來性能的優(yōu)勢(shì)。
????檢查文件夾以確定合并哪些文件夾可以通過多種方式完成西雀。有一個(gè)專門為此任務(wù)設(shè)計(jì)的預(yù)編寫應(yīng)用程序名為File Crush萨驶，這是一個(gè)由Edward Capriolo編寫的開源項(xiàng)目。File Crush不受專業(yè)支持艇肴，因此不保證它將繼續(xù)與未來版本的Hadoop一起使用(可以參考其實(shí)現(xiàn)思路)篡撵。
????批處理文件合并不會(huì)保留原始文件名。如果文件的原始文件名對(duì)于處理或者了解數(shù)據(jù)來源非常重要豆挽，則批處理合并將不會(huì)起作用育谬。但是，大多數(shù)HDFS設(shè)計(jì)在文件夾級(jí)別而不是在每個(gè)文件中嵌入命名語義帮哈。采用這種方法會(huì)將文件名依懶性作為一個(gè)問題刪除膛檀。
序列文件(Sequence File)
????當(dāng)需要維護(hù)原始文件名的時(shí)候，一種非常常見的方法就是使用序列文件。在此解決方案中咖刃，文件名作為密鑰存儲(chǔ)在序列文件中,文件內(nèi)容作為值存儲(chǔ)泳炉。下表給出了如何將小文件存儲(chǔ)在序列文件中的示例：
| key | value | key | value | key | value |
|---|---|---|---|---|---|
| file1.txt | file1 contents | file2.txt | file2 contents | file3.txt | file3 contents |
如果有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本身功能的高級(jí)話題了。
HBase
????如果要生產(chǎn)大量的小文件麻顶，將數(shù)據(jù)作為文件存儲(chǔ)在HDFS中可能不是最佳解決方案赦抖。此時(shí)，可以考慮使用HBase進(jìn)行存儲(chǔ)辅肾。如果使用HBase可以將攝取過程從生成許多小型的文件更改為將單個(gè)記錄寫入HBase表队萤。如果數(shù)據(jù)訪問模式基于明確定義的隨機(jī)訪問查找，則HBase可能是一個(gè)很好的選擇矫钓。它在架構(gòu)上針對(duì)高速的數(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)性田篇，并且需要高級(jí)系統(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合陵，請(qǐng)注意您有一個(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è)知識(shí)來開發(fā)對(duì)應(yīng)的自定義輸入格式赋荆。但是，一旦編寫完成懊昨，可以配置一個(gè)最大分割大小窄潭，它將合并文件，直到滿足這個(gè)大小酵颁。
????請(qǐng)注意：由于合并的文件并不會(huì)在磁盤中保留嫉你，因此CombineFileInputFormat不會(huì)環(huán)境NameNode的內(nèi)存問題。
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語句中的小性能損失是可接受的沐鼠。需要使用的配置是：
| Property | Description | default value |
|---|---|---|
| hive.merge.mapfiles | Merge small files that are produced from the map-only jobs | true |
| hive.merge.maprefiles | Merge small files that are produced from the map-reduce jobs | false |
| hive.merge.size.per.task | When merging small files the target size for the merge files at the end of the job | 256 000000(in bytes) |
| hive.merge.samllfiles.avgsize | when the average size of the ouput file is less than this number,hive will execute an additional MapReduce Job to merge the files based on hive.merge.mapfiles and hive.merge.maprefiles | 16 000000(in bytes) |
使用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流程可接受的延遲級(jí)別是多少桨嫁？注意：這里的MapReduce流程不單單指的是編寫的MapReduce程序，也可以是在其他計(jì)算引擎中使用到MapReduce的Api
