一、概述
首先明確概念，這裏的小文件是指小於HDFS系統Block大小的文件（默認64M），如果使用HDFS存儲大量的小文件，將會是一場災難，這取決於HDFS的實現機制和框架結構，每一個存儲在HDFS中的文件、目錄和塊映射爲一個對象存儲在NameNode服務器內存中，通常佔用150個字節。如果有1千萬個文件，就需要消耗大約3G的內存空間。如果是10億個文件呢，簡直不可想象。
這裏需要特別說明的是，每一個小於Block大小的文件，存儲是實際佔用的存儲空間仍然是實際的文件大小，而不是整個block大小。
爲解決小文件的存儲Hadoop自身提供了兩種機制來解決相關的問題，包括HAR和SequeueFile，這兩種方式在某些方面解決了本層面的問題，單仍然存在着各自的不足。
二、Hadoop HAR
Hadoop Archives (HAR files) ，這個特性從Hadoop 0.18.0版本就已經引入了，他可以將衆多小文件打包成一個大文件進行存儲，並且打包後原來的文件仍然可以通過Map-reduce進行操作，打包後的文件由索引和存儲兩大部分組成，索引部分記錄了原有的目錄結構和文件狀態。其原理如下圖所示：
缺點：
1.HAR 方式雖然能夠實現NameNode內存空間的優化，但是他是一個人工干預的過程，同時他既不能夠支持自動刪除原小文件，也不支持追加操作，當有新文件進來以後，需要重新打包。
2.HAR files一旦創建就不能修改，要做增加和修改文件必須重新打包。事實上，這對那些寫後便不能改的文件來說不是問題，因爲它們可以定期成批歸檔，比如每日或每週。
3.HAR files目前還不支持文檔壓縮。
三、SequeuesFile
Sequence file由一系列的二進制key/value組成，如果key爲小文件名，value爲文件內容，則可以將大批小文件合併成一個大文件。Hadoop-0.21.0版本開始中提供了SequenceFile，包括Writer，Reader和SequenceFileSorter類進行寫，讀和排序操作。該方案對於小文件的存取都比較自由，不限制用戶和文件的多少，支持Append追加寫入，支持三級文檔壓縮（不壓縮、文件級、塊級別）。其存儲結構如下圖所示：
private static void writeTest(FileSystem fs, int count, int seed, Path file,
CompressionType compressionType, CompressionCodec codec)
throws IOException {
fs.delete(file, true);
LOG.info("creating " + count + " records with " + compressionType +
" compression");
//指明壓縮方式
SequenceFile.Writer writer =
SequenceFile.createWriter(fs, conf, file,
RandomDatum.class, RandomDatum.class, compressionType, codec);
RandomDatum.Generator generator = new RandomDatum.Generator(seed);
for (int i = 0; i < count; i++) {
generator.next();
//keyh
RandomDatum key = generator.getKey();
//value
RandomDatum value = generator.getValue();
/追加寫入
writer.append(key, value);
}
writer.close();
}缺點：
目前爲止只發現其Java版本API支持，未在其他開發接口中發現相關版本的實現，尤其是LibHDFS和thrift接口中，可能真是C++陣營狂熱支持者的一個悲劇。
四、Hbase
如果你需要處理大量的小文件，並且依賴於特定的訪問模式，可以採用其他的方式，比如Hbase。Hbase以MapFiles存儲文件，並支持Map/Reduce格式流數據分析。對於大量小文件的處理，也不失爲一種好的選擇。