YARN 是资源管理零碎，实践上反对多种资源，目前反对 CPU 和内存两种资源
YARN 产生背景
间接源于 MRv1 在几个方面的缺点
扩展性受限
单点故障
难以反对 MR 之外的计算
多计算框架各自为战，数据共享艰难
MR：离线计算框架
Storm：实时计算框架
Spark：内存计算框架
YARN 设计指标
通用的对立资源管理零碎
同时运行长应用程序和短应用程序
长应用程序
通常状况下，永不进行运行的程序
Service、HTTP Server 等
短应用程序
短时间（秒级、分钟级、小时级）内会运行完结的程序
MR job、Spark Job 等
YARN 根本架构
ResourceManager
整个集群只大数据培训有一个，负责集群资源的对立治理和调度
具体性能
解决客户端申请
启动 / 监控 ApplicationMaster
监控 NodeManager
资源分配与调度
NodeManager
整个集群有多个，负责单节点资源管理和应用
具体性能
单个节点上的资源管理和工作治理
解决来自 ResourceManager 的命令
解决来自 ApplicationMaster 的命令
ApplicationMaster
每个利用有一个，负责应用程序的治理
具体性能
数据切分
为应用程序申请资源，并进一步调配给外部工作
工作监控与容错
Container
对工作运行环境的形象
形容一系列信息
工作运行资源（节点、内存、CPU）
工作启动命令
工作运行环境
YARN 运行过程
YARN 容错性
ResourceManager
存在单点故障；
正在基于 ZooKeeper 实现 HA。
NodeManager
失败后，RM 将失败工作通知对应的 AM；
AM 决定如何解决失败的工作。
ApplicationMaster
失败后，由 RM 负责重启；
AM 需解决外部工作的容错问题；
RMAppMaster 会保留曾经运行实现的 Task，重启后无需从新运行。
YARN 调度框架
双层调度框架
RM 将资源分配给 AM
AM 将资源进一步调配给各个 Task
基于资源预留的调度策略
资源不够时，会为 Task 预留，直到资源短缺
与“all or nothing”策略不同（Apache Mesos）
YARN 资源调度器
多类型资源调度
采纳 DRF 算法
目前反对 CPU 和内存两种资源
提供多种资源调度器
FIFO
Fair Scheduler
Capacity Scheduler
多租户资源调度器
反对资源按比例调配
反对层级队列划分形式
反对资源抢占
YARN 资源隔离计划
反对内存和 CPU 两种资源隔离
内存是一种“决定生死”的资源
CPU 是一种“影响快慢”的资源
内存隔离
基于线程监控的计划
基于 Cgroups 的计划
CPU 隔离
默认不对 CPU 资源进行隔离
基于 Cgroups 的计划
YARN 反对的调度语义
反对的语义
申请某个特定节点 / 机架上的特定资源量
将某些节点退出（或移除）黑名单，不再为本人调配这些节点上的资源
申请偿还某些资源
不反对的语义
申请任意节点 / 机架上的特定资源量
申请一组或几组合乎某种特质的资源
超细粒度资源
动静调整 Container 资源
运行在 YARN 上的计算框架（还有别的）
离线计算框架：MapReduce
DAG 计算框架：Tez
流式计算框架：Storm
内存计算框架：Spark
离线计算框架：MapReduce
仅适宜离线批处理
具备很好的容错性和扩展性
适宜简略的批处理工作
毛病显著
启动开销大、过多应用磁盘导致效率低下等
DAG 计算框架：Apache Tez
DAG 计算：多个作业之间存在数据依赖关系，并造成一个依赖关系有向图（Directed Acyclic Graph），该图的计算称为“DAG 计算”
和 Mapreduce 相比
Tez 利用场景
间接编写应用程序
Tez 提供了一套通用编程接口
适宜编写有依赖关系的作业
优化 Pig、Hive 等引擎
下一代 Hive：Stinger
益处 1：防止查问语句转换成过多的 MapReduce 作业后产生大量不必要的网络和磁盘 IO
益处 2：更加智能的工作解决引擎
流式计算框架：Storm
Storm on YARN（和其余如 mapreduce、tez、spartk 等都不同，其余计算框架的 client）
内存计算框架：Spark
曾经造成了本人的生态系统
转载起源作者：IT 十年