1.5.6 NN与2NN-hadoop[通俗易懂]

1.5.6 NN与2NN-hadoop[通俗易懂]1.5.6 NN与2NN 1.5.6.1 HDFS元数据管理机制 问题1:NameNode如何管理和存储元数据? 计算机中存储数据两种:内存或者是磁盘 元数据存储磁盘:存储磁盘无法面对客户端对元数据信

1.5.6 NN与2NN-hadoop

目录
  • 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与2NN

1.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
    
    <?xml version="1.0"?>
    <fsimage> 
    	<version> 
    		<layoutVersion>-63</layoutVersion> 
    		<onDiskVersion>1</onDiskVersion> 
    		<oivRevision>826afbeae31ca687bc2f8471dc841b66ed2c6704</oivRevision>
        </version> 
    	<NameSection> 
    		<namespaceId>1393381414</namespaceId> 
    		<genstampV1>1000</genstampV1> 
    		<genstampV2>1024</genstampV2> 
    		<genstampV1Limit>0</genstampV1Limit> 
    		<lastAllocatedBlockId>1073741848</lastAllocatedBlockId> 
    		<txid>265</txid> 
    	</NameSection> 
    	<INodeSection> 
    		<inode> 
    			<id>16398</id> 
    			<type>DIRECTORY</type> 
    			<name>history</name> 
    			<mtime>1592376391028</mtime> 
    			<permission>root:supergroup:0777</permission> 
    			<nsquota>-1</nsquota> 
    			<dsquota>-1</dsquota> 
    		</inode>
    		<inode>
    			<id>16399</id> 
    			<type>DIRECTORY</type> 
    			<name>done_intermediate</name> 
    			<mtime>1592375256896</mtime> 
    			<permission>root:supergroup:1777</permission> 
    			<nsquota>-1</nsquota> 
    			<dsquota>-1</dsquota> 
    		</inode>
    		<inode> 
    			<id>16400</id> 
    			<type>DIRECTORY</type> 
    			<name>root</name> 
    			<mtime>1592378079208</mtime>
                <permission>root:supergroup:0777</permission> 
    			<nsquota>-1</nsquota> 
    			<dsquota>-1</dsquota> 
    		</inode>
    		<inode>
    			<id>16413</id> 
    			<type>FILE</type> 
    			<name>job_1592375222804_0001-1592375231176-root-word+count-1592375281926-1-1-SUCCEEDED-default-					1592375261492.jhist</name> 
    			<replication>3</replication> 
    			<mtime>1592375282039</mtime> 
    			<atime>1592375281980</atime> 
    			<preferredBlockSize>134217728</preferredBlockSize> 
    			<permission>root:supergroup:0777</permission> 
    			<blocks> 
    				<block>
    					<id>1073741834</id>
    					<genstamp>1010</genstamp> 
    					<numBytes>33584</numBytes> 
    				</block>
    			</blocks>
    			<storagePolicyId>0</storagePolicyId> 
    		</inode>
    		<inode>
    			<id>16414</id> 
    			<type>FILE</type> 
    			<name>job_1592375222804_0001_conf.xml</name> 
    			<replication>3</replication> 
    			<mtime>1592375282121</mtime> 
    			<atime>1592375282053</atime> 
    			<preferredBlockSize>134217728</preferredBlockSize> 
    			<permission>root:supergroup:0777</permission> 
    			<blocks>
    				<block> 
    					<id>1073741835</id> 
    					<genstamp>1011</genstamp> 
    					<numBytes>196027</numBytes> 
    				</block> 
    			</blocks>
    			<storagePolicyId>0</storagePolicyId> 
    		</inode>
    		<inode>
    			<id>16415</id> 
    			<type>DIRECTORY</type> 
    			<name>done</name>
    			<mtime>1592376776670</mtime> 
    			<permission>root:supergroup:0777</permission> 
    			<nsquota>-1</nsquota> 
    			<dsquota>-1</dsquota> 
    		</inode>
    	
            <inode>
    			<id>16427</id> 
    			<type>DIRECTORY</type> 
    			<name>logs</name> 
    			<mtime>1592378009623</mtime> 
    			<permission>root:root:0770</permission> 
    			<nsquota>-1</nsquota>
                <dsquota>-1</dsquota> 
    		</inode> 
    		<inode> 
    			<id>16428</id> 
    			<type>DIRECTORY</type> 
    			<name>application_1592376944601_0001</name> 
    			<mtime>1592378045481</mtime> 
    			<permission>root:root:0770</permission> 
    			<nsquota>-1</nsquota> 
    			<dsquota>-1</dsquota> 
    		</inode> 
    		<inode> 
    			<id>16430</id> 
    			<type>DIRECTORY</type> 
    			<name>wcoutput</name> 
    			<mtime>1592378037463</mtime> 
    			<permission>root:supergroup:0755</permission> 
    			<nsquota>-1</nsquota> 
    			<dsquota>-1</dsquota> 
    		</inode> 
    		<inode> 
    			<id>16436</id> 
    			<type>FILE</type> 
    			<name>part-r-00000</name> 
    			<replication>3</replication> 
    			<mtime>1592378037264</mtime> 
    			<atime>1592378037074</atime> 
    			<preferredBlockSize>134217728</preferredBlockSize>
                <permission>root:supergroup:0644</permission> 
    			<blocks>
    				<block>
    					<id>1073741842</id> 
    					<genstamp>1018</genstamp> 
    					<numBytes>43</numBytes> 
    				</block>
    			</blocks>
    			<storagePolicyId>0</storagePolicyId> 
    		</inode> 
    		<inode>
    			<id>16445</id> 
    			<type>FILE</type>
    			<name>linux123_39919</name> 
    			<replication>3</replication> 
    			<mtime>1592378045469</mtime> 
    			<atime>1592378045331</atime> 
    			<preferredBlockSize>134217728</preferredBlockSize>
                <permission>root:root:0640</permission> 
    			<blocks>
    				<block>
    					<id>1073741848</id> 
    					<genstamp>1024</genstamp> 
    					<numBytes>56910</numBytes> 
    				</block>
    			</blocks>
    			<storagePolicyId>0</storagePolicyId> 
    		</inode>
    		<inode>
                <id>16446</id> 
    			<type>DIRECTORY</type>
    			<name>0617</name> 
    			<mtime>1592387393490</mtime> 
    			<permission>root:supergroup:0755</permission> 
    			<nsquota>-1</nsquota> 
    			<dsquota>-1</dsquota> 
    		</inode>
    		<inode>
    			<id>16449</id> 
    			<type>FILE</type> 
    			<name>banzhang.txt</name> 
    			<replication>1</replication> 
    			<mtime>1592388309046</mtime> 
    			<atime>1592388309026</atime> 
    			<preferredBlockSize>134217728</preferredBlockSize>
                <permission>root:supergroup:0644</permission> 
    			<storagePolicyId>0</storagePolicyId> 
    		</inode>
    	</INodeSection>
        
    </fsimage>
    

    问题: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 转换后文件输出路径 
  1. 案例实操

    [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
    
    <?xml version="1.0" encoding="UTF-8"?> 
    <EDITS> 
    	<EDITS_VERSION>-63</EDITS_VERSION> 
    	<RECORD> 
    		<OPCODE>OP_START_LOG_SEGMENT</OPCODE>
            <DATA> 
    			<TXID>113</TXID> 
    		</DATA>
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE>
            <DATA> 
    			<TXID>114</TXID> 
    			<SRC>/wcoutput/_SUCCESS</SRC> 
    			<MODE>493</MODE> 
    		</DATA>
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE>
            <DATA> 
    			<TXID>115</TXID> 
    			<SRC>/wcoutput/part-r-00000</SRC>
                <MODE>493</MODE> 
    		</DATA> 
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE>
            <DATA> 
    			<TXID>116</TXID> 
    			<SRC>/wcoutput</SRC> 
    			<MODE>511</MODE> 
    		</DATA> 
    	</RECORD>
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE>
            <DATA> 
    			<TXID>117</TXID> 
    			<SRC>/wcoutput/_SUCCESS</SRC> 
    			<MODE>511</MODE> 
    		</DATA> 
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE>
            <DATA> 
    			<TXID>118</TXID> 
    			<SRC>/wcoutput/part-r-00000</SRC>
                <MODE>511</MODE> 
    		</DATA>
    	</RECORD> 
    	<RECORD>
            <OPCODE>OP_DELETE</OPCODE> 
    		<DATA> 
    			<TXID>119</TXID> 
    			<LENGTH>0</LENGTH> 
    			<PATH>/wcoutput/part-r-00000</PATH> 
    			<TIMESTAMP>1592377324171</TIMESTAMP> 
    			<RPC_CLIENTID></RPC_CLIENTID> 
    			<RPC_CALLID>-2</RPC_CALLID> 
    		</DATA> 
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE> 
    		<DATA> 
    			<TXID>120</TXID> 
    			<SRC>/</SRC> 
    			<MODE>511</MODE> 
    		</DATA> 
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE> 
    		<DATA> 
    			<TXID>121</TXID> 
    			<SRC>/tmp</SRC> 
    			<MODE>511</MODE> 
    		</DATA> 
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE> 
    		<DATA> 
    			<TXID>122</TXID> 
    			<SRC>/tmp/hadoop-yarn</SRC> 
    			<MODE>511</MODE> 
    		</DATA> 
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE> 
    		<DATA> 
    			<TXID>123</TXID> 
    			<SRC>/tmp/hadoop-yarn/staging</SRC> 
    			<MODE>511</MODE> 
    		</DATA> 
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE> 
    		<DATA> 
    			<TXID>124</TXID> 
    			<SRC>/tmp/hadoop-yarn/staging/history</SRC> 
    			<MODE>511</MODE> 
    		</DATA> 
    	</RECORD> 
    	<RECORD> 
    		<OPCODE>OP_SET_PERMISSIONS</OPCODE> 
    		<DATA> 
    			<TXID>125</TXID> 
    			<SRC>/tmp/hadoop-yarn/staging/history/done</SRC>
                <MODE>511</MODE> 
    		</DATA> 
    </RECORD>
    <RECORD> 
    	<OPCODE>OP_SET_PERMISSIONS</OPCODE> 
    	<DATA> 
    		<TXID>126</TXID> 
    		<SRC>/tmp/hadoop-yarn/staging/history/done/2020</SRC>
            <MODE>511</MODE> 
    	</DATA> 
    </RECORD> 
    <RECORD>
    

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

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

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

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

在这里插入图片描述

1.5.6.3 checkpoint周期

[hdfs-default.xml]

<!-- 定时一小时 --> 
<property> 
	<name>dfs.namenode.checkpoint.period</name> 
	<value>3600</value> 
</property> 

<!-- 一分钟检查一次操作次数,当操作次数达到1百万时,SecondaryNameNode执行一次  --> 
<property> 
	<name>dfs.namenode.checkpoint.txns</name> 
	<value>1000000</value> 
	<description>操作动作次数</description> 
</property> 

<property> 
	<name>dfs.namenode.checkpoint.check.period</name> 
	<value>60</value> 
	<description>1分钟检查一次操作次数</description> 
</property>

原文地址:https://www.cnblogs.com/gitBook/archive/2022/12/10/16970748.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/4436.html

(0)
上一篇 2023-06-19
下一篇 2023-06-19

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注