HDFS体系结构

HDFS 支持主从结 构 ， 主节 点 称为 NameNode ，从节点称为 DataNode  HDFS中还包含一个 SecondaryNameNode 进程，只要辅助主节点

公司BOSS：NameNode （NN） 秘书：SecondaryNameNode (2NN) 员工：DataNode

NameNode介绍 首先是NameNode，NameNode是整个文件系统的管理节点，它主要维护着整个文件系统的文件目录树，文件/目录的信息 和 每个文件对应的数据块列表，并且还负责接收用户的操作请求。

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

每个文件对应的数据块列表：如果一个文件太大，那么在集群中存储的时候会对文件进行切割，这个时候就类似于会给文件分成一块一块的，存储到不同机器上面。所以HDFS还要记录一下一个文件到底被分了多少块，每一块都在什么地方存储着

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

这些元数据存在哪里，hdfs-default.xml的dfs.namenode.name.dir属性决定，hdfs-site.xml文件属于hdfs-default.xml的一个扩展，它可以覆盖掉hdfs-default.xml中同名的参数。

[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

[root@bigdata01 name]# cd current

[root@bigdata01 current]# ll

total 4152 -rw-r--r--. 1 root root 42 Apr 7 22:17 edits_0000000000000000001-000000

-rw-r--r--. 1 root root 1048576 Apr 7 22:17 edits_0000000000000000003-000000

-rw-r--r--. 1 root root 42 Apr 7 22:22 edits_0000000000000000004-000000

-rw-r--r--. 1 root root 1048576 Apr 7 22:22 edits_0000000000000000006-000000

-rw-r--r--. 1 root root 42 Apr 8 14:53 edits_0000000000000000007-000000

-rw-r--r--. 1 root root 1644 Apr 8 15:53 edits_0000000000000000009-000000

-rw-r--r--. 1 root root 1523 Apr 8 16:53 edits_0000000000000000032-000000

-rw-r--r--. 1 root root 42 Apr 8 17:53 edits_0000000000000000052-000000

-rw-r--r--. 1 root root 1048576 Apr 8 17:53 edits_0000000000000000054-000000

-rw-r--r--. 1 root root 42 Apr 8 20:31 edits_0000000000000000055-000000

-rw-r--r--. 1 root root 523 Apr 8 21:31 edits_0000000000000000057-000000

-rw-r--r--. 1 root root 1048576 Apr 8 21:31 edits_inprogress_000000000000000

-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 是 HDFS 文件系统的元数据快照，记录了当前文件系统的完整状态，包括：

文件和目录的层次结构。

文件和目录的权限、所有者、组等信息。

文件块（Block）的映射信息。

fsimage 文件通常与 edits 文件一起使用，edits 文件记录了自上次 fsimage 生成以来的所有更改。

fsimage文件有两个文件名相同的，有一个后缀是md5，md5是一种加密算法，这个其实主要是为了做md5校验的，为了保证文件传输的过程中不出问题，根据md5对fsimage的内容进行加密，获取一个值 和fsimage.md5中的内容进行比较，如果一样，说明接收到的文件就是完整的。

查看fsimage 文件

[root@bigdata01 current]# hdfs oiv -p XML -i fsimage_0000000000000000056

hdfs oiv：

oiv 是 Offline Image Viewer 的缩写，是 HDFS 提供的一个工具，用于离线查看和分析 fsimage 文件。

fsimage 是 HDFS 文件系统的元数据快照，包含了文件、目录、权限等信息。

-p XML：

-p 指定输出格式。

XML 是其中一种输出格式，表示将 fsimage 文件转换为 XML 格式。

-i fsimage_0000000000000000056：

-i 指定输入的 fsimage 文件。

fsimage_0000000000000000056 是具体的 fsimage 文件名。

会获得到一个xml 文件 xml 里面有个 标签<inode>，这个inode表示是hdfs中的每一个目录或者文件信息

        id：唯一编号         type：文件类型

        replication：文件的副本数量         mtime：修改时间

        atime：访问时间         preferredBlockSize：推荐每一个数据块的大小         permission：权限信息         blocks：包含多少数据块【文件被切成数据块】         block：内部的id表示是块id，genstamp是一个唯一编号，numBytes表示当前数据块的实际大小，storagePolicyId表示是数据的存储策略

查看 edits 文件

[root@bigdata01 current]# hdfs oev -i edits_0000000000000000057-000000000000  

<RECORD>  <OPCODE>OP_ADD</OPCODE>  <DATA>  <TXID>58</TXID>  <LENGTH>0</LENGTH>  <INODEID>16396</INODEID>  <PATH>/user.txt</PATH>  <REPLICATION>3</REPLICATION>  <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>  <MODE>420</MODE>  </PERMISSION_STATUS>  </DATA>  </RECORD>

OP_ADD：执行上传操作 OP_ALLOCATE_BLOCK_ID：申请block块id

OP_SET_GENSTAMP_V2：设置GENSTAMP

OP_ADD_BLOCK：添加block块 OP_CLOSE：关闭上传操作 

edits文件会定期合并到fsimage文件中，其实edits中保存的内容太细了，单单一个上传操作就分为了好几步，其实上传成功之后，我们只需要保存文件具体存储的block信息就行，所以在合并的时候其实是对edits中的内容进行了精简。 2NN负责定期的把edits中的内容合并到fsimage中。在 NameNode 的 HA 架 构 中 没 有 SecondaryNameNode 进 程 ， 文 件 合 并 操 作 会 由 standby NameNode负责实现，所以在Hadoop集群中，SecondaryNameNode进程并不是必须的。

current目录中还有一个seen_txid文件，HDFS 格式化之后是0，它代表的是namenode里面的edits_*文件的尾数,namenode重启的时候，会按照seen_txid的数字，顺序从头跑edits_0000001~到seen_txid的数字。

DataNode介绍 DataNode是提供真实文件数据的存储服务，针对datanode主要掌握两个概念，一个是block（默认128MB），一个是replication。

datanode中数据的具体存储位置是由dfs.datanode.data.dir来控制的，通过查询hdfs-default.xml可以知道。

namenode维护了两份关系 第一份关系：file 与block list的关系，对应的关系信息存储在fsimage和edits文件中,当NameNode启动的时候会把文件中的元数据信息加载到内存中

刚才我们说了NameNode启动的时候会把文件中的元数据信息加载到内存中，然后每一个文件的元数据信息会占用150字节的内存空间，这个是恒定的，和文件大小没有关系，咱们前面在介绍HDFS的时候说过，HDFS不适合存储小文件，其实主要原因就在这里，不管是大文件还是小文件，一个文件的元数据信息在NameNode中都会占用150字节，NameNode节点的内存是有限的，所以它的存储能力也是有限的，如果我们存储了一堆都是几KB的小文件，最后发现NameNode的内存占满了

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

namenode不要随便格式化，因为格式化了以后VERSION里面的clusterID会变，但是datanode的VERSION中的clusterID并没有变，所以就对应不上了。

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

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

HDFS的回收站

HDFS会为每一个用户创建一个回收站目录：/user/用户名/.Trash/，每一个被用户在Shell命令行删除的文件/目录，会进入到对应的回收站目录中，在回收站中的数据都有一个生存周期，也就是当回收站中的文件/目录在一段时间之内没有被用户恢复的话，HDFS就会自动的把这个文件/目录彻底删除，之后，用户就永远也找不回这个文件/目录了。

 core-site.xml

<property> <name>fs.trash.interval</name> <value>1440</value> </property>

 

指定参数 -skipTrash ，指定这个参数表示删除的文件不会进回收站

 [root@bigdata01 hadoop-3.2.0]# hdfs dfs -rm -r -skipTrash /user.txt

Deleted /user.txt

HDFS的安全模式 

[root@bigdata01 hadoop-3.2.0]# hdfs dfsadmin -safemode get

Safe mode is ON

// on表示处于安全模式，off表示安全模式已结束

// 通过命令强制离开

[root@bigdata01 hadoop-3.2.0]# hdfs dfsadmin -safemode leave

Safe mode is OFF

nameNode负责接收用户的操作请求，所有的读写请求都会经过它，如果它挂了怎么办？ 集群就太不稳定了，因为NameNode只有一个，是存在单点故障的，咱们在现实生活中，例如，县长，是有正的和副的，这样就是为了解决当正县长遇到出差的时候，副县长可以顶上去。 所以在HDFS的设计中，NameNode也是可以支持多个的，一个主的 多个备用的，当主的挂掉了，备用的可以顶上去，这样就可以解决NameNode节点宕机导致的单点故障问题了，也就实现了HDFS的高可用。

HDFS的高可用(HA)

HDFS的HA，指的是在一个集群中存在多个NameNode，分别运行在独立的物理节点上。在任何时间点，只有一个NameNode是处于Active状态，其它的是处于Standby状态。 Active NameNode（简写为Active NN）负责所有的客户端的操作，而Standby NameNode（简写为Standby NN）用来同步ActiveNameNode的状态信息，以提供快速的故障恢复能力。

为了保证Active NN与Standby NN节点状态同步，即元数据保持一致。除了DataNode需要向这些NameNode发送block位置信息外，还构建了一组独立的守护进程”JournalNodes”（简写为JN）,用来同步Edits信息。当Active NN执行任何有关命名空间的修改，它需要持久化到一半以上的JNs上。而Standby NN负责观察JNs的变化，读取从Active NN发送过来的Edits信息，并更新自己内部的命名空间。一旦Active NN遇到错误，Standby NN需要保证从JNs中读出了全部的Edits，然后切换成Active状态，如果有多个Standby NN，还会涉及到选主的操作，选择一个切换为Active 状态。

元数据保持一致，包含两块，一个是静态的，一个是动态的

静态的是fsimage和edits，其实fsimage是由edits文件合并生成的，所以只需要保证edits文件内容的一致性。这个就是需要保证多个NameNode中edits文件内容的事务性同步。这块的工作是由JournalNodes集群进行同步的

动态数据是指block和DataNode节点的信息，这个如何保证呢？当DataNode启动的时候，上报数据信息的时候需要向每个NameNode都上报一份。这样就可以保证多个NameNode的元数据信息都一样了，当一个NameNode down掉以后，立刻从Standby NN中选择一个进行接管，没有影响，因为每个NameNode 的元数据时刻都是同步的。

使用zookeeper集群自动切换NameNode的原理 当多个NameNode 启动的时候会向zookeeper中注册一个临时节点，当NameNode挂掉的时候，这个临时节点也就消失了，这属于zookeeper的特性，这个时候，zookeeper就会有一个watcher监视器监视到，就知道这个节点down掉了，然后会选择一个节点转为Active，把down掉的节点转为Standby。 

namenode：hdfs的主节点datanode：hdfs的从节点 journalnode：JournalNode进程，用来同步Edits信息的 zkfc(DFSZKFailoverController)：监视namenode的状态，负责切换namenode节点的状态 zookeeper(QuorumPeerMain)：保存ha集群的节点状态信息