HDFS体系结构

woailyoo0000

已于 2024-06-01 07:28:01 修改

阅读量1.5k

点赞数

文章标签： HDFS NameNode DataNode SecondaryName

于 2021-01-04 21:42:56 首次发布

本文链接：https://blog.csdn.net/woailyoo0000/article/details/112201373

版权

一. HDFS架构

HDFS支持主从结构, 主节点称为NameNode, NameNode支持多个.

从节点称为DataNode,DataNode也支持多个.

HDFS还包含一个SecondaryNameNode进程，这个进程从字面意思看像NameNode，其实不是，后面我们详细分析.

HDFS架构图如下：

二. NameNode介绍

NameNode是整个文件系统的管理节点。

它主要维护整个文件系统的文件目录树，文件/目录的信息和每个文件对应的数据块列表，并且还负责接收用户的操作请求。

⑴ 目录树：表示目录之间的层级关系，就是我们在HDFS上执行ls命令看到的目录结构。

⑵ 文件/目录信息:表示文件/目录的一些基本信息，文件所有者、文件所属组、文件修改时间、文件大小等信息。

⑶每个文件对应的数据块列表：如果一个文件太大，那么集群会对文件进行切割，把文件分成一块一块的，存储到不同的机器上面。所以HDFS需要记录每个文件到底被分成了多少块，每一块被存储在什么地方。

一个文件对应有多少个Block块信息，是在NameNode里面保存的.

⑷ 接收用户的操作请求：其实我们在命令行使用HDFS操作的时候，是需要先和NameNode通信，才能开始操作数据的。

因为文件信息都在NameNode上面存储着。

NameNode中包含这些文件：

这些文件的所在路径是由hdfs-default.xml和dfs.namenode.name.dir属性控制的。

hdfs-default.xml在哪里呢？

它在hadoop-3.2.2\share\hadoop\hdfs\hadoop-hdfs-3.2.2.jar中, 这个文件中包含了HDFS相关的所有默认参数，咱门再配置群集的时候会修改一个hdfs-site.xml文件, hdfs-site.xml文件属于hdfs-default.xml的一个扩展，它可以覆盖掉hdfs-default.xml中同名的参数.

我们来看一下 dfs.namenode.name.dir属性

<property>
  <name>dfs.namenode.name.dir</name>
  <value>file://${hadoop.tmp.dir}/dfs/name</value>
  <description>Determines where on the local filesystem the DFS name node
      should store the name table(fsimage).  If this is a comma-delimited list
      of directories then the name table is replicated in all of the
      directories, for redundancy. </description>
</property>

这个属性的值是由hadoop.tmp.dir属性控制的, 这个属性的值默认在core-default.xml文件中.

我们进入到$HADOOP_HOME\dfs\name目录下

发现有个current目录，还有一个in_use.lock. 文件名 in_use表示这个文件现在正在使用，不允许你再启动NameNode.

当我们启动NameNode的时候，会判断这个目录下是否有in_use.lock 这相当于一把锁，如果没有的话，才可以启动它，启动成功之后就会加一把锁，停止的时候会把这个锁去掉。

[root@bigdata01 name]# cd /data/hadoop_repo/dfs/name
[root@bigdata01 name]# ll
total 8
drwxr-xr-x. 2 root root 4096 Apr  8 21:31 current
-rw-r--r--. 1 root root   14 Apr  8 20:30 in_use.lock

current目录下有edits 和 fsimage文件


[root@bigdata01 name]# cd current
[root@bigdata01 current]# ll
total 4152
-rw-r--r--. 1 root root      42 Apr  7 22:17 edits_0000000000000000001-0000000000000000002
-rw-r--r--. 1 root root 1048576 Apr  7 22:17 edits_0000000000000000003-0000000000000000003
-rw-r--r--. 1 root root      42 Apr  7 22:22 edits_0000000000000000004-0000000000000000005
-rw-r--r--. 1 root root 1048576 Apr  7 22:22 edits_0000000000000000006-0000000000000000006
-rw-r--r--. 1 root root      42 Apr  8 14:53 edits_0000000000000000007-0000000000000000008
-rw-r--r--. 1 root root    1644 Apr  8 15:53 edits_0000000000000000009-0000000000000000031
-rw-r--r--. 1 root root    1523 Apr  8 16:53 edits_0000000000000000032-0000000000000000051
-rw-r--r--. 1 root root      42 Apr  8 17:53 edits_0000000000000000052-0000000000000000053
-rw-r--r--. 1 root root 1048576 Apr  8 17:53 edits_0000000000000000054-0000000000000000054
-rw-r--r--. 1 root root      42 Apr  8 20:31 edits_0000000000000000055-0000000000000000056
-rw-r--r--. 1 root root     523 Apr  8 21:31 edits_0000000000000000057-0000000000000000065
-rw-r--r--. 1 root root 1048576 Apr  8 21:31 edits_inprogress_0000000000000000066
-rw-r--r--. 1 root root     652 Apr  8 20:31 fsimage_0000000000000000056
-rw-r--r--. 1 root root      62 Apr  8 20:31 fsimage_0000000000000000056.md5
-rw-r--r--. 1 root root     661 Apr  8 21:31 fsimage_0000000000000000065
-rw-r--r--. 1 root root      62 Apr  8 21:31 fsimage_0000000000000000065.md5
-rw-r--r--. 1 root root       3 Apr  8 21:31 seen_txid
-rw-r--r--. 1 root root     219 Apr  8 20:30 VERSION

fsimage文件有两个文件名相同的，有一个后缀md5 md5是一种加密算法，这个其实主要是为了做MD5校验的,为了保证文件传输的过程中不出问题，相同内容的MD5是一样的。

fsimage 意味着：filesystem image（系统镜像文件）

就是给文件照了一个像，把文件的当前信息记录下来

我们可以看一下这个文件，这个文件需要使用特殊的命令进行查看.

[root@bigdata01 current]# hdfs oiv -p XML -i fsimage_0000000000000000056 -o fsimage56.xml
2020-04-08 22:23:32,851 INFO offlineImageViewer.FSImageHandler: Loading 4 strings
2020-04-08 22:23:32,916 INFO namenode.FSDirectory: GLOBAL serial map: bits=29 maxEntries=536870911
2020-04-08 22:23:32,916 INFO namenode.FSDirectory: USER serial map: bits=24 maxEntries=16777215
2020-04-08 22:23:32,916 INFO namenode.FSDirectory: GROUP serial map: bits=24 maxEntries=16777215
2020-04-08 22:23:32,916 INFO namenode.FSDirectory: XATTR serial map: bits=24 maxEntries=16777215

查看生成的fsimage56.xml

<?xml version="1.0"?>
<fsimage><version><layoutVersion>-65</layoutVersion><onDiskVersion>1</onDiskVersion><oivRevision>e97acb3bd8f3befd27418996fa5d4b50bf2e17bf</oivRevision></version>
<NameSection><namespaceId>498554338</namespaceId><genstampV1>1000</genstampV1><genstampV2>1005</genstampV2><genstampV1Limit>0</genstampV1Limit><lastAllocatedBlockId>1073741829</lastAllocatedBlockId><txid>56</txid></NameSection>
<ErasureCodingSection>
<erasureCodingPolicy>
<policyId>5</policyId><policyName>RS-10-4-1024k</policyName><cellSize>1048576</cellSize><policyState>DISABLED</policyState><ecSchema>
<codecName>rs</codecName><dataUnits>10</dataUnits><parityUnits>4</parityUnits></ecSchema>
</erasureCodingPolicy>

<erasureCodingPolicy>
<policyId>2</policyId><policyName>RS-3-2-1024k</policyName><cellSize>1048576</cellSize><policyState>DISABLED</policyState><ecSchema>
<codecName>rs</codecName><dataUnits>3</dataUnits><parityUnits>2</parityUnits></ecSchema>
</erasureCodingPolicy>

<erasureCodingPolicy>
<policyId>1</policyId><policyName>RS-6-3-1024k</policyName><cellSize>1048576</cellSize><policyState>ENABLED</policyState><ecSchema>
<codecName>rs</codecName><dataUnits>6</dataUnits><parityUnits>3</parityUnits></ecSchema>
</erasureCodingPolicy>

<erasureCodingPolicy>
<policyId>3</policyId><policyName>RS-LEGACY-6-3-1024k</policyName><cellSize>1048576</cellSize><policyState>DISABLED</policyState><ecSchema>
<codecName>rs-legacy</codecName><dataUnits>6</dataUnits><parityUnits>3</parityUnits></ecSchema>
</erasureCodingPolicy>

<erasureCodingPolicy>
<policyId>4</policyId><policyName>XOR-2-1-1024k</policyName><cellSize>1048576</cellSize><policyState>DISABLED</policyState><ecSchema>
<codecName>xor</codecName><dataUnits>2</dataUnits><parityUnits>1</parityUnits></ecSchema>
</erasureCodingPolicy>

</ErasureCodingSection>

<INodeSection><lastInodeId>16395</lastInodeId><numInodes>4</numInodes><inode><id>16385</id><type>DIRECTORY</type><name></name><mtime>1586332531935</mtime><permission>root:supergroup:0755</permission><nsquota>9223372036854775807</nsquota><dsquota>-1</dsquota></inode>
<inode><id>16393</id><type>FILE</type><name>LICENSE.txt</name><replication>2</replication><mtime>1586332513657</mtime><atime>1586332513485</atime><preferredBlockSize>134217728</preferredBlockSize><permission>root:supergroup:0644</permission><blocks><block><id>1073741827</id><genstamp>1003</genstamp><numBytes>150569</numBytes></block>
</blocks>
<storagePolicyId>0</storagePolicyId></inode>
<inode><id>16394</id><type>FILE</type><name>NOTICE.txt</name><replication>2</replication><mtime>1586332522962</mtime><atime>1586332522814</atime><preferredBlockSize>134217728</preferredBlockSize><permission>root:supergroup:0644</permission><blocks><block><id>1073741828</id><genstamp>1004</genstamp><numBytes>22125</numBytes></block>
</blocks>
<storagePolicyId>0</storagePolicyId></inode>
<inode><id>16395</id><type>FILE</type><name>README.txt</name><replication>2</replication><mtime>1586332531932</mtime><atime>1586332531689</atime><preferredBlockSize>134217728</preferredBlockSize><permission>root:supergroup:0644</permission><blocks><block><id>1073741829</id><genstamp>1005</genstamp><numBytes>1361</numBytes></block>
</blocks>
<storagePolicyId>0</storagePolicyId></inode>
</INodeSection>
<INodeReferenceSection></INodeReferenceSection><SnapshotSection><snapshotCounter>0</snapshotCounter><numSnapshots>0</numSnapshots></SnapshotSection>
<INodeDirectorySection><directory><parent>16385</parent><child>16393</child><child>16394</child><child>16395</child></directory>
</INodeDirectorySection>
<FileUnderConstructionSection></FileUnderConstructionSection>
<SecretManagerSection><currentId>0</currentId><tokenSequenceNumber>0</tokenSequenceNumber><numDelegationKeys>0</numDelegationKeys><numTokens>0</numTokens></SecretManagerSection><CacheManagerSection><nextDirectiveId>1</nextDirectiveId><numDirectives>0</numDirectives><numPools>0</numPools></CacheManagerSection>
</fsimage>

里面最外层是一个fsimage标签，里面是inode标签。

这个inode表示是hdfs中的每一个目录或者文件信息.

比如这个：

<inode>
     <id>16393</id>
     <type>FILE</type>
     <name>LICENSE.txt</name>
     <replication>2</replication>
     <mtime>1586332513657</mtime>
     <atime>1586332513485</atime>
     <preferredBlockSize>134217728</preferredBlockSize> 
     <permission>root:supergroup:0644</permission>
     <blocks>
        <block>
            <id>1073741827</id>
            <genstamp>1003</genstamp>
            <numBytes>150569</numBytes>
        </block>
     </blocks>
<storagePolicyId>0</storagePolicyId>
</inode>

id:唯一编号

type:文件类型

name:文件名称

replication:文件的副本数量

mtime:修改时间

atime:访问时间

preferredBlockSize: 每一个数据块的大小

permission : 权限信息

blocks : 包含多少个数据块( 文件被切成数据块)

block: 内部的id表示块id, genstamp是唯一编号,numBytes标识当前数据库的实际大小, storagePolicyId表示是数据的存储策略.

这个文件中其实就维护了整个文件系统的文件目录树, 文件/目录的元信息和每个文件对应的数据块列表，所以说fsimage中存放了hdfs最核心的数据.

下面我们来看下edits文件，这些文件被称为事务文件:


[root@bigdata01 name]# cd current
[root@bigdata01 current]# ll
total 4152
-rw-r--r--. 1 root root      42 Apr  7 22:17 edits_0000000000000000001-0000000000000000002
-rw-r--r--. 1 root root 1048576 Apr  7 22:17 edits_0000000000000000003-0000000000000000003
-rw-r--r--. 1 root root      42 Apr  7 22:22 edits_0000000000000000004-0000000000000000005
-rw-r--r--. 1 root root 1048576 Apr  7 22:22 edits_0000000000000000006-0000000000000000006
-rw-r--r--. 1 root root      42 Apr  8 14:53 edits_0000000000000000007-0000000000000000008
-rw-r--r--. 1 root root    1644 Apr  8 15:53 edits_0000000000000000009-0000000000000000031
-rw-r--r--. 1 root root    1523 Apr  8 16:53 edits_0000000000000000032-0000000000000000051
-rw-r--r--. 1 root root      42 Apr  8 17:53 edits_0000000000000000052-0000000000000000053
-rw-r--r--. 1 root root 1048576 Apr  8 17:53 edits_0000000000000000054-0000000000000000054
-rw-r--r--. 1 root root      42 Apr  8 20:31 edits_0000000000000000055-0000000000000000056
-rw-r--r--. 1 root root     523 Apr  8 21:31 edits_0000000000000000057-0000000000000000065
-rw-r--r--. 1 root root 1048576 Apr  8 21:31 edits_inprogress_0000000000000000066
-rw-r--r--. 1 root root     652 Apr  8 20:31 fsimage_0000000000000000056
-rw-r--r--. 1 root root      62 Apr  8 20:31 fsimage_0000000000000000056.md5
-rw-r--r--. 1 root root     661 Apr  8 21:31 fsimage_0000000000000000065
-rw-r--r--. 1 root root      62 Apr  8 21:31 fsimage_0000000000000000065.md5
-rw-r--r--. 1 root root       3 Apr  8 21:31 seen_txid
-rw-r--r--. 1 root root     219 Apr  8 20:30 VERSION

当我们上传一个文件的时候，例如上传一个100G的文件，上传到99G，失败了，这时候就需要重新上传，那HDFS其他存储的节点怎么知道这个文件失败了呢？这个是在edits文件中记录的。

当我们上传大文件的时候，一个大文件会分为多个block，那么edits文件中就会记录这些block的上传状态,只有当全部block都上传成功以后，这个时候edits中才会记录这个文件上传成功了，那么我们执行 hdfs dfs -ls的时候就能查到这个文件了

所以当我们在hdfs中执行ls命令的时候，其实会查询fsimage 和 edits中的内容

为什么会有这个两个文件呢？

首先，我们固化的一些文件内容是存储在fsimage文件中的，当前正在上传的文件信息是存储在edits文件中。

我们来看一看edits文件的内容:

<RECORD>
    <OPCODE>OP_ADD</OPCODE>
    <DATA>
      <TXID>58</TXID>
      <LENGTH>0</LENGTH>
      <INODEID>16396</INODEID>
      <PATH>/user.txt</PATH>
      <REPLICATION>3</REPLICATION>
      <MTIME>1586349095694</MTIME>
      <ATIME>1586349095694</ATIME>
      <BLOCKSIZE>134217728</BLOCKSIZE>
      <CLIENT_NAME>DFSClient_NONMAPREDUCE_-1768454371_1</CLIENT_NAME>
      <CLIENT_MACHINE>192.168.182.1</CLIENT_MACHINE>
      <OVERWRITE>true</OVERWRITE>
      <PERMISSION_STATUS>
        <USERNAME>yehua</USERNAME>
        <GROUPNAME>supergroup</GROUPNAME>
        <MODE>420</MODE>
      </PERMISSION_STATUS>
      <ERASURE_CODING_POLICY_ID>0</ERASURE_CODING_POLICY_ID>
      <RPC_CLIENTID>1722b83a-2dc7-4c46-baa9-9fa956b755cd</RPC_CLIENTID>
      <RPC_CALLID>0</RPC_CALLID>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
    <DATA>
      <TXID>59</TXID>
      <BLOCK_ID>1073741830</BLOCK_ID>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_SET_GENSTAMP_V2</OPCODE>
    <DATA>
      <TXID>60</TXID>
      <GENSTAMPV2>1006</GENSTAMPV2>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_ADD_BLOCK</OPCODE>
    <DATA>
      <TXID>61</TXID>
      <PATH>/user.txt</PATH>
      <BLOCK>
        <BLOCK_ID>1073741830</BLOCK_ID>
        <NUM_BYTES>0</NUM_BYTES>
        <GENSTAMP>1006</GENSTAMP>
      </BLOCK>
      <RPC_CLIENTID/>
      <RPC_CALLID>-2</RPC_CALLID>
    </DATA>
  </RECORD>
  <RECORD>
    <OPCODE>OP_CLOSE</OPCODE>
    <DATA>
      <TXID>62</TXID>
      <LENGTH>0</LENGTH>
      <INODEID>0</INODEID>
      <PATH>/user.txt</PATH>
      <REPLICATION>3</REPLICATION>
      <MTIME>1586349096480</MTIME>
      <ATIME>1586349095694</ATIME>
      <BLOCKSIZE>134217728</BLOCKSIZE>
      <CLIENT_NAME/>
      <CLIENT_MACHINE/>
      <OVERWRITE>false</OVERWRITE>
      <BLOCK>
        <BLOCK_ID>1073741830</BLOCK_ID>
        <NUM_BYTES>17</NUM_BYTES>
        <GENSTAMP>1006</GENSTAMP>
      </BLOCK>
      <PERMISSION_STATUS>
        <USERNAME>yehua</USERNAME>
        <GROUPNAME>supergroup</GROUPNAME>
        <MODE>420</MODE>
      </PERMISSION_STATUS>
    </DATA>
  </RECORD>

这里面每一个record都有一个事务id，txid, 事务id是连续的，其实一个put操作会在edits文件中产生很多的record, 对应的就是很多步骤，这些步骤对我们是屏蔽的。

注意了，根据我们刚才的分析，我们所有对hdfs的增删改操作都会在edits文件中留下信息, 那么fsimage文件的内容是从哪来的？

其实是这样： edits文件会定期合并到fsimage文件中.

注意：这个合并是框架去做的，在合并的时候会对edits中的内容进行转换，生成新的内容，edits保存的是明细数据，fsimage保存的是提取的block信息数据.(合并精简过的数据)

三. SecondaryNameNode

这个进程就是负责定期把edits的内容合并到fsimage中。他只做一件事，这是一件单独的进程，在实际工作中部署的时候，也需要部署到单独的节点上面。

current目录中还有一个seen_txid文件， HDFS format之后是0，它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候，会按照seen_txid的数字，顺序从头跑edits_0000001~到seen_txid的数字。如果根据对应的seen_txid无法加载到对应的文件，NameNode进程将不会完成启动以保护数据一致性.

这个合并称为 CheckPoint, 在合并的时候会对edits中的内容进行转换，生成新的内容保存到fsimage文件中.

[root@bigdata01 current]# cat VERSION 
#Wed Apr 08 20:30:00 CST 2020
namespaceID=498554338
clusterID=CID-cc0792dd-a861-4a3f-9151-b0695e4c7e70
cTime=1586268855170
storageType=NAME_NODE
blockpoolID=BP-1517789416-192.168.182.100-1586268855170
layoutVersion=-65

这里面显示的是群集的一些信息，当重新对hdfs格式化以后，这里面的信息会变化。

四. DataNode

DataNode提供真实文件数据的存储服务.

针对 DataNode主要掌握两个概念，一个是block,一个是replication

首先是block

HDFS会按照固定大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block,HDFS默认 Block大小是128MB

Block块是HDFS读写数据的基本单位，不管你的文件是文本文件还是视频或者音频文件，针对hdfs而言都是字节。

我们上传一个user.txt文件

[root@bigdata01 hadoop-3.2.0]# hdfs dfs -put user.txt /

从他的block信息可以在fsimage文件中看到，也可以在hdfs web页面上看到，里面有block的id信息，并且也会显示在哪个节点上面

这里显示在bigdata02和bigdata03上面都有，datannode中的数据具体存储位置是由dfs.datanode.data.dir来控制的，通过查询hdfs-default.xml可以知道，具体的位置：

<property>
  <name>dfs.datanode.data.dir</name>
  <value>file://${hadoop.tmp.dir}/dfs/data</value>
</property>

到目录下看一下


[root@bigdata02 subdir0]# ll
total 340220
-rw-r--r--. 1 root root     22125 Apr  8 15:55 blk_1073741828
-rw-r--r--. 1 root root       183 Apr  8 15:55 blk_1073741828_1004.meta
-rw-r--r--. 1 root root      1361 Apr  8 15:55 blk_1073741829
-rw-r--r--. 1 root root        19 Apr  8 15:55 blk_1073741829_1005.meta
-rw-r--r--. 1 root root        17 Apr  8 20:31 blk_1073741830
-rw-r--r--. 1 root root        11 Apr  8 20:31 blk_1073741830_1006.meta
-rw-r--r--. 1 root root 134217728 Apr  8 22:13 blk_1073741831
-rw-r--r--. 1 root root   1048583 Apr  8 22:13 blk_1073741831_1007.meta
-rw-r--r--. 1 root root 134217728 Apr  8 22:13 blk_1073741832
-rw-r--r--. 1 root root   1048583 Apr  8 22:13 blk_1073741832_1008.meta
-rw-r--r--. 1 root root  77190019 Apr  8 22:13 blk_1073741833
-rw-r--r--. 1 root root    603055 Apr  8 22:13 blk_1073741833_1009.meta

这里面有很多block块。里面的.meta文件也是用来做校验的。

[root@bigdata02 subdir0]# cat blk_1073741830
jack
tom
jessic
[root@bigdata02 subdir0]#

可以直接查看，发现文件内容就是我们之前上传上去的内容。

注意，这个block中的内容可能只是文件的一部分，如果你的文件很大的话，就会分为多个block存储，默认hadoop3中的block大小为128MB.

下面看一下副本概念

副本表示数据有多少个备份

我们现在的集群有2个从节点，所以最多有2个备份,这个是在hdfs-site.xml中进行配置的, 属性名为：dfs.replication

默认这个参数是3，表示会有3个副本。

五. NameNode与DataNode之间的关系

Block块存在在哪些datanode上，只有datanode自己知道，而datanode相互之前并不知道别的datanode存放了哪些数据,当群集启动的时候，datanode会扫描自己节点上的所有block块信息，然后把节点和这个节点上的所有block块信息告诉给NameNode。这个关系是每次重启群集都会动态加载的，这就是为什么群集数据越多，启动越慢的原因。

NameNode维护了两份关系：

1. file 与 block list的关系，对应的关系信息存储在fsimage和edits文件中，当NameNode启动的时候会把文件中的元数据信息加载到内存中。

2. datanode与block的关系，对应的关系主要在集群启动的时候保存在内存中，当DataNode启动时会把当前节点上的Block信息和节点信息上报给NameNode.

注意，NameNode启动的时候会把文件中的元数据信息加载到内存中，然后每一个文件的元数据会占用150字节的内存空间，这个是恒定的，和文件的大小没有关系。HDFS适合存储大文件，不适合存储小文件，主要原因就在这里，不管文件大小，一个文件的元数据信息存储为150字节，但NameNode的内存是有限的，所以它的存储能力也有限，如果我们存储了一推几KB甚至几B的小文件，最后发现NameNode内存占满了，但文件总体的大小却很小，这样就失去了HDFS的价值。

最后在DataNode数据目录下的current目录有一个VERSON文件

这个VERSION文件与NameNode的VERSION文件有一些相似之处

NameNode的VERSION文件：

[root@bigdata01 current]# cat VERSION 
#Wed Apr 08 20:30:00 CST 2020
namespaceID=498554338
clusterID=CID-cc0792dd-a861-4a3f-9151-b0695e4c7e70
cTime=1586268855170
storageType=NAME_NODE
blockpoolID=BP-1517789416-192.168.182.100-1586268855170
layoutVersion=-65

DataNode的VERSION文件：

[root@bigdata02 current]# cat VERSION 
#Wed Apr 08 20:30:04 CST 2020
storageID=DS-0e86cd27-4961-4526-bacb-3b692a90b1b0
clusterID=CID-cc0792dd-a861-4a3f-9151-b0695e4c7e70
cTime=0
datanodeUuid=0b09f3d7-442d-4e28-b3cc-2edb0991bae3
storageType=DATA_NODE
layoutVersion=-57

前面说NameNode不要随便格式化，因为格式化了之后VERSION里面的clusterID会变，但是DataNode VERSION文件中的clusterID却不会改变，所以就对应不上了。

如果确实要重新格式化，需要把/data/hadoop_repo数据目录下的内容全部清空，全部都重新生成才可以。