YARN基础笔记

  • YARN资源调度系统
  • 一、YARN资源调度系统知识要点
  • 1. YARN介绍
  • 2. YARN架构
  • 2.1 **ResourceManager**
  • 2.2 **NodeManager**
  • 2.3 Container
  • 2.4 **ApplicationMaster**
  • 2.5 Resource Request
  • 2.6 JobHistoryServer
  • 2.7 Timeline Server


YARN资源调度系统

一、YARN资源调度系统知识要点

使用CDH版本的hadoop

hadoop-2.6.0-cdh5.14.2

1. YARN介绍

  • Apache Hadoop YARN(Yet Another Resource Negotiator)是Hadoop的子项目，为分离Hadoop2.0资源管理和计算组件而引入
  • YRAN具有足够的通用性，可以支持其它的分布式计算模式

2. YARN架构

  • 类似HDFS，YARN也是经典的主从（master/slave）架构
  • YARN服务由一个ResourceManager（RM）和多个NodeManager（NM）构成
  • ResourceManager为主节点（master）
  • NodeManager为从节点（slave）
  • ApplicationMaster可以在容器内运行任何类型的任务。例如，MapReduce ApplicationMaster请求容器启动map或reduce任务，而Giraph ApplicationMaster请求容器运行Giraph任务。

组件名

作用

ApplicationManager

相当于这个Application的监护人和管理者，负责监控、管理这个Application的所有Attempt在cluster中各个节点上的具体运行，同时负责向Yarn ResourceManager申请资源、返还资源等；

NodeManager

是Slave上一个独立运行的进程，负责上报节点的状态(磁盘，内存，cpu等使用信息)；

Container

是yarn中分配资源的一个单位，包涵内存、CPU等等资源，YARN以Container为单位分配资源；

ResourceManager 负责对各个 NodeManager 上资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的 ApplicationMaster，它负责向 ResourceManager 申请资源，并要求 NodeManger 启动可以占用一定资源的任务。由于不同的 ApplicationMaster 被分布到不同的节点上，因此它们之间不会相互影响。

Client 向 ResourceManager 提交的每一个应用程序都必须有一个 ApplicationMaster，它经过 ResourceManager 分配资源后，运行于某一个 Slave 节点的 Container 中，具体做事情的 Task，同样也运行与某一个 Slave 节点的 Container 中。

2.1 ResourceManager

  • RM是一个全局的资源管理器，集群只有一个
  • 负责整个系统的资源管理和分配
  • 包括处理客户端请求
  • 启动/监控 ApplicationMaster
  • 监控 NodeManager、资源的分配与调度
  • 它主要由两个组件构成：
  • 调度器（Scheduler）
  • 应用程序管理器（Applications Manager，ASM）
  • 调度器
  • 调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。
  • 需要注意的是，该调度器是一个“纯调度器”
  • 它不从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。
  • 调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。
  • 应用程序管理器
  • 应用程序管理器主要负责管理整个系统中所有应用程序
  • 接收job的提交请求
  • 为应用分配第一个 Container 来运行 ApplicationMaster，包括应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动它等

2.2 NodeManager

  • NodeManager 是一个 slave 服务，整个集群有多个
  • NodeManager ：
  • 它负责接收 ResourceManager 的资源分配请求，分配具体的 Container 给应用。
  • 负责监控并报告 Container 使用信息给 ResourceManager。
  • 功能：
  • NodeManager 本节点上的资源使用情况和各个 Container 的运行状态（cpu和内存等资源）
  • 接收及处理来自 ResourceManager 的命令请求，分配 Container 给应用的某个任务；
  • 定时地向RM汇报以确保整个集群平稳运行，RM 通过收集每个 NodeManager 的报告信息来追踪整个集群健康状态的，而 NodeManager 负责监控自身的健康状态；
  • 处理来自 ApplicationMaster 的请求；
  • 管理着所在节点每个 Container 的生命周期；
  • 管理每个节点上的日志；
  • 当一个节点启动时，它会向 ResourceManager 进行注册并告知 ResourceManager 自己有多少资源可用。
  • 在运行期，通过 NodeManager 和 ResourceManager 协同工作，这些信息会不断被更新并保障整个集群发挥出最佳状态。
  • NodeManager 只负责管理自身的 Container，它并不知道运行在它上面应用的信息。负责管理应用信息的组件是 ApplicationMaster

2.3 Container

  • Container 是 YARN 中的资源抽象
  • 它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等
  • 当 AM 向 RM 申请资源时，RM 为 AM 返回的资源便是用 Container 表示的。
  • YARN 会为每个任务分配一个 Container，且该任务只能使用该 Container 中描述的资源。
  • Container 和集群NodeManager节点的关系是：
  • 一个NodeManager节点可运行多个 Container
  • 但一个 Container 不会跨节点。
  • 任何一个 job 或 application 必须运行在一个或多个 Container 中
  • 在 Yarn 框架中，ResourceManager 只负责告诉 ApplicationMaster 哪些 Containers 可以用
  • ApplicationMaster 还需要去找 NodeManager 请求分配具体的 Container。
  • 需要注意的是
  • Container 是一个动态资源划分单位，是根据应用程序的需求动态生成的
  • 目前为止，YARN 仅支持 CPU 和内存两种资源，且使用了轻量级资源隔离机制 Cgroups 进行资源隔离。
  • 功能：
  • 对task环境的抽象；
  • 描述一系列信息；
  • 任务运行资源的集合（cpu、内存、io等）；
  • 任务运行环境

2.4 ApplicationMaster

  • 功能：
  • 数据切分；
  • 为应用程序申请资源并进一步分配给内部任务（TASK）；
  • 任务监控与容错；
  • 负责协调来自ResourceManager的资源，并通过NodeManager监视容器的执行和资源使用情况。
  • ApplicationMaster 与 ResourceManager 之间的通信
  • 是整个 Yarn 应用从提交到运行的最核心部分，是 Yarn 对整个集群进行动态资源管理的根本步骤
  • Yarn 的动态性，就是来源于多个Application 的 ApplicationMaster 动态地和 ResourceManager 进行沟通，不断地申请、释放、再申请、再释放资源的过程。

2.5 Resource Request

引用连接

  • Yarn的设计目标
  • 允许我们的各种应用以共享、安全、多租户的形式使用整个集群。
  • 并且，为了保证集群资源调度和数据访问的高效性，Yarn还必须能够感知整个集群拓扑结构。
  • 为了实现这些目标，ResourceManager的调度器Scheduler为应用程序的资源请求定义了一些灵活的协议，Resource Request和Container。
  • 一个应用先向ApplicationMaster发送一个满足自己需求的资源请求
  • 然后ApplicationMaster把这个资源请求以resource-request的形式发送给ResourceManager的Scheduler
  • Scheduler再在这个原始的resource-request中返回分配到的资源描述Container。
  • 每个ResourceRequest可看做一个可序列化Java对象，包含的字段信息如下：
<!--
- resource-name：资源名称，现阶段指的是资源所在的host和rack，后期可能还会支持虚拟机或者更复杂的网络结构
- priority：资源的优先级
- resource-requirement：资源的具体需求，现阶段指内存和cpu需求的数量
- number-of-containers：满足需求的Container的集合
-->
<resource-name, priority, resource-requirement, number-of-containers>

2.6 JobHistoryServer

  • 作业历史服务
  • 记录在yarn中调度的作业历史运行情况情况 ,
  • 通过命令启动

mr-jobhistory-daemon.sh start historyserver

- 在集群中的数据节点机器上单独使用命令启动直接启动即可,

- 启动成功后会出现JobHistoryServer进程(使用jps命令查看，下面会有介绍) ,

- 并且可以从19888端口进行查看日志详细信息

node01:19888

点击链接，查看job日志
  • 如果没有启动jobhistoryserver，无法查看应用的日志
  • 打开如下图界面，在下图中点击History，页面会进行一次跳转
  • 点击History之后 跳转后的页面如下图是空白的，因为没有启动jobhistoryserver
  • jobhistoryserver启动后，在此运行MR程序，如wordcount
  • 点击History连接，跳转一个赞新的页面
  • TaskType中列举的map和reduce，Total表示此次运行的mapreduce程序执行所需要的map和reduce的任务数
  • 看到map任务的相关信息比如执行状态,启动时间，完成时间。
  • 可以使用同样的方式我们查看reduce任务执行的详细信息，这里不再赘述.
  • jobhistoryserver就是进行作业运行过程中历史运行信息的记录，方便我们对作业进行分析.

2.7 Timeline Server

  • 用来写日志服务数据 , 一般来写与第三方结合的日志服务数据(比如spark等)
  • 它是对jobhistoryserver功能的有效补充，jobhistoryserver只能对mapreduce类型的作业信息进行记录
  • 它记录除了jobhistoryserver能够进行对作业运行过程中信息进行记录之外
  • 还记录更细粒度的信息，比如任务在哪个队列中运行，运行任务时设置的用户是哪个用户。
  • 根据官网的解释jobhistoryserver只能记录mapreduce应用程序的记录，timelineserver功能更强大,但不是替代jobhistory两者是功能间的互补关系.