图文详解HDFS工作机制

本篇主要从下面几个方面进行展开

• HDFS是什么
• 漫画看懂HDFS骚操作
• HDFS架构原理

一、HDFS是什么

HDFS（Hadoop Distributed File System）分布式文件系统，它是谷歌的GFS提出后出现的一种用户级文件系统。提供了一个高度容错和高吞吐量的海量数据存储解决方案。

hadoop生态-HDFS的核心位置

二、漫画看懂HDFS骚操作

2.1 写操作

1

2

3

2.2 读操作

2.3 容错性

常见错误种类

节点故障

通信故障和数据损坏

读写故障

以上是漫画解说部分，主要涵盖了读写流程已经故障处理。下面会有具体的架构讲解。

三、HDFS架构原理

3.1 HDFS几个主要概念

3.1.1 NameNode

• 维护和管理DataNodes
• 管理文件系统namespace并控制client对应的访问权限
• 记录所有存储在集群中的文件的元信息。eg: blocks存储的位置、文件的大小、权限、文件结构等，有两个文件和元数据关联着
• FsImage
• 保存了最新的元数据检查点，包含了整个HDFS文件系统的所有目录和文件的信息。对于文件来说包括了数据块描述信息、修改时间、访问时间等；对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等。
• 一般开始时namenode的操作都放在EditLog中，然后通过异步更新。
• EditLog
• 记录最近通过namenode对文件系统的所有修改操作。
• 记录文件系统的所有操作元数据。 存储在 EditLogs
• 维护着与DataNodes的心跳检测
• DataNodes磁盘存储均衡、DataNodes故障转移

3.1.2 DataNode

数据存储节点

3.1.3 Secondary NameNode

它的主要职责

• 备用节点，也称为standby namenode。NameNode是HDFS的大脑核心，一旦NameNode出现不可用，那么整个HDFS集群将不可用，Secondary NameNode作为NameNode的备用节点，进行NameNode容错
• 负责合并Editlogs和FsImage
• 定时从 namenode 下载Editlogs并和现有FsImage进行合并，然后将合并后的FsImage更新到namenode

FailoverController

故障切换器，管理着将活动namenode转移为备用namenode的过程，默认通过ZK来确保仅有一个活跃namenode。每一个namenode都有一个运行着的故障转移器。

3.1.4 Balancer

用于平衡DataNode集群之间各节点的磁盘利用率。

3.1.5 HttpFS

提供Http方式访问和操作HDFS功能

上面几个概念的拓扑图

3.2 Block数据块

HDFS里的数据都是以blocks分散在DataNodes。

通常，文件系统我们存放数据都是以一个blocks集进行存储，HDFS也是如此。

在 hadoop 集群中，每个 block 的默认大小为 128M（此处指 hadoop 2.x 版本，hadoop 1.x 版本为 64M），也可以通过配置进行修改

dfs.block.size或 dfs.blocksize =64M

HDFS 不会将每个文件存储在配置的 block 大小的确切倍数中，比如一个 514M 的文件 example.txt，下图所示，假设 block 大小为默认的 128M，那么将会创建 5 个block，前 4 个 block 大小为 128M，但是最后一个 block 的大小则仅为 2M。

block大小的设置，如果太小会产生太多的blocks，这样元数据就会很多，从而使管理blocks和元数据产生巨大开销，增加NameNode和DataNode的负载。

3.3 写原理

假如我们要一个文件名字“example.txt”，248M。

假设block.size设置的128M，因此client会把该文件切分成两个block，分布是 128M和120M。

每当向HDFS写数据的时候，都遵循下面的几个流程

• HDFS client 向NameNode 发送 两个blocks（blockA、blockB）的写入请求
• NameNode给client进行写入授权并提供用来进行存储和复制的DataNodes IP
• DataNodes基于HDFS可用性、复制因子和机架感知的选择是完全随机的
• 假设复制因子设置的是3，那么NameNode将为每个blocks提供3个DataNodes IP。 相对每个block提供的3个DataNodes都是唯一的。假设NameNode提供的DataNodes列表如下：

For Block A, list A = {IP of DataNode 1, IP of DataNode 4, IP of DataNode 6}For Block B, set B = {IP of DataNode 3, IP of DataNode 7, IP of DataNode 9}

• 每个block将在三个不同的DataNode进行复制，维持整个集群的复制因子一致性
• 接下来整个数据将会经历下面三个阶段：1建立管道 2数据流与复制 3管道关闭及确认

3.3.1 建立管道

client在blocks写入之前会确保提供的DataNodes是否已经做好接受数据的准备。在这样的情况下，client会连接该block列表中的各个DataNodes，为每个block建一个管道。以BlockA举例，它的DN(DataNode)列表是 { DN 1 IP， DN 4 IP, DN 6 IP }

如上图，大概有一下几个步骤：

• client 拿着 blockA 向 NameNode发起写请求
• NameNode返回一组可供存储和复制的DN IP列表
• client向 DN1 进行写入准备确认，同时会告诉DN1接下来要进行复制的DN4和DN6的IP
• DN1 会向 DN4发起写入准备确认，依次类推DN4给DN6发送确认
• DN6 确认完毕回传给 DN4，DN4确认后会将自己以及DN6的确认信息给DN1，最后DN1将三个DN的确认结果答复给client
• 管道建立完毕，client将开始进行数据复制或者数据处理

3.3.2 数据流与复制

当client与DataNodes之间的管道建立之后，client将开始将推送数据到管道。我们这里假设的复制因子是3，所以blockA将被复制三份，但是注意的是client只会将blockA推送到DN1，然后由DataNodes自己按照顺序进行复制。

如上图所示，整个复制过程步骤如下：

• client 将blockA写入DN1，接着DN1连接DN4
• DN1通过管道向DN4复制数据
• DN4数据写完后会继续连接DN6进行最后一份数据的复制

3.3.3 管道关闭和确认

当block复制3份完成后，client和NameNode会有一系列的ack确认来保证数据被成功写入。

如下图所示，DataNodes的确认和写入的顺序恰好相反，DN6写入成功后会给DN4发送确认消息，接着DN4会将DN6和自己的确认消息发送给DN1，最后DN1将所有的确认消息发送给client，client再给NameNode确认block写入成功，然后NameNode更新对应的元数据，最终client关闭管道。

以上的所有流程，我们都是针对blockA进行解说，而blockB是完全一样的，blockB有自己的管道、自己的DataNodes并行的进行写入。

如上图所示，有两个管道分别为blokA和blockB提供，他们各自的流程顺序如下：

• For Block A: 1A -> 2A -> 3A -> 4A
• For Block B: 1B -> 2B -> 3B -> 4B -> 5B -> 6B

3.4 读原理

读的原理相对写更容易理解，我们同样以example.txt举例。

如上图所示，有以下几个步骤

• client请求NameNode 要读取example.txt的数据，NameNode查询元数据，将该文件对应的所有block及对应的DataNode列表返回
• client并行的分别从DataNodes读取blockA和blockB的数据。为了保证低延迟和节约带宽，通常会选择离client近的副本进行读取，如果可能，会选择和阅读节点在同一个机架上的副本（如图中所示，选择了Rack1, blockA和blockB都有对应的副本）
• client一旦获取到所有的block，就会开始组装成文件，并返回。

最后

本篇先以漫画的方式阐述场景HDFS 读写流程，然后又以HDFS里的概念进行进一步的描述，相信大家已经对此有所了解。