小文件是指那些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