第六章-Hadoop优化与发展

Hadoop探讨

Hadoop1.0 的核心组件（仅指 MapReduce 和 HDFS， 不包括 Hadoop 生态系统内的 Pig、Hive、HBase 等其他组件），主要存在以下不足：

• 抽象层次低，需人工编码
• 表达能力有限
• 开发者自己管理作业（Job）之间的依赖关系
• 难以看到程序整体逻辑
• 执行迭代操作效率低
• 资源浪费（Map和Reduce分两阶段执行）
• 实时性差（适合批处理，不支持实时交互式）

Hadoop的优化与发展主要体现在两个方面：

• 一方面是 Hadoop 自身两大核心组件 MapReduce 和 HDFS的架构设计改进
• 另一方面是 Hadoop 生态系统其它组件的不断丰富，加入了Pig、Tez、Spark 等新组件

组件	Hadoop1.0的问题	Hadoop2.0的改进
HDFS	单一名称节点，存在单点失效问题	设计了HDFS HA，提供名称节点热备机制
HDFS	单一命名空间，无法实现资源隔离	设计了HDFS Federation，管理多个命名空间
MapReduce	资源管理效率低	设计了新的资源管理框架YARN

HDFS HA

HDFS 1.0 只存在一个名称节点，一旦这个唯一的节点发生故障，将会导致整个集群的不可用，因此存在“单点故障问题”。而第二名称节点只能起到冷备份的作用，无法解决单点故障问题。

为了解决单点故障问题，HDFS 2.0 采用了 HA（High Availability）架构。

HA集群中设置两个名称节点，分别处于“活跃（Active）”状态和“待命（Standby）”状态。活跃名称节点负责对外处理所有客户端的请求，而待命名称节点作为备用节点。两种名称节点的状态同步，可以借助于一个共享存储系统来实现。（相当于说待命名称节点提供了“热备份”的功能）

一旦活跃名称节点出现故障，就可以立即切换到待命名称节点，不会影响到系统的正常对外服务。Zookeeper确保只有一个名称节点在对外服务，不会出现“两个管家”的情况。名称节点维护映射信息，数据节点同时向两个名称节点汇报信息。

HDFS Federation

HDFS 1.0中存在的问题：

• 单点故障问题
• 不可以水平扩展（通过纵向扩展会带来过长的系统启动时间，不可取）
• 系统整体性能受限于单个名称节点的吞吐量
• 单个名称节点难以提供不同程序之间的隔离性

虽然 HDFS HA 是热备份，提供高可用性，但是其本质上还是单名称节点，只是解决了单点故障，还是无法解决可扩展性、系统性能和隔离性的问题，而 HDFS Federation 可以很好地解决这三个问题。

HDFS Federation的设计：

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

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

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

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

资源调度框架YARN

MapReduce1.0的缺陷

MapReduce 1.0采用 Master/Slaver 架构设计，包括一个 JobTracer 和若干个 TaskTracer ，前者负责作业的调度和资源的管理，后者负责执行 JobTracer 指派的具体任务。 MapReduce 1.0既是一个计算框架，也是一个资源管理调度框架。

但是，这样一种架构有一些难以克服的缺陷：

1. JobTracker 存在单点故障
2. JobTracker 任务过重（任务多时内存开销大，增加潜在失败风险，上限4000节点）
3. 容易出现内存溢出（分配资源只考虑MapReduce任务数，不考虑CPU、内存实际使用情况）
4. 资源划分不够合理（强制划分为slot ，包括Map slot和Reduce slot）

YARN设计思路

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

YARN的设计思路：把原 JobTracer 的三大功能进行拆分，即不让JobTracer 承担过多的功能，这样大大降低了 JobTracer 的负担，提升了系统运行的效率和稳定性。

重新设计后得到的 YARN 包括 ResourceManager、ApplicationMater 和 NodeManager。

• ResourceManager 负责资源管理
• ApplicationMaster 负责任务调度和监控
• NodeManager 负责执行原 TaskTracer 的任务

YARN体系结构

组件	功能
ResourceManager	处理客户端请求 启动/监控 ApplicationMaster 监控 NodeManager 资源分配和调度
ApplicationMaster	为应用程序申请资源，并分配给内部任务 任务调度、监控与容错
NodeManager	单个节点上的资源管理 处理来自 ResourceManager 的命令 处理来自 ApplicationMaster 的命令

Resource Manager：

• ResourceManager（RM）是一个全局的资源管理器，负责整个系统的资源 管理和分配，主要包括两个组件，即调度器（Scheduler）和应用程序管理 器（Applications Manager）
• 调度器接收来自ApplicationMaster的应用程序资源请求，把集群中的资源以 “容器”的形式分配给提出申请的应用程序，容器的选择通常会考虑应用 程序所要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢”
• 容器（Container）作为动态资源分配单位，每个容器中都封装了一定数量 的CPU、内存、磁盘等资源，从而限定每个应用程序可以使用的资源量
• 调度器被设计成是一个可插拔的组件，YARN不仅自身提供了许多种直接可 用的调度器，也允许用户根据自己的需求重新设计调度器
• 应用程序管理器（Applications Manager）负责系统中所有应用程序的管理 工作，主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、 监控ApplicationMaster运行状态并在失败时重新启动等

Application Master：

• ResourceManager接收用户提交的作业，按照作业的上下文信息以及从 NodeManager收集来的容器状态信息，启动调度过程，为用户作业启动一 个ApplicationMaster
• ApplicationMaster的主要功能是：
  1. 当用户作业提交时，ApplicationMaster与ResourceManager协商获取资源， ResourceManager会以容器的形式为ApplicationMaster分配资源；
  2. 把获得的资源进一步分配给内部的各个任务（Map任务或Reduce任务）， 实现资源的“二次分配”；
  3. 与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控， 并在任务发生失败时执行失败恢复（即重新申请资源重启任务）；
  4. 定时向ResourceManager发送“心跳”消息，报告资源的使用情况和应用的进度信息；
  5. 当作业完成时，ApplicationMaster向ResourceManager注销容器，执行周期完成。

Node Manager：

• NodeManager是驻留在一个YARN集群中的每个节点上的代理，主要负责：
  1. 容器生命周期管理
  2. 监控每个容器的资源（CPU、内存等）使用情况
  3. 跟踪节点健康状况
  4. 以“心跳”的方式与ResourceManager保持通信
  5. 向ResourceManager汇报作业的资源使用情况和每个容器的运行状态
  6. 接收来自ApplicationMaster的启动/停止容器的各种请求

需要说明的是，NodeManager主要负责管理抽象的容器，只处理与容器相关 的事情，而不具体负责每个任务（Map任务或Reduce任务）自身状态的管理， 因为这些管理工作是由ApplicationMaster完成的，ApplicationMaster会通过不 断与NodeManager通信来掌握各个任务的执行状态。

在集群部署方面，YARN的各个组件是和Hadoop集群中的其他组件进行统一部署的

YARN工作流程

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

• 步骤1：用户编写客户端应用程序，向YARN提交应用程序
• 步骤2：YARN中的ResourceManager负责接收和处理来自客户端的请求，为应用 程序分配一个容器，在该容器中启动一个ApplicationMaster
• 步骤3：ApplicationMaster被创建后会首 先向ResourceManager注册
• 步骤4：ApplicationMaster向 ResourceManager申请资源
• 步骤5：ResourceManager以“容器”的 形式向提出申请的ApplicationMaster分 配资源
• 步骤6：对资源二次分配，并在容器中 启动任务
• 步骤7：各个任务向ApplicationMaster汇 报自己的状态和进度
• 步骤8：应用程序运行完成后， ApplicationMaster向ResourceManager的 应用程序管理器注销并关闭自己

YARN与MapReduce1.0的对比

从MapReduce1.0框架发展到YARN框架，客户端并没有发生变 化，其大部分调用API及接口都保持兼容。

YARN 大大减少了承担中心服务功能的ResourceManager的资源消耗

• ApplicationMaster来完成需要大量资源消耗的任务调度和监控
• 多个作业对应多个ApplicationMaster，实现了监控分布化

MapReduce1.0既是一个计算框架，又是一个资源管理调度框 架，但是，只能支持MapReduce编程模型。而YARN则是一个 纯粹的资源调度管理框架，在它上面可以运行包括 MapReduce在内的不同类型的计算框架，只要编程实现相应 的ApplicationMaster

YARN中的资源管理比MapReduce1.0更加高效，它以容器为单位，而不是以 slot 为单位

YARN的发展目标

YARN的目标是实现“一个集群多个框架”

一个企业当中同时存在各种不同的业务应用场景，需要采用不同的计算框架

• MapReduce实现离线批处理
• 使用Storm实现流式数据实时分析
• 使用Spark实现迭代计算
• ······

这些产品通常来自不同的开发团队，具有各自的资源调度管理机制，为了避免不同类型应用之间互相干扰，企业就需要把内部的服务器拆分成多个集群，分别安装运行不同的计算框架，即“一个框架一个集群”

• 集群资源利用率低
• 数据无法共享
• 维护代价高

YARN的目标就是实现“一个集群多个框架”，即在一个集群上部署一个统一的资源调度管理框架YARN，在YARN之上可以部署其他各种计算框架。

由YARN为这些计算框架提供统一的资源调度管理服务，并且能够根据各种 计算框架的负载需求，调整各自占用的资源，实现集群资源共享和资源弹性收缩。可以实现一个集群上的不同应用负载混搭，有效提高了集群的利用率。不同计算框架可以共享底层存储，避免了数据集跨集群移动。