您的位置:首页 > 大数据 > Hadoop

hadoop(三)hdfs的NameNode和DataNode工作机制

2020-07-01 23:37 375 查看

hadoop系列笔记
hadoop(一)入门、hadoop架构、集群环境搭建.
hadoop(二)HDFS概述、shell操作、客户端操作(各种API操作)以及hdfs读写流程.
hadoop(三)hdfs的NameNode和DataNode工作机制.
hadoop(四)MapReduce入门及序列化实操.
hadoop(五)MapReduce框架原理及工作机制.
hadoop(六)hadoop数据压缩、yarn架构及工作原理、hadoop企业优化.

文章目录

  • 1.2 Fsimage和Edits解析
  • 1.3 chkpoint时间设置
  • 1.4 NameNode故障处理
  • 1.5 集群安全模式
  • 1.6 NameNode多目录配置
  • 2.DataNode(面试开发重点)
  • 2.6 Datanode多目录配置
  • 1. NameNode和SecondaryNameNode(面试开发重点)

    1.1 NN和2NN工作机制

    1.1.1引言

    • 思考:NameNode中的元数据是存储在哪里的?

    • 首先,我们做个假设,如果存储在NameNode节点的磁盘中,因为经常需要进行随机访问,还有响应客户请求,必然是效率过低。因此,元数据需要存放在内存()中。但如果只存在内存中,一旦断电,元数据丢失,整个集群就无法工作了。因此产生在磁盘中备份元数据的Fsimage。

    • 这样又会带来新的问题,当在内存中的元数据更新时,如果同时更新FsImage,就会导致效率过低,但如果不更新,就会发生一致性问题,一旦NameNode节点断电,就会产生数据丢失。因此,引入Edits文件(只进行追加操作,效率很高)。每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到Edits中。这样,一旦NameNode节点断电,可以通过Fsimage和Edits的合并,合成元数据。

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

    • 这里hdfs相应的持久化策略,类比redis,redis中有两种持久化策略,一种是RDB,它是将redis的内存做了一份镜像放在磁盘中,把内存的状态保存下来,它的特点是持久化的过程长,生成慢,安全性略低占空间小,加载比较快;另一种是AOF,它是将内存的操作流程放在AOF文件中,它的特点安全性高,生成的快,但是占空间大。同样,hdfs也有两种持久化策略,一种是Fsimage(类RDB);另一种是edits.log(类AOF),hdfs主要用这个(因为hadoop对安全性要求高),再结合Fsimage使用,具体使用看上面介绍。

    1.1.2 具体工作机制介绍

    • NN和2NN工作机制:
    • 1.第一阶段:NameNode启动
      (1)第一次启动NameNode格式化后,创建Fsimage和Edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
      (2)客户端对元数据进行增删改的请求(请求写给edits)。
      (3)NameNode记录操作日志,更新滚动日志。
      (4)NameNode在内存中对数据进行增删改。
    • 2.第二阶段:Secondary NameNode工作
      (1)Secondary NameNode询问NameNode是否需要CheckPoint(合并)。直接带回NameNode是否检查结果。
      (2)Secondary NameNode请求执行CheckPoint。
      (3)NameNode滚动正在写的Edits日志。
      (4)将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
      (5)Secondary NameNode加载编辑日志和镜像文件到内存,并合并。
      (6)生成新的镜像文件fsimage.chkpoint。
      (7)拷贝fsimage.chkpoint到NameNode。
      (8)NameNode将fsimage.chkpoint重新命名成fsimage。

    1.1.3 NN和2NN工作机制详解:

    • Fsimage:NameNode内存中元数据序列化后形成的文件,说白了,就是内存的“存档”,记录了某一刻的内存状态。
    • Edits:记录客户端更新元数据信息的每一步操作(可通过Edits运算出元数据)。
    • NameNode启动时,先滚动Edits并生成一个空的edits.inprogress,然后加载Edits和Fsimage到内存中,此时NameNode内存就持有最新的元数据信息。Client开始对NameNode发送元数据的增删改的请求,这些请求的操作首先会被记录到edits.inprogress中(查询元数据的操作不会被记录在Edits中,因为查询操作不会更改元数据信息),如果此时NameNode挂掉,重启后会从Edits中读取元数据的信息。然后,NameNode会在内存中执行元数据的增删改的操作。
      由于Edits中记录的操作会越来越多,Edits文件会越来越大,导致NameNode在启动加载Edits时会很慢,所以需要对Edits和Fsimage进行合并(所谓合并,就是将Edits和Fsimage加载到内存中,照着Edits中的操作一步步执行,最终形成新的Fsimage)。SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。
    • SecondaryNameNode首先会询问NameNode是否需要CheckPoint(触发CheckPoint需要满足两个条件中的任意一个,定时时间到和Edits中数据写满了)。直接带回NameNode是否检查结果。SecondaryNameNode执行CheckPoint操作,首先会让NameNode滚动Edits并生成一个空的edits.inprogress,滚动Edits的目的是给Edits打个标记,以后所有新的操作都写入edits.inprogress,其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地,然后将拷贝的Edits和Fsimage加载到内存中进行合并,生成fsimage.chkpoint,然后将fsimage.chkpoint拷贝给NameNode,重命名为Fsimage后替换掉原来的Fsimage。NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可,因为合并过的Edits中的元数据信息已经被记录在Fsimage中。
    • 那么,我们问nn和2nn之间内存状态一致吗?显然不一致,这是差了合并之后nn又执行每一步存在edits.inprogress中,比2nn多了一部分,所以2nn是辅助工作。

    1.2 Fsimage和Edits解析

    • 查看oiv和oev命令
      oiv是查看fsimage
      oev是查看edits
      DataNode和namenode在/opt/module/hadoop-2.7.2/data/tmp/dfs/中
      fsimage和edits在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current/下

    1.2.1oiv查看Fsimage文件

    • 基本语法
      hdfs oiv -p 文件类型 -i 镜像文件 -o 转换后文件输出路径
    • 案例:hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-2.7.2/fsimage.xml

    1.2.2oev查看Edits文件

    • 基本语法
      hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
    • 案例:hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-2.7.2/edits.xml

    1.3 chkpoint时间设置

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

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

    1.4 NameNode故障处理

    • NameNode故障后,可以采用如下两种方法恢复数据:
    • 方法一:将SecondaryNameNode中数据拷贝到NameNode存储数据的目录; 1.kill -9 NameNode进程
    • 2.删除NameNode存储的数据(/opt/module/hadoop-2.7.2/data/tmp/dfs/name)
    • 此时NameNode就出现故障了,解决如下:
    • 3.拷贝SecondaryNameNode中数据到原NameNode存储数据目录
    • scp -r liuyongjun@hadoop104:/opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/* ./name/
    • 4.重新启动NameNode
  • 方法二:使用-importCheckpoint选项启动NameNode守护进程,从而将SecondaryNameNode中数据拷贝到NameNode目录中。
      1.修改hdfs-site.xml
    <property>
    <name>dfs.namenode.checkpoint.period</name>
    <value>120</value>
    </property>
    
    <property>
    <name>dfs.namenode.name.dir</name>
    <value>/opt/module/hadoop-2.7.2/data/tmp/dfs/name</value>
    </property>
    • 2.kill -9 NameNode进程
    • 3.删除NameNode存储的数据(/opt/module/hadoop-2.7.2/data/tmp/dfs/name)
    • 此时NameNode就出现故障了,解决如下:
    • 4.如果SecondaryNameNode不和NameNode在一个主机节点上,需要将SecondaryNameNode存储数据的目录拷贝到NameNode存储数据的平级目录,并删除in_use.lock文件
    • scp -r liuyongjun@hadoop104:/opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary ./
    • rm -rf in_use.lock
    • 5.导入检查点数据(等待一会ctrl+c结束掉)
    • hdfs namenode -importCheckpoint
    • 6.启动NameNode

    1.5 集群安全模式

    1.5.1概述

    • 1.NameNode启动 Namenode启动时,首先将映像文件(fsimage)载入内存,并执行编辑日志(edits)中的各项操作。一旦在内存中成功建立文件系统元数据的映像,则创建一个新的fsimage文件和一个空的编辑日志。此时,namenode开始监听datanode请求。这个过程期间,namenode运行在安全模式,即namenode的文件系统对于客户端来说是只读的。
  • 2.DataNode启动
      系统中的数据块的位置并不是由namenode维护的,而是以块列表的形式存储在datanode中。在系统的正常操作期间,namenode会在内存中保留所有块位置的映射信息。在安全模式下,各个datanode会向namenode发送最新的块列表信息,namenode了解到足够多的块位置信息之后,即可高效运行文件系统。
  • 3.安全模式退出判断
      如果满足“最小复本条件”,namenode会在30秒钟之后就退出安全模式。所谓的最小复本条件指的是在整个文件系统中99.9%的块满足最小复本级别(默认值:dfs.replication.min=1)。在启动一个刚刚格式化的HDFS集群时,因为系统中还没有任何块,所以namenode不会进入安全模式。

    1.5.2基本语法

    • 集群处于安全模式,不能执行重要操作(写操作)。集群启动完成后,自动退出安全模式。
    • (1)bin/hdfs dfsadmin -safemode get (功能描述:查看安全模式状态)
    • (2)bin/hdfs dfsadmin -safemode enter (功能描述:进入安全模式状态)
    • (3)bin/hdfs dfsadmin -safemode leave (功能描述:离开安全模式状态)
    • (4)bin/hdfs dfsadmin -safemode wait (功能描述:等待安全模式状态)

    1.6 NameNode多目录配置

    • 1.NameNode的本地目录可以配置成多个,且每个目录存放内容相同,增加了可靠性
    • 2.具体配置如下: (1)在hdfs-site.xml文件中增加如下内容
    <property>
    <name>dfs.namenode.name.dir</name>
    <value>file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2</value>
    </property>
    • (2)停止集群,删除data和logs中所有数据
    • (3)格式化集群并启动。
    • (4)查看即可

    2.DataNode(面试开发重点)

    2.1 DataNode工作机制

    • 1)一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。
    • 2)DataNode启动后向NameNode注册,通过后,周期性(1小时)的向NameNode上报所有的块信息。
    • 3)心跳是每3秒一次,心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳,则认为该节点不可用。
    • 4)集群运行中可以安全加入和退出一些机器。

    基本概念介绍:
    校验和:保证传输过程中数据的完整性
    周期性的时间可以改
    实际判定节点不可用时,hdfs默认的超时时长为10分钟+30秒

    2.2 数据完整性

    • 思考:如果电脑磁盘里面存储的数据是控制高铁信号灯的红灯信号(1)和绿灯信号(0),但是存储该数据的磁盘坏了,一直显示是绿灯,是否很危险?同理DataNode节点上的数据损坏了,却没有发现,是否也很危险,那么如何解决呢?
    • 如下是DataNode节点保证数据完整性的方法。 1)当DataNode读取Block的时候,它会计算CheckSum。
    • 2)如果计算后的CheckSum,与Block创建时值不一样,说明Block已经损坏。
    • 3)Client读取其他DataNode上的Block。
    • 4)DataNode在其文件创建后周期验证CheckSum,如图

    2.3 掉线时限参数设置

    • 需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒,dfs.heartbeat.interval的单位为秒。所以,举个例子,如果heartbeat.recheck.interval设置为5000(毫秒),dfs.heartbeat.interval设置为3(秒,默认),则总的超时时间为40秒。
    • 在hdfs-site.xml中更改
    <property>
    <name>dfs.namenode.heartbeat.recheck-interval</name>
    <value>5000</value>
    </property>
    <property>
    <name>dfs.heartbeat.interval</name>
    <value>3</value>
    </property>

    2.4 服役新数据节点

    • 随着公司业务的增长,数据量越来越大,原有的数据节点的容量已经不能满足存储数据的需求,需要在原有集群基础上动态添加新的数据节点。
    • 1.环境准备
      (1)在hadoop104主机上再克隆一台hadoop105主机
      (2)修改IP地址和主机名称
      (3)删除原来HDFS文件系统留存的文件(/opt/module/hadoop-2.7.2/data和log)
      rm -rf data/ logs/

      (4)source一下配置文件.

      这就是克隆扩展,很简单,克隆一个主机,看看有没有hadoop和java,没有的话传一下(别忘了环境变量),有就不用了,删除hadoop2.7.2下的data和logs,source一下配置文件,启动datanode即可
    • 2.服役新节点具体步骤
      (1)直接启动DataNode,即可关联到集群

    2.5 退役旧数据节点

    2.5.1 添加白名单

    • 添加到白名单的主机节点,都允许访问NameNode,不在白名单的主机节点,都会被退出。
    • 配置白名单的具体步骤如下: (1)在NameNode的/opt/module/hadoop-2.7.2/etc/hadoop目录下创建whitelist文件,添加如下主机名称(不添加hadoop105)
    • (2)在NameNode的hdfs-site.xml配置文件中增加dfs.hosts属性
    <property>
    <name>dfs.hosts</name>
    <value>/opt/module/hadoop-2.7.2/etc/hadoop/whitelist</value>
    </property>
    • (3)配置文件分发xsync hdfs-site.xml
    • (4)刷新NameNode
      hdfs dfsadmin -refreshNodes
    • (5)在web浏览器上查看
    • hadoop105直接没有了 ,直接被关闭了,所以退役用黑名单

    2.5.2 黑名单退役

    • 在黑名单上面的主机都会被强制退出
    • 1.在NameNode的/opt/module/hadoop-2.7.2/etc/hadoop目录下创建blacklist文件,里面添加要退役的主机
    • 2.在NameNode的hdfs-site.xml配置文件中增加dfs.hosts.exclude属性
    <property>
    <name>dfs.hosts.exclude</name>
    <value>/opt/module/hadoop-2.7.2/etc/hadoop/blacklist</value>
    </property>
    • 3.刷新NameNode

    • 4.检查Web浏览器,退役节点的状态为decommission in progress(退役中),说明数据节点正在复制块到其他节点,如图

    • 5.等待退役节点状态为decommissioned(所有块已经复制完成),停止该节点及节点资源管理器。注意:如果副本数是3,服役的节点小于等于3,是不能退役成功的,需要修改副本数后才能退役,如图

    • 注意:不允许白名单和黑名单中同时出现同一个主机名称

    2.6 Datanode多目录配置

    • 1.DataNode也可以配置成多个目录,每个目录存储的数据不一样。即:数据不是副本
    • 2.具体配置如下
      hdfs-site.xml

      dfs.datanode.data.dir
      file:///hadoop.tmp.dir/dfs/data1,file:///{hadoop.tmp.dir}/dfs/data1,file:///hadoop.tmp.dir/dfs/data1,file:///{hadoop.tmp.dir}/dfs/data2
    • 之后的操作参考namenode多目录配置
  • 内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
    标签: