zoukankan      html  css  js  c++  java
  • Hadoop HDFS NameNode工作机制

     

    Secondary namenode

    首先,我们假设如果存储在Namenode节点的磁盘中,因为经常需要进行随机访问,还有响应客户请求,必然是效率过低。因此,元数据需要存放在内存中。但如果只存在内存中,一旦断点,元数据丢失,整个集群就无法工作了!!!因此必须在磁盘中有备份,在磁盘中的备份就是fsImage,存放在Namenode节点对应的磁盘中。当在内存中的元数据更新时,如果同时更新fsImage镜像文件(文件的随机读写),会导致效率过低,但如果不更新,就会发生一致性问题,一旦Namenode节点断电,就会产生数据丢失。因此,引入操作日志文件edits.log(只进行追加操作,效率很高)。每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到edits.log中。这样,一旦Namenode节点断电,可以通过镜像

    文件fsImage和edits.log的合并,合成元数据。但是,如果长时间添加数据到edit.log中,会导致该文件数据过大,效率降低且一旦断电,恢复元数据需要的时间过长。因此,需要定期进行fsImage和edits.log的合并,如果这个操作由Namenode节点完成,又会效率过低。因此,引入一个新的secondaryNamenode,专门用于fsImage和edits.log的合并。

     

    chkpoint检查时间参数设置

    (1)通常情况下,SecondaryNameNode每隔一小时执行一次。

           [core-site.xml]

    <property>

      <name>dfs.namenode.checkpoint.period</name>

      <value>3600</value>

    </property>

    (2)一分钟检查一次操作次数,当操作次数达到1百万时,SecondaryNameNode执行一次。

    <property>

      <name>dfs.namenode.checkpoint.txns</name>

      <value>1000000</value>

    <description>操作动作次数</description>

    </property>

    <property>

      <name>dfs.namenode.checkpoint.period</name>

      <value>60</value>

    <description> 1分钟检查一次操作次数</description>

    </property>

    元数据目录分析

    在第一次部署好Hadoop集群的时候,我们需要在NameNode(NN)节点上格式化磁盘:

    $HADOOP_HOME/bin/hdfs namenode -format

    格式化完成之后,将会在$dfs.namenode.name.dir/current目录下如下的文件结构

    current/
    |-- VERSION
    |-- edits_*
    |-- fsimage_0000000000008547077
    |-- fsimage_0000000000008547077.md5
    `-- seen_txid

    其中的dfs.name.dir是在hdfs-site.xml文件中配置的,默认值如下:

    <property>
      <name>dfs.name.dir</name>
      <value>file://${hadoop.tmp.dir}/dfs/name</value>
    </property>
     
    hadoop.tmp.dir是在core-site.xml中配置的,默认值如下
    <property>
      <name>hadoop.tmp.dir</name>
      <value>/tmp/hadoop-${user.name}</value>
      <description>A base for other temporary directories.</description>
    </property>

    dfs.namenode.name.dir属性可以配置多个目录,

    如/data1/dfs/name,/data2/dfs/name,/data3/dfs/name,....。各个目录存储的文件结构和内容都完全一样,相当于备份,这样做的好处是当其中一个目录损坏了,也不会影响到Hadoop的元数据,特别是当其中一个目录是NFS(网络文件系统Network File System,NFS)之上,即使你这台机器损坏了,元数据也得到保存。
    下面对$dfs.namenode.name.dir/current/目录下的文件进行解释。
    1、VERSION文件是Java属性文件,内容大致如下:

    #Fri Nov 15 19:47:46 CST 2013
    namespaceID=934548976
    clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196
    cTime=0
    storageType=NAME_NODE
    blockpoolID=BP-893790215-192.168.24.72-1383809616115
    layoutVersion=-47

    其中
      (1)、namespaceID是文件系统的唯一标识符,在文件系统首次格式化之后生成的;
      (2)、storageType说明这个文件存储的是什么进程的数据结构信息(如果是DataNode,storageType=DATA_NODE);
      (3)、cTime表示NameNode存储时间的创建时间,由于我的NameNode没有更新过,所以这里的记录值为0,以后对NameNode升级之后,cTime将会记录更新时间戳;
      (4)、layoutVersion表示HDFS永久性数据结构的版本信息, 只要数据结构变更,版本号也要递减,此时的HDFS也需要升级,否则磁盘仍旧是使用旧版本的数据结构,这会导致新版本的NameNode无法使用;
      (5)、clusterID是系统生成或手动指定的集群ID,在-clusterid选项中可以使用它;如下说明

    a、使用如下命令格式化一个Namenode:

    $HADOOP_HOME/bin/hdfs namenode -format [-clusterId <cluster_id>]

    选择一个唯一的cluster_id,并且这个cluster_id不能与环境中其他集群有冲突。如果没有提供cluster_id,则会自动生成一个唯一的ClusterID。

    b、使用如下命令格式化其他Namenode:

     $HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id>

    c、升级集群至最新版本。在升级过程中需要提供一个ClusterID,例如:

    $HADOOP_PREFIX_HOME/bin/hdfs start namenode --config $HADOOP_CONF_DIR  -upgrade -clusterId <cluster_ID>

    如果没有提供ClusterID,则会自动生成一个ClusterID。

      (6)、blockpoolID:是针对每一个Namespace所对应的blockpool的ID,上面的这个BP-893790215-192.168.24.72-1383809616115就是在我的ns1的namespace下的存储块池的ID,这个ID包括了其对应的NameNode节点的ip地址。
      
    2、$dfs.namenode.name.dir/current/seen_txid非常重要,是存放transactionId的文件,format之后是0,它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候,会按照seen_txid的数字,循序从头跑edits_0000001~到seen_txid的数字。所以当你的hdfs发生异常重启的时候,一定要比对seen_txid内的数字是不是你edits最后的尾数,不然会发生建置namenode时metaData的资料有缺少,导致误删Datanode上多余Block的资讯。

    3、$dfs.namenode.name.dir/current目录下在format的同时也会生成fsimage和edits文件,及其对应的md5校验文件。

    补充:seen_txid

    文件中记录的是edits滚动的序号,每次重启namenode时,namenode就知道要将哪些edits进行加载edits

     

    hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-2.7.2/edits.xml

    hdfs oev -p XML -i edits_0000000000000000001-0000000000000000002 -o /mnt/hgfs/linuxsharefile/edits_test_3.xml

    hdfs oev -p XML -i edits_0000000000000000003-0000000000000000015 -o /mnt/hgfs/linuxsharefile/edits_test_4.xml

    hdfs oev -p XML -i edits_0000000000000000003-0000000000000000016 -o /mnt/hgfs/linuxsharefile/edits_test_11.xml

    hdfs oev -p XML -i edits_inprogress_0000000000000000017 -o /mnt/hgfs/linuxsharefile/edits_inprogress_10.xml

    fsimage_0000000000000000017

    hdfs oiv -p XML -i fsimage_0000000000000000017 -o /mnt/hgfs/linuxsharefile/fsimage_1.xml

    hdfs oiv -p XML -i fsimage_0000000000000000002 -o /mnt/hgfs/linuxsharefile/fsimage_1.xml

    hdfs oiv -p XML -i fsimage_0000000000000000016 -o /mnt/hgfs/linuxsharefile/fsimage_1.xml

    hdfs oiv -p XML -i fsimage_0000000000000000002 -o fsimage_1.xml
    fsimage_0000000000000000002

  • 相关阅读:
    ural(Timus) 1019 Line Painting
    ACMICPC Live Archive 2031 Dance Dance Revolution
    poj 3321 Apple Tree
    其他OJ 树型DP 选课
    poj 3548 Restoring the digits
    ACMICPC Live Archive 3031 Cable TV Network
    递归循环获取指定节点下面的所有子节点
    手动触发asp.net页面验证控件事件
    子级Repeater获取父级Repeater绑定项的值
    没有列名的数据绑定
  • 原文地址:https://www.cnblogs.com/Transkai/p/10473554.html
Copyright © 2011-2022 走看看