Hadoop学习笔记之二：HDFS体系架构

HDFS简介

HDFS有着高容错性（fault-tolerant）的特点，并且设计用来部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。
1. HDFS有以下几个主要特点：
处理超大文件：存储的一个超大文件可以达到数GB级、数TB级、数PB级。
集群规模动态扩展：节点动态加入到集群，可以数百数千个
流式数据读写：HDFS的设计思想“一次写入，多次读取”，一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。
运行于廉价的商用机器集群上：HDFS设计时充分考虑了可靠性、安全性及高可用性，因此Hadoop对硬件要求比较低，可以运行于廉价的商用机器集群，无需昂贵的高可用性机器

2. HDFS的局限性：
不适合低延迟数据访问： HDFS是为了处理大型数据集，主要是为了达到高的数据吞吐量而设计，这就可能以高延迟作为代价。10毫秒以下的访问可以无视hdfs，不过hbase可以弥补这个缺
无法高效存储大量小文件： namenode节点在内存中存储住整个文件系统的元数据，因此文件的数量就会受到限制，每个文件的元数据大约150字节
不支持多用户写入及任意修改文件 ：不支持多用户对同一文件进行操作，而且写操作只能在文件末尾完成，即追加操作。

HDFS体系结构

HDFS的基本概念：

块（block）：
HDFS的文件以块的方式存储，块的大小默认为64MB。大于多数文件系统的块的大小。通常文件系统的块的大小为几千字节，磁盘块的大小为512B。

比磁盘块大很多，目的是减少寻址开销。如果块太小，大量的时间将花在磁盘块的定位时间上。

当HDFS文件小于块大小时，不会占满整个数据块的存储空间 ？？

HDFS体系结构说明

HDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanode组成。

Namenode是一个中心服务器，负责管理文件系统的命名空间和客户端对文件的访问。

Namenode执行文件系统的命名空间操作，例如打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。

Datanode负责处理文件系统的读写请求，在Namenode的指挥下进行block的创建、删除和复制

一个文件其实分成一个或多个block，这些block存储在Datanode集合里。

NameNode：

NameNode作用：负责管理文件系统的命名空间（元数据），维护整个文件系统的文件目录树及这些文件的索引目录。

NameNode的文件结构（图示引用书籍：Hadoop实战）：



fsimage：二进制文件，存储HDFS文件和目录元数据Edits：二进制文件，每次保存fsimage之后到下次保存之间的所有HDFS操作，记录在Edit s文件。对文件的每一次操作，如打开、关闭、重命名文件和目录，都会生成一个edit记录。fstime：二进制文件，fsimage做完一次checkpoint后，将最新的时间戳写入到fstimeVERSION：文本文件，文件的内容为（图示引用书籍：Hadoop实战）：



其中，namespaceID是文件系统的唯一标识符，当文件系统第一次被格式化的时候会被创建，这个标识符也要求所有的DataNode节点和NameNode保持一致。 NameNode会使用它识别新的DataNode，DataNode只有在向NameNode注册后才会获取namespaceID。 元数据
包括文件和目录的ownership和permission；
文件包含哪些块，块的个数及块的副本数；
块保存在哪个Datanode（由Datanode启动时上报）；

fsimage中的元数据结构如图所示：

元数据分类：分为内存元数据和元数据文件
元数据文件：包含fsimage&edits，存储在本地磁盘和NFS，防止NameNode所在机器磁盘坏掉后数据丢失
内存元数据：包含fsimage和Blockmap的映像。NameNode启动时会加载fsimage&edits文件到内存，merge后将最新的fsimage回写到本地磁盘和NFS，覆盖旧的fsimage文件

NameNode启动过程中fsimage文件处理流程

第一步：首先加载硬盘上的fsimage文件和edits文件，在内存中merge后将新的fsimage写到磁盘上，这个过程叫checkpoint（一般NameNode会配置两个目录来存放fsimage和edits文件，分别是本地磁盘和NFS，防止NameNode所在机器的磁盘坏掉后数据丢失。NameNode启动时会比较NFS和本地磁盘中的fstime中记载的checkpoint时间加载最新的fsimage。） 第二步：NameNode加载完fsimage&edits文件后，会将merge后的结果同时写到本地磁盘和NFS。此时磁盘上有一份原始的fsimage文件和一份checkpoint文件：fsimage.ckpt。同时edits文件为空。 第三步：写完checkpoint后，将fsimage.ckpt改名为fsimage（覆盖原有的fsimage），并将最新时间戳写入fstime文件

DataNode

DataNode的作用：
保存block
启动DataNode线程的时候会向NameNode汇报block信息
通过向NameNode发送心跳保持与其联系（3秒一次），如果NameNode10分钟没有收到DataNode的心跳，则认为其已经lost，并copy其上的block到其它DataNode

DataNode的文件结构（图示引用书籍：Hadoop实战）：



Blk_refix：HDFS中的文件数据块，存储的是原始文件内容Blk_refix.meta：块的元数据文件：包括版本和类型信息的头文件，与一系列块的的区域校验和组成。VERSION：文本文件，文件的内容为：

其中NamesopaceID、cTime、layoutVersion与NameNode保持一致，namespaceID是第一次连接NameNode获得的。storageType对于DataNode来说是唯一的，用于NameNode表示DataNode。 DataNode启动过程
datanode启动时，每个datanode对本地磁盘进行扫描，将本datanode上保存的block信息汇报给namenode
namenode在接收到每个datanode的块信息汇报后，将接收到的块信息，以及其所在的datanode信息等保存在内存中。
Namenode将block ->datanodes list的对应表信息保存在BlocksMap（如图所示）中。

Secondary NameNode

为了提高NameNode的可靠性，从Hadoop 0.23开始引入了Secondary NameNode。

Secondary NameNode的作用

Fsimage是HDFS存储元数据的文件，它不会在HDFS的每次文件操作（如打开、查询、创建、修改文件）后进行更新。而HDFS的每一次文件操作会增加一条edits记录。这样会出现edits记录不断增加的情况。
这种设计不影响系统的恢复能力。因为如果Namenode失败了，元数据的最新状态可以通过从磁盘中读出fsimage文件加载到内存中来进行重新恢复，然后重新执行edits记录中的操作，这也正是NameNode重新启动时所做的事情。但是如果edits记录很多，NameNode启动时会花很长的时间来运行edits记录中的操作。在此期间，HDFS文件系统是不可用的。

为了解决这个问题，Hadoop在NameNode之外的节点上运行了一个Secondary NameNode进程。Secondary NameNode定期从NameNode拷贝fsimage和edits记录到临时目录并合并成一个新的Fsimage，随后它将新的fsimage上传到NameNode，这样NameNode便会更新fsimage并删除原来的编辑日志。这个过程叫checkpoint。具体过程如下：



说明：
第一步：Secondary NameNode首先请求NameNode进行edits的滚动，这样NameNode开始重新写一个新的edit log
第二步：Secondary NameNode通过HTTP方式读取NameNode中的fsimage及edits
第三步：Secondary NameNode读取fsimage到内存中，然后执行edits中的每个操作，并创建一个新的统一的fsimage文件。
第四步：Secondary NameNode通过HTTP方式将新的fsimage发送到NameNode
第五步：NameNode用新的fsimage替换旧的fsimage，旧的edits文件用步骤1中的edits进行替换，同时系统会更新fsimage文件记录检查点时间

Secondary NameNode的文件结构（图示引用书籍：Hadoop实战）：



Secondary NameNode不足之处：
因为Secondary namenode并不是实时进行checkpoint，所以当还没有进行下一次checkpoint的时候namenode出现了硬件故障同时又没有通过NFS存储元数据，那么Namenode中自上次checkpoint之后到故障发生期间的所有edits文件将丢失。因为此时secondary namenode存的只有上一次的fsimage文件，没有最新的edits文件，无法通过secondary namenode进行这段时间内的数据恢复。
Secondary NameNode不是NameNode的备份进程，如果NameNode宕机了，而SecondaryNameNode没有宕机，集群照样不能正常工作。如果要恢复集群工作，需要手动将Secondary NameNode上的fsimage文件拷贝到新的NameNode上面。

为了解决以上问题，从Hadoop2.0开始，引入了高可用HA NameNode