HDFS如何处理大量的小文件

过多小文件导致的问题?

1、在HDFS中，任何一个文件，目录或者block在NameNode节点的内存中均以一个对象表示（元数据），而这受到NameNode物理内存容量的限制。每个元数据对象约占150byte，所以如果有1千万个小文件，每个文件占用一个block，则NameNode大约需要15G空间。如果存储1亿个文件，则NameNode需要150G空间，这毫无疑问1亿个小文件是不可取的。

2、处理小文件并非Hadoop的设计目标，HDFS的设计目标是流式访问大数据集（TB级别）。因而，在HDFS中存储大量小文件是很低效的。访问大量小文件经常会导致大量的寻找，以及不断的从一个DatanNde跳到另一个DataNode去检索小文件（Reading through small files normally causes lots of seeks and lots of hopping from datanode to datanode to retrieve each small file），这都不是一个很有效的访问模式，严重影响性能。

3、处理大量小文件速度远远小于处理同等大小的大文件的速度。每一个小文件要占用一个slot，而task启动将耗费大量时间甚至大部分时间都耗费在启动task和释放task上。

如何处理这些问题?

1、使用HAR(Hadoop Archives)

为了缓解大量小文件带给namenode内存的压力，Hadoop 0.18.0引入了Hadoop Archives(HAR files)，其本质就是在HDFS之上构建一个分层文件系统。通过执行hadoop archive 命令就可以创建一个HAR文件。在命令行下，用户可使用一个以har://开头的URL就可以访问HAR文件中的小文件。使用HAR files可以减少HDFS中的文件数量。
下图为HAR文件的文件结构，可以看出来访问一个指定的小文件需要访问两层索引文件才能获取小文件在HAR文件中的存储位置，因此，访问一个HAR文件的效率可能会比直接访问HDFS文件要低。对于一个mapreduce任务来说，如果使用HAR文件作为其输入，仍旧是其中每个小文件对应一个map task，效率低下。所以，HAR files最好是用于文件归档。

2、使用sequencefile

SequenceFile核心是以文件名为key，文件内容为value组织小文件。10000个100KB的小文件，可以编写程序将这些文件放到一个SequenceFile文件，然后就以数据流的方式处理这些文件，也可以使用MapReduce进行处理。一个SequenceFile是可分割的，所以MapReduce可将文件切分成块，每一块独立操作。不像HAR，SequenceFile支持压缩。在大多数情况下，以block为单位进行压缩是最好的选择，因为一个block包含多条记录，压缩作用在block之上，比reduce压缩方式（一条一条记录进行压缩）的压缩比高。
把已有的数据转存为SequenceFile比较慢。比起先写小文件，再将小文件写入SequenceFile，一个更好的选择是直接将数据写入一个SequenceFile文件，省去小文件作为中间媒介。

下图为SequenceFile的文件结构。HAR files可以列出所有keys，但是SequenceFile是做不到的，因此，在访问时，只能从文件头顺序访问 。

3、运行时使用CombinerFileInputFormat