Mapreduce 1.0 旧的MapReduce架构

旧的MapReduce架构
、

MapReduce架构

基本概念

• JobTracker: 负责资源管理，跟踪资源消耗和可用性，作业生命周期管理（调度作业任务，跟踪进度，为任务提供容错）
• TaskTracker: 加载或关闭任务，定时报告认为状态

旧的架构的问题

1. JobTracker是MapReduce的集中处理点，存在单点故障
2. JobTracker完成了太多的任务，造成了过多的资源消耗，当MapReduce job 非常多的时候，会造成很大的内存开销。这也是业界普遍总结出老Hadoop的MapReduce只能支持4000 节点主机的上限
3. 在TaskTracker端，以map/reduce task的数目作为资源的表示过于简单，没有考虑到cpu/ 内存的占用情况，如果两个大内存消耗的task被调度到了一块，很容易出现OOM
4. 在TaskTracker端，把资源强制划分为map task slot和reduce task slot, 如果当系统中只有map task或者只有reduce task的时候，会造成资源的浪费，也就集群资源利用的问题

Hadoop2.0 YARN 架构

在这里插入图片描述

在这里插入图片描述

在Hadoop2.0中, YARN负责管理MapReduce中的资源(内存, CPU等)并且将其打包成Container. 这样可以精简MapReduce, 使之专注于其擅长的数据处理任务, 将无需考虑资源调度. YARN会管理集群中所有机器的可用计算资源. 基于这些资源YARN会调度应用(比如MapReduce)发来的资源请求, 然后YARN会通过分配Container来给每个应用提供处理能力

基本概念

ResourceManager

• 负责整个集群的资源管理和分配，是一个全局的资源管理系统。
• NodeManager 以心跳的方式向 ResourceManager 汇报资源使用情况（目前主要是 CPU 和
  内存的使用情况）。RM 只接受 NM 的资源回报信息，对于具体的资源处理则交给 NM 自己
  处理。
• YARN Scheduler 根据 application 的请求为其分配资源，不负责 application job 的
  监控、追踪、运行状态反馈、启动等工作。

NodeManager

• NodeManager 是每个节点上的资源和任务管理器，它是管理这台机器的代理，负责该节
  点程序的运行，以及该节点资源的管理和监控。YARN 集群每个节点都运行一个
  NodeManager。
• NodeManager 定时向 ResourceManager 汇报本节点资源（CPU、内存）的使用情况和
  Container 的运行状态。当 ResourceManager 宕机时 NodeManager 自动连接 RM 备用节
  点。
• NodeManager 接收并处理来自 ApplicationMaster 的 Container 启动、停止等各种请
  求。

ApplicationMaster

• 用户提交的每个应用程序均包含一个ApplicationMaster，他可以运行在ResourceManager意外的任何机器上ResourceManager 以外的机器上。
• 负责与RM调度器协商获取资源（container）
• 将得到的任务进一步分配给内部的任务(资源的二次分配)
• 与NM通信以启动/停止任务
• 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务

Container

在Hadoop集群中，平衡内存（RAM）、处理器（CPU核心）和磁盘的使用是至关重要的，合理规划以免某一项引起瓶颈制约。一般的建议是，一块磁盘和一个CPU核心上配置两个Container会达到集群利用率的最佳平衡,Container是YARN中处理能力的基本单元, 是对内存, CPU等的封装
从可用的硬件资源角度看，要调整群集每个节点Yarn和MapReduce的内存配置到合适的数据，应注意以下几个重要的元素：

• RAM (总内存大小)
• CORES (CPU核心数)
• DISKS (磁盘数)
  Yarn和MapReduce的总的可用内存应考虑到保留的内存。保留的内存是由系统进程和其他Hadoop进程（如Hbase）所需要的内存。

保留内存=保留系统内存+保留HBase内存（如果HBase是在同一个节点）
下面的计算是确定每个节点的Container允许的最大数量。
Container数量=min (2CORES, 1.8DISKS, (可用内存)/最低Container的大小)
最低Container的大小 这个值是依赖于可用的RAM数量——在较小的存储节点，最小的Container的大小也应较小。下面的表列出了推荐值：

最后计算的每个Container的内存大小是

每个Container的内存大小 = max(最小Container内存大小, (总可用内存) /Container数))

新旧架构对比

YARN 的核心就是将jobTracker的功能进行拆解，分成了资源管理和任务调度监控两个进程，一个全局的资源管理和每个作业的管理。ResourceManager和Nodemanager提供了计算资源的分配和管理，ApplicationMaster负责完成程序的运行.YARN架构下形成了一个通用的资源管理平台和一个通用的应用计算平，避免了旧架构的单点问题和资源利用率问题，同时也让在其上运行的应用不再局限于MapReduce形式

Yarn基本流程

在这里插入图片描述

1. 用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等
2. ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster
3. ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManage查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7
4. ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源
5. 一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务
6. NodeManager为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务
7. 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态
8. 应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己

Yarn调度器Scheduler

理想情况下，我们应用对 Yarn 资源的请求应该立刻得到满足，但现实情况资源往往是
有限的，特别是在一个很繁忙的集群，一个应用资源的请求经常需要等待一段时间才能的到
相应的资源。在Yarn中，负责给应用分配资源的就是Scheduler。其实调度本身就是一个
难题，很难找到一个完美的策略可以解决所有的应用场景。为此Yarn提供了多种调度器
和可配置的策略供我们选择。在 Yarn 中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，Fair Scheduler。

三种调度器基本原理

在这里插入图片描述

• FIFO Scheduler: 把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推
• Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。
• Fair 针对不同的应用（也可以为用户或用户组），每个应用属于一个队列，主旨是让每个应用分配的资源大体相当。（当然可以设置权重），若是只有一个应用，那集群所有资源都是他的。和 Capacity的区别是不需要预留资源 。适用情况：共享大集群、队列之间有较大差别。

配置文件位置

• capacity调度器的启用：
  在ResourceManager节点上的yarn-site.xml设置
  Property===>yarn.resourcemanager.scheduler.class
  Value=====>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

• capacity调度器的配置:
  在目录$HADOOP_HOME/hadoop/etc/hadoop/capacity-scheduler.xml

YARN-FailOver

任务失败

1. 运行时异常或者JVM退出都会报告给AM
2. 通过心跳检查任务的timeout，会检查多次（可配置）才判断该任务是否有效
3. 失败的任务或者作业都有AM重新运行

ApplicationMaster失败

1. AM 定时发送心跳信号到RM，通常一旦AM失败，就认为失败，但是也可以通过配置多次失败才算失败
2. AM失败后，RM会启动一个新的ApplicationMaster
3. 新的AM负责回复之前错误的AM的状态，(yarn.app.mapreduce.am.job.recovery.enable=true)，这一步是通过将应用运行状态保存到共享的存储上来实现的，ResourceManager不会负责任务状态的保存和恢复
4. Client也会定时向ApplicationMaster查询进度和状态，一旦发现其失败，则向ResouceManager询问新的ApplicationMaster

NodeManager失败

1. NodeManager定时发送心跳到ResourceManager，如果超过一段时间没有收到心跳消息，ResourceManager就会将其移除
2. 任何运行在该NodeManager上的任务和ApplicationMaster都会在其他NodeManager上进行恢复
3. 如果某个NodeManager失败的次数太多，ApplicationMaster会将其加入黑名单，任务调度时不在其上运行任务

ResourceManager失败

1. 通过checkpoint机制，定时将其状态保存到磁盘，然后失败的时候，重新运行
2. 通过zookeeper同步状态和实现透明的HA