小文件指的是那些size比HDFS的block size(默認64M)小的多的文件。如果在HDFS中存儲小文件，那么在HDFS中肯定會含有許許多多這樣的小文件(不然就不會用hadoop了)。而HDFS的問題在于無法很有效的處理大量小文件。

任何一個文件，目錄和block，在HDFS中都會被表示為一個object存儲在namenode的內存中，沒一個object占用150 bytes的內存空間。所以，如果有10million個文件，沒一個文件對應一個block，那么就將要消耗namenode 3G的內存來保存這些block的信息。如果規模再大一些，那么將會超出現階段計算機硬件所能滿足的極限。

不僅如此，HDFS并不是為了有效的處理大量小文件而存在的。它主要是為了流式的訪問大文件而設計的。對小文件的讀取通常會造成大量從datanode到datanode的seeks和hopping來retrieve文件，而這樣是非常的低效的一種訪問方式。

大量小文件在mapreduce中的問題

Map tasks通常是每次處理一個block的input(默認使用FileInputFormat)。如果文件非常的小，并且擁有大量的這種小文件，那么每一個map task都僅僅處理了非常小的input數據，并且會產生大量的map tasks，每一個map task都會消耗一定量的bookkeeping的資源。比較一個1GB的文件，默認block size為64M，和1Gb的文件，沒一個文件100KB，那么后者沒一個小文件使用一個map task，那么job的時間將會十倍甚至百倍慢于前者。

hadoop中有一些特性可以用來減輕這種問題：可以在一個JVM中允許task reuse，以支持在一個JVM中運行多個map task，以此來減少一些JVM的啟動消耗(通過設置mapred.job.reuse.jvm.num.tasks屬性，默認為1，－1為無限制)。另一種方法為使用MultiFileInputSplit，它可以使得一個map中能夠處理多個split。

為什么會產生大量的小文件？

至少有兩種情況下會產生大量的小文件

1.這些小文件都是一個大的邏輯文件的pieces。由于HDFS僅僅在不久前才剛剛支持對文件的append，因此以前用來向unbounde files(例如log文件)添加內容的方式都是通過將這些數據用許多chunks的方式寫入HDFS中。

2.文件本身就是很小。例如許許多多的小圖片文件。每一個圖片都是一個獨立的文件。并且沒有一種很有效的方法來將這些文件合并為一個大的文件

這兩種情況需要有不同的解決方式。對于***種情況，文件是由許許多多的records組成的，那么可以通過件邪行的調用HDFS的sync()方法(和 append方法結合使用)來解決。或者，可以通過些一個程序來專門合并這些小文件(see Nathan Marz’s post about a tool called the Consolidator which does exactly this)。

對于第二種情況，就需要某種形式的容器來通過某種方式來group這些file。hadoop提供了一些選擇：

HAR files

Hadoop Archives (HAR files)是在0.18.0版本中引入的，它的出現就是為了緩解大量小文件消耗namenode內存的問題。HAR文件是通過在HDFS上構建一個層次化的文件系統來工作。一個HAR文件是通過hadoop的archive命令來創建，而這個命令實 際上也是運行了一個MapReduce任務來將小文件打包成HAR。對于client端來說，使用HAR文件沒有任何影響。所有的原始文件都 visible && accessible（using har://URL）。但在HDFS端它內部的文件數減少了。

通過HAR來讀取一個文件并不會比直接從HDFS中讀取文件高效，而且實際上可能還會稍微低效一點，因為對每一個HAR文件的訪問都需要完成兩層 index文件的讀取和文件本身數據的讀取(見上圖)。并且盡管HAR文件可以被用來作為MapReduce job的input，但是并沒有特殊的方法來使maps將HAR文件中打包的文件當作一個HDFS文件處理。可以考慮通過創建一種input format，利用HAR文件的優勢來提高MapReduce的效率，但是目前還沒有人作這種input format。需要注意的是：MultiFileInputSplit，即使在HADOOP-4565的改進(choose files in a split that are node local)，但始終還是需要seek per small file。

Sequence Files

通常對于“the small files problem”的回應會是：使用SequenceFile。這種方法是說，使用filename作為key，并且file contents作為value。實踐中這種方式非常管用。回到10000個100KB的文件，可以寫一個程序來將這些小文件寫入到一個單獨的 SequenceFile中去，然后就可以在一個streaming fashion(directly or using mapreduce)中來使用這個sequenceFile。不僅如此，SequenceFiles也是splittable的，所以mapreduce 可以break them into chunks，并且分別的被獨立的處理。和HAR不同的是，這種方式還支持壓縮。block的壓縮在許多情況下都是***的選擇，因為它將多個 records壓縮到一起，而不是一個record一個壓縮。

將已有的許多小文件轉換成一個SequenceFiles可能會比較慢。但是，完全有可能通過并行的方式來創建一個一系列的SequenceFiles。 (Stuart Sierra has written a very useful post about converting a tar file into a SequenceFile—tools like this are very useful)。更進一步，如果有可能***設計自己的數據pipeline來將數據直接寫入一個SequenceFile。