基于Hadoop云盤系統3：小文件存儲優化
一、概述
首先明確概念，這里的小文件是指小于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格式流數據分析。對于大量小文件的處理，也不失為一種好的選擇。
原文鏈接：http://www.cnblogs.com/hadoopdev/archive/2013/03/08/2950121.html
【編輯推薦】
