从Hadoop1.0到Hadoop2.0架构的优化和发展探索详解

2020-11-30 16:18 517人阅读评论(0)

前言

本人大三软件工程大数据专业，在此领域本人有诸多不明确疑问，可能文章会有些许错误，望大家在评论区指正，本篇文章错误将会不断更正维护。

提示：以下是本篇文章正文内容，下面案例可供参考

一、Hadoop1.0

Hadoop1.0即第一代Hadoop，由分布式存储系统HDFS和分布式计算框架MapReduce组成，其中HDFS由一个NameNode和多个DateNode组成，MapReduce由一个JobTracker和多个TaskTracker组成。

1.1HDFS1.0

HDFS采用了主从（Master/Slave）结构模型，一个HDFS集群包括一个名称节点和若干个数据节点。名称节点作为中心服务器，负责管理文件系统的命名空间及客户端对文件的访问。其中，master主节点称之为Namenode节点，而slave从节点称为DataNode节点。

NameNode管理着整个文件系统，负责接收用户的操作请求
NameNode管理着整个文件系统的目录结构，所谓目录结构类似于我们Windows操作系统的体系结构
NameNode管理着整个文件系统的元数据信息，所谓元数据信息指定是除了数据本身之外涉及到文件自身的相关信息
NameNode保管着文件与block块序列之间的对应关系以及block块与DataNode节点之间的对应关系

对于第三点名称节点保存元数据：

（1）.在磁盘上：Fslnage和EditLog

（2）.在内存中：映射信息，即文件包含哪些块，每个块存储在哪个数据节点

NameNode	DataNode
保存元数据	存储文件内容
元数据保存在内存中	文件内容保存在磁盘
保存文件，block，datanode之间的映射关系	维护了block id到datanode本地文件的映射关系

namenode有且只有一个，虽然可以通过SecondaryNameNode与NameNode进行数据同步备份，但是总会存在一定的延时，如果NameNode挂掉，但是如果有部份数据还没有同步到SecondaryNameNode上，还是可能会存在着数据丢失的问题。

第二名称节点会定期与第一名称节点通信。

缺陷：

单点故障问题：NameNode含有我们用户存储文件的全部的元数据信息，当我们的NameNode无法在内存中加载全部元数据信息的时候，集群就面临崩溃。第二名称节点无法解决单点故障问题。
不可以水平扩展，不过可以纵向扩展增加硬盘，但是不方便不灵活。单台机器的NameNode必然有到达极限的地方。
系统整体性能受限于单个名称节点的吞吐量。
单个名称节点难以提供不同程序之间的隔离性
Secondaryname只有冷备份作用。

1.2MadReduce1.0

对MapReduce来说，同样时一个主从结构，是由一个JobTracker（主）和多个TaskTracker（从）组成。

MapReduce1.0既是有一个计算框架，也是一个资源管理调度框架。

可以看得出JobTracker相当于是一个资源管理调度器，必然要面对大量的任务处理。而且出现错误集群必然崩溃。

各个角色的功能：

作业调度流程图：

缺陷：

存在单点故障问题，一旦Master节点坏掉即JobTracker故障，其他节点不能再工作。
JobTacker工作过重，如果任务多时开销太大。
容易出现内存溢出，分配资源只考虑MapReduce任务数，不考虑CPU、内存。
资源划分不合理（强制划分为slot，包括Map slot和Reduce slot）

二、Hadoop2.0

相对于Hadoop1.0来说，2就好多，这也是毋庸置疑的，总不可能越更新越差吧。

我们来详细了解一下2版本究极加了哪些东西。

2.1HDFS2.0

2.1.1HDFS HA

HDFS HA（High Availability）是为了解决单点故障问题而设计。

JN：JounrnalNode日志节点，在学习期间一般使用3个节点来部署JN。

ZKFC：全称是ZooKeeper Failover Controller，这个一个单独的进程，其数量和NN数量一样，负责监控NN节点的健康状态，同时向ZK发送心跳表明它还在工作和NN的状态，如果NN挂了，就可以让ZK马上选举出新的NN(其实就是让standbyNN的状态切换称active)，所以ZKFC是NN的一个守护进程，其一般会和其对应的NN部署在同一个节点上。

ZK：ZooKeeper，当一个activeNN挂掉以后，从standbyNN节点中选举新的NN来充当activeNN对外提供服务，一个是部署奇数台的。这里建议当你的集群规模是在50台一下的时候，ZK一般部署7个节点；50～100台时，ZK在9或者11个节点；100以上就部署11个节点以上吧。但并部署越多越好的，ZK进程越多需要计算的时间就越多，选举的时间就越长，所以合适就好。

HA集群设置了两个名称节点，“活跃（Active）”和“待命（Standby）”以至于不会落入单点故障。处于活跃状态的名称节点负责对外处理所有客户端的请求，而处于待命状态的名称节点则作为备用节点，保存了足够多的系统元数据，当名称节点出现故障时提供快速恢复能力。也就是说，在HDFS HA中，处于待命状态的名称节点提供了“热备份”，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点，不会影响到系统的正常对外服务。

由于待命名称节点是活跃的“热备份”，因此活跃名称节点的状态信息必须实时同步到待命名称节点。两种名称节点的状态同步，可以借助于一个共享存储系统来实现，比如NFS（Network File System）、QJM（Quorum Journal Manager）或者Zookeeper。活跃名称节点将更新数据写入到共享存储系统，待命名称节点会一直监听该系统，一旦发现有新的写入，就立即从公共存储系统中读取这些数据并加载到自己的内存中，从而保证与活跃名称节点状态完全同步。此外，名称节点中保存了数据库（block）到实际存储位置的映射信息，即每个数据块是由哪个数据节点存储的。当一个数据节点加入HDFS集群时，它会把自己所包含的数据块列表报告给名称节点，此后会通过“心跳”的方式定期执行这种告知操作，以确保名称节点的块映射是最新的。

2.1.2HDFS Federation(联邦)

HDFS1.0采用单名称节点的设计，还存在可扩展性、性能和隔离性等问题。而HDFS联邦可以很好地解决上述三个方面的问题。

HDFS联邦采用多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联邦（Federation）关系，不需要批次协调。并且向后兼容
HDFS联邦中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报
属于同一个命名空间的块构成一个“块池”

对于联邦中多个命名空间，可以采用客户端挂载表（Client Side Mount Table）方式进行数据共享和访问
客户可以访问不同的挂载点来访问不同的子命名空间
把各个命名空间挂载到全局“挂载表”（mount-table）中，实现数据全局共享
同样的命名空间挂载到个人的挂载表中，就称为应用程序课件的命名空间

HDFS Federation设计可以解决单名称节点存在的以下几个问题：

HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目
性能更高效。多个名称节点管理不同的数据。且同时对外提供服务，将为用户提供更好的读写吞吐率。
良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小。

需要注意的是，HDFS Federation并不能解决单点故障问题，也就是说，每个名称节点都存在在单点故障问题，需要为每个名称节点部署一个后备名称节点，以应对名称节点挂掉对业务产生的影响。

2.2YARN

YARN设计思路是将原JobTacker三大功能拆分

Hadoop2.0以后，MapReduce1.0中的资源管理调度功能，被单独分离出来形成了YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架。被剥离了资源管理调度功能的MapReduce就变成了MapReduce2.0，它是运行在YARN之上的一个纯粹的计算框架，不再自己负责资源调度管理服务，而是由YARN为其提供资源管理调度服务。

YARN作业调度流程

2.2.1ResourceManager

处理客户端请求
启动/监控ApplicationMaster
监控NodeManager
资源分配与调度

ResourceManager 拥有系统所有资源分配的决定权，负责集群中所有应用程序的资源分配，拥有集群资源主要、全局视图。因此为用户提供公平的，基于容量的，本地化资源调度。根据程序的需求，调度优先级以及可用资源情况，动态分配特定节点运行应用程序。它与每个节点上的NodeManager和每一个应用程序的ApplicationMaster协调工作。

ResourceManager的主要职责在于调度，即在竞争的应用程序之间分配系统中的可用资源，并不关注每个应用程序的状态管理。

ResourceManager主要有两个组件：Scheduler和ApplicationManager：Scheduler是一个资源调度器，它主要负责协调集群中各个应用的资源分配，保障整个集群的运行效率。Scheduler的角色是一个纯调度器，它只负责调度Containers，不会关心应用程序监控及其运行状态等信息。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务。

调度器被设计成一个可插拔的组件，YARN不仅自身提供了许多种直接可用的调度器，也应许用户根据自己的需求设计调度器。

容器（Container）作为动态资源分配单位，每个容器中都封装了一定数量的CPU、内存、磁盘等资源，从而限定每个应用程序可以使用的资源量。

2.2.2ApplicationMaster

为应用程序申请资源，并分配给内部任务
任务调度、监控与容错

ApplicationManager主要负责接收job的提交请求，为应用分配第一个Container来运行ApplicationMaster，还有就是负责监控ApplicationMaster，在遇到失败时重启ApplicationMaster运行的Container

2.2.3NodeManager

单个节点上的资源管理
处理来自ResourceManager的命令
处理来自ApplicationMaster的命令

NodeManager是yarn节点的一个“工作进程”代理，管理hadoop集群中独立的计算节点，主要负责与ResourceManager通信，负责启动和管理应用程序的container的生命周期，监控它们的资源使用情况（cpu和内存），跟踪节点的监控状态，管理日志等。并报告给RM。

NodeManager在启动时，NodeManager向ResourceManager注册，然后发送心跳包来等待ResourceManager的指令，主要目的是管理resourcemanager分配给它的应用程序container。NodeManager只负责管理自身的Container，它并不知道运行在它上面应用的信息。在运行期，通过NodeManager和ResourceManager协同工作，这些信息会不断被更新并保障整个集群发挥出最佳状态