最近做数据中台有一段时间了，一直被Yarn的集群资源分配所困扰。具体体现在，spark on yarn 提交任务，任务状态长时间停留在ACCEPTED状态无法继续，日志显示AM已经被分配启动，一个Container已经被分配，向RM申请其它Contanier资源时被拒。也多次尝试调整资源配置，效果不佳。除此之外，基于Yarn的map reduce, tez引擎时延也难以忍受，原因不明。所以今日决定从底层入手，深入了解yarn底层结构。主要参考资料《Hadoop权威指南》，《Hadoop Yarn权威指南》。
Yarn基本概念
Yarn有两个长期守护进程
- Resource Manager：资源管理器，负责整个集群的资源分配，只在NameNode上。RM包括两个组件，一个是Application Manager，用于管理集群中的所有用户作业；另一个是Scheduler。
- Node Manager：节点管理器，负责在单个节点上启动和监控Container，在所有节点上都有一个。向RM负责并保持心跳。
RM依赖NM的心跳来维护一个全局视图。
一个比较重要的概念Container：容器负责任务的具体执行，可以是一个进程，也可以是一个Linux cgroup(?)，可以配置。
每个容器都有资源限制（CPU，内存），一个Container代表一个节点上的一组资源。
另外一个概念就是Application Master：AM对应于每个应用，即向Yarn提交的应用。AM是这个应用的中枢，负责监控应用的信息。AM自身也在一个Container里，与NM协同工作来执行/监控Container。AM会通过心跳与RM建立联系，申请资源；心跳应答中，AM会收到绑定了一组资源的Container租约。
RM主要负责的是在不同应用之间调度资源，AM负责应用的进程状态信息的监控和容错等。
下面讲述下Yarn如何运行一个应用：
- client向RM申请提交一个任务；RM应答返回一个ApplicationID。
- client带着ApplicationID，用户名，队列名，申请资源，作业文件等再发给RM，要求运行Application Master进程。
- RM检验应用的合法性，合格之后状态即为ACCEPTED。
- 之后RM交给Scheduler分配资源，如果足够多的资源可以满足需求，则app状态为RUNNING.
- RM为client找一个NM，NM启动一个Container,用来装载Application Master
- aplication Master向RM注册，RM返回集群的容量信息，AM决定如何使用当前可用的资源。
- AM请求Container，RM向AM应答该请求
刚才说到的ACCEPTED问题，就发生在第3步出现的问题，申请资源时出错。
资源申请一般由两种模式，一种是程序运行之初，就把所有Container都分配好，比如Spark就是这种模式；
另一种就是可以在运行时再去动态的分配Container，比如Map Reduce.
Yarn调度器
Yarn的调度器角色非常单一，就是一个纯粹的调度器，根据资源的申请需求进行分配，除此之外，没有其他功能。
调度器隶属于Resource Manager，是一个可插拔的组件，根据配置文件修改。
- FIFO调度器：顾名思义，先来的占据整个集群，后来的必须等前一个任务做完才会开始。
- 容量调度器：其实就是一个多队列调度器，不同队列有一个容量限制，任务会提交到具体某个队列中去。
- 公平调度器：保留队列的概念，如果只有一个任务，则占据全部资源，新来的作业，可以在前一个作业Container释放的时候，申请到这个Container，即使前一个作业还未彻底完成。此时的队列名其实就是用户名，每个用户一个队列，可以创建配置文件，分割每个用户的权重。也可以把每个用户都引流到default队列中，实现应用的公平调度。
网友评论