1.5.6 NN与2NN-hadoop-最全最完整的保姆级的java大数据学习资料

目录

• 1.5.6 NN与2NN
  • 1.5.6.1 HDFS元数据管理机制
  • 1.5.6.2 Fsimage与Edits文件解析
    • 1.5.6.2.1 Fsimage文件内容
    • 1.5.6.2.2 Edits文件内容
  • 1.5.6.3 checkpoint周期

1.5.6 NN与2NN1.5.6.1 HDFS元数据管理机制

问题1：NameNode如何管理和存储元数据？

计算机中存储数据两种：内存或者是磁盘

元数据存储磁盘：存储磁盘无法面对客户端对元数据信息的任意的快速低延迟的响应，但是安全性高

元数据存储内存：元数据存放内存，可以高效的查询以及快速响应客户端的查询请求，数据保存在内 存，如果断点，内存中的数据全部丢失。
解决方案：内存+磁盘；NameNode内存+FsImage的文件（磁盘）
新问题：磁盘和内存中元数据如何划分？
两个数据一模一样，还是两个数据合并到一起才是一份完整的数据呢？
一模一样：client如果对元数据进行增删改操作，需要保证两个数据的一致性。FsImage文件操作起来 效率也不高。
两个合并=完整数据：NameNode引入了一个edits文件（日志文件：只能追加写入）edits文件记录的 是client的增删改操作，
不再选择让NameNode把数据dump出来形成FsImage文件（这种操作是比较消耗资源）。

元数据管理流程图

• 第一阶段：NameNode启动

  • 第一次启动NameNode格式化后，创建Fsimage和Edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。

  • 客户端对元数据进行增删改的请求。

  • NameNode记录操作日志，更新滚动日志。

  • NameNode在内存中对数据进行增删改。

• 第二阶段：Secondary NameNode工作

  • Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否执行检查点操作结果。
  • Secondary NameNode请求执行CheckPoint。
  • NameNode滚动正在写的Edits日志。
  • 将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
  • Secondary NameNode加载编辑日志和镜像文件到内存，并合并。
  • 生成新的镜像文件fsimage.chkpoint。
  • 拷贝fsimage.chkpoint到NameNode。
  • NameNode将fsimage.chkpoint重新命名成fsimage。

1.5.6.2 Fsimage与Edits文件解析

NameNode在执行格式化之后，会在/opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current目录下产生如下文件

• Fsimage文件：是namenode中关于元数据的镜像，一般称为检查点，这里包含了HDFS文件系统所有目录以及文件相关信息（Block数量，副本数量，权限等信息）
• Edits文件 ：存储了客户端对HDFS文件系统所有的更新操作记录，Client对HDFS文件系统所有的更新操作都会被记录到Edits文件中（不包括查询操作）
• seen_txid：该文件是保存了一个数字，数字对应着最后一个Edits文件名的数字
• VERSION：该文件记录namenode的一些版本号信息，比如：CusterId,namespaceID等

1.5.6.2.1 Fsimage文件内容

官方地址https://hadoop.apache.org/docs/r2.9.2/hadoop-project-dist/hadoop-hdfs/HdfsImageViewer.html

1. 查看oiv和oev命令

   [root@linux121 current]$ hdfs oiv     Offline Image Viewer  View a Hadoop fsimage INPUTFILE using the specified PROCESSOR,saving the results in OUTPUTFILE.oev     Offline edits viewer  Parse a Hadoop edits log file INPUT_FILE and save results in OUTPUT_FILE

2. 基本语法

   hdfs oiv -p 文件类型(xml) -i 镜像文件 -o 转换后文件输出路径

3. 案例实操

   [root@linux121 current]$ cd /opt/lagou/servers/hadoop-2.9.2/data/tmp/dfs/name/current [root@linux121 current]$ hdfs oiv -p XML -i fsimage_0000000000000000265 -o /opt/lagou/servers/fsimage.xml [root@linux121 current]$ cat /opt/lagou/servers/fsimage.xml

     -63 1 826afbeae31ca687bc2f8471dc841b66ed2c6704      1393381414 1000 1024 0 1073741848 265    16398 DIRECTORY history 1592376391028 root:supergroup:0777 -1 -1 16399 DIRECTORY done_intermediate 1592375256896 root:supergroup:1777 -1 -1  16400 DIRECTORY root 1592378079208            root:supergroup:0777 -1 -1 16413 FILE job_1592375222804_0001-1592375231176-root-word+count-1592375281926-1-1-SUCCEEDED-default-1592375261492.jhist 3 1592375282039 1592375281980 134217728 root:supergroup:0777  10737418341010 33584 0 16414 FILE job_1592375222804_0001_conf.xml 3 1592375282121 1592375282053 134217728 root:supergroup:0777  1073741835 1011 196027  0 16415 DIRECTORY done1592376776670 root:supergroup:0777 -1 -1         16427 DIRECTORY logs 1592378009623 root:root:0770 -1            -1   16428 DIRECTORY application_1592376944601_0001 1592378045481 root:root:0770 -1 -1   16430 DIRECTORY wcoutput 1592378037463 root:supergroup:0755 -1 -1   16436 FILE part-r-00000 3 1592378037264 1592378037074 134217728            root:supergroup:0644 1073741842 1018 43 0  16445 FILElinux123_39919 3 1592378045469 1592378045331 134217728            root:root:0640 1073741848 1024 56910 0             16446 DIRECTORY0617 1592387393490 root:supergroup:0755 -1 -1 16449 FILE banzhang.txt 1 1592388309046 1592388309026 134217728            root:supergroup:0644 0     

   问题：Fsimage中为什么没有记录块所对应DataNode？

在内存元数据中是有记录块所对应的dn信息，但是fsimage中就剔除了这个信息；HDFS集群在启动的 时候会加载image以及edits文件，block对应的dn信息

都没有记录，集群启动时会有一个安全模式 （safemode）,安全模式就是为了让dn汇报自己当前所持有的block信息给nn来补全元数据。后续每隔一段时间dn

都要汇报自己持有的block信息。

1.5.6.2.2 Edits文件内容

1. 基本语法

hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径 

2. 案例实操

   [root@linux121 current]$ hdfs oev -p XML -i edits_0000000000000000266- 0000000000000000267 -o /opt/lagou/servers/hadoop-2.9.2/edits.xml [root@linux121 current]$ cat /opt/lagou/servers/hadoop-2.9.2/edits.xml

     -63  OP_START_LOG_SEGMENT         113   OP_SET_PERMISSIONS         114 /wcoutput/_SUCCESS 493   OP_SET_PERMISSIONS         115 /wcoutput/part-r-00000            493    OP_SET_PERMISSIONS         116 /wcoutput 511   OP_SET_PERMISSIONS         117 /wcoutput/_SUCCESS 511    OP_SET_PERMISSIONS         118 /wcoutput/part-r-00000            511          OP_DELETE  119 0 /wcoutput/part-r-00000 1592377324171  -2    OP_SET_PERMISSIONS  120 / 511    OP_SET_PERMISSIONS  121 /tmp 511    OP_SET_PERMISSIONS  122 /tmp/hadoop-yarn 511    OP_SET_PERMISSIONS  123 /tmp/hadoop-yarn/staging 511    OP_SET_PERMISSIONS  124 /tmp/hadoop-yarn/staging/history 511    OP_SET_PERMISSIONS  125 /tmp/hadoop-yarn/staging/history/done            511   OP_SET_PERMISSIONS  126 /tmp/hadoop-yarn/staging/history/done/2020        511   

   备注：Edits中只记录了更新相关的操作，查询或者下载文件并不会记录在内！！

   问题：NameNode启动时如何确定加载哪些Edits文件呢？

   nn启动时需要加载fsimage文件以及那些没有被2nn进行合并的edits文件，nn如何判断哪些edits已经被合并了呢？

   可以通过fsimage文件自身的编号来确定哪些已经被合并。

1.5.6.3 checkpoint周期

[hdfs-default.xml]

  dfs.namenode.checkpoint.period 3600    dfs.namenode.checkpoint.txns 1000000 操作动作次数   dfs.namenode.checkpoint.check.period 60 1分钟检查一次操作次数