HDFS概述

一、HDFS是什么？

         HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是Hadoop主要应用的一个分布式文件系统。“主要”表示Hadoop还有其他分布式文件系统，“分布式文件系统”说明HDFS的核心是一个文件系统，认识并把握住核心才能很好的理解HDFS。

        文件系统的目的是用来管理怎样存储和读取文件的，讲到管理，就不得不了解其组织结构和运行规则。HDFS的组织结构是主从结构（master-slaves），运行规则指的是在主从结构中，master负责做什么、slaves负责做什么等。（wikipedia的解释：The structure and logic rules used to manage the groups of information and their names is called a "file system".）

 

1、基础介绍

      数据块（Block）
      文件都是以块的形式存储在磁盘上，块的大小就是系统读/写可操作的最小文件大小，一个磁盘的Block通常是512B。HDFS的块是个抽象的概念，默认大小是64MB。把Block设置得这么大，是因为HDFS上的文件普遍都是大文件，如果Block很小，那一个文件就要存放在很多Block上，而这些位置信息都要被NameNode所记录，一来浪费NameNode的存储空间，二来检索一个文件的时候开销也比较高。当一个文件的长度小于一个Blocksize时，它会单独占用一个Block，但它占用的磁盘空间仍然是其真实的长度。

      NameNode和DataNode
      NameNode（Master）管理集群中的执行调度，管理文件系统的命名空间，维护整个文件系统的文件目录树及这些文件的索引目录，DataNode（Slaves）是具体任务的执行节点。从NameNode中你可以获得每个文件的每个块所在的DataNode，需要注意的是，这些信息不是永久保存的，NameNode会在每次系统启动时动态地重建这些信息。DataNode是真正存储数据的地方。一般情况下一个Block会存放在多个不同的DataNode上，以提高容错性。（SecondaryNameNode并不是NameNode出现问题后的备用节点，其主要功能是周期性地将NameNode的命名空间镜像文件namespace image和修改日志edit log合并，以防日志文件过大）

 

2、体系架构
      HDFS采用Master-Slave架构对文件系统进行管理，一个集群由一个NameNode和一定数目的DataNode组成。客户端联系NameNode以获取文件的元数据，而真正的文件I/O操作是直接和DataNode进行交互的。

写文件

Client向NameNode发起文件写入的请求。NameNode根据文件大小和文件块配置情况，返回给Client它所管理部分DataNode的信息。Client将文件划分为多个Block，根据DataNode的地址信息，按顺序写入到每一个DataNode块中。

读文件

Client向NameNode发起文件读取的请求。NameNode返回文件存储的DataNode的信息。Client读取文件信息。

 

二、HDFS能做什么？

1、优点

      A：处理超大文件
存储并处理超大文件，上G、T甚至P的超大文件。

      B：流式的访问数据
HDFS的设计建立在更多地响应"一次写入、多次读写"任务的假设上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

      C：搭建在普通商业机群上
Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机器也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性、安全性及高可用性。

 

2、缺点

      A：低延时访问

HDFS不适合于那些要求低延时（数十毫秒）访问的应用程序，因为HDFS是设计用于处理大吞吐量数据的，这是以一定延时为代价的。HDFS是单Master的，所有的对文件的请求都要经过它，当请求多时，肯定会有延时。当前，对于那些有低延时要求的应用程序，HBase是一个更好的选择，它的口号就是goes real time。
使用缓存或多master设计可以降低client的数据请求压力，以减少延时。还有就是对HDFS系统内部的修改，这就得权衡大吞吐量与低延时了，HDFS不是万能的银弹。

       B：大量小文件
因为NameNode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由NameNode的内存大小来决定的。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。
      要想让HDFS能处理好小文件，有不少方法：
      ①.利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。 对于这种方法，如果想找回原来的小文件内容，那就必须得知道与归档文件的映射关系。
      ②.横向扩展，一个Hadoop集群能管理的小文件有限，那就把几个Hadoop集群拖在一个虚拟服务器后面，形成一个大的Hadoop集群。google也是这么干过的。
      ③.多Master设计，这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计，还支持Master的Failover，而且Block大小改为1M，有意要调优处理小文件啊。
附带个Alibaba DFS的设计，也是多Master设计，它把Metadata的映射存储和管理分开了，由多个Metadata存储节点和一个查询Master节点组成。

       C：多用户写，任意文件修改
目前Hadoop只支持单用户写，不支持并发多用户写。可以使用Append操作在文件的末尾添加数据，但不支持在文件的任意位置进行修改。这些特性可能会在将来的版本中加入，但是这些特性的加入将会降低Hadoop的效率，就拿GFS来说吧，这篇文章里就说了google自己的人都用着Multiple Writers很不爽。
利用Chubby、ZooKeeper之类的分布式协调服务来解决一致性问题。

 

 

 

参考书目：《Hadoop实战》《Hadoop权威指南》《Hadoop技术内幕》