Yarn:
定位：分布式操作系统
作用：资源整合——让系统的资源可以最大化的利用
在同一套硬件集群上同时可以运行MR任务，Spark任务，Storm任务等
Yarn中包含重要的角色：RM、NM、AM
Hadoop1.0 ：
1.jobtracker（主进程：任务调度、资源分配）
2.tasktracker（从进程：接受请求、分配资源、任务监控）
Hadoop2.0：
jobtracker进程演化为：
- 任务调度— AM（ApplicationMaster）
- 资源分配— RM（ResourceManager）
tasktracker进程演化为： NM（NodeManager）— 接受RM的请求、分配自己资源（Container）、通过心跳的方式汇报（资源使用情况）给RM，管理自己节点内部的资源利用情况
- Container：进程，NM来启动并监控Container，通过心跳回报给RM
- ApplicationMaster（AM）：执行任务的主， 本质是运行在Container里的进程 ，一个Job只有一个AM
- 一个分布式应用程序代替一个 MapReduce 作业
RM、AM的产生：本质是对jobtracker的一个绝对权力的肢解
资源（Container）：
Hadoop1.0：资源是slot — 槽位（map slot、reduce slot）
资源浪费问题
- slot是最基本的资源调配单元，slot决定着cpu和内存的大小
hadoop1.0里面：一个节点默认启动两个map slot和reduce slot
slot是一个逻辑概念，类似一种许可证map slot 总数 = 集群节点数 * mapred.tasktracker.map.tasks.maximun
reduce slot 总数 = 集群节点数 * mapred.tasktracker.reduce.tasks.maximun
前提：设定一个slot代表2G内存和1个cpu
1.一个任务只需要1G内存，1个cpu — 导致资源碎片，资源利用率低 2.一个任务需要3G内存 — 出现抢占其他任务的资源 — 集群利用率过高假设：1个机器（节点），16个cpu，32G，机器上配置了4个slot
一个slot = 4个cpu和8G内存（等量划分） 
Hadoop2.0：资源成为 Container（比喻成乐高玩具的小组件）
一个机器有多少个container？ container的数量 = min（2cores , 1.8disks , 总内存/最小容量） 最小容量 = container最小的容量大小，可以配置控制最小容量来控制container的数量
Container分类两类：cpu 和 内存 ，这两类container会分布到不同的节点上，位置随机
Yarn里面的core概念和真实的cpu是不一样的 ( Yarn中是虚拟概念 ) Container相当于一个进程
1.0 : MapReduce称为job
2.0 : MapReduce称为ApplicationMapReduce经历了完全重构,不再是Hadoop的组件,而是称为Yarn上的一种应用框架,称为MRv2 ( MapReduce的第二版 )
容错:
- RM挂了怎么办?
HA , 找一个从??
单点故障，新版本可以基于Zookeeper实现HA高可用集群，可通过 配置进行设置准备RM，主提供服务，备同步主的信息，一旦主挂掉，备立即做 切换接替进行服务
- NM挂了怎么办?
两种情况 :
1.运行着AM : 整个任务就挂了 2.没有运行AM : 整个任务没影响
不止一个，当一个挂了，会通过心跳方式通知RM， RM将情况通知对 应AM， AM作进一步处理
- AM挂了怎么办?
整个任务就挂了??
若挂掉， RM负责重启，其实RM上有一个RMApplicationMaster， 是AM的AM，上面保存已经完成的task，若重启AM，无需重新运行已经完成的 task
调度器 Scheduler (可插拔) :
什么是可插拔?
灵活配置项
- FIFO Scheduler : 按提交顺序 , 最简单 , 大应用占所有集群资源 , 不适合共享集群
- Capcity Scheduler : 转有队列运转小人物 , 预先占一定集群资源 , 导致大人物执行时间落后于 FIFO
- Fair Scheduler (默认) : 不需要预占 , 动态调整 , 公平共享
Yarn框架运行过程:
- Client请求Resource Manager运行一个Application Master实例（step 1）；
- Resource Manager选择一个Node Manager，启动一个Container并运行Application Master实例（step 2a、 step 2b）；
- Application Master根据实际需要向ResourceManager请求更多的Container资源（step 3）；
- Application Master通过获取到的Container资源执行分布式计算（step 4a、 step 4b）
Yarn框架对于旧的MapReduce框架的优势 :
- 减少了Jobtracker ( 也就是现在的RM ) 的资源消耗 , 并且让监测每一个job子任务 ( tasks ) 状态的程序分布式化了
- AM是一个可变更的部分 , 用户可以对不同的编程模型写自己的 AM , 让更多类型的编程模型能够跑在Hadoop集群中
- 对于资源的表示以内存为单位 , 比之前以剩余slot数目更合理
- 老的框架中 , Jobtrackr一个很大的负担就是监控job下的tasks的运行状态 , 现在 , 这部分就扔给ApplicationMaster做了
- 资源表示成内存量 , 那就没有了之前的 map slot / reduce slot 分开造成集群资源限制的尴尬情况
关于 RM，NM，AM，Container的一些说明：：：
R M：
- RM处理客户端请求，接收JobSubmitter提交的作业，按照作业的上下文(Context) 信息，以及从 NodeManager（NM） 收集来的状态信息，启动调度过程，分配一个 Container 作为 App Mstr
- RM拥有为系统中所有应用资源分配的决定权，是中心服务，做的事情就是调度启动每一个Job所属的Application、另外监控Application的存在情况
- 与运行在每个节点上的NM进程交互，通过心跳通信，达到监控NM的目的RM有一个可插拔的调度器组件Scheduler
-
- – Scheduler是一个纯粹的调度器：
- 不负责应用程序的监控和状态跟踪
- 不保证应用程序失败或者硬件失败的情况下对Task的重启
- – Scheduler是一个纯粹的调度器：
N M：
- 是slave进程，类似TaskTracker的角色，是每个机器框架代理
- 处理来自RM的任务请求接收并处理来自ApplicationMaster的Container启动、停止等各种请求
- 负责启动应用程序的Container（执行应用程序的容器），并监控他们的资源使用情况（CPU、内存、磁盘和网络），并报告给RM
- 总的来说，在单节点上进行资源管理和任务管理
AM：
- 应用程序的Master，每一个应用对应一个AM，在用户提交一个应用程序时，一 个AM的轻量型进程实例会启动， AM协调应用程序内的所有任务的执行
- 负责一个Job生命周期内的所有工作，类似旧的JobTracker
- 每一个Job都有一个AM，运行在RM以外的机器上
- 与RM协商资源
- — 与Scheduler协商合适的Container
- 与NM协同工作与Scheduler协商合适的Container进行Container的监控
- 是一个普通Container的身份运行
Container：
- 是任务运行环境的抽象封装
- Container只是使用NM上指定资源的权利
- AM必须向NM提供更多的信息来启动Container
- 描述任务的运行资源（节点、内存、 cpu）、启动命令和运行环境