Hadoop学习-关于 YARN 的一些概念

简介

YARN （Yet Another Resource Negotiator，另一种资源调度器）是Hadoop的集群资源管理系统，最初被引入Hadoop 2，是为了改善mapreduce的实现，基本设计思想是将旧MR中的JobTracker 拆分重构，减少JobTracker 的负担，解决单点故障问题，提高资源利用率

---

Hadoop 1.0 架构

• JobTracker 必须不断跟踪所有TaskTracker和所有map、reduce任务，TaskTracker 上的任务都是JobTracker来分配的，存在单点故障
• JobTracker 完成了太多的任务，，造成了过多的资源消耗，当job非常多的时候，会造成很大的内存开销，也导致了Hadoop 1.x 的mapreduce只能支持4000左右节点上限
• TaskTracker，以map/reduce task的数目作为资源的表示过于简单，没有考虑到cpu/ 内存的占用情况，如果两个大内存消耗的task被调度到了一块，很容易出现OOM
• TaskTracker，把资源强制划分为map task slot和reduce task slot, 如果当系统中只有map task或者只有reduce task的时候，会造成资源的浪费，也就集群资源利用的问题

Hadoop 2.0与Hadoop 1.0 对比

Hadoop 2.0 变化的一些地方

• 重构的根本思想：将JobTracker两个主要的功能（资源管理和任务调度/监控）分离成单独的组件，ResourceManager 负责资源管理，ApplicationMaster 负责任务调度/监控
• 原框架中核心的JobTracker 和TaskTracker 不见了，取而代之的是ResourceManager，ApplicationMaster与NodeManager 三部分
• ResourceManager 代替集群资源管理器
• ApplicationMaster 代替一个专用且短暂的JobTracker(任务管理)
• NodeManager 代替TaskTracker
• 一个分布式应用程序代替一个MapReduce作业,而MapReduce 经历了完全重构，不再是Hadoop的核心组件，而成为YARN上的一种应用框架
• 定义为集群操作系统，封装cpu、内存资源， 为应用程序（任务)提供了基本服务来更好地利用大的、动态的、并行的基础设施资源，
• 使得多种计算框架可以运行在一个集群中，如mapreduce,storm,spark，对多种类型、多版本应用进行统一管理和调度
• 在YARN中，Job的概念换成了application应用程序
• 自带了多种用户调度器FIFO，Faire公平调度，适合共享集群环境

---

优化方向：

可扩展性

YARN 可以在更大规模的集群上运行。旧的架构当节点数达到4000，任务数达到40000时，就会遇到性能瓶颈问题，问题就来自于jobtracker 必须同时管理作业和任务。YARN 利用其资源管理器和application master 分离的架构优点，可以扩展倒更多的节点和任务。

可用性

旧框架中Jobtracker内存中存在大量快速变化的复杂状态，使得改进jobtracker服务获得高可用性非常困难。而YARN 中jobtracker 在资源管理器和application master之间进行了职责划分，高可用的服务随之称为一个分而治之的问题：先为资源管理器提供高可用性，再为YARN应用提供高可用性。

利用率

旧框架中tasktracker 中划分为map slot 和 reduce slot 。一个map slot 仅能用于运行一个map任务，一个reduce slot 仅能用于运行一个reduce任务，可能会出现仅由map slot ，但reduce任务等待的情况。YARN中，一个节点管理器管理一个资源池，而不是指定的固定数目slot，应用按需请求资源。相比传统模式，提高了资源利用率、降低运维成本和数据共享成本

多租户

某种程度上说，YARN的最大优点在于向MapReduce 以外的其他类型的分布式应用开放了Hadoop。MapReduce 仅仅时许多YARN应用中的一个。

---

YARN 的一些核心概念

• MapReduce 经历了完全重构，不再是Hadoop的核心组件，而成为Yarn上的一种应用框架
• ResourceManager
  • ResourceManager处理客户端请求，接收JobSubmitter提交的作业，（按照作业的上下文（context)信息run.sh提交的参数，以及从NodeManager收集来的状态信息),启动调度过程，分配一个container作为ApplicationMaster
  • ResourceManager 拥有为系统中所有应用资源分配的决定权，是中心服务，做的事情就是调度、启动每一个Job所属的Application、另外监控Application的存在情况
  • 与运行在每个节点上的NodeManager进程交互，通过心跳通信，达到监控NodeManager的目的
  • ResourceManager 有一个可插拔的调度器组件Scheduler
    • Scheduler是一个纯粹的调度器：
      • 不负责应用程序的监控和状态跟踪
      • 不保证应用程序失败或者硬件失败的情况下对Task的重启（ApplicationMaster)
• NodeManager
  • 是slave1进程，类似TaskTracker的角色，是每个机器框架代理
  • 处理来自ResourceManage的任务请求
  • 接收并处理来自ApplicationMaster的Container启动、停止等各种请求
  • 负责启动应用程序Container（执行应用程序的容器），并监控他们的资源使用情况（CPU、内存、磁盘和网络），并报告给ResourceManage
  • 总的来说，在单节点上进行资源管理和任务管理
• ApplicationMaste
  • 应用程序的Master，每一个应用对应一个ApplicationMaste，在用户提交要给应用程序时，一个ApplicationMaste的轻量型进程实例会启动，ApplicationMaste协调应用程序内的所有任务的执行
  • 负责一个Job生命周期内的所有工作，类似旧得JobTracker
  • 每一个Job都有一个ApplicationMaste，运行在ResourceManage以外的机器上
  • 与ResourceManage协商资源
    • 与Scheduler协商合适的Container
  • 与NodeManager协同工作与Schedule协商合适的Container进行Container的监控
  • 是一个普通Container的身份运行
• Container
  • 是任务运行环境的抽象封装
  • Container只是使用NodeManager上指定资源的权力
  • ApplicationMaste必须向Container只是使用NodeManager上指定资源的权力提供更多的信息来启动Container
  • 描述任务的运行资源（内存、cpu）、启动命令run.sh和运行环境

---

提交Application 到 YARN 的流程

• Client 请求ResourceManager运行一个ApplicationMaster
• ResourceManager选择一个NodeManager，启动一个Container并运行Application Master实例
• ApplicationMaster根据实际需要向ResourceManager 请求更多的Container资源
• ApplicationMaster通过获取到的Container资源执行分布式计算

---

YARN 的容错能力

• 任务失败：任务JVM 会在退出之前向父applicationmaster 发送错误报告，记入用户日志，并释放容器以便资源可以为其他任务使用。applicationmaster 会尝试在其他节点重新调度执行任务，默认4次
  （可配置）后不会再重试，
• ResourceManager挂掉：单点故障，新版本可以基于Zookeeper实现HA高可用集群，可通过配置进行设备准备ResourceManager，主提供服务，备同步主的信息，一旦主挂掉，备立即做切换接替进行服务
• NodeManager挂掉：不止一个，当一个挂了，会通过心跳方式通知ResourceManager，ResourceManager将情况通知对应ApplicationMaster，ApplicationMaster做一步处理
• ApplicationMaster挂掉：若挂掉，ResourceManager上有一个RMApplicationManager，是ApplicationMasterr的ApplicationMasterManager，上面保存已经完成的task，在一个新的container中重启新的ApplicationMaster,r，无需重新运行已经完成的task

关于YARN

关于YARN，初衷为了改善mapreduce的实现，解决单点故障问题而进行拆分和重构，但因为YARN的包容性，使得更多的计算框架能够接入HDFS中，更多的专注于计算性能的提升，从而使得HDFS成为应用最广泛的大数据存储系统