Hadoop Archive解决海量小文件存储

 

      单台服务器作为Namenode,当文件数量规模不断增大时,元数据的规模增长将是一个需要面对的问题,由于Namenode需要将所有元数据Load到内存中,单台Namenode可能会无法管理海量的元数据。另一个是HDFS中SequenceFile存储方式的讨论,利用Block压缩方式可以很好的解决空间压力。

 

 

      HDFS中文件是按Block来存储的,默认一个Block的长度是128MB,当HDFS中存在大量小文件(长度小于128MB)时,

不仅占用大量存储空间,而且也占用大量的Namespace,给Namenode带来了内存压力.

 

      Yahoo内部有一个生产集群,统计下来有57,000,000个小于128MB的文件,这些小文件消耗了95%的namespace,

占用了30%的存储空间。Namenode的压力一般也常常是因为有海量的小文件存在,如果没有这些小文件存在的话,

Namenode内存还没撑爆,估计存储空间就先爆了.

 

       Hadoop Archive: File Compaction for HDFS提到了解决方法,是利用Hadoop Archive(HAR),这个特性从Hadoop 0.18.0版本就已经引入了,他可以将众多小文件打包成一个大文件进行存储,并且打包后原来的文件仍然可以通过Map-reduce进行操作,打包后的文件由索引和存储两大部分组成,索引部分记录了原有的目录结构和文件状态。

 

 

 

Har归档:

 

hadoop archive -archiveName test.har -p /A/B/C/D/ E1/F1 E2/F2 /A/G/

命令分析:

目标文件名:-archiveName test.har

源文件的父目录: -p /A/B/C/D/

源文件(夹可以有多个),如这里的E1/F1和E2/F2

所以源文件其实是: 父目录路径 + 相对子路径

最后一个参数就是目录文件夹了 dest path: 所以最终结果的路径是 dest path + achiveName

root@ubuntu:~/workspace# hadoop archive -archiveName files.har testhar/testhar/* testhar
 

      HAR对我们来说,就是把众多文件整合到一起,文件个数减小了,但是文件总体大小并没有减少(无压缩)。归档文件与原文件分别使用了不同的Block,并没有共用Block。当归档文件较多时,性能并不明显(典型的HDFS拷贝)。

 

package cn.edu.xmu.dm.har;


import java.net.URI;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileStatus;
import org.apache.hadoop.fs.HarFileSystem;
import org.apache.hadoop.fs.Path;

/**
 * desc:Har test
 * <code>HarMain</code>
 * @author chenwq ([email protected])
 * @version 1.0 2012/05/18
 *@since Hadoop 0.18
 */
public class HarMain {
	public static void main(String[] args) throws Exception {
		Configuration conf = new Configuration();
		conf.set("fs.default.name", "hdfs://127.0.0.1:9000");
			
		HarFileSystem fs = new HarFileSystem();
		fs.initialize(new URI("har:////user/root/testhar/files.har"), conf);
		FileStatus[] listStatus = fs.listStatus(new Path("user/root/"));
		for (FileStatus fileStatus : listStatus) {
			System.out.println(fileStatus.getPath().toString());
		}
	}
}
 

 

 

你可能感兴趣的:(hadoop)