在我们使用hadoop对数据进行一些数据处理的时候，我们必须开启HDFS，接下来我为大家讲解一些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节点组成。
以上就是我搜集的资料。不过总结的来说HDFS对于hadoop来说是它的而重要组成的基石，是一个具有很大的容错性的文件系统，对硬件的要求是非常低的，并且她能提供高吞吐量的数据访问，有利于大规模数据集上的应用。
好了，我是曜耀，我们下次见。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
