yarn命令（yarn命令kill任务）



在使用hadoop集群的时候,所有的任务都是最终以Application的形式跑在集群中,不管你是自己写的MR程序亦或是你写的hive sql转化成的mr任务,最终都是以Application应用的身份在跑.这些Application跑完之后,这些信息在jobHistory中就可以看了,可以说hadoop在这方面做得真的非常完整.但是完善归完善.但是jobHistory可以说是一种"事后分析",而有的时候我们反而是需要去控制目前所在的Applications.举个例子,比如某用户误启动了几十个应用,这些应用又是非常消耗资源的,一般这时候集群的管理者就会想尽办法去kill这些应用,否则资源都被占了,别人怎么使用.但是比较不幸的一点,目前Yarn在kill应用的操作上还没有提供批处理的方式,只有最简单的kill+appID的形式,都是单一的操作,所以会造成最后"应用是kill掉了,但是花了半个小时时间."这样的结果.所以本文就来分析一下批处理kill应用的解决方案,从应用场景到方案设计再到最终实现,依次进行描述.

1.误操作启动大量应用.就是文章开头所描述到的场景.这个在小集群,少用户的情况下不容易发生,但是一旦集群具备了一定规模,达到多组用户的时候,这种现象发生的概率就会比较高了.用户多了,遇到这种问题,必须得解决吧,而且必须得高效解决.

2.第二种情况发生在Application recovery阶段，比如说当你的集群中开启了yarn的recovery功能之后，此时做ResourceManager重启的时候，他会从rmStateStore中读取上次保存下来的Application信息，然后进行全部恢复。这个时候如果你不想要恢复上次由于RM服务停止造成中断的应用，那么你也需要有个方法去批量kill正在此时恢复的应用。这种场景就不是被动发生的，在某些场景下他就会出现，发生。

所以总结上面提到的2个case,1个是偏外部因素，1个是偏内部因素，但是都说明了我们需要1个方法能够去批量执行kill应用的操作。

现有存在于YARN中的kill应用的操作命令很简单，如下

没用过这个命令的同学可以在自己的测试集群中输入这个命令玩一下。同时yarn application下还有一些其他的命令参数，输入下面这个命令可以打出帮助信息

CLI是CommandLine的简称,就是命令行,上一段中的-kill <applicationId>在Yarn是是被定义为1个ApplicationCLI,是针对Application的命令操作.表现出来的形式是以YarnCli的形式被调用,所以会在前面看到yarn这个前缀.所以我们的1个目标就是创造出一些能进行批处理的执行kill应用的操作命令.但是这里会冒出另外1个问题,如果进行批量执行应用操作,那么这些待kill的应用一定具有某种类似或相同的属性,否则我们就无法划分,归类了.首先需要找出在Yarn中的Application到底有哪些属性,我截取出了部分代码:

另外一个project中的定义:

所以综合以上这2个类的定义,可以跳出3个比较常见的属性作为CLI参数,

第一.user,用户名.

第二.queue,所属队列.

第三.applicationState.应用状态,比如我想kill正在running状态的应用或是处于Accepted但是还没开始running的应用,这也是1个不错的指标维度.

我们最终想要达到的效果是这样的:

这里需要提出一点建议,对于第二个命令-killByUser,因为涉及到直接关联用户的操作命令,如果操作者是普通用户,不一定会有权限去kill别人的应用,所以这个命令更应该放在RmAdminCLI的命令中而不是YarnCLI.这一点在后面的具体代码实现中会加以区分.

在打算具体实现新的命令接口,需要首先对rm对应的内部对应服务有1个了解.ResourceManager在这里的设计可以说是比较巧妙的,为了避免客户端命令的服务影响admin超级管理员的命令服务,他将这2套服务进行了分开处理,即AdminService和ClientRMService,然后被RMAdminCLI和ApplicationCLI所远程调用,具体的结构如下

所以在后面需要改动代码的地方就是在图中出现的几个主要类中.

对Yarn新增命令行操作,难的并不是他的实现,而是在于他的流程,因为有些代码是自己生成的,你需要改一些.proto的文件,下面演示一下如何改ApplicationCLI,RMAdminCLI将简单描述.

里面不明白的地方,请自行查阅protocolbuffer的使用说明.最后使用编译命令重新打包,比如"mvn package -Dmaven.test.skip=true",以此生成相应代码.

比如以KillByAppStates的命令为例子:

Impl实现类中会用到之前pb生成的代码.

具体继承子类,一般就2类,1个是Client对应类,1个是服务端对应类,

服务端对应2个,1个是PbClient对应的PbServer还有1个真正操作的服务端,在这里就是ClientRMService

ClientRMService中的实现:

可以看到ClientRMService也是继承了ApplicationClientPtotocol,只要有新的客户端命令,就必然会存在对应的服务端的实现.上面的killApplicationsByAppStates的方法是模仿了原有的kill单一Application方法,如下:

最终都是把包装好后的kill event事件发给对应的处理分发器.

调用方法如下:

客户端的被调用方法就是要力求简单,就传个参数就可以了,主要操作在Server端执行就OK了.

在没有测试集群的情况下,这不失为1种最好的试验办法.对client端和Server端各造一个testcase.

对于其他2个维度,对user和queue都是类似的,这里就不重新进行描述了,具体代码可以见我下面的patch链接.这个新属性功能我将此建议功能提交开源hadoop社区,编号YARN-4529.

Issue链接:https://issues.apache.org/jira/browse/YARN-4529

Github patch链接:https://github.com/linyiqun/open-source-patch/tree/master/yarn/YARN-4529

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/rfx/68776.html