devbox
小桥流水78
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

HDFS体系结构_简述hdfs的总体架构,并对每部分进行认知描述

作者：小桥流水78 | 2024-08-02 07:33:46

赞

踩

简述hdfs的总体架构,并对每部分进行认知描述

     一. 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属性

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

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

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

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

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

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

current目录下有edits 和 fsimage文件

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

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

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

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

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

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

查看生成的fsimage56.xml

  1. <?xml version="1.0"?>
  2. <fsimage><version><layoutVersion>-65</layoutVersion><onDiskVersion>1</onDiskVersion><oivRevision>e97acb3bd8f3befd27418996fa5d4b50bf2e17bf</oivRevision></version>
  3. <NameSection><namespaceId>498554338</namespaceId><genstampV1>1000</genstampV1><genstampV2>1005</genstampV2><genstampV1Limit>0</genstampV1Limit><lastAllocatedBlockId>1073741829</lastAllocatedBlockId><txid>56</txid></NameSection>
  4. <ErasureCodingSection>
  5. <erasureCodingPolicy>
  6. <policyId>5</policyId><policyName>RS-10-4-1024k</policyName><cellSize>1048576</cellSize><policyState>DISABLED</policyState><ecSchema>
  7. <codecName>rs</codecName><dataUnits>10</dataUnits><parityUnits>4</parityUnits></ecSchema>
  8. </erasureCodingPolicy>
  9.  
  10. <erasureCodingPolicy>
  11. <policyId>2</policyId><policyName>RS-3-2-1024k</policyName><cellSize>1048576</cellSize><policyState>DISABLED</policyState><ecSchema>
  12. <codecName>rs</codecName><dataUnits>3</dataUnits><parityUnits>2</parityUnits></ecSchema>
  13. </erasureCodingPolicy>
  14.  
  15. <erasureCodingPolicy>
  16. <policyId>1</policyId><policyName>RS-6-3-1024k</policyName><cellSize>1048576</cellSize><policyState>ENABLED</policyState><ecSchema>
  17. <codecName>rs</codecName><dataUnits>6</dataUnits><parityUnits>3</parityUnits></ecSchema>
  18. </erasureCodingPolicy>
  19.  
  20. <erasureCodingPolicy>
  21. <policyId>3</policyId><policyName>RS-LEGACY-6-3-1024k</policyName><cellSize>1048576</cellSize><policyState>DISABLED</policyState><ecSchema>
  22. <codecName>rs-legacy</codecName><dataUnits>6</dataUnits><parityUnits>3</parityUnits></ecSchema>
  23. </erasureCodingPolicy>
  24.  
  25. <erasureCodingPolicy>
  26. <policyId>4</policyId><policyName>XOR-2-1-1024k</policyName><cellSize>1048576</cellSize><policyState>DISABLED</policyState><ecSchema>
  27. <codecName>xor</codecName><dataUnits>2</dataUnits><parityUnits>1</parityUnits></ecSchema>
  28. </erasureCodingPolicy>
  29.  
  30. </ErasureCodingSection>
  31.  
  32. <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>
  33. <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>
  34. </blocks>
  35. <storagePolicyId>0</storagePolicyId></inode>
  36. <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>
  37. </blocks>
  38. <storagePolicyId>0</storagePolicyId></inode>
  39. <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>
  40. </blocks>
  41. <storagePolicyId>0</storagePolicyId></inode>
  42. </INodeSection>
  43. <INodeReferenceSection></INodeReferenceSection><SnapshotSection><snapshotCounter>0</snapshotCounter><numSnapshots>0</numSnapshots></SnapshotSection>
  44. <INodeDirectorySection><directory><parent>16385</parent><child>16393</child><child>16394</child><child>16395</child></directory>
  45. </INodeDirectorySection>
  46. <FileUnderConstructionSection></FileUnderConstructionSection>
  47. <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>
  48. </fsimage>

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

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

比如这个：

  1. <inode>
  2.      <id>16393</id>
  3.      <type>FILE</type>
  4.      <name>LICENSE.txt</name>
  5.      <replication>2</replication>
  6.      <mtime>1586332513657</mtime>
  7.      <atime>1586332513485</atime>
  8.      <preferredBlockSize>134217728</preferredBlockSize> 
  9.      <permission>root:supergroup:0644</permission>
  10.      <blocks>
  11.         <block>
  12.             <id>1073741827</id>
  13.             <genstamp>1003</genstamp>
  14.             <numBytes>150569</numBytes>
  15.         </block>
  16.      </blocks>
  17. <storagePolicyId>0</storagePolicyId>
  18. </inode>

id:唯一编号

type:文件类型

name:文件名称

replication:文件的副本数量

mtime:修改时间

atime:访问时间

preferredBlockSize: 每一个数据块的大小

permission : 权限信息

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

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

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

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

  1.  
  2. [root@bigdata01 name]# cd current
  3. [root@bigdata01 current]# ll
  4. total 4152
  5. -rw-r--r--. 1 root root      42 Apr  7 22:17 edits_0000000000000000001-0000000000000000002
  6. -rw-r--r--. 1 root root 1048576 Apr  7 22:17 edits_0000000000000000003-0000000000000000003
  7. -rw-r--r--. 1 root root      42 Apr  7 22:22 edits_0000000000000000004-0000000000000000005
  8. -rw-r--r--. 1 root root 1048576 Apr  7 22:22 edits_0000000000000000006-0000000000000000006
  9. -rw-r--r--. 1 root root      42 Apr  8 14:53 edits_0000000000000000007-0000000000000000008
  10. -rw-r--r--. 1 root root    1644 Apr  8 15:53 edits_0000000000000000009-0000000000000000031
  11. -rw-r--r--. 1 root root    1523 Apr  8 16:53 edits_0000000000000000032-0000000000000000051
  12. -rw-r--r--. 1 root root      42 Apr  8 17:53 edits_0000000000000000052-0000000000000000053
  13. -rw-r--r--. 1 root root 1048576 Apr  8 17:53 edits_0000000000000000054-0000000000000000054
  14. -rw-r--r--. 1 root root      42 Apr  8 20:31 edits_0000000000000000055-0000000000000000056
  15. -rw-r--r--. 1 root root     523 Apr  8 21:31 edits_0000000000000000057-0000000000000000065
  16. -rw-r--r--. 1 root root 1048576 Apr  8 21:31 edits_inprogress_0000000000000000066
  17. -rw-r--r--. 1 root root     652 Apr  8 20:31 fsimage_0000000000000000056
  18. -rw-r--r--. 1 root root      62 Apr  8 20:31 fsimage_0000000000000000056.md5
  19. -rw-r--r--. 1 root root     661 Apr  8 21:31 fsimage_0000000000000000065
  20. -rw-r--r--. 1 root root      62 Apr  8 21:31 fsimage_0000000000000000065.md5
  21. -rw-r--r--. 1 root root       3 Apr  8 21:31 seen_txid
  22. -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文件的内容:

  1. <RECORD>
  2.     <OPCODE>OP_ADD</OPCODE>
  3.     <DATA>
  4.       <TXID>58</TXID>
  5.       <LENGTH>0</LENGTH>
  6.       <INODEID>16396</INODEID>
  7.       <PATH>/user.txt</PATH>
  8.       <REPLICATION>3</REPLICATION>
  9.       <MTIME>1586349095694</MTIME>
  10.       <ATIME>1586349095694</ATIME>
  11.       <BLOCKSIZE>134217728</BLOCKSIZE>
  12.       <CLIENT_NAME>DFSClient_NONMAPREDUCE_-1768454371_1</CLIENT_NAME>
  13.       <CLIENT_MACHINE>192.168.182.1</CLIENT_MACHINE>
  14.       <OVERWRITE>true</OVERWRITE>
  15.       <PERMISSION_STATUS>
  16.         <USERNAME>yehua</USERNAME>
  17.         <GROUPNAME>supergroup</GROUPNAME>
  18.         <MODE>420</MODE>
  19.       </PERMISSION_STATUS>
  20.       <ERASURE_CODING_POLICY_ID>0</ERASURE_CODING_POLICY_ID>
  21.       <RPC_CLIENTID>1722b83a-2dc7-4c46-baa9-9fa956b755cd</RPC_CLIENTID>
  22.       <RPC_CALLID>0</RPC_CALLID>
  23.     </DATA>
  24.   </RECORD>
  25.   <RECORD>
  26.     <OPCODE>OP_ALLOCATE_BLOCK_ID</OPCODE>
  27.     <DATA>
  28.       <TXID>59</TXID>
  29.       <BLOCK_ID>1073741830</BLOCK_ID>
  30.     </DATA>
  31.   </RECORD>
  32.   <RECORD>
  33.     <OPCODE>OP_SET_GENSTAMP_V2</OPCODE>
  34.     <DATA>
  35.       <TXID>60</TXID>
  36.       <GENSTAMPV2>1006</GENSTAMPV2>
  37.     </DATA>
  38.   </RECORD>
  39.   <RECORD>
  40.     <OPCODE>OP_ADD_BLOCK</OPCODE>
  41.     <DATA>
  42.       <TXID>61</TXID>
  43.       <PATH>/user.txt</PATH>
  44.       <BLOCK>
  45.         <BLOCK_ID>1073741830</BLOCK_ID>
  46.         <NUM_BYTES>0</NUM_BYTES>
  47.         <GENSTAMP>1006</GENSTAMP>
  48.       </BLOCK>
  49.       <RPC_CLIENTID/>
  50.       <RPC_CALLID>-2</RPC_CALLID>
  51.     </DATA>
  52.   </RECORD>
  53.   <RECORD>
  54.     <OPCODE>OP_CLOSE</OPCODE>
  55.     <DATA>
  56.       <TXID>62</TXID>
  57.       <LENGTH>0</LENGTH>
  58.       <INODEID>0</INODEID>
  59.       <PATH>/user.txt</PATH>
  60.       <REPLICATION>3</REPLICATION>
  61.       <MTIME>1586349096480</MTIME>
  62.       <ATIME>1586349095694</ATIME>
  63.       <BLOCKSIZE>134217728</BLOCKSIZE>
  64.       <CLIENT_NAME/>
  65.       <CLIENT_MACHINE/>
  66.       <OVERWRITE>false</OVERWRITE>
  67.       <BLOCK>
  68.         <BLOCK_ID>1073741830</BLOCK_ID>
  69.         <NUM_BYTES>17</NUM_BYTES>
  70.         <GENSTAMP>1006</GENSTAMP>
  71.       </BLOCK>
  72.       <PERMISSION_STATUS>
  73.         <USERNAME>yehua</USERNAME>
  74.         <GROUPNAME>supergroup</GROUPNAME>
  75.         <MODE>420</MODE>
  76.       </PERMISSION_STATUS>
  77.     </DATA>
  78.   </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文件中.

  1. [root@bigdata01 current]# cat VERSION 
  2. #Wed Apr 08 20:30:00 CST 2020
  3. namespaceID=498554338
  4. clusterID=CID-cc0792dd-a861-4a3f-9151-b0695e4c7e70
  5. cTime=1586268855170
  6. storageType=NAME_NODE
  7. blockpoolID=BP-1517789416-192.168.182.100-1586268855170
  8. 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可以知道，具体的位置：

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

到目录下看一下

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

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

  1. [root@bigdata02 subdir0]# cat blk_1073741830
  2. jack
  3. tom
  4. jessic
  5. [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文件：

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

DataNode的VERSION文件 ：

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

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

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

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/小桥流水78/article/detail/917767
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号