Hadoop02-HDFS分布式文件系统

第二章 分布式文件系统HDFS

2.1 HDFS简介

HDFS(Hadoop Distributed File System，Hadoop 分布式文件系统) 是Hadoop的存储服务，属于分布式文件管理系统的一种。通过集群来失陷其功能，通过统一的命名空间目录树来定位文件，它们为存储和处理超大规模数据提供所需的扩展能力。

HDFS适合一次写入，多次读出的场景，且不支持文件修改，适合用来做数据存储和分析。

2.2 HDFS的架构和重要概念

1. 架构

HDFS是典型的M/S架构（Master/Slave）

NameNode(nn) ： Master,他是集群管理者

• 管理HDFS命名空间（NameSpace）；
• 配置副本策略；
• 管理数据块（block）映射信息；
• 处理客户端的读写请求

DataNode(dn) : Slave,接手NameNode指令，执行具体的操作

• 存储实际的数据块；
• 执行数据块的读写操作

Client ：客户端

• 文件切分，文件上传到HDFS时，由client负责切分成Block；
• 与NameNode交互获取文件位置信息等元数据；
• 与DataNode交互，进行文件读写；
• 提供与一系列命令，可供用户管理和访问HDFS

2. HDFS的一些重要概念

• 分块存储(Block机制)

  HDFS中的文件，再物理上是分块存储的，快的大小可以通过参数配置（dfs.blocksize）Hadoop2.x版本中默认的block大小是128M；1.x是64M。

  一般来说寻址时间是传输时间的1%时，则为读写最佳状态；
  目前磁盘的传输速率普遍为100Mb/s；
  假设把寻址时间控制在10ms左右，则传输时间大概在1s,这时候最适合的块大小就是100MB左右；

  如果HDFS块设置的太小，块总数就很大，会增加寻址时间
  如果块设置太大，从磁盘传输数据的时间会增加，远远大于定位到这个快所需的时间，导致块处理时间变慢

  HDFS块大小设置主要取决于磁盘传输效率

• 命名空间（NameSapce）

  HDFS支持传统的层次型文件组织结构。用户或者程序可以创建目录，管理目录。文件系统命名空间的层次结构和常见的文件系统类似，用户可以创建，删除，，移动或者重命名文件，而不用关心文件存储的实际位置。

  NameNode负责维护文件系统的命名空间，任何对文件系统名字空间或者属性的修改都会被记录下来。

  HDFS提供给客户单一的抽象目录树，访问形式为：hdfs://namenode的hostname:port/test/input

  hdfs://linux121:9000/test/input

• 元数据管理

  HDFS的目录结构以及文件块的位置信息被称为元数据。NameNode的元数据记录了每一个文件所对应的Block信息，比如block的id,以及所在的节点信息

• 副本机制

  HDFS为了容错，所有存储的Block都会有副本，副本系数可以在文件创建的时候指定，也可以在之后改变。默认的数量是三个。

2.3 HDFS的数据流

2.3.1 HDFS写数据的流程

1. 写数据的流程

1. 客户端通过Distributed FileSystem模块像NameNode请求上传文件，那么node检查目标文件和父目录是否存在。

2. NameNode检查完毕之后返回是否可以上传。

3. 客户端向NameNode请求第一个Blockh上传到哪几个DadaNode服务器上。

4. NameNode返回三个节点，n1,n2,n3.

5. 客户端通过FSDataOutputStream模块请求向n1上传数据，n1收到请求后调用n2，n2继续调用n3，逐级建立通信管道。

6. 通信管道建立完成后，n3,n2,n1逐级应答客户端。

7. 客户端开始n1上传一个Block（磁盘到本地缓存），以一个更小的单位Packet（64KB）为单位上传，n1收到完整的Packet后传给n2，n2传给n3；在这个过程中，n1每传一个Packet都要放入一个队列等待确认。

8. 当第一个Block完全传给n1之后，客户端再次向NameNode请求上传第二个Block。一直循环到所有Block上传完成。

阅读源码 ： org.apache.hadoop.hdfs.DFSOutputStream

2. 节点距离计算

​ 在HDFS写数据的过程中，NameNode会选择距离待上传数据最近距离的DataNode接收数据。

​ 网络拓扑中节点距离： 两个节点到达最近的共同先祖节点的距离总和。

3. 副本配置策略

​ HDFS官网描述为：For the common case, when the replication factor is three, HDFS’s placement policy is to put one replica on the local machine if the writer is on a datanode, otherwise on a random datanode, another replica on a node in a different (remote) rack, and the last on a different node in the same remote rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure; this policy does not impact data reliability and availability guarantees. However, it does reduce the aggregate network bandwidth used when reading data since a block is placed in only two unique racks rather than three. With this policy, the replicas of a file do not evenly distribute across the racks. One third of replicas are on one node, two thirds of replicas are on one rack, and the other third are evenly distributed across the remaining racks. This policy improves write performance without compromising data reliability or read performance.（一般来说HDFS默认3副本，HDFS的放置策略是，如果写入器在datanode上，则将一个副本放在本地机器上，否则在随机datanode上，另一个副本放在不同(远程)机架中的节点上，最后一个副本放在同一远程机架中的不同节点上。该策略减少了机架间的写流量，从而提高了写性能。机架故障的概率远小于节点故障的概率;此策略不影响数据可靠性和可用性保证。然而，它确实减少了读取数据时使用的总网络带宽，因为一个块只放在两个唯一的机架中，而不是三个。使用此策略，文件的副本不会均匀地分布在机架上。三分之一的副本在一个节点上，三分之二的副本在一个机架上，另外三分之一均匀分布在其余机架上。在不影响数据可靠性和读性能的前提下，提高写性能。）

​ 总结：第一个副本在Client所处的节点上，如果客户端在集权外，随机选择一个；第二个副本在另一个机架的随机节点。第三个副本在第二副本所在的机架随机节点。

2.3.1 HDFS读数据的流程

1. 客户端的Distributed FileSystem向NameNode请求下载文件，NameNode查询元数据，找到文件快所在的DataNode节点，并返回给客户端。
2. 客户端选择一台DataNode服务器，请求读取数据。
3. DataNode收到请求后，奖数据块，从磁盘读取到本地缓存，开始以Packt为校验单位给客户端传输数据。
4. 客户端接手到数据，在本地缓存并检验，最终写入目标文件。

2.4 NameNode

2.4.1 元数据管理

1. 元数据管理方式

• HDFS的元数据管理采用的是内存+磁盘的方式，元数据加载到内存，可以快速响应客户端的各种请求操作，也能快速实现元数据的新增更新等操作，为了防止断电，也需要将元数据持久化到磁盘中，HDFS采用FsImage文件（fs镜像）来持久化元数据。
• 内存中的元数据理论上是实时变化的，同步更新FsImage文件或者直接把内存中的元数据dump(转存)到磁盘形成FsImage文件，会非常消耗NameNode资源，影响NameNode效率。如果不跟新，会导致数据不一致。
• 为了解决这个问题，HDFS使用只只追加写入的Edits文件（编辑日志），元数据变化的同时，把客户端更新元数据信息的每一步操作记录追加到Edits文件。只需要隔一段时间，对Edits文件和FsImage文件进行合并，就能得到完整的持久化元数据。
• 同时，HDFS为了避免日志合并给NameNode带来过大开销，使用Secondary NameNode来进行日志合并.

2. NameNode的元数据操作

1. 第一次启动NameNode格式化后，创建FsImage和Edits文件，如果不是第一次启动，直接把编辑日志和镜像文件加载到内存，形成完整的元数据。
2. 客户端对数据进行增删改操作。
3. NameNode记录操作日志，一定条件下则更新滚动日志（查询元数据的操作不会被记录在Edits中，因为查询操作不会更改元数据信息）。
4. NameNode在内存中对元数据进行修改。

3. Secondary NameNode的元数据操作

1. Secondary NameNode 向NameNode发出请求询问是否需要CheckPoint。NameNode返回请求结果。
2. 如果需要 （定时时间到了或者Edits中数据写满了），则secondary NameNode 请求执行CheckPoint。
3. NameNode 滚动正在写的编辑日志（生成一个空的edits.inprogress文件记录新的编辑日志），滚动前的所有没有合并的编辑日志和镜像文件拷贝到Secondary NameNode中。
4. Secondary NameNode 加载编辑日志（edits）和镜像文件(fsimage)到内存，进行合并，生成新的镜像文件fsimage.chkpoint。
5. 把fsimage.chkpoint拷贝到NameNode。
6. NameNode 把fsimage.chkpoint重新命名为fsimage替换原来的文件，形成新的镜像文件。

4. Fsimage与Edits文件解析

NameNode格式化后会在*/hadoop/data/tmp/dfs/name/current目录下产生如下文件：

• Fsimage文件：

  是namenode中关于元数据的镜像，一般称为检查点，这里包含了HDFS文件系统所有目录以及文件相关信息（Block数量，副本数量，权限等信息）。

• Edits文件 ：

  存储了客户端对HDFS文件系统所有的更新操作记录，Client对HDFS文件系统所有的更新操作都会被记录到Edits文件中（不包括查询操作）。

• seen_txid：

  该文件是保存了一个数字，数字对应着最后一个Edits文件名的数字。

• VERSION：

  该文件记录namenode的一些版本号信息，比如：CusterId,namespaceID等。
  

5. chockPoint时间设置

配置在[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 >

2.4.2 NN故障处理

• NameNode故障最主要的影响是导致元数据丢失，导致HDFS文件系统无法正长对外提供服务。主要有两种方式解决：
• 采用Secondary NameNode的镜像文件恢复，存在元数据丢失的风险。
• 一般生产使用都搭建HDFS的HA(高可用)集群，借助Zookeeper实现高可用，多个NameNode共同管理元数据（Active和Standby），ACtive故障能立马切换到正常的节点。

2.4.5 集群安全模式

• 安全模式是HDFS所处的一种特殊状态，在这种状态下，文件系统只接受读数据请求，而不接受删除、修改等变更请求。
• 在NameNode主节点启动时，HDFS首先进入安全模式，DataNode在启动的时候会向NameNode汇报可用的block等状态，当整个系统达到安全标准时，HDFS自动离开安全模式。如果HDFS出于安全模式下，则文件block不能进行任何的副本复制操作，因此达到最小的副本数量要求是基于DataNode启动时的状态来判定的，启动时不会再做任何复制（从而达到最小副本数量要求），HDFS集群刚启动的时候，默认30S钟的时间是出于安全期的，只有过了30S之后，集群脱离了安全期，然后才可以对集群进行操作。

//手动安全模式
hdfs dfsadmin -safemode

2.5 DataNode

1. DataNode工作机制

1. 一个数据块在DataNode，有两个文件存储在磁盘上，一个是数据本身，一个是元数据，包括数据块的长度，校验和，时间戳等。

2. DataNode注册通过后，周期性（一般一个小时）的向Name Node上报所有的块信息。

3. DataNode和NamoNode 保持心跳，每三秒一次，心跳返回结果中带有NameNode的命令，如复制数据块，删除数据块等。如果十分钟没收到心跳，NameNode则认为改节点不可用。

4. 由于副本机制的存在，集群运行中加入和退出一些DataNode节点是安全的。

2. DataNode数据完整性

1. DataNode在其文件创建后周期验证CheckSum.
2. 当Client读取Block的时候，它会计算CheckSum，如果计算后的CheckSum，与Block创建时值不一样，说明Block已经损坏，Client读取其他DataNode上的Block。
3. 常见的校验算法 crc（32），md5（128），sha1（160）

3. DataNode掉线判定

1. NameNode与DataNode保持心跳，没有同步心跳不会立刻把该节判定为节点死亡。

2. 默认超时时长是10分钟+30秒

   ##TimeOut计算公式：
   TimeOut = 2 * dfs.namenode.heartbeat.recheck-interval + 10 * dfs.heartbeat.interval
   ##dfs.namenode.heartbeat.recheck-interval默认值为5分钟
   ##dfs.heartbeat.interval默认值为3秒
   
   #hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒，dfs.heartbeat.interval的单位为秒。
   <property>
       <name>dfs.namenode.heartbeat.recheck-interval</name>
       <value>300000</value>
   </property>
   <property>
       <name>dfs.heartbeat.interval</name>
       <value>3</value>
   </property>
   

喜欢可以订阅专栏： 大数据笔记之Hadoop
上一篇： Hadoop-概述
下一篇： Hadoop-HDFS的客户端操作