2.1 Hadoop1.x的架构

2016-03-04 01:49:27 5,606 1


本教程讲解的是Hadoop2.x,不过个人觉得有必要介绍一下Hadoop1.X中的架构,可以作为知识补充,也可以作为对技术发展历史的了解。

Hadoop起源于Nutch(搜索引擎),搜索殷勤有两个非常重要的部分:存储大量的网页索引数据、高效的检索。在Hadoop1.x中,存储部分使用的是分布式文件存储系统(HDFS),计算部分使用的是MapReduce。我们都知道Hadoop是分布式的集群,事实上,在Hadoop中,Hdfs和MapReduce是两套分布式架构。HDFS是分布式存储,MapReduce是分布式计算。因此本节主要讲解的就是这两套分布式架构。

一、HDFS架构

HDFS是用来存储数据的,其使用的分布式开发中主从架构(master/slave)。master节点只有一个,称之为NameNode;slave节点可以有多个,称之为DataNode。(补充说明节点并不一定是指一个单独的物理机器,更准确的说,节点指的是一个进程。如果你在一台机器上,启动了多个slave,我们也称之为多个slave节点。)

简单来说,NameNode是管理文件元数据的,而DataNode负责实际上的文件存储

因为HDFS是分布式的文件存储系统,假设用户要从HDFS中读取文件,首先必须定位到这个文件位于哪一个节点上,一台一台机器去遍历明显是低效率的。如果有一个地方,存储了所有的文件位置信息并可以高效的查询,那么必然会提高效率,NameNode干的就是这个事。个人理解,NameNode中的Name,就是指的是文件的路径信息。当然用户不会只是查询,还会有一些存储需求,那么到底上传到哪个DataNode呢?随机找一个明显是不可以的,最简单的限制因素,可能这个DataNode的存储空间不够了。所以,用户的请求也是由NameNode负责的,NameNode知道哪个DataNode存储空间是足够的,那个DataNode当前不是那么繁忙。从而将用户的请求转发到合适的DataNode上。此外,Hadoop为了保证数据的安全性,默认情况下,一个数据文件会被存储3个备份,当然每个备份位于不同的DataNode节点上,这样即使某个DataNode的硬盘坏了,其他的DataNode上的数据还可以继续使用。

以下列出了NameNode和DataNode各自的责任。

namenode负责: 

  接收用户操作请求

  维护文件系统的目录结构

  管理文件与block之间关系,block与datanode之间关系,可以类比这里的block为linux文件中的block,一个文件会存储到多个block中。

datanode负责:

  存储文件

  文件被分成block存储在磁盘上

  为保证数据安全,文件会有多个副本 


补充:关于HDFS中Block的概念,实际上就相当于文件系统中的概念。如下图:

QQ截图20160303232243.png

这是一个txt文件,实际大小只有2.66KB,但是占用空间确是4KB。为什么会这样呢?文件系统在格式化的时候,让我们指定最小的存储单位是多少。最小的存储单位就是的概念。如果一个文件占用空间小于簇的大小,那么其占用空间就是1个簇。如果文件过大,就会占用多个簇。合理的簇大小的设置,会提高磁盘的检索效率。很明显,在磁盘扫描的时候,如果一个文件存储在多个簇中,那么将会增加扫描的时间,如果分配在一个簇中,那么可能磁盘转动一次就扫描到了。有的读者可能会想,那么簇是不是设置的越大越好呢?答案是不行的,因为簇是最小的存储单位,假设你设置簇大小是10M,那么意味着即使一个1KB的文件,也需要占用10M的存储空间。总结下来就是,簇设置的过小,会增加文件检索的时间;簇设置的过大,会造成磁盘空间的浪费。

如果将上述簇的概念替换成HDFS中block概念,相信读者就能很好的理解了。

二、MapReduce的架构

MapReduce是Hadoop中用于分布式计算的框架。其遵循的也是主从架构。主节点称之为JobTracker(只有一个),从节点称之为TaskTracker(可以有多个)

分布式计算是什么概念呢?

举例来说,假设我们要从10亿个随机的数字中,挑选出值是最大的哪一个。如果一台机器来执行,可能需要执行很长时间。但是如果我们有10台机器,那么每台机器只要处理1亿条,10台机器各自挑选出自己负责的1亿条数据的最大值,然后将10台机器各自的最大值汇总再进行比较,很明显计算的时间会大大缩短。这就是分布式计算,将一个计算的任务由多台计算机联合进行处理。当然如果计算任务很简单,只是从100个数字中挑出最大值,那么一台机器毫秒级时间就可以算出。这种简单的任务不应该使用分布式计算,毕竟分布式计算是需要在多个节点之间进行网络通信的,这都需要时间。

具体到Hadoop,当用户提交一个计算的任务时,任务需要进行切分之后再处理。JobTracker负责接收用户提交的任务,分割之后交由TaskTracker处理。可能某个TaskTracker当前正在执行其他的运算任务,因此JobTracker需要负责将任务分配给相对空闲的TaskTracker,而不是随机分配。此外,如果某个TaskTracker在运行任务的时候如果失败了(例如宕机),JobTracker还需要将分配给这个TaskTracker的任务重新分配给其他的TaskTracker。

以下列出了JobTracker和TaskTracker的主要职责:

JobTracker负责: 

  接收客户提交的计算任务

  把计算任务分给TaskTrackers执行

  监控TaskTracker的执行情况 

  TaskTrackers负责: 

  执行JobTracker分配的计算任务


三、Hadoop集群的物理分布

11.png


Switch是交换机(路由器)Rack代表机房里的一个机柜,每个机柜里都有很多台服务器,称之为节点。

从上图中可以看出,不管有多少个机柜,只有一个机柜里面可以有JobTrackerNamenode。其他的机柜里是没有的,因此在一个hadoop集群中,JobTrackerNamenode只有一个,一般部署在不同的节点上。每一个具体的节点上即每一台服务器上同时设置了TaskTrakerDataNode


关于hadoop集群部署的几个要思考的问题:


问题1:既然只有一个机柜里面有JobTrackerNameNode,那么其他的机柜如何处理请求?

收到客户端的请求后,都是统一发送给JobTrackerNameNode,虽然不在一个机柜里面,但是由于是通过交换机进行连接的,因此一个机柜中的主机不光可以把任务分配给自己所属机柜里面的节点处理,也可以分配到其他机柜里的节点处理。是可以把请求分配到其他的机柜里的节点处理。

  

问题2:为什么JobTracker和Namenode需要单独的部署,而多个节点上会同时部署TaskTracker和DataNode?

        单独部署JobTracker和Namenode主要是因为,所有的用户对于HDFS操作的请求都会转发到NameNode,所有的运算MapReduce任务都会转发JobTracker。因此这两个节点运行是的压力是比较大的。因此这两个节点不光要单独配置,而其机器的性能还要非常好。

        TaskTracker和DataNode一个是负责实际的数据存储,一个负责实际的运算任务。假设一台物理机上同时部署了TaskTracker和DataNode,当TaskTracker任务中所需的数据刚好来自同一台机器上的DataNode,那么不需要走网络传输,既可以获取数据,提高效率。如果单独部署,那么数据的来源可能就需要经过网络,效率降低。


四、单点物理结构

22.png

从上图可以看出来,Hadoop中的主从节点的区别,是根据服务器上运行的程序来进行划分的

如果服务器上运行的NameNodeJobtracker,那么这个节点就是主节点。

如果服务器上运行的是TaskTrackerdatanode,那么这个节点就是从节点。

上图中,NameNodeJobTracker,Secondary NameNode一般都是部署在不同的机器上。

五、关于SecondNameNode的补充

在hadoop中,namenode负责对HDFS的metadata的持久化存储,并且处理来自客户端的对HDFS的各种操作的交互反馈。为了保证交互速度,HDFS文件系统的metadata是被load到namenode机器的内存中的,并且会将内存中的这些数据保存到磁盘进行持久化存储

为了保证这个持久化过程不会成为HDFS操作的瓶颈,hadoop采取的方式是:没有对任何一次的当前文件系统的snapshot进行持久化,对HDFS最近一段时间的操作list会被保存到namenode中的一个叫Editlog的文件中去(并没有直接于当前的元数据fsImage进行合并)。当重启namenode时,除了load fsImage以外,还会对这个EditLog文件中记录的HDFS操作进行replay,以恢复HDFS重启之前的最终状态。

而SecondaryNameNode,会周期性从NameNode上下载元数据信息(fsimage,edits),然后把二者合并,生成新的fsimage,在本地保存,并将其推送到NameNode,同时重置NameNode的edits。具体操作的将EditLog中记录的对HDFS的操作合并到一个checkpoint中,然后清空 EditLog。所以namenode的重启就会Load最新的一个checkpoint,并replay EditLog中 记录的hdfs操作,由于EditLog中记录的是从 上一次checkpoint以后到现在的操作列表,所以就会比较小。如果没有snn的这个周期性的合并过程,那么当每次重启namenode的时候,就会花费很长的时间。而这样周期性的合并就能减少重启的时间。同时也能保证HDFS系统的完整性。

这就是SecondaryNameNode所做的事情。所以snn并不能分担namenode上对HDFS交互性操作的压力。尽管如此,当 namenode机器宕机或者namenode进程出问题时,namenode的daemon进程可以通过人工的方式从snn上拷贝一份metadata 来恢复HDFS文件系统。

hadoop的默认配置中让 snn进程默认运行在了 namenode 的那台机器上,但是这样的话,如果这台机器出错,宕机,对恢复HDFS文件系统是很大的灾难,更好的方式是:将snn的进程配置在另外一台机器 上运行。