首页 > 代码库 > Hadoop学习笔记之二:Hadoop体系架构

Hadoop学习笔记之二:Hadoop体系架构

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体系结构说明wKiom1P5qJ6iNNjKAAEekFUIDK0764.jpg


 

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

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

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

 

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

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

 

NameNode

  • NameNode作用:负责管理文件系统的命名空间(元数据),维护整个文件系统的文件目录树及这些文件的索引目录。

  • NameNode的文件结构(图示引用书籍:Hadoop实战)

wKioL1P5qdLjrcZaAAAv5gp5q94308.jpg

fsimage二进制文件,存储HDFS文件和目录元数据

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

fstime:二进制文件,fsimage做完一次checkpoint后,将最新的时间戳写入到fstime

  • VERSION文本文件,文件的内容为(图示引用书籍:Hadoop实战)

wKiom1P5qMzymOryAABPAzxRgPA901.jpg

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

 

  • 元数据

    包括文件和目录的ownershippermission

    文件包含哪些块,块的个数及块的副本数;

    块保存在哪个Datanode(由Datanode启动时上报);

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

wKioL1P5qfWxTfgNAAC_P5hc_EM937.jpg

  • 元数据分类:分为内存元数据和元数据文件

    元数据文件:包含fsimage&edits,存储在本地磁盘和NFS,防止NameNode所在机器磁盘坏掉后数据丢失

    内存元数据:包含fsimageBlockmap的映像。NameNode启动时会加载fsimage&edits文件到内存,merge后将最新的fsimage回写到本地磁盘和NFS,覆盖旧的fsimage文件

 

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

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

(一般NameNode会配置两个目录来存放fsimageedits文件,分别是本地磁盘和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实战)

wKiom1P5qPPhYZlyAABoZ1Wj8Hw596.jpg

 

Blk_refixHDFS中的文件数据块,存储的是原始文件内容

Blk_refix.meta:块的元数据文件:包括版本和类型信息的头文件,与一系列块的的区域校验和组成。

VERSION文本文件,文件的内容为:

wKioL1P5qiTQRfvOAAB1QGuATf0977.jpg

其中NamesopaceIDcTimelayoutVersionNameNode保持一致,namespaceID是第一次连接NameNode获得的。storageType对于DataNode来说是唯一的,用于NameNode表示DataNode

 

  • DataNode启动过程

    datanode启动时,每个datanode对本地磁盘进行扫描,将本datanode上保存的block信息汇报给namenode

    namenode在接收到每个datanode的块信息汇报后,将接收到的块信息,以及其所在的datanode信息等保存在内存中。

    Namenodeblock ->datanodes list的对应表信息保存在BlocksMap(如图所示)中wKioL1P5qjuQGLr0AACiceOnrZI253.jpg

 

Secondary NameNode

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

 

  • Secondary NameNode的作用

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

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

 

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

wKiom1P5qTShBIVzAAFDeRnqcP8316.jpg

说明:

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

第二步:Secondary NameNode通过HTTP方式读取NameNode中的fsimageedits

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

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

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

 

  • Secondary NameNode的文件结构(图示引用书籍:Hadoop实战)

wKiom1P5qUngOtVgAABcioCPBus165.jpg

  • 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


Hadoop学习笔记之二:Hadoop体系架构