单台服务器作为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进行操作，打包后的文件由索引和存储两大部分组成，索引部分记录了原有的目录结构和文件状态。


hadoop tez怎么读 hadoop archive_hadoop tez怎么读

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

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

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

    1. package
2.   
3.   
4. import
5. import
6. import
7. import
8. import
9.   
10. /** 
11.  * desc:Har test 
12.  * <code>HarMain</code> 
13.  * @author chenwq (irwenqiang@gmail.com) 
14.  * @version 1.0 2012/05/18 
15.  *@since Hadoop 0.18 
16.  */
17. public class
18. public static void main(String[] args) throws
19. new
20. "fs.default.name", "hdfs://127.0.0.1:9000");   
21.                
22. new
23. new URI("har:user/root/testhar/files.har"), conf);   
24. new Path("user/root/"));   
25. for
26.             System.out.println(fileStatus.getPath().toString());   
27.         }   
28.     }   
29. }