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十年