前言
YARN 是 Hadoop 资源管理器。负责协调任务作业的服务器资源。使任务有序对资源进行利用。除了支持原生 MapReduce任务，他还提供了Spark等任务接入的入口。
基本概念
Yar主要由 4 种组件组成，它们的主要功能如下
ResourceManager (RM)
ResourceManager 是一个全局的资源管理器，负责整个系统的资源管理和分配， 它主要由两个组件组成：
-
Scheduler：资源调度器，主要功能和特点如下：
- 负责将资源分配给各种正在运行的应用程序，这些应用程序受到容量、队列等限制；
- Scheduler 是纯调度程序，不会监视或跟踪应用程序的状态；由于应用程序故障或硬件故障，它不提供有关重新启动失败任务的保证；
- 在配置文件yarn-site中配置每台的（内存、CPU、磁盘、网络），根据机子的好坏,设置不同的值《yarn-site.xml配置文件详解》
- Scheduler 根据应用程序的资源需求来执行其调度功能，它是基于资源容器的抽象概念来实现的，容器（Container）内包含内存、CPU、磁盘、网络等因素；
Container 就是config, 最后真正对内存，cpu等待因素的限制还要看NodeManager - Scheduler 是一个可插拔的插件（即可配置），负责在各种队列、应用程序等之间对集群资源进行区分。当前支持的Scheduler类包括：FairScheduler、FifoScheduler、CapacityScheduler；
-
Application Manager：负责接受 job 提交请求，为应用程序分配第一个 Container 以运行 ApplicationMaster，并提供失败时重新启动运行着 ApplicationMaster 的 Container 的服务。
ApplicationMaster（AM）
当用户提交一个应用程序时，将启动一个被称为 ApplcationMaster 的轻量级进程的实例，用以协调应用程序内所有任务的执行。它的主要工作包括：
- 向 ResourceManager 申请并以容器（Container）的形式提供计算资源；
- 管理在容器内运行的任务：
- 跟踪任务的状态并监视它们的执行；
- 遇到失败时，重新启动失败的任务；
- 推测性的运行缓慢的任务以及计算应用计数器的总值。
NodeManager（NM）
NodeManager 进程运行在集群中的节点上，是每个节点上的资源和任务管理器。它的主要功能包括：
- 接收 ResourceManager 的资源分配请求Container，并为其具体化应用程序 ；
- 管理每个 Container 的生命周期；
- 管理每个节点上的日志；
- 接收并处理来自 ApplicationMaster 的 Container 启动/停止等请求。
- 定时地向 ResourceManager 汇报本节点上的资源使用情况, 和各个Container(ApplicationMaster) 的运行状态
- 定时地向各 ApplicationMaster 汇报 各个 Container 的运行状态，以确保整个集群平稳运行；
Container（容器）
Container 是 Yarn 中的资源抽象，是执行具体应用的基本单位，它包含了某个 NodeManager 节点上的多维度资源，如内存、CPU、磁盘和网络 IO，当然目前仅支持内存和 CPU。任何一个 Job 或应用程序必须运行在一个或多个 Container 中，在 Yarn 中，ResourceManager 只负责告诉 ApplicationMaster 哪些 Containers 可以用，ApplicationMaster 需要自己去找 NodeManager 请求分配具体的 Container。
Container 和集群节点的关系是：一个节点会运行多个 Container，但一个 Container 不会跨节点。
Yarn 任务提交流程
下面我们详细了解下一个任务是怎么提交到 Yarn 中运行的。
- Client 向 RM 发起任务请求：「RM，我要执行一个任务」
- RM 给 Client 返回 Application ID 等信息：「好的，给你分配一个 Application ID」
- Client 根据返回的信息，检查作业的输入输出目录是否正确、计算作业输入分片是否正常，将运行作业需要的资源（作业 Jar 文件、配置文件、输入分片）复制到以 Application ID 命名的 HDFS 目录中。
- Client 向 RM 正式提交作业：「我都准备好了，执行任务吧」
- RM 将请求信息传递给自己的小弟 Scheduler：「Scheduler 老弟，你来分配个 Container」
- Scheduler 分配 Container，用于启动 ApplicationMaster：「好的，这个 Container 就是 0 号选手」
- ApplicationsManager 与指定的 NodeManager 通信，要求在 Container 中启动 ApplicationMaster。
- ApplicationMaster 初始化任务并向 RM 申请所需要的资源：「RM 大哥，给我资源运行任务」
- RM 将会根据调度策略，尽可能返回满足 ApplicationMaster 申请的资源：「给你 1、2 两个 NodeManager」
- ApplicationMaster 与对应的 NodeManager 通信，申请 Container 启动任务「NodeManager 大哥，给我启动 Container 运行这个任务」
- Container 中的应用程序会先将需要的计算资源从 HDFS 下载到本地，再启动任务：「都给我跑起来」
- 运行过程中，任务会将状态和进度报告给 ApplicationMaster，Client 每秒 (通过mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户。
- 运行完成后，Container 会注销掉，也就是把资源归还给系统，ApplicationMaster 向 RM 注销自己。
Yarn调度器介绍
ResourceScheduler是资源调度器，它按照一定的约束条件（比如队列容量限制等）将集群中的资源分配给各个应用程序，当前主要考虑内存和CPU资源。
FIFO Scheduler(先进先出调度器)
FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。
Capacity Scheduler(容量调度器)
Capacity Scheduler调度器以队列为单位划分资源。简单通俗点来说，就是一个个队列有独立的资源，队列的结构和资源是可以进行配置的
- 多队列 ：每个队列可配置一定的资源量，每个队列内部采用FIFO调度策略；
- 容量保证：管理员可为每个队列设置资源最低保证和资源使用上线；
- 灵活性：如果一个队列中的资源有剩余，可以暂时共享给那些需要资源的队列，而一旦该队列有新的应用程序提交，则其他队列借调的资源会归还给该队列；
- 多租户：
- 支持多用户共享集群和多应用程序同时运行；
- 为了防止同一个用户的作业独占队列中的资源，该调度器会对同一用户提交的作业所占资源进行限定。
Fair Scheduler(公平调度器)
Fair Scheduler也是基于队列的，与Capacity Scheduler相似，其不同点
- 资源公平共享：在每个队列中，Fair Scheduler可选择按照FIFO、Fair或DRF策略为应用程序分配资源。Fair策略即平均分配，默认情况下，每个队列采用该方式分配资源
- 支持资源抢占：当某个队列中有剩余资源时，调度器会将这些资源共享给其他队列，而当该队列中有新的应用程序提交时，调度器要为它回收资源。为了尽可能降低不必要的计算浪费，调度器采用了先等待再强制回收的策略，即如果等待一段时间后尚有未归还的资源，则会进行资源抢占；从那些超额使用资源的队列中杀死一部分任务，进而释放资源
- 负载均衡：Fair Scheduler提供了一个基于任务数的负载均衡机制，该机制尽可能将系统中的任务均匀分配到各个节点上。此外，用户也可以根据自己的需求设计负载均衡机制
- 调度策略灵活配置：Fiar Scheduler允许管理员为每个队列单独设置调度策略（当前支持FIFO、Fair或DRF三种）
- 提高小应用程序响应时间：由于采用了最大最小公平算法，小作业可以快速获取资源并运行完成
公平调度器队列资源分配方式
1.FIFO策略
公平调度器每个队列资源分配策略若是选择FIFO，相当于容量调度器；
2.Fair策略
3.DRF策略
DRF(Dominant Resource Fairness)主导资源公平调度算法，是一种通用的多资源最大-最小公平分配策略(Max-Min Fairness Strategy),核心思想是在多环境下一个用户的资源分配应该由用户的主导份额资源决定。用户所有份额中的最大值称为该用户的主导份额，与主导份额相对应的资源称为主导资源。
假设集群一共有100 CPU和10T 内存，而应用A需要(2 CPU, 300GB)，应用B需要(6 CPU，100GB)。 则两个应用分别需要A(2%CPU, 3%内存)和B(6%CPU, 1%内存)的资源，这就意味着A是内存主导的, B是 CPU主导的。
源码分析
《ApplicationMaster源码分析》
《Yarn Container启动流程源码分析》
《YARN DistributedShell源码分析与修改》
通过Container启动流程可以发现，Container是逻辑分配，真正直接管理的还是通过shell命令 让程序以 docker的方式运行，或者《linux的cgroups详解》对进行CPU，内存等资源进行管控。
ps, docker的底层也是cgroups
yarn的发展
yarn 只是对任务的一个资源管理，但实际的大数处理场景中，很多问题会转换成DAG任务关系，因此需要工作流调度工具去解决
- Oozie是Apache旗下的，用于管理Hadoop任务的工作流/协调系统，可与Hadoop生态圈紧密结合，提供诸多配置和功能。
- Zeus&hera
同样的yarn平台基于MR模型的任务会在DAG关系中，会对中间状态数据存入,取出HDFS,实际中用户并不关心中间结果。因此需求更好的计算模块去解决中间数据的问题
- tez: 是基于Hadoop YARN之上的DAG（有向无环图，Directed Acyclic Graph）计算框架。它把Ｍap/Reduce过程拆分成若干个子过程，同时可以把多个Ｍap/Reduce任务组合成一个较大的DAG任务，减少了Ｍap/Reduce之间的文件存储。
- spark:MapReduce计算框架不适合迭代计算和交互式计算，MapReduce是一种磁盘计算框架，而Spark则是一种内存计算框架，它将数据尽可能放到内存中以提高迭代应用和交互式应用的计算效率。
编写MR程序，或者Spark程序是复杂的，对于快速响应的数据分析。大家都想基于高级的脚本语言，由程序翻译成MR代码
- hive：Hive主要用于静态的结构以及需要经常分析的工作。HiveQL与SQL相似
主要参考
《Yarn 架构》
《Yarn的工作机制》
《Yarn ResourceManager总体架构 》
《Yarn调度器和调度算法(FIFO、容量调度器 与 公平调度器)》
《如何用形象的比喻描述大数据的技术生态 》
《Hadoop技术内幕：深入解析YARN架构设计与实现原理 董西成》
《Hadoop YARN权威指南》
491
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
