Every day to be a little better

Yarn

Yarn

  • Yarn 外围有很多插件,yarn为各种插件提供一个最基本的服务,来利用底层最基本的设置资源,以尽可能最大利用率的方式调动整体资源。
  • 动态: 动态分配资源分配
  • Yarn : 集群操作系统
  • JobTracker :资源管理、作业调度及监控
  • Yarn:
    • 资源管理:RM
    • 作业调度及监控:AM(ApplicationMaster)
  • RM有一个可以插拔的调度组件Scheduler(纯粹的调度器): 负责运行中的各种应用分配资源,不负责应用程序的监控和状态跟踪
  • 什么是资源:Container —-主要有两类(cpu和内存)
  • AM本质也是一个Container:不是一直处于启动状态
  • AM利用多态机器的处理能力完成一个作业,为了实现该目标,AM向RM申请资源,资源就是Container,集群以Cotainer的形式运转AM的应用,运行汇报Container的进程,可能是一个map,也可能是一个reducer,Container也得与AM同行,报告任务的状态和健康信息

YARN(Yet Another Resource Negotiator)

  • Hadoop集群的资源管理系统(ResourceManger->RM)
  • 更高级:集群操作系统
  • 为应用程序提供了基本服务来更好地利用大的、动态的、并行的基础设施资源
  • Hadoop2.0对MapReduce框架做了彻底的重构
  • Hadoop2.0中的MapReduce成为MRv2或者Yarn
  • 负责集群的资源管理和调度
  • 使得多种计算框架可以运行在一个集群中
  • 在Yarn中,Job的概念换成了application

特点:

  • 良好的扩展性、高可用
  • 对多种类型应用进行统一管理和调度
  • 自带了多种用户调度器,适合共享集群环境
  • 相比传统模式,提高了资源利用率、降低运维成本和数据共享成本

  • hadoop1.0

  • hadoop2.0

Hadoop1.0中的状况

  • JobTracker 资源管理,作业调度及监控
  • JobTracker必须不断跟踪所有TaskTracker和所有map、reduce任务,TaskTracker上的任务都是JobTracker来分配的
  • 优化方向:
    • 我们减少了单个JobTracker的职责,将部分职责委派给TaskTracker,因为集群中有许多TaskTracker。在新设计中,这个概念通过将JobTracker的双重职责(集群资源管理和任务协调)分开为两种不同类型的进程来反映
    • 不再拥有JobTracker,引入集群管理器,负责跟踪集群中的活动节点和可用资源,并将它们分配给任务
    • 对于提交给集群的每个作业,会启动一个专用的、短暂的JobTracker来控制该作业中的任务的执行,短暂的JobTracker由在从属节点上运行的TaskTracker启动

Hadoop2.0中的设计

  • ResourceManager(RM)代替集群管理器
  • ApplicationMaster(AM)代替一个专用且短暂的JobTracker
  • NodeManager(NM)代替TaskTracker
  • 一个分布式应用程序代替一个MapReduce作业
  • 重构的根本思想:将JobTracker两个主要的功能分离成单独的组件,这两个功能是资源管理和任务调度/ 监控
  • hadoop1.0

  • hadoop2.0

  • 对比
  • 原框架中核心的JobTracker和TaskTracker不见了,取而代之的是ResourceManager, ApplicationMaster与NodeManager三个部分

Apache Hadoop Yarn核心概念

  • MapReduce经历了完全重构,不再是Hadoop的核心组件,而成为Yarn上的一种应用框架,称为MRv2(MapReduce的第二版)

RM

  • RM处理客户端请求,接收JobSubmitter提交的作业,按照作业的上下文(Context) 信息,以及从NodeManager(NM)收集来的状态信息,启动调度过程,分配一个Container 作为App Mstr
  • RM拥有为系统中所有应用资源分配的决定权,是中心服务,做的事情就是调度、启动每一个Job所属的Application、另外监控Application的存在情况
  • 与运行在每个节点上的NM进程交互,通过心跳通信,达到监控NM的目的
  • RM有一个可插拔的调度器组件Scheduler
    • Scheduler是一个纯粹的调度器:
      • 不负责应用程序的监控和状态跟踪
      • 不保证应用程序失败或者硬件失败的情况下对Task的重启

NM

  • 是slave进程,类似TaskTracker的角色,是每个机器框架代理
  • 处理来自RM的任务请求
  • 接收并处理来自ApplicationMaster的Container启动、停止等各种请求
  • 负责启动应用程序的Container(执行应用程序的容器),并监控他们的资源使用情况(CPU、内存、磁盘和网络),并报告给RM
  • 总的来说,在单节点上进行资源管理和任务管理

AM

  • 应用程序的Master,每一个应用对应一个AM,在用户提交一个应用程序时,一个AM的轻量型进程实例会启动,AM协调应用程序内的所有任务的执行
  • 负责一个Job生命周期内的所有工作,类似旧的JobTracker
  • 每一个Job都有一个AM,运行在RM以外的机器上
  • 与RM协商资源
    • 与Scheduler协商合适的Container
  • 与NM协同工作与Scheduler协商合适的Container进行Container的监控
  • 是一个普通Container的身份运行

Container

  • 是任务运行环境的抽象封装
  • Container只是使用NM上指定资源的权利
  • AM必须向NM提供更多的信息来启动Container
  • 描述任务的运行资源(节点、内存、cpu)、启动命令和运行环境

Yarn框架对于旧的MapReduce框架的优势

  • 减小了JobTracker(也就是现在的RM)的资源消耗,并且让监测每一个Job 子任务(tasks) 状态的程序分布式化了,更安全、更优美
  • AM是一个可变更的部分,用户可以对不同的编程模型写自己的AM,让更多类型的编程模型能够跑在Hadoop 集群中
  • 对于资源的表示以内存为单位,比之前以剩余slot 数目更合理
  • 老的框架中,JobTracker一个很大的负担就是监控job 下的tasks 的运行状况,现在,这个部分就扔给ApplicationMaster做了
  • 资源表示成内存量,那就没有了之前的map slot/reduce slot 分开造成集群资源闲置的尴尬情况

Yarn框架的运行过程

  • Client请求Resource Manager运行一个Application Master实例(step 1);
  • Resource Manager选择一个Node Manager,启动一个Container并运行Application Master实例(step 2a、step 2b);
  • Application Master根据实际需要向Resource Manager请求更多的Container资源(step 3);
  • Application Master通过获取到的Container资源执行分布式计算(step 4a、step 4b)

Yarn的容错能力

  • RM挂掉:单点故障,新版本可以基于Zookeeper实现HA高可用集群,可通过配置进行设置准备RM,主提供服务,备同步主的信息,一旦主挂掉,备立即做切换接替进行服务
  • NM挂掉:不止一个,当一个挂了,会通过心跳方式通知RM,RM将情况通知对应AM,AM作进一步处理
  • AM挂掉:若挂掉,RM负责重启,其实RM上有一个RMApplicationMaster,是AM的AM,上面保存已经完成的task,若重启AM,无需重新运行已经完成的task

Yarn的调度器

  • FIFO Scheduler:按提交顺序,最简单,大应用占用所有集群资源,不适合共享集群
  • Capacity Scheduler:专有队列运转小任务,预先占一定集群资源,导致大任务执行时间落后于FIFO
  • Fair Scheduler:不需要预占,动态调整,公平共享

未经允许不得转载:奇葩菌博客 » Yarn

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址