Hadoop系列（一）——身体是革命的本钱 HDFS体系结构（NameNode、DataNode）详解

HDFS简介

以往的企业需要处理的数据往往是企业内部员工相关的数据，受限于员工数量的相对广大全民用户比较少，往往单机就能管理和储存这些数据；而在现代的企业环境中，随着互联网的普及，广大全民用户涌入，自然而然的为企业涌入了海量的数据，单机容量往往无法存储大量数据，需要跨机器存储。以统一管理分布在集群上的文件系统称为分布式文件系统就此应运而生；而当分布式文件系统与网络互通时最大的难点就是如果保证在节点不可用的时候数据不丢失。分布式文件系统的发展有以下两大阶段：

传统分布式文件系统

如下图所示：传统的网络文件系统（NFS）虽然也称为分布式文件系统，但是其存在一些限制。由于NFS中，文件是存储在单机上，因此无法提供可靠性保证，当很多客户端同时访问NFS Server时，很容易造成服务器压力，造成性能瓶颈。另外如果要对NFS中的文件中进行操作，需要首先同步到本地，这些修改在同步到服务端之前，其他客户端是不可见的。某种程度上，NFS不是一种典型的分布式系统，虽然它的文件的确放在远端（单一）的服务器上面。

严格意义上来说。传统分布式文件系统管理上还是单机模式，只不过解决了储存上的难点。其依然受限于主机计算节点和管理CPU的性能，处理的数据量依然还是少量的。

hadoop HDFS分布式文件系统

HDFS是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统，能检测和应对硬件故障，用于在低成本的通用硬件上运行。

HDFS简化了文件的一致性模型，通过部署在datanode上的分布式文件系统以流式数据访问模式来存储超大文件，提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序。此外它提供了一次写入多次读取的机制，数据以块的形式，同时分布在集群不同物理机器上。简单的来说将数据的存储和管理分布在各个集群节点上，降低以往单机模式性能对数据处理的影响，同时还能降低集群成本。

HDFS特点：

1. 数据冗余，硬件容错
2. 流式的数据存储；不适合低延时的数据访问
3. 存储大文件；不适合大量小文件
4. 适合数据批量读写，吞吐量高；不适合交互式应用，低延迟很难满足
5. 适合一次写入多次读取，顺序读写；不支持多用户并发写相同文件

HDFS 体系结构

HDFS体系结构图如下：

hadoop 的HDFS体系结构主要有Blocks、NameNode和DataNode组成。

blocks

物理磁盘中有块的概念，磁盘的物理Block是磁盘操作最小的单元，读写操作均以Block为最小单元，一般为512 Byte。HDFS这类分布式文件体系同样也有块的概念，它的底层正好封装了底层的block块。

HDFS的blocks：

HDFS上的文件被划分为块大小的多个分块，作为独立的存储单元，称为数据块，2.7.3版本开始，默认block size由64MB变成了128 MB。

比如说一个300MB的文件会被拆分为2个128MB和1个44MB的文件储存在HDFS上。当一个文件很小的时候，也会以128MB的形式存储，不过它实际占用的空间还是实际大小的容量，而不是128MB，只不过是以128MB的形式去存储。当然这样没有意义，因为hadoop 是为大数据而生的，少量的数据根本不适合，也不会选择hadoop 生态圈。

HDFS的Blocks为什么这么大？

是为了最小化查找（seek）时间，控制定位文件与传输文件所用的时间比例。假设定位到Block所需的时间为10ms，磁盘传输速度为100M/s。如果要将定位到Block所用时间占传输时间的比例控制1%，则Block大小需要约100M。
但是如果Block设置过大，在MapReduce任务中，Map或者Reduce任务的个数 如果小于集群机器数量，会使得作业运行效率很低。

HDFS块大小如何设定？

全局修改：hadoop 配置文件 hdfs-default.xml

<property>
  <name>dfs.blocksize</name>   #block块存储的配置信息
  <value>134217728</value>   #这里的块的默认容量是128M，请注意单位为字节；这里可以指定block的大小
  <description>
      The default block size for new files, in bytes.
      You can use the following suffix (case insensitive):
      k(kilo), m(mega), g(giga), t(tera), p(peta), e(exa) to specify the size (such as 128k, 512m, 1g, etc.),
      Or provide complete size in bytes (such as 134217728 for 128 MB).
  </description>
</property>

局部文件修改

如果想单独对某个文件修改，采用命令如hadoop fs -Ddfs.blocksize=134217728 -put ./test.txt /test即可。

NameNode

NameNode是整个文件系统的管理节点。NameNode在内存中保存着整个文件系统(hdfs)的命名空间(namespace）和文件数据块的地址映射(Blockmap)。整个HDFS可存储的文件数受限于NameNode的内存大小。

它的功能如下：

1. NameNode负责文件元数据信息的操作以及处理客户端的请求
2. NameNode管理HDFS文件系统的命名空间NameSpace
3. NameNode维护文件系统树(FileSystem）以及文件树中所有的文件和文件夹的元数据信息(matedata)；最主要的是维护文件到块的对应关系和块到节点的对应关系据信息(matedata)
4. NameNode文件有 namespace镜像文件(fsimage)和操作日志文件(edit log)；这些信息被Cache在RAM中，当然这两个文件也会被持久化存储在本地硬盘。
5. NameNode记录每个文件中各个块所在的数据节点的位置信息。但它并不永久保存块的位置信息，因为这些信息在系统启动时由数据节点重建。
6. 两个namenode为了数据同步，通过journalnode的独立进程进行通信。

DataNode

DataNode数据节点负责存储和提取Block，读写请求可能来自namenode，也可能直接来自客户端。DataNode定时和NameNode进行通信，上报来更新NameNode上的映射表。并接受NameNode的指令。

DataNode 具体功能如下：

1. 一个数据块在DataNode以文件存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳；
2. DataNode启动后向NameNode注册，通过后，周期性(1小时)的向NameNode上报所有的块信息；
3. 心跳是每3秒一次，心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳，则认为该节点不可用；
4. 集群运行中可以安全加入和退出—些机器。
5. DataNode之间还会相互通信，执行数据块复制任务。同时，在客户端执行写操作的时候，DataNode之间需要相互配合，以保证写操作的一致性。

Secondary NameNode

在HDFS集群中，NameNode依然是单点故障（SPOF）。元数据同时写到多个文件系统以及Second NameNode定期checkpoint有利于保护数据丢失，但是并不能提高可用性。当NameNode故障时，常规的做法是使用元数据备份重新启动一个NameNode。元数据备份可能来源于多文件系统写入中的备份和Second NameNode的检查点文件中的一个。下面我主要介绍一下Secondary NameNode的元数据备份原理。

在谈Secondary NameNode之前先了解其内部和nameNode交互的两个概念edits和fsimage。

edits 操作日志文件

edits为二进制文件，记录对HDFS的各种更新操作，客户端执行所有的写操作都会被记录到editlog中。比如创建文件，删除文件。打开、关闭、重命名文件和目录，都会生成一个edit记录。edits是在NameNode启动后，对文件系统的改动序列。

客户端对hdfs进行写文件时会首先被记录在edits文件中。edits修改时元数据也会更新。每次hdfs更新时edits先更新后客户端才会看到最新信息。

fsimage 元数据镜像文件

fsimage为二进制文件，保存了最新的元数据检查点，包含了整个HDFS文件系统的所有目录和文件信息。对于目录来说包括修改时间、访问权限控制信息(目录所属用户，所在组)等；对于文件来说包括数据块描述信息、修改时间、访问时间等。简单的说，**fsimage就是在某一时刻，整个hdfs元数据信息的快照。**也就是说在这个时刻hdfs上所有的文件块和目录，分别的状态，位于哪些个datanode，各自的权限，副本个数等。值得注意的是，Block的位置信息不会保存到fsimage，由DataNode在向NameNode进行注册时重新加载和定期加载。

Secondary NameNode与NameNode交互过程

Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。具体如下图所示：

Secondary NameNode与NameNode交互过程可分为以下6步：

1. 一般开始时对namenode的操作都放在edits中，并且这个edits是一个新的edits.new。为什么不放在fsimage中呢?因为fsimage是namenode的完整的镜像，内容很大，如果每次都加载到内存的话生成树状拓扑结构，这是非常耗内存和CPU。
2. 过程中会不断的对nameNode进行操作，edits logs文件因此会变的很大，但是NameNode的重启会花费很长时间，为了更好的解决这个问题。会将namenode中的edits和fsimage备份到Secondary NameNode进行处理，同时缓解了NameNode的负载。
3. 在Secondary NameNode去更新最新的操作日志文件edits和元数据文件发生变化的信息。
4. 合并Secondary NameNode中更新的edits和fsimage文件为fsimage.ckpt，就是临时副本，并上传到 NameNode。
5. 将接受到的fsimage.ckpt去覆盖原有的fsimage中的内容。
6. 同时更新最新的edits去覆盖原有的edits.new文件内容。

简单的说，Secondary NameNode把每个时刻文件和目录的元数据信息持久化地存储到fsimage文件中，将元数据加载到内存中构建目录结构树之后的操作记录在edits log中，定期将edits与fsimage合并刷到fsimage中，然后上传到NameNode中覆盖其原有的fsimage文件，同时更新一次edits文件内容。NameNode在下次重启时会使用这个新的fsimage文件，减少重启的时间。

数据流读写实例

下图是一个sky.avi文件的读写流程图：

数据流读写操作过程中都会涉及到hadoop YARN集群资源管理器，详情请参考下一篇Hadoop系列（二）——灵魂管理者 YARN 详解

写sky.avi文件操作

客户端申请上传一个300MB大小的sky.avi文件。namenode中通过hadoop YARN这个核心会返回一个hdfs路径，要求其上传到该路径上，具体如下：

1. HDFS会将文件默认分为2个128MB和1个44MB的块P1,P2和P3。然后客户端向NameNode申请写入P1请求，NameNode收到请求，并确认，返回一个可以写入的信息给客户端；
2. 客户端收到NameNode的回应后，开始向NameNode申请上传文件块P1请求；NameNode收到请求，并确认，返回一个可以上传的节点编号给客户端（此处默认文件副本为3）；
3. 客户端收到NameNode的回应后，开始申请上传传输通道。可以理解先确保每个节点均可以上传文件块P1。它会依次向NameNode所提供的节点编号dn1,dn3和dn4申请上传传输通道。必须所有的节点的传输通道都确认畅通，才可以上传；只要有一个不畅通；客户端会向NameNode重新申请上传P1。
4. 所有节点的传输通道确保畅通后，开始上传P1到每个节点，上传成功后每个节点都会有一个应答返回给客户端，只有所有的节点的应答都是成功的，文件P1才会上传成功。一旦 失败，重新上传。
5. 文件块P2和P3按1-4步骤以此类推，P1、P2和P3所有都上传成功，文件sky.avi就会上传成功。

读sky.avi文件操作

客户端申请下载一个300MB大小的sky.avi文件。namenode中通过hadoop YARN这个核心会返回一个hdfs路径，要求其到该路径上下载该文件，具体如下：

1. 客户端向NameNode申请读取sky.avi请求，NameNode收到请求，并确认，返回一个可以读取的信息给客户端；同时HDFS会把sky.avi数据信息，包括分片信息共享给NameNode,NameNode把分片信息一道发送给客户端；
2. 客户端收到NameNode的回应后，开始向NameNode申请下载文件块P1请求；NameNode收到请求，并确认，返回一个可以下载的节点编号给客户端；比如说P1可以从dn3读取、P2可以从dn2读取和P3可以从dn1读取；
3. 客户端收到NameNode的回应后，开始下载sky.avi文件。此时，hadoop YARN会管理调度，启动一个APP Master去负责取出你要读取内容的文件块：P1可以从dn3读取、P2可以从dn2读取和P3可以从dn1读取；同时YARN会在内部启动一个MapReduce任务，去整合这三块的文件信息；将结果返回给客户端。
4. 客户端下载sky.avi成功。