小文件是指那些size比HDFS的block size（默认64m）小的多的文件。任何一个文件，目录和bolck，在HDFS中都会被表示为一个object存储在namenode的内存中，每一个object占用150bytes的内存空间。所以，如果有10milion个文件，每一个文件对应一个block，那么就会消耗namenode 3G来保存这些block的信息。如果规模再大一点，那么将会超出现阶段计算机硬件所能满足的极限。

控制小文件的方法有：

1应用程序自己控制

2archieve

第一种是我采用的方法，感觉使用起来还是比较方便的，我的需求是要对几千个文件进行分布式运算，每个文件占用的空间是2m左右，如果不进行合并的话，那样子运行效率太低了，这里我打算把50个小文件合并为一个大文件放到hdfs系统里面进行运算，代码如下：

final File dir=new File(/home/user/mapinput");
int filename=0;
while(dir.listFiles().length!-0){
    Path path=new Path("/input/+filename);
    FSDataOutputStream create=fs.creat(path);
int num=0;
for(File fileName:dir.listFiles()){
   System.out.println(fileName.getAbsolutePath());
   final FileInputStream fileInputStream=new FileInputStream(fileName.getAbsolutePath());
   final List<String> readLines=IOUtils.readLines(fileInputStream);
  for(String line=readLines)
  {
      create.write(line.getBytes());
      create.write(‘\n‘);
  }
     fileInputStream.close();
    File f=new File("/home/user/mapinput/"+fileName);
   if(fileName.exists())fileName.delete();
   mun++;
   if(num==50){
    break;
  }
}
  filename++;
   create.close();
}  

这样，原本几千个小文件就变成了若干个100m左右的文件了，文件的大小可以通过参数num的数目来决定。

2使用Archive来操作

hadoop不适合小文件的存储，小文件本省就占用了很多的metadata，就会造成namenode越来越大。Hadoop Archives的出现视为了缓解大量小文件消耗namenode内存的问题。

通过HAR来读取一个文件并不会比直接从HDFS中读文件高效，而且实际上可能还会稍微低效一点，因为对每一个HAR文件的访问都需要完成两层读取，index文件的读取和文件本身的读取，而且尽管HAR文件可以被用来作为mapreduce job的input，但是并没有特殊的方法来使maps将HAR文件中打包的文件当做一个HDFS文件处理。

命令：

   hadoop archive -archiveName user.har -p /user output /user/har

查看内容:hadoop fs -lsr har:///user/har/user.har

关于hadoop处理大量小文件情况的解决方法