关闭

hadoop namenode的工作机制

967人阅读 评论(0) 收藏 举报

hadoop 集群中有两种节点,一种是namenode,还有一种是datanode。

其中datanode主要负责数据的存储,namenode主要负责三个功能,分别是(1)管理元数据  (2)维护目录树 (3)响应客户请求

首先介绍下,元数据格式


hdfs在外界看来就是普通的文件系统,可以通过路径进行数据的访问等操作,但在实际过程存储中,却是分布在各个节点上。如上图所示,是一条元数据,/test/a.log 是在hdfs文件系统中的路径,3是这个文件的副本数(副本数可以通过在配置文件中的配置来修改的)。在hdfs中,文件是进行分块存储的,如果文件过大,就要分成多块存储,每个块在文件系统中存储3个副本,以上图为例,就是分成blk_1和blk_2两个块,每个块在实际的节点中有3个副本,比如blk_1的3个副本分别存储在h0,h1,h3中。

现在由此引出一个问题,namenode中的元数据是存储在哪里的?首先,我们做个假设,如果存储在namenode节点的磁盘中,因为经常需要进行随机访问,还有响应客户请求,必然是效率过低。因此,元数据需要存放在内存中。但如果只存在内存中,一旦断点,元数据丢失,整个集群就无法工作了!!!因此必须在磁盘中有备份,在磁盘中的备份就是fsImage,存放在namenode节点对应的磁盘中。这样又会带来新的问题,当在内存中的元数据更新时,如果同时更新fsImage,就会导致效率过低,但如果不更新,就会发生一致性问题,一旦namenode节点断点,就会产生数据丢失。因此,引入edits.log文件(只进行追加操作,效率很高)。每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到edits.log中。这样,一旦namenode节点断电,可以通过fsImage和edits.log的合并,合成元数据。但是,如果长时间添加数据到edit.log中,会导致该文件数据过大,效率降低,而且一旦断电,恢复元数据需要的时间过长。因此,需要定期进行fsImage和edits.log的合并,如果这个操作有namenode节点完成,又会效率过低。因此,引入一个新的节点secondaryNamenode,专门用于fsImage和edits.log的合并。

检查点处理过程的具体步骤如下

1)namenode节点每隔一定时间请求secondaryNamenode合并操作

2)secondaryNamenode请求namenode进行edits.log的滚动,这样新的编辑操作就能够进入新的文件中

3)secondaryNamenode从namenode中下载fsImage和edits.log

4)secondaryNamenode进行fsImage和edits.log的合并,成为fsImage.checkpoint文件

5)namenode下载合并后的fsImage.checkpoin文件

6)将fsImage.checkpoint和edits.new命名为原来的文件名(这样之后fsImage和内存中的元数据只差edits.new)

具体的过程如下图所示


1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1767次
    • 积分:72
    • 等级:
    • 排名:千里之外
    • 原创:5篇
    • 转载:0篇
    • 译文:0篇
    • 评论:0条