这是我参与「第四届青训营 」笔记创作活动的的第4天！
写了3小时，内动太多了!!!
1 YARN 概述
1.1 调度系统简介
调度系统： 把有限的资源（CPU/GPU）合理的分配给几乎无限的任务需求（数据分析，数据处理）的系统
调度系统主要解决的是 需求请求和可用资源之间的映射（mapping）问题
1.2 调度系统演化史
1.3 YARN 设计思想
演化背景
离线生态
面临挑战
1.4 YARN 整体架构
Resource Manager
- 资源管理和调度
- 任务生命周期管理
- 对外进行交互 Node manager
- 提供集群资源
- 管理Continer（容器）运行
具体的执行过程（从1到14）
2 YARN的核心模块
- Resource Manager
- Node manager
- Application Master（自己补充）
2.1 Rousource manager（RM）
2.1.1 Rousource manager的整体架构
RM主要职责
RM负责集群所有资源的统一管理和分配，接受汇总各节点的信息并按照一定策略分配给各个任务
- 与客户端交互
- 启动管理所有AM（Application manager）
- 管理所有NM（Node manager）
- 资源管理调度
- 组织资源（资源池）
- 组织任务（队列）
- 接受资源请求
- 分配资源
RM状态机管理（对应上图）
（1）RMApp 状态机
- NEW_SAVING: 收到任务后，创建RMApplmpl对象并将基本信息持久化
- ACCEPTED:调度器接受改任务后的状态，任务等待被分配
- RUNNING:任务成功获取到资源并在节点上运行
（2）RMAppAttempt
- SCHEDULED：通过合法性检查后的状态，开始为该任务分配资源
- ALLOCATED_SAVING:收到分配的continer(容器)后，持久化完成所处的状态（比如备份数据等）
- ALLOCATED:信息持久化后所处的状态
- LAUNCHED: RM的ApplicationMaterLauncher 与 NM通信以启动AM时所处的状态
（3）RMcontiner
- RESERVED:开始资源预留时，当前节点不能满足资源请求时所处的状态
- ALLOCATED:调度器分配一个Container给AM
- ACQUIRED:Continer被AM领走的状态
- EXPIRED：AM收到Continer后，如果一段时间没启动Continer，RM会强制回收Continer
（4）RMNode
- RECOMMISSIONED:节点下线后的状态
- UNHEALTHY:节点处于不健康状态，节点监测。健康监测脚本异常或者磁盘故障
- LOST:节点超过一定时间（一般10 min）没有跟RM发生心跳后的状态
RM调度器分析-任务资源组织
- 按队列组织
- 按节点label组织
RM调度器分析-调度流程
- AM与RM心跳： 记录资源请求
- 触发时机：节点心跳
- 找label：获取所有队列
- 找队列：最“饥饿”的队列优先（比如等待时间最长，看具体算法）
- 找任务：优先级高的任务优先
- 找资源请求：优先级高的请求优先
RM调度器分析-典型调度器
2.2 Node manager（NM）
Node manager的整体架构
Node manager的主要责任
NM是节点代理，从AM（Application Master）接受命令(启停container)并执行，通过心跳方式向RM汇报节点并领取命令（清理Continer）
- 与RM交互
- 心跳汇报节点状态
- 领取RM下的命令
- 与AM交互
- 启动容器
- 停止容器
- 获取容器状态
NodeManager 状态机管理（对应上图）
NodeManager 状态机管理（1） - Application
- INITING：Application初始化状态，创建工作目录和日志目录
- Finishing_Continers_Wait: 等待回收Continer所占资源所处的状态
- Application_Resource_Cleaningup: Application所有Continer占用资源被回收后所处的状态
NodeManager 状态机管理（2） - Continer
- Localizing：正在从HDFS下载依赖的资源
- Exited_With_Success:Continer运行脚本正常退出执行
- Continer_Cleanup_After_Kill:Continer被kill所处的状态
NodeManager 状态机管理（3） - LocalizedResource
- Downloading:资源处于下载状态
- Localized:资源下载完成
- Failed:资源下载失败
Node Manager节点健康监测机制
节点健康监测机制可以时刻掌握NM的状态并且汇报给RM，RM根据NM是否健康决定是否为其调度新任务
- 自定义Shell
- NodeHealthScriptRunner服务周期性执行节点健康状态检测的脚本
- 若输出“Error”开头则不健康
- 检测磁盘损坏数目
- 判断磁盘损坏标准：若一个目录具有读、写和执行权限，则目录正常
- LocalDirsHandlerService服务周期性检测NM本地磁盘好坏，磁盘数超过阈值则不健康
2.3 ApplicationMaster（AM）自己补充
2.3.1 AM是什么
ApplicationMaster运行在Container中。
ApplicationMaster的主要作用是
向ResourceManager申请资源并和NodeManager协同工作来运行应用的各个任务，然后跟踪它们状态及监控各个任务的执行，遇到失败的任务还负责重启它
2.32 AM的主要作用
- 数据切分
- 为应用程序申请资源并进一步分配给内部任务。
- 任务监控与容错
- 负责协调来自RM的资源，并通过NM监视任务的执行和资源使用情况。
启动后做以下的工作：
- 和ResourceManager保持连接，定期向ResourceManager发送heartbeat
- 计算一个Application需要的Resource
- 通过ResourceRequest的形式，跟ResourceManager沟通，让ResourceManager给它分配Container
- 和NodeManager沟通来加载Container
- 跟踪Container的状态
- 处理Container故障或者Node故障的问题
3 重要机制
3.1 调度策略 -Fair Share调度策略背景
- 为什么需要Fair Share调度策略？
- 实现队列减资源共享，提高资源利用率
- 缓解繁忙的队列压力
- 什么是Fair Share调度策略
- 队伍空闲时按照一定策略将资源分配给其他队列
- Fair Share类型
- Steady Fair Share
- Instantaneout Fair Share
3.2 Instantaneout Fair Share
3.2.1 Instantaneout Fair Share 定义
- S： 队列
- R：可以理解为 资源量
3.2.1 Instantaneout Fair Share 计算逻辑（二分法）
3.3.1 DRF（Dominant Resource Fair）调度策略
- 为什么需要DRF
- 在保证公平的前提下进行资源降维（具体看下图）
- 什么是DRF
- DRF是最大最小公平算法在多维资源上的具体实现
- 让不同的“主分享量保持最大的公平”
- 最大最小公平算法：最大化最小资源需求的满足度
- 资源按照需求递增顺序分配
- 获取的资源不超过自身的需求
- 未满足用户等价分享资源
具体例子
ABCD（比如CPU,GPU,内存，硬盘）的4种资源的总量是10，
- 第一步：Task原本的申请资源量
- 第二步：RM 给Task实际分配的，可以发现A多分配了0.5
- 第三步：其他资源每个多0.1666（0.5/3） 发现B也多了
- 第四步：把B多的部分分给CD
3.3.2 DRF（Dominant Resource Fair）调度策略描述
3.3.2 DRF（Dominant Resource Fair）调度策略计算逻辑
3.4 高性能保障
状态机管理
事件处理模型
