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

最新推荐文章于 2021-06-04 21:44:01 发布

weixin_34080903

最新推荐文章于 2021-06-04 21:44:01 发布

阅读量135

点赞数

文章标签：运维大数据

原文链接：http://blog.51cto.com/bobbleyan/1544151

版权

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实战）：

fsp_w_picpath：二进制文件，存储HDFS文件和目录元数据

Edits：二进制文件，每次保存fsp_w_picpath之后到下次保存之间的所有HDFS操作，记录在Edit s文件。对文件的每一次操作，如打开、关闭、重命名文件和目录，都会生成一个edit记录。

fstime：二进制文件，fsp_w_picpath做完一次checkpoint后，将最新的时间戳写入到fstime

VERSION：文本文件，文件的内容为（图示引用书籍：Hadoop实战）：

其中，namespaceID是文件系统的唯一标识符，当文件系统第一次被格式化的时候会被创建，这个标识符也要求所有的DataNode节点和NameNode保持一致。 NameNode会使用它识别新的DataNode，DataNode只有在向NameNode注册后才会获取namespaceID。

元数据
包括文件和目录的ownership和permission；
文件包含哪些块，块的个数及块的副本数；
块保存在哪个Datanode（由Datanode启动时上报）；

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

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

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

第一步：首先加载硬盘上的fsp_w_picpath文件和edits文件，在内存中merge后将新的fsp_w_picpath写到磁盘上，这个过程叫checkpoint

（一般NameNode会配置两个目录来存放fsp_w_picpath和edits文件，分别是本地磁盘和NFS，防止NameNode所在机器的磁盘坏掉后数据丢失。

NameNode启动时会比较NFS和本地磁盘中的fstime中记载的checkpoint时间加载最新的fsp_w_picpath。）

第二步：NameNode加载完fsp_w_picpath&edits文件后，会将merge后的结果同时写到本地磁盘和NFS。此时磁盘上有一份原始的fsp_w_picpath文件和一份checkpoint文件：fsp_w_picpath.ckpt。同时edits文件为空。

第三步：写完checkpoint后，将fsp_w_picpath.ckpt改名为fsp_w_picpath（覆盖原有的fsp_w_picpath），并将最新时间戳写入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的作用

Fsp_w_picpath是HDFS存储元数据的文件，它不会在HDFS的每次文件操作（如打开、查询、创建、修改文件）后进行更新。而HDFS的每一次文件操作会增加一条edits记录。这样会出现edits记录不断增加的情况。

这种设计不影响系统的恢复能力。因为如果Namenode失败了，元数据的最新状态可以通过从磁盘中读出fsp_w_picpath文件加载到内存中来进行重新恢复，然后重新执行edits记录中的操作，这也正是NameNode重新启动时所做的事情。但是如果edits记录很多，NameNode启动时会花很长的时间来运行edits记录中的操作。在此期间，HDFS文件系统是不可用的。

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

说明：

第一步：Secondary NameNode首先请求NameNode进行edits的滚动，这样NameNode开始重新写一个新的edit log

第二步：Secondary NameNode通过HTTP方式读取NameNode中的fsp_w_picpath及edits

第三步：Secondary NameNode读取fsp_w_picpath到内存中，然后执行edits中的每个操作，并创建一个新的统一的fsp_w_picpath文件。

第四步：Secondary NameNode通过HTTP方式将新的fsp_w_picpath发送到NameNode

第五步：NameNode用新的fsp_w_picpath替换旧的fsp_w_picpath，旧的edits文件用步骤1中的edits进行替换，同时系统会更新fsp_w_picpath文件记录检查点时间

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

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