步骤2 提交ApplicationMaster。将启动ApplicationMaster所需的所有信息打包到数据结构ApplicationSubmissionContext中，主要包括以下几种信息：
(1) application id
(2) application 名称
(3) application优先级
(4) application 所属队列
(5) application 启动用户名
(6) ApplicationMaster对应的Container信息，包括：启动ApplicationMaster所需各种文件资源、jar包、环境变量、启动命令、运行ApplicationMaster所需的资源（主要指内存）等。
客户端调用ClientRMProtocol#submitApplication(ApplicationSubmissionContext)将ApplicationMaster提交到ResourceManager上。
（ResourceManager收到请求后，会为ApplicationMaster寻找合适的节点，并在该节点上启动它）。
客户端可通过多种方式查询应用程序的运行状态，其中一种是调用RPC函数ClientRMProtocol#getApplicationReport获取一个应用程序当前运行状况报告，该报告内容包括应用程序名称、所属用户、所在队列、ApplicationMaster所在节点、一些诊断信息、启动时间等。
（2）编写ApplicationMaster
ApplicationMaster需要与ResoureManager和NodeManager交互，以申请资源和启动Container，期间涉及到多个数据结构和两个RPC协议。具体步骤如下：
步骤1 注册。ApplicationMaster首先需通过RPC协议AMRMProtocol向ResourceManager发送注册请求RegisterApplicationMasterRequest，该数据结构中包含ApplicationMaster所在节点的host、RPC port和TrackingUrl等信息，而ResourceManager将返回RegisterApplicationMasterResponse，该数据结构中包含多种信息，包括该应用程序的ACL列表、可资源使用上限和下限等。
步骤2 申请资源。根据每个任务的资源需求，ApplicationMaster可向ResourceManager申请一系列用于运行任务的Container，ApplicationMaster使用ResourceRequest类描述每个Container（一个container只能运行一个任务）：
1）Hostname期望Container所在的节点，如果是“*”，表示可以为任意节点。
2）Resource capability 运行该任务所需的资源量，当前仅支持内存资源。
3）Priority 任务优先级。一个应用程序中的任务可能有多种优先级，ResourceManager会优先为高优先级的任务分配资源。
4）numContainers符合以上条件的container数目。
一旦为任务构造了Container后，ApplicationMaster会使用RPC函数AMRMProtocol#allocate向ResourceManager发送一个AllocateRequest对象，以请求分配这些Container，AllocateRequest中包含以下信息：
1）Requested containers 所需的Container列表
2）Released containers有些情况下，比如有些任务在某些节点上失败过，则ApplicationMaster不想再在这些节点上运行任务，此时可要求释放这些节点上的Container。
3）Progress update information 应用程序执行进度
4）ResponseId RPC响应ID，每次调用RPC，该值会加1。
ResourceManager会为ApplicationMaster返回一个AllocateResponse对象，该对象中主要信息包含在AMResponse中：
1）reboot ApplicationMaster是否需要重新初始化.当ResourceManager端出现不一致状态时，会要求对应的ApplicationMaster重新初始化。
2）Allocated Containers 新分配的container列表。
3）Completed Containers已运行完成的container列表，该列表中包含运行成功和未成功的Container，ApplicationMaster可能需要重新运行那些未运行成功的Container。
ApplicationMaster会不断追踪已经获取的container，且只有当需求发生变化时，才允许重新为Container申请资源。
步骤3 启动Container。当ApplicationMaster（从ResourceManager端）收到新分配的Container列表后，会使用RPC函数ContainerManager#startContainer向对应的NodeManager发送ContainerLaunchContext以启动Container，ContainerLaunchContext包含以下内容：
1）ContainerId Container id
2）Resource 该Container可使用的资源量（当前仅支持内存）
3）UserContainer所属用户
4）Security tokens 安全令牌，只有持有该令牌才可启动container
5）LocalResource运行Container所需的本地资源，比如jar包、二进制文件、其他外部文件等。
6）ServiceData 应用程序可能使用其他外部服务，这些服务相关的数据通过该参数指定。
6）Environment启动container所需的环境变量
7）command启动container的命令
ApplicationMaster会不断重复步骤2~3，直到所有任务运行成功，此时，它会调用AMRMProtocol#finishApplicationMaster，以告诉ResourceManage自己运行结束。
【注意】 整个运行过程中，ApplicationMaster需通过心跳与ResourceManager保持联系，这是因为，如果一段时间内（默认是10min），ResourceManager未收到ApplicationMaster信息，则认为它死掉了，会重新调度或者让其失败。通常而言，ApplicationMaster周期性调用RPC函数AMRMProtocol#allocate向其发送空的AllocateRequest请求即可。
MapReduce v2最基本的设计思想是将JobTracker的两个主要功能，即资源管理和作业调度及监控拆分为两个独立的进程。在该解决方案中包含两个组件：全局的Resource Manager和与每个应用相关的Application Master，ResourceManager和NodeManager（NM，每个节点一个）共同组成整个数据计算框架。
RM负责整个集群的资源管理和分配，是一个全局的资源调度系统。这里是纯调度工作，不再负责监控或者跟踪应用的执行状态，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些工作都交由AM执行。
NM是每个节点上的资源和任务管理器，定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；同时，它还接收并处理来自AM的Container启动/停止等各种请求。
用户提交的每个应用程序均包含1个AM，主要功能包括：
Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。会把程序的jar包也拷贝到容器内存中。
Yarn工作流程
yarn的工作流程如下图所示：
Yarn集群默认自带，不需要任何配置，并不适用于共享集群（多租户场景），耗时长的任务会导致后提交的任务一直处于等待状态，如果这个集群是多用户共享的，显然不合适。
[图片上传失败...(image-3635e5-1595569808205)]
Capacity Schedule调度器以队列为单位划分资源。一个个队列有独立的资源，队列的结构和资源是可以进行配置的，如下图：
default队列占30%资源，analyst和dev分别占40%和30%资源；类似的，analyst和dev各有两个子队列，子队列在父队列的基础上再分配资源。队列以分层方式组织资源，设计了多层级别的资源限制条件以更好的让多用户共享一个Hadoop集群，比如队列资源限制、用户资源限制、用户应用程序数目限制。队列里的应用以FIFO方式调度，每个队列可设定一定比例的资源最低保证和使用上限，同时，每个用户也可以设定一定的资源使用上限以防止资源滥用。而当一个队列的资源有剩余时，可暂时将剩余资源共享给其他队列。
在ResourceManager中配置它要使用的调度器，配置方式是修改conf/yarn-site.xml，设置属性：
调度器的核心就是队列的分配和使用了，修改conf/capacity-scheduler.xml可以配置队列。
Capacity调度器默认有一个预定义的队列——root,所有的队列都是它的子队列。队列的分配支持层次化的配置，使用.来进行分割，比如yarn.scheduler.capacity.<queue-path>.queues
下面是配置的样例，比如root下面有三个子队列:
它是队列的资源容量占比(百分比)。系统繁忙时，每个队列都应该得到设置的量的资源；当系统空闲时，该队列的资源则可以被其他的队列使用。同一层的所有队列加起来必须是100%。
队列资源的使用上限。由于系统空闲时，队列可以使用其他的空闲资源，因此最多使用的资源量则是该参数控制。默认是-1，即禁用。
每个任务占用的最少资源。比如，你设置成了25%。那么如果有两个用户提交任务，那么每个任务资源不超过50%。如果3个用户提交任务，那么每个任务资源不超过33%。如果4个用户提交任务，那么每个任务资源不超过25%。如果5个用户提交任务，那么第五个用户需要等待才能提交。默认是100，即不去做限制。
每个用户最多使用的队列资源占比，如果设置为50.那么每个用户使用的资源最多就是50%。
Fair调度器的设计目标是为所有的应用分配公平的资源（对公平的定义可以通过参数来设置）。公平调度也可以在多个用户间工作。举个例子，假设有两个用户A和B，他们分别拥有一个队列。当A启动一个job而B没有任务时，A会获得全部集群资源；当B启动一个job后，A的job会继续运行，不过一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个job并且其它job还在运行，则它将会和B的第一个job共享B这个队列的资源，也就是B的两个job会用于四分之一的集群资源，而A的job仍然用于集群一半的资源，结果就是资源最终在两个用户之间平等的共享。
Fair调度器的配置文件位于类路径下的fair-scheduler.xml文件中，这个路径可以通过yarn.scheduler.fair.allocation.file属性进行修改。我们可以在配置文件中配置每一个队列，并且可以像Capacity调度器一样分层次配置队列。比如，参考capacity-scheduler.xml来配置fair-scheduler：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）