首页 > 代码库 > 关于hadoop处理大量小文件情况的解决方法

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

小文件是指那些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处理大量小文件情况的解决方法