HDFS的缺点及改进策略


  HDFS是一个不错的分布式文件系统,它有很多的优点,但也存在有一些缺点。目前而言,它在以下几个方面就效率不佳:
  低延时访问
  HDFS不太适合于那些要求低延时(数十毫秒)访问的应用程序,因为HDFS是设计用于大吞吐量数据的,这是以一定延时为代价的。HDFS是单Master的,所有的对文件的请求都要经过它,当请求多时,肯定会有延时。当前,对于那些有低延时要求的应用程序,HBase是一个更好的选择。现在HBase的版本是0.20,相对于以前的版本,在性能上有了很大的提升,它的口号就是goes real time。
  使用缓存或多master设计可以降低client的数据请求压力,以减少延时。还有就是对HDFS系统内部的修改,这就得权衡大吞吐量与低延时了,HDFS不是万能的银弹。
  大量小文件
   因为Namenode把文件系统的元数据放置在内存中,所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说,每一个文件、 文件夹和Block需要占据150字节左右的空间,所以,如果你有100万个文件,每一个占据一个Block,你就至少需要300MB内存。当前来说,数 百万的文件还是可行的,当扩展到数十亿时,对于当前的硬件水平来说就没法实现了。还有一个问题就 是,因为Map task的数量是由splits来决定的,所以用MR处理大量的小文件时,就会产生过多的Map task,线程管理开销将会增加作业时间。举个例子,处理10000M的文件,若每个split为1M,那就会有10000个Map tasks,会有很大的线程开销;若每个split为100M,则只有100个Map tasks,每个Map task将会有更多的事情做,而线程的管理开销也将减小很多。
  要想让HDFS能处理好小文件,有不少方法:
  1、利用SequenceFile、MapFile、Har等方式归档小文件,这个方法的原理就是把小文件归档起来管理,HBase就是基于此的。对于这种方法,如果想找回原来的小文件内容,那就必须得知道与归档文件的映射关系。
  2、横向扩展,一个Hadoop集群能管理的小文件有限,那就把几个Hadoop集群拖在一个虚拟服务器后面,形成一个大的Hadoop集群。google也是这么干过的。
  3、多Master设计,这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计,还支持Master的Failover,而且Block大小改为1M,有意要调优处理小文件啊。
附带个Alibaba DFS的设计,也是多Master设计,它把Metadata的映射存储和管理分开了,由多个Metadata存储节点和一个查询Master节点组成。
  Alibaba DFS(目前下载不了,加群60534259吧(Hadoop技术交流),群共享里有下 :))
  多用户写,任意文件修改
  目前Hadoop只支持单用户写,不支持并发多用户写。可以使用Append操作在文件的末尾添加数据,但不支持在文件的任意位置进行修改。这些特性可能会在将来的版本中加入,但是这些特性的加入将会降低Hadoop的效率,就拿GFS来说吧,这篇文章里就说了google自己的人都用着Multiple Writers很不爽。
  利用Chubby、ZooKeeper之类的分布式协调服务来解决一致性问题。

posted @ 2010-03-20 00:31  searchDM  阅读(3455)  评论(0编辑  收藏  举报