这段时间看了公司部门邮件中大家讨论较多的几个关于HDFS的问题，一个是关于Namenode可扩展性的讨论，目前单台服务器作为Namenode，当文件数量规模不断增大时，元数据的规模增长将是一个需要面对的问题，由于Namenode需要将所有元数据Load到内存中，单台Namenode可能会无法管理海量的元数据。另一个是HDFS中SequenceFile存储方式的讨论，利用Block压缩方式可以很好的解决空间压力。
今天刚好看到Yahoo! Hadoop Blog上的一篇文章Hadoop Archive: File Compaction for HDFS，和上面两个问题都有一点联系，文章主要提出了在HDFS中存在海量的小文件时，会给存储带来的一系列问题 。
HDFS中文件是按Block来存储的，默认一个Block的长度是128MB，当HDFS中存在大量小文件（长度小于128MB）时，不仅占用大量存储空间，而且也占用大量的namespace，给Namenode带来了内存压力，Yahoo内部有一个生产集群，统计下来有57,000,000个小于128MB的文件，这些小文件消耗了95%的namespace，占用了30%的存储空间。Namenode的压力一般也常常是因为有海量的小文件存在，如果没有这些小文件存在的话，Namenode内存还没撑爆，估计存储空间就先爆了。。
文中提到了解决方法，是利用Hadoop Archive（HAR），这个特性从Hadoop 0.18.0版本就已经引入了，他可以将众多小文件打包成一个大文件进行存储，并且打包后原来的文件仍然可以通过Map-reduce进行操作，打包后的文件由索引和存储两大部分组成，索引部分记录了原有的目录结构和文件状态。
举个例子，原本获取一个文件通过命令
hadoop fs –get hdfs://namenode/foo/file-1 localdir
如果将foo目录打包成bar.har后，获取file-1的命令就变成
hadoop fs –get har://namenode/bar.har#foo/file-1 localdir
通过以下命令可以将文件打包成HAR。
hadoop archive -archiveName *
但是，目前HAR文件中的源数据只能获取，不能修改，文章中提到实现可以修改将是下一步的工作。
参考文章：
22:59, 2010-08-05Justice /
顶技术贴，虽然看不懂
08:12, 2010-09-15日记门 /
博主勤奋啊，经常看你更新
11:39, 2010-09-27Bill.Bao /
很好的功能，可以解决众多小文件存储的问题。可否预先建立一个归档文件，然后向归档文件中写文件，就像RAR文件那样
12:54, 2010-09-27chocobo /
@Bill.Bao
HDFS目前只支持append的方式修改文件，所以归档文件没有办法再修改，另外更正一下文章里的说法，小文件虽然占用的块是128M的，但实际占用的磁盘空间仍然是文件大小，所以HAR想要缓解的仅仅是Namenode的内存压力。
17:55, 2010-12-08hudson /
HAR 需要依赖m/r