Hadoop-YARN

时间  2019-11-21 标签 hadoop yarn

Hadoop - YARN

旧的MapReduce架构

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

此架构会有如下问题：算法

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

总的来讲就是单点问题和资源利用率问题架构

YARN架构

YARN就是将JobTracker的职责进行拆分，将资源管理和任务调度监控拆分红独立#x7ACB;的进程：一个全局的资源管理和一个每一个做业的管理（ApplicationMaster） ResourceManager和NodeManager提供了计算资源的分配和管理，而ApplicationMaster则完成应用程序的运行app

  • ResourceManager: 全局资源管理和任务调度
  • NodeManager: 单个节点的资源管理和监控
  • ApplicationMaster: 单个做业的资源管理和任务监控
  • Container: 资源申请的单位和任务运行的容器

架构对比

YARN架构下造成了一个通用的资源管理平台和一个通用的应用计算^#x5E73;台，避免了旧架构的单点问题和资源利用率问题，同时也让在其上运行的应用再也不局限于MapReduce形式异步

YARN基本流程

1. Job submissionoop

从ResourceManager中获取一个Application ID 检查做业输出配置，计算输入分片 拷贝做业资源（job jar、配置文件、分片信息）到HDFS，以便后面任务的执行ui

2. Job initialization操作系统

ResourceManager将做业递交给Scheduler（有不少调度算法，通常是根据优先级）Scheduler为做业分配一个Container，ResourceManager就加载一个application master process并交给NodeManager管理ApplicationMaster主要是建立一系列的监控进程来跟踪做业的进度，同时获取输入分片，为每个分片建立一个Map task和相应的reduce task Application Master还决定如何运行做业，若是做业很小（可配置），则直接在同一个JVM下运行线程

3. Task assignment3d

ApplicationMaster向Resource Manager申请资源（一个个的Container，指定任务分配的资源要求）通常是根据data locality来分配资源blog

4. Task execution

ApplicationMaster根据ResourceManager的分配状况，在对应的NodeManager中启动Container 从HDFSN#x4E2D;读取任务所需资源（job jar，配置文件等），而后执行该任务

5. Progress and status update

定时将任务的进度和状态报告给ApplicationMaster Client定时向ApplicationMaster获取整个任务的进度和状态

6. Job completion

Client定时检查整个做业是否完成 做业完成后，会清空临时文件、目录等

YARN - ResourceManager

负责全局的资源管理和任务调度，把整个集群当&##x6210;计算资源池，只关注分配，无论应用，且不负责容错

资源管理

  1. 之前资源是每一个节点分红一个个的Map slot和Reduce slot，如今是一个个Container，每一个Container能够根据须要运行ApplicationMaster、Map、Reduce或者任意的程序
  2. 之前的资源分配是静态的，目前是动态的，资源利用率更高
  3. Container是资源申请的单位，一个资源申请格式：<resource-name, priority, resource-requirement, number-of-containers>, resource-name：主机名、机架名或*（表明任意机器）, resource-requirement：目前只支持CPU和内存
  4. 用户提交做#x4F5C;业到ResourceManager，而后在某个NodeManager上分配一个Container来运行ApplicationMaster，ApplicationMaster再根据自身程序须要向ResourceManager申请资源
  5. YARN有一套Container的生命周期管理机制，而ApplicationMaster和其Container之间的管理是应用程序本身定义的

任务调度

  1. 只关注资源的使用状况，根据需求合理分配资源
  2. Scheluer能够根据申请的须要，在特定的机器上申请特定的资源（ApplicationMaster负责申请资源时的数据本地化的考虑，ResourceManager将尽可能知足其申请需求，在指定的机器上分配Container，从而减小数据移动）

内部结构

  • Client Service: 应用提交、终止、输出信息（应用、队列、集群等的状态信息）
  • Adaminstration Service: 队列、节点、Client权限管理
  • ApplicationMasterService: 注册、终止ApplicationMaster, 获取ApplicationMaster的资源申请或取消的请求，并将其异步地传给Scheduler, 单线程处理
  • ApplicationMaster Liveliness Monitor: 接收ApplicationMaster的心跳消息，若是某个ApplicationMaster在必定时间内没有发送心跳，则被任务失效，其资源将会被回收，而后ResourceManager会从新分配一个ApplicationMaster运行该应用（默认尝试2次）
  • Resource Tracker Service: 注册节点, 接收各注册节点的心跳消息
  • NodeManagers Liveliness Monitor: 监控每一个节点的心跳消息，若是长时间没有收到心跳消息，则认为该节点无效, 同时全部在该节点上的Container都标记成无效，也不会调度任务到该节点运行
  • ApplicationManager: 管理应用程序，记录和管理已完成的应用
  • ApplicationMaster Launcher: 一个应用提交后，负责与NodeManager交互，分配Container并加载ApplicationMaster，也负责终止或销毁
  • YarnScheduler: 资源调度分配， 有FIFO(with Priority)，Fair，Capacity方式
  • ContainerAllocationExpirer: 管理已分配但没有启用的Container，超过必定时间则将其回收

YARN - NodeManager

Node节点下的Container管理

  1. 启动时向ResourceManager注册并定时发&##x9001;心跳消息，等待ResourceManager的指令
  2. 监控Container的运行，维护Container的生命周期，监控Container的资源使用状况
  3. 启动或中止Container，管理任务运行时的依赖包（根据ApplicationMaster的须要，启动Container以前将须要的程序及其依赖包、配置文件等拷贝到本地）

内部结构

  • NodeStatusUpdater: 启动向ResourceManager注册，报告该节点的可用资源状况，通讯的端口和后续状态的维护

  • ContainerManager: 接收RPC请求（启动、中止），资源本地化（下载应用须要的资源到本地，根据须要共享这些资源）

    PUBLIC: /filecache</local-dir>

    PRIVATE: /usercache//filecache</local-dir>

    APPLICATION: /usercache//appcache//（在程序完成后会被删除）</app-id></local-dir>

  • ContainersLauncher: 加载或终止Container

  • ContainerMonitor: 监控Container的运行和资源使用状况
  • ContainerExecutor: 和底层操做系统交互，加载要运行的程序

YARN - ApplicationMaster

单个做业的资源管理和任务监控

具体功能描述#x8FF0;：

  1. 计算应用的资源需求，资源能够是静态或动态计算的，静态的通常是Client申请时就指定了，动态则须要ApplicationMaster根据应用的运行状态来决定
  2. 根据数据来申请对应位置的资源（Data Locality）
  3. 向ResourceManager申请资源，与NodeManager交互进行程序的运行和监控，监控申请的资源的使用状况，监控做业进度
  4. 跟踪任务状态和进度，定时向ResourceManager发送心跳消息，报告资源的使用状况和应用的进度信息
  5. 负责本做业内的任务的容错

ApplicationMaster能够是用任何语言编写的程序，它和ResourceManager和NodeManager之间是经过ProtocolBuf交互，之前是一个全局的JobTracker负责的，如今每一个做业都一个，可伸缩性更强，至少不会由于做业太多，形成JobTracker瓶颈。同时将做业的逻辑放到一个独立的ApplicationMaster中，使得灵活性更加高，每一个做业均可以有本身的处理方式，不用绑定到MapReduce的处理模式上

如何计算资源需求

通常的MapReduce是根据block数量来定Map和Reduce的计算数量，而后通常的Map或Reduce就占用一个Container

如何发现数据的本地化

数据本地化是经过HDFS的block分片信息获取的

YARN - Container

  1. 基本的资源单位（CPU、内存等）
  2. Container能够加载任意程序，并且不限于Java
  3. 一#x4E2A;Node能够包含多个Container，也能够是一个大的Container
  4. ApplicationMaster能够根据须要，动态申请和释放Container

YARN - Failover

失败类型

  1. 程序问题
  2. 进程崩溃
  3. 硬&#x#x4EF6;问题

失败处理

任务失败

  1. 运行时异常或者JVM退出都会报告给ApplicationMaster
  2. 经过心跳来检查挂住的任务(timeout)，会检查屡次（可配置）才判断该任务是否失效
  3. 一个做业的任务失败率超过配置，则认为该做业失败
  4. 失败的任务或做业都会有ApplicationMaster从新运行

ApplicationMaster失败

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

NodeManager失败

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

ResourceManager失败

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

能够看出，通常的错误处理都是由当前模块的父模块进行监控（心跳）和恢复。而最顶端的模块则经过定时保存、同步状态和zookeeper来ֹ#x5B9E;现HA

联系我们 沪ICP备2021010478号-7