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

转载 2017年01月03日 20:36:10

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。

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

转载:1 http://www.cnblogs.com/hanyuanbo/archive/2012/07/25/2608698.html 2 http://blog.csdn.net/u0...
  • qq394829044
  • qq394829044
  • 2016年11月13日 19:43
  • 527

Hadoop2.0 HA的checkpoint过程

hdfs将文件系统的元数据信息存放在fsimage和一系列的edits文件中。在启动HDFS集群时,系统会先加载fsimage,然后逐个执行所有Edits文件中的每一条操作,来获取完整的文件系统元数据...
  • Amber_amber
  • Amber_amber
  • 2015年07月22日 15:00
  • 3205

D07 hdfs读写机制及其checkpoint机制

一、hdfs写数据流程总结:即向hdfs上传文件 将源文件取128M做成一个block。 具体实现步骤 : ①client:向namenode请求上传文件;       ...
  • u014253445
  • u014253445
  • 2017年08月25日 15:06
  • 96

Hadoop学习——HDFS中的Snapshot和Checkpoint

Snapshot(快照):在数据库或者文件系统中,一个快照表示对当前系统状态的一个备份,当系统发生故障时,可以利用这个快照将系统恢复到产生快照时的样子。 Checkpoint(检查点):因为数据库系统...
  • yangning5850
  • yangning5850
  • 2013年07月09日 22:05
  • 2554

CheckPoint运行原理

一、Checkpoint到底是什么?1,Spark在生产环境下经常会面临Tranformations的RDD非常多(例如一个Job中包含1万个RDD)或者具体Tranformation产生的RDD本身...
  • sundujing
  • sundujing
  • 2016年05月15日 23:37
  • 964

spark源码学习(十二)--- checkpoint机制分析

checkpoint原理: 上篇cacheManager源码分析文章中提到,当RDD使用cache机制从内存中读取数据,如果数据没有读到,会使用checkpoint机制读取数据。此时如果没有ch...
  • englishsname
  • englishsname
  • 2016年03月03日 21:33
  • 711

第一篇---Hadoop1.X版本中HDFS的存储机制理论

HDFS(Hadoop Distributed File System)是Hadoop分布式计算中的数据存储系统,是基于流数据模式访问和处理超大文件的需求而开发的。下面我们首先介绍HDFS中的一些基础...
  • pfnie
  • pfnie
  • 2016年07月21日 15:02
  • 2485

Hadoop源代码分析(完整版)

Hadoop源代码分析(一) 关键字: 分布式云计算 Google的核心竞争技术是它的计算平台。Google的大牛们用了下面5篇文章,介绍了它们的计算设施。 GoogleCluster:...
  • huoyunshen88
  • huoyunshen88
  • 2013年02月25日 23:20
  • 27655

02_flink 流处理

Streaming 高性能 & 低延迟 Flink的流计算实现,仅需要很低的配置,就能实现高吞吐量和低延迟的流数据处理。下面的图表显示了一个分布式流数据的计数任务,的性能和cpu...
  • codemosi
  • codemosi
  • 2015年11月09日 22:23
  • 942

检查点(Checkpoint)的本质

1.检查点(Checkpoint)的本质   许多文档把Checkpint描述得非常复杂,为我们正确理解检查点带来了障碍,结果现在检查点变成了一个非常复杂的问题。实际上,检查点只是一个数据...
  • xiaobluesky
  • xiaobluesky
  • 2015年12月13日 20:08
  • 3745
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:hadoop namenode的工作机制 (checkpoint过程、元数据合并一个意思)
举报原因:
原因补充:

(最多只允许输入30个字)