Yarn工作机制
Yarn工作机制
概述 ：
该系统是一个资源调度平台, 主要承担为各种运算程序提供服务器级计算资源的任务. 相似于一种基于分布式计算的操作系统架构, 而在Yarn平台上运行的MapReduce类程序类似于在操作系统的虚拟环境中执行的应用程序.
基本架构 ：
YARN主要包含以下组件：ResourceManager、NodeManager、ApplicationMaster和Container等
工作机制 ：
解释 ：
- 计算资源：在YARN框架下定义的计算资源具体指CPU和内存两种类型。每个作业在其启动前必须先向 ResourceManager（RM）提交请求，在Name Node（NM）上才能运行自己的任务流程。
- 资源队列：YARN系统将整个集群的计算能力划分为若干个功能区或业务队列，并对每个队列的最大处理能力进行严格配置以防止单个作业耗尽整体资源而影响其他作业执行。
- 逻辑CPU与虚拟内存：Name Node会根据集群管理员的实际配置参数向ResourceManager汇报当前可用的虚拟核心数与可用内存容量。例如一台48核、128G内存的机器可配置为40个虚拟核心与120G内存容量对外提供给作业使用。
- 资源上下限管理：为了确保每个队列都能获得必要的基础处理能力又不至于浪费集群空闲时间YARN采取了弹性伸缩策略即通过minResources与maxResources两个参数来动态调整各队列可分配的最大最小处理能力minResources表示只要作业需求不超过该值集群就会保证满足；当作业需求超过minResources但集群仍有剩余处理能力时仍然能够满足；同时maxResources则设定了上限防止过高的作业需求导致集群超负荷运转从而影响整体系统的稳定性。
- 任务容器：作业申请到必要的计算资源后会在Name Node上运行起来所形成的完整工作单元统称为任务容器简称Container。它可以是MapReduce中的Mapper或Reducer Spark应用中的Driver或Executor等不同的执行角色取决于具体的场景需求。
工作机制简化版 ：
- 用户通过客户端向 RM 发起任务提交请求，在线指定目标队列及所需资源数量，默认情况下采用系统默认设置。
- 当 RM 接收客户端提交的任务请求时，在满足资源与队列配置条件的基础上选择合适的 NM，并通知其启动特殊容器 ApplicationMaster（AM）。
- AM 完成注册后根据自身任务需求向 RM 请求分配所需容器数量、所需资源量及位置信息。
- 若该队列剩余资源充足，则由 RM 负责将容器分配给具有剩余空间充足的 NM，并由 AM 通知其启动容器。
- container 启动后将执行其分配的任务作业；NM 除了负责启动容器外还需监控容器运行状态及是否出现故障退出情况；如果容器实际使用的内存超出申请值，则系统会将其终止重启以保障其他容器正常运行。
- 所有 container 完成工作后将进度报告发送至 AM 并完成任务注销流程；AM 接收所有 container 报告后触发退出机制；最后 RM 通知相关 NM 删除对应的 container 并完成整个任务流程退出。
container设置多少资源合适？
当 container 内存配置较低时，在实际运行中若使用较高负载的作业集，则可能导致 YARN 在运行过程中因资源不足而终止该容器进程而导致无法正常运行。此外，在 container 内部若线程并发度较高而 vcore 设置相对较少，则可能导致作业被分配至已有负载较高的机器上从而影响运行效率。因此建议在设计时预估单个 container 处理的数据总量所需的内存资源，并确保 vcore 配置参数不低于容器内核线程并发度以避免资源分配不足的问题。
工作机制复杂版 ：
解释 ：
1）Mr 程序提交到客户端所在的节点
2）Yarnrunner 向 ResourceManager 申请一个 Application
3）rm 将该应用程序的资源路径返回给 yarnrunner
4）该程序将运行所需资源提交到 HDFS 上
5）程序资源提交完毕后，申请运行 mrAppMaster
6）RM 将用户的请求初始化成一个 task
7）其中一个 NodeManager 领取到 task 任务
8）该 NodeManager 创建容器 Container，并产生 MRAppmaster
9）Container 从 HDFS 上拷贝资源到本地
10）MRAppmaster 向 MR 申请运行 maptask 资源
11）RM 负责执行 maptask 任务并将之分配给另外两个 NodeManager；这两个 NodeManager 接收任务并生成相应的容器
12）MR向响应两个接收到任务的NodeManager提交启动脚本文件，并由其中每个NodeManager依次执行maptask任务以对数据进行分区排序处理。
在所有 maptask 完成之后, MrAppMaster 将会向 RM 发起容器申请请求, 启动 reduce 任务.
14）reduce task 向 maptask 获取相应分区的数据
15）程序运行完毕后，MR 会向 RM申请注销自己
作业提交全过程 ：
作业提交全过程详解
（1）作业提交
第0步：该MapReduce作业被客户端发起请求至整个Hadoop集群中的相应节点队列中。
第1步：client向RM申请一个作业id。
第2步：RM给client返回该job资源的提交路径和作业id。
第3步：client提交jar包、切片信息和配置文件到指定的资源提交路径。
第4步：client提交完资源后，向RM申请运行MrAppMaster。
（2）作业初始化
第5步：当RM收到client的请求后，将该job添加到容量调度器中。
第6步：某一个空闲的NM领取到该job。
第7步：该NM创建Container，并产生MRAppmaster。
第8步：下载client提交的资源到本地。
（3）任务分配
第9步：MrAppMaster向RM申请运行多个maptask任务资源。
在第10步中, RM负责执行maptask任务的分配工作,并将该任务发送给其他两个NodeManager;这两个NodeManager各自接受其分配的任务,并同时完成容器的构建.
（4）任务运行
第11步：MR向接收到任务的两个NodeManager传递程序启动脚本，这两个NodeManager各自执行maptask任务，并使该任务对数据进行分区排序。
第12步：当所有maptask完成之后，MrAppMaster请求容器并执行reduce任务。
第13步：reduce task向maptask获取相应分区的数据。
第14步：程序运行完毕后，MR会向RM申请注销自己。
（5）进度和状态更新
YARN的任务将进度信息及其状态（包括counter）反馈给应用管理器；客户端每秒通过配置参数mapreduce.client.progressmonitor.pollinterval向应用管理器发起请求，并将进度更新展示给用户。
（6）作业完成
除了向应用管理器查询作业进度外, 客户端每隔五分钟会通过触发waitForCompletion()来定期检查当前作业的状态。该配置参数允许客户端每隔五分钟自动查询一次当前作业的进度。一旦所有作业都完成完毕后，则应用管理器以及容器将清除各自的工作状态。所有记录完成后，则这些信息会被存储到专门的历史服务器中以便后续进行核查。
资源调度器 ：
目前而言，Hadoop作业调度器主要分为三种：FIFO调度机制、容量限制调度机制以及公平调度机制。通常情况下，默认使用的资源调度器为容量限制调度机制。
具体设置详见：yarn-default.xml文件
<property>
<description>The class to use as the resource scheduler.</description>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>1、先进先出调度器（FIFO）
优点 :调度算法简单，JobTracker（job提交任务后发送得地方）工作负担轻。
缺点是忽略了不同类型作业的需求差异。若类似对海量数据进行统计分析等需求较高的作业长期占用计算资源，则可能导致后续提交的交互型或其他类型作业长时间得不到及时处理。
从而影响用户体验。
2、 容量调度器（Capacity Scheduler）=== >Yahoo开发
1.多队列支持，每个队列采用FIFO
为了防止同一个用户的作业独占队列中的资源,该调度器会限制同一个用户在队列中占用过多资源的行为.其主要目的是确保每个用户的作业能够获得公平合理的资源分配.
首先评估每个队列中运行的任务数量与其应分配的计算资源的比例或比率，并选择那个比例或比率最低的队列
4.其次，在按照作业的优先级设置和提交时间排序的基础上，并对队列内的任务调度安排进行优化
三个队列将按照任务优先级排序依次处理，并行执行时会将job11、job21和job31安排在首位位置上进行启动，并行处理过程中这三个任务会是最早开始运行的，并且是同步进行的。
该调度在默认情况下不支持优先级设置 ，但可以通过配置文件中的相关参数进行启用设置；一旦启用带优先级功能，则调度算法采用基于优先级的队列方式（FIFO）。
避免高优先级作业抢占 ，在该作业启动后 ，在完成之前它不会受到高优先级作业的资源占用 。
对该用户的作业在获取资源百分比方面设置了上限以防止同属一用户的作业独占资源
3、 *公平调度器（Fair Scheduler）==== >Facebook开发*
能够支持多个_queue和_user；每个_queue内的_Resource容量可进行设置；同一_queue内的_Job实现_fair sharing 该_queue的所有_resourc
例如设有三个队列A、B、C.其中每个队列内的任务（Job）根据其优先级分配计算资源.高优先级的任务会获得更多的计算资源.尽管如此在计算资源有限时每个任务都会得到一定的计算能力保障这种情况下任务的实际利用率被称为任务缺额（Job Deficit）.同一队列内缺额较高的任务会更早地被调度处理任务将按照其缺额大小依次被调度处理如图所示在调度过程中可以允许多个任务同时运行
任务的推测执行 ：
speculative execution 是指在集群环境中对 mapreduce 任务进行推测执行。这可能因程序错误、资源分配不均或其他相关问题导致同一个 job 中的多个 task 运行速度不一。例如某些 task 已经完成而其他 task 只完成了 10% 的工作量。根据桶底效应原则（也称木桶定律）这些较慢的任务将决定整个 job 的性能瓶颈。当集群启用了 speculative execution 机制时系统会优先处理这些较慢的任务并启动特定策略以最大化整体效率。具体来说 A hadoop task 会启动一个备份 task 来处理剩余数据。这样 A speculative task 和其原始 task 将共享剩余的数据最先完成任一 task 的那个会被选中作为最终结果；另一个未完成的任务则会被立即终止以确保整体 job 的高效运行
1）作业完成时间取决于最慢的任务完成时间
一个作业包含若干个Map任务和Reduce任务。由于硬件老化或软件Bug等原因，某些作业可能运行得非常慢。
标准案例中指出：其中99%的Map任务已完成。然而，在剩下的少数几个Map中，它们总是进展缓慢而未能完成，请问如何解决？
2）推测执行机制：
识别成为拖累进度的任务，并举例说明某项特定作业的执行效率明显低于整体平均水平。
针对成为拖累进度的任务部署一个备用作业，并同步执行。
最先完成的那个会被优先选用其结果作为最终输出。
3）执行推测任务的前提条件
（1）每个task只能有一个备份任务；
（2）当前job已完成的task必须不小于0.05（5%）
（3）开启推测执行参数设置，mapred-site.xml文件中默认是打开的。
<property>
<name>mapreduce.map.speculative</name>
<value>true</value>
<description>
If true, then multiple instances of some map tasks may be executed in parallel.
</description>
</property>
<property>
<name>mapreduce.reduce.speculative</name>
<value>true</value>
<description>If true, then multiple instances of some reduce tasks
may be executed in parallel.</description>
</property> 4）不能启用推测执行机制情况
（1）任务间存在严重的负载倾斜；
（2）特殊任务，比如任务向数据库中写数据。