大数据学习笔记4 - Hadoop的优化与发展(Hadoop 2.0) - at_today

时间:2024-02-18 08:36:40

大数据学习笔记4 - Hadoop的优化与发展(Hadoop 2.0)

前面介绍了Hadoop核心组件HDFS和MapReduce,Hadoop发展之初在架构设计和应用性能方面仍然存在不足,Hadoop的优化与发展一方面体现在两个核心组件的架构设计改进,一方面体现在Hadoop生态系统其他组件的不断丰富。此文介绍Hadoop2.0中添加的新特性。

一、HDFS 2.0新特性

这对HDFS的改进,HDFS 2.0主要增加了HDFS HA 以及HDFS联邦等新特性。

(一)HDFS HA

HA即High Availability,用于解决HDFS 1.0中的单点故障问题

HDFS 1.0中,存在一个名称节点,一个第二名称节点,第二名称节点不是名称节点的备份,它的主要功能是解决当数据操作记录较多时,EdlirLog文件过大的问题,并不能提供热备份功能,当名称节点故障时无法提供实时切换,第二名称节点不能立即对外提供服务,需要停机恢复。

一旦唯一的名称节点出现故障,就会导致整个集群不可用,这就是“单点故障问题”。为解决这一问题,HDFS 2.0采用HA架构,集群包含两个名称节点,一个活跃(Active)状态,一个待机(Standby)状态:

Active状态的名称节点负责对外处理客户端请求;

Standby状态的节点负责提供热备份,保存足够的元数据信息,Active节点故障时提供快速恢复能力。

Standby名称节点作为备份节点,需要存储与Active节点一致的元数据信息,那么HA又是如何保证Active名称节点的信息实时同步到Standby名称节点的呢?

两个名称节点之间的状态同步借助于共享存储系统实现,如NFS、QJM或Zookeeper。Active名称节点给将数据写入到共享存储系统,Standby节点监听共享存储系统,若有新写入,则从公共存储系统读取数据并加载到自己的内存,以此保证数据同步。

 

为了能让Standby节点随时接替Active节点对外提供服务,Standby节点也需要保存集群中各个块的位置信息,HA又是如何处理这个问题的呢?

HA架构下给数据节点配置两个名称节点地址,并把块的位置信息和心跳信息同时发送到两个名称节点。

当集群中存在两个名称节点时,需要保证某一时刻仅一个名称节点处于Active状态,这又是如何实现的呢?

HA使用Zookeeper确保任意时刻只有一个名称节点提供对外服务。

(二)HDFS联邦

HDFS HA解决了单点故障问题,但仍只有一个Active节点,仍存在可扩展性、系统性能、隔离性问题。单个工作名称节点,会造成集群横向扩展困难、单个节点吞吐量限制、一个程序消耗过多资源导致其他程序无法顺利运行等问题。

HDFS 联邦机制解决了上述问题,设计多个相互独立的名称节点,分别进行各自命名空间和块的管理,相互之间属于联邦关系,需不要彼此协调。兼容性方面,HDFS

联邦具有良好的向后兼容性,针对单名称节点的部署配置不需要做任何修改就可以继续工作。

1、HDFS 联邦的架构设计

HDFS联邦的名称节点提供命名空间和块管理功能,所有名称节点共享底层的数据节点存储资源。每个数据节点向集群中所有名称节点注册,周期性地向名称节点发送心跳信息报告自身状态,并处理所有名称节点的指令。

不同于HDFS 1.0中的单个命名空间,联邦提供多个独立的命名空间,每个命名空间管理属于自己的一组块,一个命名空间下的一组块成为一个“块池”,每个数据节点为多个块池提供块的存储。一个块池是一组块的逻辑集合,属于逻辑概念,块池中的各个块实际是存储在各个数据节点中的,数据节点是物理概念。HDFS联邦架构如下图:

 

联邦中一个名称节点失效,不会影响与它相关的数据节点为其他名称节点提供服务。

2、HDFS联邦的访问方式

对于联邦中的多个命名空间,可以采用客户端挂载表的方式进行数据共享和访问。把各个命名空间挂载到全局挂载表,实现数据全局共享,客户端通过访问不同的挂载点来访问不同的子命名空间,命名空间挂载到个人的挂载表中就成为应用程序可见的命名空间。

注意,HDFS联邦不能解决单点故障问题,每个联邦内的名称节点都存在单点故障问题,需要为每个名称节点部署备份名称节点。

 


 

二、新一代资源管理框架YARN

1、MapReduce1.0的缺陷

在MapReduce1.0采用Master/Slave架构下,包含一个JobTracker负责作业的调度和资源管理,若干个TaskTracker负责执行JobTracker指派的任务。这样的架构存在单点故障问题,JobTracker故障后系统不可用;JobTracker任务过重,既负责作业调度和失败恢复,又负责资源管理分配,当任务过多时增加失败风险;TaskTracker端的资源分配不考虑硬件的实际使用情况,多个大资源任务分配到同一个TaskTracker时容易造成内存溢出;资源等量划分为slot,又分为Map槽、Reduce槽,不可混用,造成资源浪费。

2、YARN架构

为解决上述问题,Hadoop 2.0中将MapReduce重新设计,生成MapReduce2.0和YARN。YARN的基本设计思路是为JobTracker组件“放权”,把原JobTracker的功能(资源管理、任务调度、任务监控)进行拆分。YARN包括ResourceManager、ApplicationMaster和Node Manager。YARN设计思路如下图:

(1)ResourceManager(RM)是全局资源管理器,负责整个系统的资源管理和分配。包括调度器和应用程序管理器两个组件。

  • 1)调度器负责资源管理和分配,接收来自Application的应用程序资源请求,根据容量、队列等限制条件,把集群中的资源以容器的形式分配给提出申请的应用程序,容器的选择一般遵循就近选择,实现计算向数据靠拢。容器是动态资源分配单位,封装了一定数量的CPU等资源,为每个应用分配相应资源,而不再是1.0中槽的概念。调度器可插拔,用户可使用YARN提供的调度器,也可以自定义。
  • 2)应用程序管理器负责系统中全部应用程序的管理,如程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重启等。

Hadoop平台上,用户应用程序以作业(Job)形式提交,一个Job被分解成若干任务(包括Map任务、Reduce任务)进行分布式执行,ResourceManager接收用户提交的作业,按照作业上下文信息以及从NodeManager收集来的容器状态信息,启动调度过程,为用户作业启动一个ApplicationMaster。

(2)ApplicationMaster负责任务调度和监控,它的功能包括:

  • 当用户提交作业时,Application与ResourceManager协商获取资源;
  • 把获得的容器资源进一步分配给内部的各个任务(Map或Reduce任务),实现资源二次分配;
  • 与NodeManager交互,进行程序的启动、运行、监控、停止,监控资源使用情况,对任务的进度和状态进行监控,在任务失败时重启任务;
  • 定时向ResourceManager发送心跳信息,报告监控数据;
  • 作业完成时,向ResourceManager注销容器。

(3)NodeManager负责执行原TaskTracker任务。

NodeManager是驻留在一个YARN集群中的每个节点上的代理,负责容器的生命周期管理,监控容器资源使用情况,并通过心跳向ResourceManager汇报这些信息,同时,接收来自ApplicationMaster的启动/停止容器的各种请求。NodeManager主要负责抽象的容器只处理与容器相关的事情,而不具体负责每个任务自身状态的管理(这些工作由ApplicationMaster完成)

3、YARN工作流程

在YARN框架中执行一个MapReduce程序时,从提交到完成需要经历的步骤:

  • 向YARN提交用户编写的客户端程序,提交内容包括:ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
  • YARN中ResourceManager负责接收和处理来自客户端的请求。接到请求后,调度器为应用程序分配容器;应用程序管理器与容器所在的NodeManager通信,为该程序在该容器中启动一个Application Master。
  • Application Manager创建后向ResourceManager注册,从而使用户可以通过ResourceManager直接查看应用运行状态

接下来是具体的应用程序执行步骤。

  • ApplicationManager采用轮询方式通过RPC协议向ResourceManager申请资源。
  • ResourceManager以容器形式向提出申请的ApplicationMaster分配资源,ApplicationMaster申请到资源后就与该容器所在NodeManager通信,要求它启动任务。
  • ApplicationMaster要求容器启动任务时,为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)然后将任务启动命令写到脚本中,最后通过在容器中运行脚本来启动任务。
  • 各个任务通过某RPC协议向ApplicationMaster汇报自己的状态和进度,让ApplicationMaster可以随时掌握各个任务的运行状态,从而可以在任务失败时重启任务。
  • 程序运行完成后,ApplicationMaster和ResourceManager的应用程序管理器注销并关闭自己。若ApplicationMaster失败,ResourceManager中的应用程序管理器会监测到失败并重启,直至任务执行完毕。

YARN的发展目标是实现“一个集群多个框架”,即在一个集群上部署一个统一的资源调度框架YARN,在YARN上可以部署各种计算框架,如MapReduce、HBase、Storm、Spark等,由YARN为这些计算框架提供统一的资源调度管理服务,实现一个集群不同应用负载混搭,并能够根据各种计算框架的负载需求调整各自占用的资源,实现集群资源共享和资源弹性收缩。