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

相关推荐

  • python越来越火_python一点都不简单

    python越来越火_python一点都不简单学一门语言,可能大部分人还是跟我一样,初衷还是想拿一份不错的收入,从事个朝阳行业。普通python工资在10-13K居多,如果有几年经验,能入行机器学习与数据分析,则工资突破20K还是可以的,将超过很多人的工资。

    2023-08-25
    143
  • FileMaker Pro 19 Advanced (数据库工具)「建议收藏」

    FileMaker Pro 19 Advanced (数据库工具)「建议收藏」FileMaker Pro19 Advanced 是一款功能强大、易于使用的数据库软件。它能帮助你和你的团队更快地完成各种类型的工作。在商业、政府和教育领域,有数百万的用户使用 FileMaker P

    2023-05-31
    193
  • redis集合数据结构_redis的set集合命令

    redis集合数据结构_redis的set集合命令redis 的集合是无序的,集合成员是唯一的,不能重复。用户可以快速地对集合执行添加元素操作、移除元素操作以及检查一个元素是否存在于集合中。这里介绍一些常用的集合处理命令,并在 Yii 中的使用。 S

    2023-03-11
    143
  • Python bytes转str方法详解

    Python bytes转str方法详解在Python中,bytes和str是两种最基本的数据类型,它们经常在文件 I/O 或网络传输过程中使用。在这些操作中,bytes类型用于表示二进制数据,而str类型则用于表示文本数据。

    2024-08-18
    29
  • linux数据库操作命令_docker基本命令

    linux数据库操作命令_docker基本命令我们可以将用于数据服务的数据库分为关系型数据库和非关系型数据库,关系型数据库最典型的就是Mysql,以及和他同源的MariaDB数据库,oracle等,非关系型数据库则有redis数据库,mongod

    2023-04-20
    140
  • Python教程示例:动手学习

    Python教程示例:动手学习Python是一种易于学习的编程语言。以下是Python的几个基本语法示例。

    2024-03-15
    77
  • 数据插补—拉格朗日插值法 – hjk「建议收藏」

    数据插补—拉格朗日插值法 – hjk「建议收藏」##数据分析 ###数据清洗:缺失值处理、1删除记录 2数据插补 3不处理 ###数据在https://book.tipdm.org/jc/219 中的资源包中数据和代码chapter4demod

    2023-05-10
    147
  • Python单引号和双引号的区别

    Python单引号和双引号的区别在Python编程过程中,单引号和双引号都可以用来表示字符串,而且它们的语法是相同的。那么,为什么Python中会存在这两种字符串表示方法呢?它们之间有什么区别呢?在本文中,我们将深入探讨Python单引号和双引号的区别。

    2024-06-06
    55

发表回复

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