zoukankan      html  css  js  c++  java
  • hadoop namenode的工作机制 (checkpoint过程、元数据合并一个意思)

    转载:1 http://www.cnblogs.com/hanyuanbo/archive/2012/07/25/2608698.html
    2 http://blog.csdn.net/u010846741/article/details/52369527

    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执行过程如下:

    理解这两个概念,对于理解Hadoop是如何管理备份,Secondary Namenode、Checkpoint Namenode和Backup Node如何工作的很重要。

    • fsimage:文件是文件系统元数据的一个永久性检查点,包含文件系统中的所有目录和文件idnode的序列化信息。
    • edits:文件系统的写操作首先把它记录在edit中

    将文件系统个元数据操作分开操作,是为了提升内存的处理效率。如果不分开处理,即所有的写操作均记录在一个文件中,比如,fsimage中,那么每个操作都会对这个文件进行修改,因为这个文件可能会很大,所以每次进行写操作的时候就会很慢,随着fsimage越来越大,速度便会越来越低。

    Hadoop的解决方案是辅助Namenode节点,文件系统的写操作不是直接被修改到fsimage中,二是edits中,辅助Namenode节点负责将两者在自己的内存中整合然后进行相应的替换操作,这样会频繁的对edits进行修改而不是fsimage,而edits文件的大小是可以接受的,而且大小也不会不断增加。具体的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。

  • 相关阅读:
    LeetCode 121. Best Time to Buy and Sell Stock
    LeetCode 221. Maximal Square
    LeetCode 152. Maximum Product Subarray
    LeetCode 53. Maximum Subarray
    LeetCode 91. Decode Ways
    LeetCode 64. Minimum Path Sum
    LeetCode 264. Ugly Number II
    LeetCode 263. Ugly Number
    LeetCode 50. Pow(x, n)
    LeetCode 279. Perfect Squares
  • 原文地址:https://www.cnblogs.com/pengpenghuhu/p/13753531.html
Copyright © 2011-2022 走看看