【Hadoop_05】NN、2NN以及DataNode的工作机制

本文详细解释了HadoopNameNode和SecondaryNameNode的工作原理,涉及Fsimage和Edits文件的使用,CheckPoint时间设置,以及DataNode的数据完整性保障机制,包括心跳、校验和检查等关键概念。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1、NameNode和SecondaryNameNode

1.1 NN和2NN工作机制

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

  • 首先,我们做个假设,如果存储在NameNode节点的磁盘中,因为经常需要进行随机访问,还有响应客户请求,必然是效率过低。因此,元数据需要存放在内存中。但如果只存在内存中,一旦断电,元数据丢失,整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。
  • 这样又会带来新的问题,当在内存中的元数据更新时,如果同时更新FsImage,就会导致效率过低,但如果不更新,就会发生一致性问题,一旦NameNode节点断电,就会产生数据丢失。==因此,引入Edits文件(只进行追加操作,效率很高)。每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到Edits中。==这样,一旦NameNode节点断电,可以通过FsImage和Edits的合并,合成元数据。
  • 但是,如果长时间添加数据到Edits中,会导致该文件数据过大,效率降低,而且一旦断电,恢复元数据需要的时间过长。因此,需要定期进行FsImage和Edits的合并,如果这个操作由NameNode节点完成,又会效率过低。因此,引入一个新的节点SecondaryNamenode,专门用于FsImage和Edits的合并。

FsImage记录的是结果的值,比如a=100、b=30等。Edits记录的是计算的步骤,比如a*2、b-12等。因此FsImage和Edits需要合并。

  • 当服务器一启动的时候,就会将FsImage和Edits加载到内存。
  • 当服务器一关机的时候,就会将FsImage和Edits进行合并。【是2NN将这两个文件定期合并】

NameNode工作机制:
在这里插入图片描述

1)第一阶段:NameNode启动
(1)第一次启动NameNode格式化后,创建Fsimage和Edits文件。如果不是第一次启
动,直接加载编辑日志和镜像文件到内存。
(2)客户端对元数据进行增删改的请求。
(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.2 Fsimage和Edits解析

在这里插入图片描述

1)oiv查看Fsimage文件

(1)查看oiv和oev命令

[root@hadoop102 current]$ hdfs

oiv:将离线fsimage查看器应用于fsimage
oev:将离线编辑查看器应用于编辑文件

(2)基本语法
hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径

(3)案例实操

[root@hadoop102 current]$ pwd
/opt/module/hadoop-3.1.3/data/dfs/name/current
[root@hadoop102 current]$ hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-3.1.3/fsimage.xml
[root@hadoop102 current]$ cat /opt/module/hadoop-3.1.3/fsimage.xml

将显示的xml文件内容拷贝到Idea中创建的xml文件中,并格式化。部分显示结果如下。

<inode>
	<id>16386</id>
	<type>DIRECTORY</type>
	<name>user</name>
	<mtime>1512722284477</mtime>
	<permission>atguigu:supergroup:rwxr-xr-x</permission>
	<nsquota>-1</nsquota>
	<dsquota>-1</dsquota>
</inode>
<inode>
	<id>16387</id>
	<type>DIRECTORY</type>
	<name>atguigu</name>
	<mtime>1512790549080</mtime>
	<permission>atguigu:supergroup:rwxr-xr-x</permission>
	<nsquota>-1</nsquota>
	<dsquota>-1</dsquota>
</inode>
<inode>
	<id>16389</id>
	<type>FILE</type>
	<name>wc.input</name>
	<replication>3</replication>
	<mtime>1512722322219</mtime>
	<atime>1512722321610</atime>
	<perferredBlockSize>134217728</perferredBlockSize>
	<permission>atguigu:supergroup:rw-r--r--</permission>
	<blocks>
		<block>
			<id>1073741825</id>
			<genstamp>1001</genstamp>
			<numBytes>59</numBytes>
		</block>
	</blocks>
</inode >

可以看出,Fsimage中没有记录块所对应DataNode,为什么?

原因:在集群启动后,要求DataNode主动上报数据块信息,并间隔一段时间后再次上报。

2)oev查看Edits文件

(1)基本语法
hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
(2)案例实操

[root@hadoop102 current]$ hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-3.1.3/edits.xml
[root@hadoop102 current]$ cat /opt/module/hadoop-3.1.3/edits.xml

将显示的xml文件内容拷贝到Idea中创建的xml文件中,并格式化。显示结果如下。

<?xml version="1.0" encoding="UTF-8"?>
<EDITS>
	<EDITS_VERSION>-63</EDITS_VERSION>
	<RECORD>
		<OPCODE>OP_START_LOG_SEGMENT</OPCODE>
		<DATA>
			<TXID>129</TXID>
		</DATA>
	</RECORD>
	<RECORD>
		<OPCODE>OP_ADD</OPCODE>
		<DATA>
			<TXID>130</TXID>
			<LENGTH>0</LENGTH>
			<INODEID>16407</INODEID>
			<PATH>/hello7.txt</PATH>
			<REPLICATION>2</REPLICATION>
			<MTIME>1512943607866</MTIME>
			<ATIME>1512943607866</ATIME>
			<BLOCKSIZE>134217728</BLOCKSIZE>
			<CLIENT_NAME>DFSClient_NONMAPREDUCE_-1544295051_1</CLIENT_NAME>
			<CLIENT_MACHINE>192.168.10.102</CLIENT_MACHINE>
			<OVERWRITE>true</OVERWRITE>
			<PERMISSION_STATUS>
				<USERNAME>atguigu</USERNAME>
				<GROUPNAME>supergroup</GROUPNAME>
				<MODE>420</MODE>
			</PERMISSION_STATUS>
			<RPC_CLIENTID>908eafd4-9aec-4288-96f1-e8011d181561</RPC_CLIENTID>
			<RPC_CALLID>0</RPC_CALLID>
		</DATA>
	</RECORD>
	<RECORD>
		<OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
		<DATA>
			<TXID>131</TXID>
			<BLOCK_ID>1073741839</BLOCK_ID>
		</DATA>
	</RECORD>
	<RECORD>
		<OPCODE>OP_SET_GENSTAMP_V2</OPCODE>
		<DATA>
			<TXID>132</TXID>
			<GENSTAMPV2>1016</GENSTAMPV2>

1.3 CheckPoint时间设置

1)通常情况下,SecondaryNameNode每隔一小时执行一次。
[hdfs-default.xml]

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600s</value>
</property>

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

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

2、DataNode

2.1 DataNode工作机制

在这里插入图片描述
(1)一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。
(2)DataNode启动后向NameNode注册,通过后,周期性(6小时)的向NameNode上报所有的块信息。
DN向NN汇报当前解读信息的时间间隔,默认6小时;

<property>
	<name>dfs.blockreport.intervalMsec</name>
	<value>21600000</value>
	<description>Determines block reporting interval in milliseconds.</description>
</property>

DN扫描自己节点块信息列表的时间,默认6小时

<property>
	<name>dfs.datanode.directoryscan.interval</name>
	<value>21600s</value>
	<description>Interval in seconds for Datanode to scan data 
	directories and reconcile the difference between blocks in memory and on the disk.
	Support multiple time unit suffix(case insensitive), as described
	in dfs.heartbeat.interval.
	</description>
</property>

(3)心跳是每3秒一次,心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳,则认为该节点不可用。

(4)集群运行中可以安全加入和退出一些机器。

2.2 数据完整性

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

在这里插入图片描述

  • 实际上使用的不是简单的奇偶校验,而是采用crc校验位。

2.3 掉线时限参数设置

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒,dfs.heartbeat.interval的单位为秒。

300000毫秒=300秒=5分钟

<property>
    <name>dfs.namenode.heartbeat.recheck-interval</name>
    <value>300000</value>
</property>

<property>
    <name>dfs.heartbeat.interval</name>
    <value>3</value>
</property>
### 回答1: Hadoop是一个分布式存储和计算系统。它由一组节点组成,每个节点都有存储和计算功能。 Hadoop中有两种节点:NameNode和DataNode。 NameNode是Hadoop的管理节点,负责维护文件系统的元数据,即文件名、块位置、块大小等信息。它还负责维护文件系统的命名空间,即文件目录结构。 DataNodeHadoop的存储节点,负责存储文件的实际数据块。它接收来自NameNode的命令,将数据块写入磁盘,并在需要时将数据块读取出来。 Hadoop中还有一个组件:SecondaryNameNode。它的作用是定期从NameNode拉取元数据的副本,并与NameNode进行同步。如果NameNode出现故障,可以使用SecondaryNameNode上的元数据副本来恢复。 简而言之,NameNode负责文件系统的元数据管理和命名空间维护,DataNode负责存储文件的实际数据块,SecondaryNameNode负责与NameNode的元数据同步。 ### 回答2Hadoop中的NameNode(NN)和SecondaryNameNode(2NN)是HDFS(分布式文件系统)的重要组件,它们都承担着维护文件系统元数据的责任,但在工作原理上有所不同。 NameNode是HDFS的主节点,它负责管理文件系统的命名空间和其它重要的元数据信息。当客户端请求执行某个文件操作时,首先会与NameNode通信,NameNode会返回相应的数据块所在的DataNode列表,然后客户端才能与对应的DataNode进行通信。NameNode还记录了文件的层次结构、文件块的位置、复本数量以及各个DataNode的健康状况等信息。NameNode将元数据信息存储在内存中,并定期将其持久化到本地磁盘以防止系统故障时的数据损失。因此,NameNode的工作可简单概括为处理元数据请求、维护文件系统结构、存储数据块位置信息。 SecondaryNameNode(或者称为CheckpointNode)并不是NameNode的替代物,仅用于辅助NameNode进行元数据的备份和合并。SecondaryNameNode根据预定的时间间隔或事务数目,从主节点中得到元数据的快照,并将其存储在本地文件系统上。这样就可以在主节点出现故障的情况下,通过使用SecondaryNameNode上的快照信息来恢复主节点。此外,SecondaryNameNode还负责合并NameNode的编辑日志,将内存中的元数据信息与编辑日志中存储的增量变更合并,减轻了NameNode的元数据负担。 综上所述,NameNode是Hadoop中负责管理文件系统元数据的主节点,而SecondaryNameNode则是辅助NameNode进行备份和合并工作的节点。它们的工作原理是相辅相成的,共同维护HDFS的可靠性和高可用性,在大规模数据存储和处理的分布式环境中起到了关键的作用。 ### 回答3: Hadoop中的NN(NameNode)和2NN(Secondary NameNode)是Hadoop分布式文件系统(HDFS)中的关键组件,它们共同协同工作来保障数据的高可用性和数据一致性。 NN是HDFS的主节点,负责存储和管理文件系统的元数据信息,包括文件和目录的命名空间、块到数据节点的映射关系等。NN也负责处理客户端的文件操作请求,例如文件的读写、创建和删除等。NN将元数据以文件(fsimage)和编辑日志(edits)的形式存储在本地磁盘上。NN工作原理如下: 1. 当客户端发起文件写入请求时,NN接收到请求后会先将文件的元数据记录到内存中,并返回给客户端一个文件写入路径。 2. 当客户端结束文件写入后,NN将文件划分为固定大小的数据块,并记录下每个数据块所在的数据节点信息。 3. 当客户端请求文件读取时,NN根据文件元数据信息获取到数据块的位置,并返回给客户端所需的数据节点信息。 2NNNN的辅助节点,它主要用来定期合并NN的文件系统元数据和编辑日志,生成新的文件系统镜像(fsimage)和编辑日志快照(edits),以便在NN发生故障时进行故障恢复。2NN工作原理如下: 1. 2NN定期从NN获取文件系统的编辑日志,并将这些编辑日志合并到之前的镜像文件上,生成新的文件系统镜像和编辑日志快照。 2. 当NN发生故障时,2NN可以用其最新的文件系统镜像和编辑日志快照来帮助恢复NN,以保障文件系统的高可用性。 总结来说,NN负责管理HDFS的文件系统元数据信息和处理客户端的文件操作请求,2NN则负责定期合并NN的元数据信息和编辑日志,以备份和恢复NN的故障。通过NN2NN的协同工作Hadoop能够提供高可用性的分布式文件存储和处理服务。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

温欣2030

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值