关闭

hadoop namenode的工作机制 (checkpoint过程、元数据合并一个意思)

320人阅读 评论(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的合并。具体的checkpoint执行过程如下:

这里写图片描述

以下即是checkpoint过程:

secondary namenode请求主Namenode停止使用edits文件,暂时将新的写操作记录到一个新文件中,如edits.new。 
secondary namenode节点从主Namenode节点获取fsimage和edits文件(采用HTTP GET) 
secondary namenode将fsimage文件载入到内存,逐一执行edits文件中的操作,创建新的fsimage文件 
secondary namenode将新的fsimage文件发送回主Namenode(使用HTTP POST) 
主Namenode节点将从secondary namenode节点接收的fsimage文件替换旧的fsimage文件,用步骤1产生的edits.new文件替换旧的edits文件(即改名)。同时更新fstime文件来记录检查点执行的时间

注:从Hadoop0.21.0开始,辅助Namenode已经放弃不用,由checkpoint节点取而代之,功能不变。新版本同时引入一种新的Namenode,名为BackupNode。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:251616次
    • 积分:2985
    • 等级:
    • 排名:第12233名
    • 原创:20篇
    • 转载:268篇
    • 译文:0篇
    • 评论:13条
    最新评论