深入学习Hadoop之第一篇——HDFS架构解析

HDFS：Hadoop distributed file system，Hadoop的分布式文件系统；

图1 HDFS架构图

HDFS是一个主从架构(master/slave)，namenode被称作master，datanode被称作slave；

master管理整个HDFS的命名空间namespace以及控制客户端对文件的存取；

一个Hadoop集群中，即一个HDFS中有多个datanode，也就是所谓的slave，他们各自负责所在机器上的文件存储；

一个文件实际上会根据自身大小被切分为1到多个block中，这些blocks被存放在datanode集合中；

namenode执行HDFS的namespace operations（命名空间操作），比如：打开、关闭和重命名文件或目录；namenode还决定了blocks和datanodes之间的映射；namenode上只存放了整个HDFS中的文件的metadata，即HDFS只把用户数据user data的metadata（即文件的描述性信息：文件名，副本数量，存取路径，所在的datanodes，以及所在的blocks等等）存放在namenode所在机器的内存中，所以HDFS存放文件的总量受该内存大小的限制，其真正的文本数据是以block的形式存放在相应的datanode所在机器的本地磁盘中；

datanode负责响应来自HDFS客户端的读写请求；另外根据namenode的指令来进行block的创建、删除和复制；

（注：图1中虽然只画了一个namenode，但在生产环境中，都会是2~3台，具体看下面的HDFS HA with QJM，另外HDFS目前不支持软链接和硬链接）

1.HDFS副本存放策略

(1).replicas==3（副本数量等于3）

这是最常见的情况：
两个在同一个rack但不在同一个datanode,另外一个在其他rack上的datanode
优点：提升了写性能但又不影响读性能和可靠性

(2).replicas>3
第4个以及之后的replicas随机存放在racks上，保持不超过每一个rack对replicas数量的上限，
上限的计算公式：通常是：upper==(replicas - 1) / racks + 2)？？？

(3).在支持" Storage Types and Storage Policies "后
namenode选择datanode来存放replicas首先按照以上(1)、(2)的描述的rack awareness；然后检测候选节点是否符合要求，如果不符合就继续找，如果该路径下的节点再没有符合要求的节点，而又没有达到replicas数量要求时，
namenode将去其他路径下继续寻找，如此寻找下去...

2.副本选择

距离读请求最近的replica响应读请求

3.metadata元数据的存储
EditLog中记录了文件系统中所有元数据信息变化
FsImage中记录了所有namespace信息以及blocks到files之间的映射关系；
（EditLog和FsImage中都存放在namenode的本地OS的磁盘中）

4.文件写入staging（分阶段进行）

图2 staging

一个客户端的创建文件的请求并不直接会送达namenode；实际上，
1.最初HDFS客户端会把数据缓存在本地的buffer中，
2.应用的写操作被透明地重定向到该buffer；当缓存数据量达到128M时(block size)，客户端会联系namenode,
3.namenode把该文件的文件名插入文件系统中并分配一个block给它；
4.namenode将datanode的身份以及目的block响应给客户端；
5.客户端把buffer中的数据传送给指定的datanode；
6.客户端通知namenode文件已关闭
7.namenode把该文件的metadata提交给EditLog和FsImage
8.如果namenode在文件关闭之前失效了，该文件将会丢失

HDFS HA with QJM:(HDFS High Availability Using the Quorum Journal Manager)

图1是没有配置HA（高可用性）的HDFS系统，生产环境中，为了避免namenode单节点失效而造成整个集群瘫痪，都会配置2~3台namenode，甚至更多；当然，同一时刻只有一个namenode处于active状态，其他处于standby状态；前者处理来自HDFS客户端的所有操作，后者或者后者们仅仅作为worker来维持必要的状态，同时再配合zookeeper来监控namenode的状态，一旦处于active的namenode突然失效，zookeeper会立即从所有standby状态中的namenode中选出新的替代节点，并让其处于active状态，这就叫做失效备援Failover；

为了让standby节点（们）能够与active节点的状态信息保持同步，他们之间通过“JournalNodes” (JNs)来取得联系；当active节点上发生任何namespace的变化，active节点同时会保证把这些操作记录在多半以上JNs的操作日志（准确的来说是n/2+1;n代表JournalNode的数目；实践中为了达到可靠性以及容错，该数目必须为大于3的奇数）；standby节点持续监控JNs中操作日志的变化，并据其更新自身的namespace；当然，datanodes节点中有全部namenode的位置信息，并向他们发送block信息以及heartbeats

具体架构见下图：

图3 HDFS高可用架构图

Automatic Failover（自动失效备援）

自动失效备援的配置需要在HDFS的配置中增加两个组件：ZooKeeper quorum, 和ZKFailoverController 进程(缩写为：ZKFC).

HDFS依赖zookeeper来完成以下两件事（该进程名叫做：QuorumPeer）：

(1)失效监测

集群中的每一个namenode节点在zookeeper中维持一个长会话(persistent session)，如果active的namenode所在节点宕机，长会话也会随之过期消失，此时zookeeper会通知其他所有处于standby的namenode节点进行备援(failover)

(2)Active节点的选举

zookeeper提供了一个简单的机制：可以从所有处于standby状态下的namenode节点中唯一地选出一个作为active节点；如果当前的active节点宕机，另外一个standby节点将会在zookeeper上加一个排它锁，表名自己将成为下一个active节点；

ZKFailoverController (ZKFC) 是zookeeper用来监控和管理namenode的状态，因此每一个namenode节点上都必须运行着该进程；

其详细内容如下：

ZKFC is responsible for:

• Health monitoring - the ZKFC pings its local NameNode on a periodic basis with a health-check command. So long as the NameNode responds in a timely fashion with a healthy status, the ZKFC considers the node healthy. If the node has crashed, frozen, or otherwise entered an unhealthy state, the health monitor will mark it as unhealthy.

• ZooKeeper session management - when the local NameNode is healthy, the ZKFC holds a session open in ZooKeeper. If the local NameNode is active, it also holds a special “lock” znode. This lock uses ZooKeeper’s support for “ephemeral” nodes; if the session expires, the lock node will be automatically deleted.

• ZooKeeper-based election - if the local NameNode is healthy, and the ZKFC sees that no other node currently holds the lock znode, it will itself try to acquire the lock. If it succeeds, then it has “won the election”, and is responsible for running a failover to make its local NameNode active. The failover process is similar to the manual failover described above: first, the previous active is fenced if necessary, and then the local NameNode transitions to active state.