一、什么是yarn
1、基本概念
YARN （Yet Another Resource Negotiator，另一种资源协调者）从 Hadoop 2.0开始抽象出来的资源管理器，其引入的目的有两个：
- 为了解决1.x中资源管理和任务调度的耦合问题
- 为了方便其他程序扩展接入yarn
2、拓展
- 计算向数据移动：大数据系统下，数据的大小往往比编码的jar包大的多，将jar移动到数据所在的节点运行可以节省很多带宽跟时间
- 资源管理：资源管理的通性往往需要有一个Master负责接收各个子节点汇报的资源信息
- 常服务：一个常用服务进程，不能关闭，可能会因某些原因挂掉
- 临时服务：用完了即可以关闭回收的进程，与常服务相反
二、Hadoop 1.x
1、MapReduce中的角色
- JobTracker：负责资源管理、任务调度
- TaskTracker：负责任务管理、资源汇报
2、执行流程
- client 流程
- 会根据每次计算数据，咨询NN（NameNode）元数据信息，计算出split切片的清单，根据切片清单就知道map的数量
- 生成运行的程序所需要的配置文件：job.split，job.xml，run.jar，并将其上传到特定hdfs目录下
- client会调用JobTracker，同时要启动一个计算程序，并告知文件都在hdfs哪个位置
- JobTracker 流程
- 从hdfs中获取split清单
- 根据自己收到的TaskTracker汇报的资源，最终确定每一个split对应的map应该去到哪个节点
- 后续，TT（TaskTracker）会在向JT发送心跳的时候取回分配给自己的任务信息
- TaskTracker 流程
- 在跟JT心跳时取回任务
- 从hdfs中下载jar，xml到本机
- 最终启动任务描述中的MapTask/ReduceTask（最终代码在某一个节点被启动，是通过client上传，TT下载，也就是计算向数据移动的实现）
3、存在问题
- JobTracker的三个问题：
- 单点故障
- 压力过大：一直接收各个client的提交的信息，监控TT的资源
- 集成了资源管理和任务调度，两者耦合
- 弊端：后续新的计算框架不能复用同一套资源管理
- 重复造轮子（资源管理可以统一用一套，没必要出现新的计算框架需要新起一套资源管理）
- 因为各自实现资源管理，但是它们又部署在同一批硬件上，因为隔离，所以不能感知到对方的使用
三、Hadoop 2.x
1、yarn中的角色
- ResourceManager：负责整体资源管理
- NodeManager：向RS汇报心跳，提交自己的资源情况
2、执行流程
- MapReduce on yarn 流程
- MR-client 将切片信息，配置文件，jar上传至hdfs上，访问RM（ResourceManager）申请AppMaster
- RM选择一台不忙的节点通知NM（NodeManager）启动一个container，在里面反射启动一个AppMaster
- AppMaster从hdfs下载切片清单，并根据清单信息向RM申请资源
- RM根据自己掌握的资源情况得到一个清单，通知NM启动container
- container启动后会反向注册到已经启动的AppMaster进程
- AppMaster （类似前面的JobTracker的阉割版，少了资源管理）最终将任务task发送给container
- container会反射相应的Task类对象，调用方法执行，其结果就是我们的业务逻辑代码
- 除此之外还会有Task失败重试机制
3、解决问题
- 单点故障：
- 以前是全局的JT挂了，整个计算层就没有了调度
- yarn中每一个APP由一个自己的AppMaster调度
- yarn还支持AppMaster失败重试
- 压力过大：
- yarn中每个计算程序都有各自的AppMaster，每个AppMaster只负责自己计算程序的任务调度
- AppMaster是在不同的节点中启动的
- 集成了资源管理和任务调度，两者耦合：
- yarn只有资源管理，不负责具体任务调度，是公立的
- 计算框架继承yarn的AppMaster，自己实现AppMaster的内部逻辑，就可以使用同一个统一资源层
四、总结
- Hadoop 1.x 主要的问题：JT和TT设计为MR的常服务，即作为资源管理者，又要接受任务调度
- Hadoop 2.x 就是针对1.x的问题进行解决，删除了JT和TT这两个角色，资源管理由其他角色代替，相对的，MR的client调度任务都是用临时服务（即AppMaster等）取代
版权声明：本文为weixin_40253547原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。