大数据面试题V3.0 -- YARN部分

YARN部分

介绍下YARN

Yet Another Resource Negotiator，另一种资源协调者,是一种新的 Hadoop 资源管理器
它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度
它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

YARN有几个模块

ResourceManager 负责所有资源的监控、分配和管理,分为应用管理器 application manager 和资源调度器 resource scheduler；
ApplicationMaster 负责每一个具体应用程序的调度和协调；
NodeManager 负责每一个节点的维护。
Container 资源的抽象 内存 cpu 磁盘 网络

YARN工作机制

1. 用户向 Yarn 中提交一个 MR 任务
由 Resource Manager 中的 Applications Manager 接收
2.Applications Manager 负责资源的分配, 
根据任务计算出所需要的资源,如cpu资源和内存资源,将这些资源封装成 Container
3.Applications Manager 将任务和 Container 发送给 Resource Scheduler(资源调度器)
4.Resource Scheduler 将任务和 Container 分配给 Application Master, 由 Application Master 进行二次划分, 将任务分解成 MapTask 和 ReduceTask
5.ApplicationMaster 将 MapTask 和 ReduceTask 分配给 Node Manager,三个 Node Manager 随机接收
6.注意, Application Master 会对 NodeManager 的任务完成情况进行监控, 而 Applications Manager 会对 Node Manager 的任务资源使用情况进行监控.
7.如果 Node Manager 上的任务执行成功,会把成功信息发送给 Application Master 和 Applications Manager , 然后 Applications Manager 会进行资源的回收.
8.如果 Node Manager 上的任务执行失败,会把失败信息发送给 Application Master 和 Applications Manager , 然后 Applications Manager 仍然会进行资源的回收. 
此时 Application Master 会向 Applications Manager 申请资源 , 重新将这个任务分配给这个 Node Manager , 循环往复, 直到任务执行成功.

YARN有什么优势，能解决什么问题?

1、YARN的设计减小了JobTracker的资源消耗，减少单点故障，并且让监测每一个Job子任务（tasks)状态的程序分布式化了，更安全、更优美。
2、在新的Yarn中，ApplicationMaster是一个可变更的部分，用户可以对不同的编程模型写自己的AppMst，让更多类型的编程模型能够跑在Hadoop集群中。
3、对于资源的表示以内存为单位，比之前以剩余slot数目更加合理。
4、MRv1中JobTracker一个很大的负担就是监控job下的tasks的运行状况，现在这个部分就扔给ApplicationMaster做了，
而ResourceManager中有一个模块叫做ApplicationManager，它是监测ApplicationMaster的运行状况，如果出问题，会在其他机器上重启。
5、Container用来作为YARN的一个资源隔离组件，可以用来对资源进行调度和控制。

YARN容错机制

1. ApplicationMaster 容错：RM 监控 AM 的运行状态，一旦发现它运行失败或者超时，就会重新分配资源并启动它，启动之后AM内部的状态如何恢复由自己保证，
比如 MRAppMaster 在作业运行过程中将状态信息动态记录到 HDFS 上，一旦出现故障重启后，它能够从 HDFS 读取并恢复之前的运行状态，减少重复计算带来的开销。
2. NodeManager 容错：NM 超时没有心跳，则 RM 认为它死掉，会将上面的 Container 状态置为失败，并告诉对应的 ApplicationMaster ，以决定如何处理这些 Container 中运行的任务
3. Container 容错：如果 AM 在一定时间内未启动分配到的 Container，则 RM 会将该 Container 状态置为失败并回收它；
如果一个 Container 在运行过充中，因为外界原因导致运行失败，则 RM 会转告对应的 AM ,由 AM 决定如何处理

YARN高可用

ResourceManager Recovery 主要流程如下：

保存元信息：Active ResourceManager 运行过程中，会将应用程序的元信息，状态信息以及安全凭证等数据持久化到状态存储系统（state–store）中，YARN支持三种可选的state-store，分别是：
基于 ZooKeeper 的 state-store：ZooKeeper 是 ResourceManager HA 必选的 state-store，
尽管 Resource Restart 可选择其他 state-store，但只有 ZooKeeper 能防止脑裂（split- brain）现象，即同时存在多个 Active ResourceManager 状态信息的情况。
基于 FileSystem 的 state-store：支持 HDFS 和本地文件系统两种方式，但不能防止脑裂。
基于 LevelDB 的 state-store：基于 LevelDB 的 state-store 比前两种方案更加轻量级。LevelDB 能更好地支持原子操作，每次更新占用更少的 IO 资源，生成的文件数目更少。
加载元信息：一旦 Active ResourceManager 重启或出现故障，新启动的 Resource Manager 将从存储系统中重新加载应用程序的相关数据，在此过程中，所有运行在各个 NodeManager 的 Container 仍正常运行。
重构状态信息：新的 ResourceManager 重启完成后，各个 NodeManager 会向它重新注册，并将所管理的 Container 汇报给 ResourceManager，
这样 ResourceManager 可动态重构资源分配信息、各个应用程序以及其对应 Container 等关键数据；
同时， ApplicationMaster 会向 ResourceManager 重新发送资源请求，以便 ResourceManager 重新为其分配资源。
NodeManager Recovery
NodeManager 内置了重启恢复功能，当 NodeManager 就地重启时，之前正在运行的 Container 不会被杀掉，而是由新的 NodeManager 接管，并继续正常运行。

YARN调度器

1. FIFO Scheduler
FIFO = first in first out 先进先出 （队列）
这种调度把应用提交按顺序排成一个队列，先进先出的队列，在进行资源分配的时候，先给队列中最头部的应用分配资源，等到应用满足了，再给下一个分配，以此类推。问题：大的应用可能会占用所有的资源，造成阻塞，不适合集群
2. Capacity Scheduler
专门有一个队列来运行小任务，但是为小任务专门设置的队列也会占用一定的资源，会导致大任务的执行时间落后于FIFO
3. Fair  Shceduler
不需要预先占用一定资源，动态调整
比如第一个是大任务，且只有这个大任务在运行，那么把所有资源给它，然后第二个小任务提交了 ，Fair Shceduler 就会分配一半的资源给到小任务，公平的共享资源，小任务跑完了还是会把资源给到大任务。

YARN中Container是如何启动的?

Container启动时并不知道具体要在其中做什么
它被要求启动时只管根据 request 的要求准备运行环境，
从 request 中取出预先存储的命令简单加工后写到脚本文件并执行。
具体执行命令前先发出一个容器已启动的事件，再运行脚本，启动过程就完成了

YARN的改进之处，Hadoop3.x相对于Hadoop 2.x?

Hadoop 2.x - 使用具有可伸缩性问题的旧时间轴服务。
Hadoop 3.x - 改进时间线服务v2并提高时间线服务的 可扩展性 和 可靠性。

YARN监控

YARN提供了一个WebUI V1服务，该服务属于内置服务，随着RM启动而启动。
V1表示这是第一代版本的WebUI服务。用户可以通过浏览器登录界面，来监视群集、队列、应用程序、服务、节点信息。
还可以查看集群详细配置的信息，检查各种应用程序和服务的日志。
浏览器输入http://RM HOST:8088/访问YARN WebUI服务。
页面打开后，以列表形式展示处于各种状态（接收、执行、完成、杀死、失败）的各种应用程序，
如MapReduce应用、Spark应用、Flink应用等，与点击页面左侧Application栏目红线框Applications链接显示的内容一致。