vlambda博客
学习文章列表

HDFS的不同组件之间是如何运行的?

很多人学习大数据估计最开始接触的就是HDFS,那么你知道什么是HDFS,HDFS擅长做哪些事情,HDFS不同组件之间是如何运行的嘛。
HDFS全称为Hadoop Distributed File System,本质上是个分布式文件系统。具有高容错性,适合部署在廉价的机器上,能提供高吞吐量的数据访问,还可以实现write-once-read-many。
HDFS中含有以下组件:
NameNode
JournalNode
zkfc,即FailoverCrontroller
DataNode
整个HDFS的架构大致如下图:

下面来详细介绍下各个组件的功能。
NameNode:其上保留着HDFS的名字空间,对于任何对文件系统元数据产生的操作,NameNode都会使用一种称为EditLog的事务日志记录下来,例如,在HDFS中创建一个文件,NameNode就会在EditLog中插入一条记录来表示,同样地,修改文件的副本系数也将往EditLog中插入一条记录,NameNode在本地操作系统的文件系统中存储这个EditLog,整个文件系统的名字空间,包括数据块到文件的映射,文件的属性等,都存储在一个称为FSImage的文件中,这个文件也放在NameNode所在的本地文件系统上。

NameNode在内存中保存着整个文件系统的名字空间和文件数据块映射(Blockmap)的映像,这个关键的元数据结构设计得很紧凑,因而有4G内存的NameNode足够支撑大量的文件和目录,当NameNode启动时,从硬盘中读取EditLog和FSImage,将所有EditLog中的事务作用在内存中的FSImage上,并将这个新版本的FSImage从内存中保存到本地磁盘上,然后删除旧的EditLog,旧的EditLog的事务都已经作用在FSImage上了,这个过程称之为一个检查点。在当前实现中,检查点只发生在NameNode启动时,在后期将会实现支持周期性的检查点。

NameNode负责维护文件系统命名空间,任何对文件系统名字空间或属性的修改都将被NameNode记录下来,应用程序可以设置HDFS保存的文件的副本数目,文件副本的数目称为文件的副本系数,这个信息也是由NameNode保存的。
文件系统命名空间,即NameSpace,HDFS支持传统的层次型文件组织结构,用户或者应用程序可以创建目录,,然后将文件保存在这些目录里,文件系统名字空间的层次结构和大多数现有的文件系统类似,用户可以创建删除,移动或重命名文件。
在Hadoop1.0时代,NameNode是单点的,SecondaryNameNode辅助NameNode进行检查点操作,在Hadoop2.0时代,NameNode增加了主备高可用模式。
zkfc:zfkc进程只存在于NameNode节点上,他会定期向它监控的NameNode发起健康心跳检测,从而确定当前NameNode是否处于正常工作状态,如果机器宕机或者NameNode服务异常,心跳检测失败,则zkfc就会标记其处于不健康的状态。
JounaNode:作用相当于NFS共享文件系统,Active NameNode执行了修改命名空间的操作后,会定期将执行的操作记录在editLog中,并往JournaNode集群的多个节点里面写editLog,而StandBy NameNode会一直监听JournaNode集群上editLog文件的变化,当发现editLog发生变化后,便从里面读取editLog与当前的命名空间合并,以实现Active NameNode与StandBy NameNode之间命名空间状态的同步。保证了数据一致性。
DataNode:DataNode会同时向主备NameNode发送心跳以及块汇报消息,进一步保证了主备NameNode的元数据的完全同步,当发生故障时,可以实现立马切换。

思考如下问题:

1.NameNode如何防止脑裂?

针对脑裂问题,HDFS提供了三个级别的隔离机制:

1).共享存储隔离:同一时间只允许一个NameNode向JournalNodes写入editLog数据。

2).客户端隔离:同一时间只允许一个NameNode响应客户端请求。

3).DataNode隔离:同一时间只允许一个NameNode向DataNode发出指令,例如删除,复制数据块指令。

2.NameNode如何实现主备切换?

zkfc会定期对监控的NameNode发起健康探测,如果NameNode是健康的,zkfc会在zookeeper中保持一个打开的会话,如果当前节点NameNode是active状态,则该节点的zkfc服务会在zookeeper中占有一个为短暂类型的znode,并会watch锁对应的znode,当该NameNode服务异常后,这个znode会被删除,然后备用的NameNode会得到这个锁,升级为主的NameNode,同时标记状态为active,当异常的NameNode重新启动后,由于zookeeper数据是同步的,发现zookeeper中已经存在znode,便会自动变为znode状态。