YARN命令与Rest API实战：集群资源调度诊断与自动化运维

1. 项目概述：YARN不是“ yarn”毛线，而是集群资源调度的中枢神经

很多人第一次看到YARN，下意识念成“yarn”（毛线），结果在技术讨论里被问：“你打算用毛线编个调度器出来？”——其实YARN全称是Yet Another Resource Negotiator，直译过来就是“又一个资源协调者”，但这个“又”字背后，藏着Hadoop生态十年演进的全部重量。它不是可有可无的配角，而是整个大数据平台真正意义上的“操作系统内核”：MapReduce、Spark、Flink、Presto、Hive on Tez……所有计算框架跑在YARN上，本质上都是在向YARN申请CPU、内存、容器（Container）这些硬资源。没有YARN，集群就是一堆散装服务器；有了YARN，它才真正成为一个可调度、可监控、可伸缩的统一资源池。

我最早接触YARN是在某高校实验室部署教学集群时，当时只当它是“启动MapReduce的配套服务”，直到某次Spark任务卡死，日志里全是ApplicationMaster failed to register，排查三天才发现是YARN ResourceManager内存被其他Java进程吃光，而自己连yarn top命令都没用过。从那以后，我把YARN命令和API当成运维人员的“听诊器”和“X光机”——不靠猜，不靠重启，靠命令输出的真实指标说话。这篇内容，就是把我在生产环境、测试集群、CI/CD流水线中高频使用的YARN命令和Rest API，掰开揉碎讲清楚：哪些命令能5秒定位问题，哪些API能嵌入监控看板，哪些参数调错会导致任务集体超时，以及为什么yarn application -kill有时比kill -9还管用。适合刚接手大数据平台的运维新人、需要调试Spark/Flink任务的开发同学，以及想把YARN状态接入自建告警系统的SRE工程师。核心不在于背命令，而在于理解每个命令背后对应的YARN组件行为逻辑。

2. YARN架构与命令/API映射关系：搞懂ResourceManager、NodeManager、ApplicationMaster三者的“权力分工”

要真正用好YARN命令和API，必须先厘清它的三层权力结构。这不像Linux命令那样“输入即执行”，YARN的每个操作都对应着特定组件间的通信和状态变更。我把这套机制类比成一家大型制造工厂的调度体系：

• ResourceManager（RM）是总调度中心，相当于工厂的“中央计划部”。它不直接干活，只做两件事：一是维护全局资源视图（当前集群还有多少CPU核、多少GB内存空闲），二是审批所有资源申请（比如Spark Driver说“我要32G内存”，RM决定批不批、分几块）。所有yarn开头的客户端命令，底层都是通过RPC或HTTP协议跟RM打交道。

• NodeManager（NM）是车间主任，每台物理机/虚拟机上都运行一个。它负责具体执行：启动容器、监控进程、汇报本机资源使用率（比如“我这台机器现在用了16G内存，还剩8G”）。yarn node命令查到的节点列表，就是所有NM向RM注册后的“在岗车间主任名单”。

• ApplicationMaster（AM）是每个应用的专属项目经理，由RM为每个提交的应用（如一个Spark作业）单独启动。AM不处理业务逻辑，只干一件事：代表本应用，持续向RM申请资源（“再给我5个2G内存的容器”），拿到后通知对应NM启动容器执行Task。yarn application命令查到的应用列表，本质就是所有AM的“项目经理花名册”。

提示：很多初学者误以为yarn logs -applicationId是去某个NM上翻日志文件，其实它走的是YARN的日志聚合机制——AM会把各Container日志上传到HDFS指定路径，yarn logs命令只是帮你从HDFS里把归档日志拉下来。如果没开启日志聚合（yarn.log-aggregation-enable=false），这条命令就完全失效。

Rest API的设计也严格遵循这套架构。所有以/ws/v1/cluster/开头的API（如/apps、/nodes）都是查询RM持有的全局状态；而/ws/v1/cluster/apps/{appid}/state这类带{appid}的API，则是RM根据AM注册信息，代理转发给对应AM获取的实时状态。这种设计决定了：RM API是快照式、最终一致的；AM API是实时式、强一致的，但只对本应用有效。比如你想查某个Spark作业的Shuffle数据量，必须调用AM的/metrics接口，而不是RM的/apps接口——后者根本不知道Shuffle是什么。

实操中最大的坑，就是混淆了“应用生命周期”和“容器生命周期”。yarn application -kill杀的是AM进程，AM死后会通知所有它管理的Container优雅退出；而yarn container -kill直接干掉某个Container进程，AM发现后会立刻申请新Container重试任务。前者是“解散项目组”，后者是“开除一个员工”。选错命令，轻则任务重试延迟，重则引发AM反复崩溃的雪崩效应。

3. 高频YARN命令详解：从日常巡检到故障急救的完整操作链

YARN客户端命令（yarn）是运维人员最直接的交互界面。它不像hdfs dfs命令那样纯粹是文件操作，而是深度耦合YARN状态机。下面按使用频率和场景，拆解真正值得每天敲的命令及其参数逻辑。

3.1 资源大盘与节点健康：yarn top与yarn node

yarn top是YARN版的top命令，但它显示的不是单机进程，而是整个集群的实时资源热力图。执行后你会看到类似这样的输出：

NODES: 4 HEALTHY: 4 UNHEALTHY: 0 DECOMMISSIONED: 0 LOST: 0 REBOOTED: 0 Queue: default Total: 64G Used: 42G Pending: 0B Reserved: 0B APPID USER QUEUE STATE FINAL_STATUS STARTED FINISHED DURATION MEM(GB) VCORES LOGICAL_TIME application_171... hive default RUNNING UNDEFINED 2024-05-10... N/A 1234567 32.0 16 123456789

关键字段解读：

• MEM(GB)列显示的是该应用已分配的内存总量，不是实际使用量。YARN只管分配，不管应用是否真用了这么多。
• LOGICAL_TIME是YARN内部计时器，单位毫秒，用于公平调度器（Fair Scheduler）的权重计算，和真实耗时无关。
• STATE为RUNNING但FINAL_STATUS为UNDEFINED，说明应用还在运行中，尚未完成。

注意：yarn top默认刷新间隔是3秒，可通过-interval参数调整（如yarn top -interval 10）。但别设太小——频繁轮询会给RM带来压力，尤其在百节点集群上，1秒刷新可能让RM CPU飙升20%。

yarn node则聚焦单点健康。常用组合是yarn node -list -states all，列出所有节点及其状态。状态含义至关重要：

• NEW：NM刚启动，正在向RM注册；
• RUNNING：正常工作；
• UNHEALTHY：NM主动上报“我这台机器磁盘快满了/内存泄漏了”，RM会停止派发新任务；
• DECOMMISSIONING：管理员手动下线节点，RM不再分配新任务，但允许现有Container跑完；
• LOST：NM心跳超时（默认10分钟未响应），RM认为节点失联，会强制杀死其上所有Container。

我曾遇到一个诡异问题：yarn node -list显示节点状态是RUNNING，但yarn top里该节点内存使用率始终为0。排查发现是NM配置了错误的yarn.nodemanager.resource.memory-mb=0，导致它向RM报告“我有0内存可分配”。此时yarn node -status <nodeId>会显示详细资源能力，一眼就能揪出配置错误。

3.2 应用全生命周期管理：yarn application的核心战场

yarn application是使用频率最高的命令，覆盖从提交、查询到终止的全流程。它的参数设计非常讲究，不是简单罗列选项，而是对应YARN状态机的关键节点。

• 提交应用：yarn jar本质是yarn application的封装。当你执行yarn jar xxx.jar MainClass，客户端会先向RM申请一个Application ID，再启动AM。注意-D参数可透传JVM选项，比如-Dyarn.app.mapreduce.am.env="JAVA_HOME=/opt/jdk11"，这是解决AM启动失败最常见的手段。

• 精准查询：yarn application -list默认只显示RUNNING和ACCEPTED状态的应用。但生产环境常需查历史任务，必须加-appStates参数：

  # 查最近24小时所有状态的应用（包括失败、完成） yarn application -list -appStates ALL -startTime 1715356800000 -endTime 1715443200000

  时间戳单位是毫秒，1715356800000对应2024-05-10 00:00:00 UTC。这里有个经验：YARN RM默认只保留10000个应用历史记录，超过会被自动清理。如果-list查不到老任务，不是命令错了，是RM的yarn.resourcemanager.max-completed-applications参数限制了。

• 深度诊断：yarn application -status <appid>返回JSON格式详情，包含startedTime、finishedTime、amContainerLogs（AM日志URL）、trackingUrl（Web UI链接）等。其中amContainerLogs字段值形如http://rm-host:8088/node/containerlogs/container_e01_1715356800000_0001_01_000001/hive，这就是yarn logs -applicationId命令的底层依据。

• 强制终止：yarn application -kill <appid>是故障处理的终极武器。但要注意：它发送的是KILL信号给AM，AM收到后会尝试优雅关闭（如Spark会触发Stage Cancel）。如果AM本身已僵死（比如OOM后卡在GC），这个命令会超时失败。此时必须用yarn application -forceKill <appid>（YARN 3.3+支持），它绕过AM直接通知RM标记应用为KILLED，RM再强制清理所有相关Container。切记：-forceKill是最后手段，滥用会导致数据不一致（如HDFS写入未完成）。

3.3 容器级精细操作：yarn container与yarn logs的实战技巧

当应用层面诊断无法定位问题时，必须下沉到容器（Container）层。yarn container命令提供了对单个Container的直接控制。

• yarn container -list <appid>列出该应用所有Container ID。输出中的State字段很关键：RUNNING表示容器进程在跑，COMPLETE表示已退出，FAILED表示启动失败。如果看到大量FAILED，大概率是资源不足（如申请8G内存但NM只有4G可用）或镜像拉取失败。

• yarn container -status <containerId>返回容器详细信息，其中diagnostics字段是排障金矿。例如：

  diagnostics: "Container [pid=12345,containerID=container_e01_1715356800000_0001_01_000001] is running beyond physical memory limits. Current usage: 8.2 GB of 8 GB physical memory used."

  这明确告诉你：容器因物理内存超限被NM Kill。解决方案不是调大YARN内存，而是检查应用代码是否存在内存泄漏，或调整JVM-Xmx参数使其小于YARN申请的内存。

yarn logs命令的威力常被低估。它不只是看日志，更是验证日志聚合是否生效的标尺：

# 获取应用主日志（AM日志） yarn logs -applicationId application_1715356800000_0001 # 获取某个Container的日志（需指定Container ID） yarn logs -applicationId application_1715356800000_0001 -containerId container_e01_1715356800000_0001_01_000001 # 按时间范围过滤（需Hadoop 3.2+） yarn logs -applicationId application_1715356800000_0001 -from 1715356800000 -to 1715357700000

实操心得：yarn logs默认只返回最近4KB日志。如果应用日志量巨大（如Spark Driver打印了10万行DEBUG），必须加-size参数，如-size 10485760（10MB）。否则你看到的永远是日志末尾的“Exception”，却找不到前面的“Connection refused”根源。

4. YARN Rest API深度解析：从状态监控到自动化运维的工程化落地

如果说YARN命令是运维人员的手动工具，那么Rest API就是把运维能力封装成服务、嵌入系统、实现自动化的基石。YARN的Rest API设计非常RESTful，路径清晰，状态码规范，是自动化脚本和监控平台的理想接口。

4.1 API基础结构与认证机制：绕不开的Kerberos与Simple Auth

YARN Rest API根路径是http://<rm-host>:8088/ws/v1/cluster/。所有请求都遵循标准HTTP方法：

• GET /apps：查询应用列表（对应yarn application -list）
• GET /apps/{appid}：查询单个应用详情（对应yarn application -status）
• GET /nodes：查询节点列表（对应yarn node -list）
• POST /apps：提交新应用（对应yarn jar）

但生产环境最大的拦路虎不是API语法，而是认证。YARN支持两种主流模式：

• Simple Authentication（简单认证）：适用于测试环境。只需在请求头加Authorization: Basic base64(username:password)。但明文密码风险极高，绝不允许在生产使用。

• Kerberos Authentication（Kerberos认证）：生产标配。客户端需先用kinit获取TGT票据，然后在HTTP请求头中加入Authorization: Negotiate <base64-encoded-ticket>。这个过程不能手写，必须用curl --negotiate -u :或Python的requests_kerberos库。我见过太多团队卡在这一步，最后用curl -k跳过SSL验证，却忘了Kerberos票据已过期，导致API返回401 Unauthorized。

提示：Kerberos环境下，yarn命令本身会自动处理票据传递，所以yarn application -list能成功，不代表你的curl脚本能成功。调试API时，务必用klist确认票据有效，且kinit -R可刷新票据。

4.2 核心API端点详解：从全局视图到应用细节的逐层穿透

4.2.1 集群全局状态：/apps与/nodes的参数魔法

GET /apps接口看似简单，但参数组合决定了你能挖多深的数据：

• state：过滤应用状态，支持all、running、accepted、failed等。state=failed是故障复盘的第一步。
• user：按提交用户过滤，user=hive可快速定位Hive服务的所有作业。
• queue：按队列过滤，queue=root.prod能隔离生产队列负载。
• limit与startedTimeBegin：分页与时间范围是性能关键。limit=1000一次拉1000条没问题，但limit=10000可能让RM响应超时。更稳妥的做法是结合时间戳分段查询：

  # 查询今天0点到当前时间的应用 curl "http://rm:8088/ws/v1/cluster/apps?startedTimeBegin=$(date -d 'today 00:00' +%s%3N)&state=all"

GET /nodes接口返回所有NM节点的健康快照。关键字段nodeHostName和nodeHTTPAddress是构建节点级监控的基础。我们曾用此API + Prometheus Exporter，实现了节点CPU、内存、磁盘使用率的实时看板，当healthReport字段包含"disk full"时自动触发告警。

4.2.2 应用深度诊断：/apps/{appid}与/apps/{appid}/state的协同作战

GET /apps/{appid}返回应用的静态元数据（提交时间、用户、队列），而GET /apps/{appid}/state返回动态运行时状态。两者结合才能看清真相。例如：

• /apps/{appid}中finalStatus=FAILED，但/apps/{appid}/state中state=RUNNING，说明应用已失败，但AM进程还在苟延残喘，需要-forceKill。
• /apps/{appid}中progress=0.0且state=ACCEPTED，说明AM还没启动成功，问题出在RM到NM的资源分配环节，应立即查/nodes看是否有节点UNHEALTHY。

更强大的是/apps/{appid}/attempts接口，它返回该应用所有AM尝试记录。一个Spark作业因AM OOM失败后，YARN会自动重试（yarn.resourcemanager.am.max-attempts默认2次）。通过遍历attempts，你能拿到每次AM失败的diagnostics，从而判断是代码问题还是资源配置问题。

4.2.3 日志与指标API：/apps/{appid}/logs与/apps/{appid}/metrics的工程价值

GET /apps/{appid}/logs是yarn logs命令的API版，但更灵活。它支持start_time和end_time参数，可精确截取某段时间的日志流，这对分析偶发性超时问题至关重要。例如：

# 获取应用启动后前5分钟的日志（排除初始化噪音） curl "http://rm:8088/ws/v1/cluster/apps/application_1715356800000_0001/logs?start_time=1715356800000&end_time=1715357100000"

GET /apps/{appid}/metrics则是Spark/Flink等框架的宝藏接口。它返回应用级别的运行指标，如：

• allocatedMB：已分配内存总量
• allocatedVCores：已分配vCore总数
• runningContainers：当前运行中的Container数
• totalLaunchedContainers：历史启动过的Container总数

这些指标可直接喂给Grafana，绘制“资源申请成功率”、“Container平均存活时间”等高阶监控图表。我们曾发现totalLaunchedContainers远大于runningContainers，且差值稳定在200左右，最终定位到是Spark的spark.dynamicAllocation.enabled=true配置导致大量Container被频繁启停，进而引发NM GC压力过大。

4.3 自动化运维脚本实战：用Python封装YARN API实现智能巡检

光会调API不够，必须把它变成可复用的工程能力。以下是一个生产环境验证过的Python巡检脚本核心逻辑（基于requests和requests_kerberos）：

import requests from requests_kerberos import HTTPKerberosAuth import time class YarnMonitor: def __init__(self, rm_host, kerberos=True): self.base_url = f"http://{rm_host}:8088/ws/v1/cluster" self.auth = HTTPKerberosAuth() if kerberos else None def get_failed_apps(self, hours=1): """获取过去N小时内失败的应用""" end_time = int(time.time() * 1000) start_time = end_time - hours * 3600 * 1000 params = { "state": "failed", "startedTimeBegin": start_time, "startedTimeEnd": end_time } resp = requests.get(f"{self.base_url}/apps", params=params, auth=self.auth) return resp.json().get("apps", {}).get("app", []) def get_app_diagnostics(self, app_id): """获取应用失败诊断信息""" resp = requests.get(f"{self.base_url}/apps/{app_id}", auth=self.auth) app_data = resp.json().get("app", {}) # 尝试获取最后一次AM尝试的诊断 attempts_resp = requests.get(f"{self.base_url}/apps/{app_id}/attempts", auth=self.auth) attempts = attempts_resp.json().get("appAttempts", {}).get("appAttempt", []) if attempts: last_attempt = sorted(attempts, key=lambda x: x.get("id", ""), reverse=True)[0] return last_attempt.get("diagnostics", "No diagnostics") return app_data.get("diagnostics", "No diagnostics") def auto_kill_stuck_apps(self, timeout_hours=2): """自动杀死运行超时的应用""" now = int(time.time() * 1000) timeout_ms = timeout_hours * 3600 * 1000 params = { "state": "running", "startedTimeBegin": now - timeout_ms } resp = requests.get(f"{self.base_url}/apps", params=params, auth=self.auth) apps = resp.json().get("apps", {}).get("app", []) for app in apps: if app.get("startedTime", 0) < now - timeout_ms: # 发送KILL请求（非force） kill_resp = requests.delete(f"{self.base_url}/apps/{app['id']}", auth=self.auth) print(f"Killed stuck app {app['id']}: {kill_resp.status_code}") # 使用示例 monitor = YarnMonitor("rm.example.com") failed_apps = monitor.get_failed_apps(hours=24) for app in failed_apps: diag = monitor.get_app_diagnostics(app["id"]) print(f"App {app['id']} failed: {diag}")

这个脚本的价值在于：它把零散的API调用变成了可配置、可调度、可告警的运维服务。我们把它部署在Airflow上，每15分钟执行一次，失败应用诊断信息自动推送到企业微信机器人，运维人员手机上就能看到“application_1715356800000_0001因java.lang.OutOfMemoryError: Java heap space失败”，点击链接直达YARN Web UI，5分钟内完成处置。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

YARN的报错信息往往像谜语，表面看是资源不足，根因可能是配置冲突、网络分区或时钟漂移。以下是我在多个集群踩过的坑，按发生频率排序，附带可直接复现的验证步骤和根治方案。

5.1 经典问题速查表：症状、根因、验证命令、修复方案

5.2 隐藏极深的配置冲突：yarn.nodemanager.resource.memory-mb与yarn.scheduler.maximum-allocation-mb的致命组合

这是最隐蔽也最致命的问题。假设你配置：

<!-- yarn-site.xml --> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>32768</value> <!-- NM声明有32G内存 --> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>16384</value> <!-- RM允许单个Container最大16G --> </property>

看起来合理，但当Spark提交一个--executor-memory 20g的任务时，YARN会拒绝分配，因为20G > 16G。然而错误日志里不会直接说“你超了最大分配”，而是模糊地报Failed to request resources。

验证方法极其简单：

# 查看RM实际接受的最大内存分配 curl "http://rm:8088/ws/v1/cluster/info" | jq '.clusterInfo' # 输出中找 "maxAllocationMB" 字段，它必须 >= 你的Executor内存

根治方案：yarn.scheduler.maximum-allocation-mb必须 ≥yarn.nodemanager.resource.memory-mb，且建议留20%余量。同理，yarn.scheduler.maximum-allocation-vcores也要 ≥yarn.nodemanager.resource.cpu-vcores。这个原则我称之为“NM声明即上限”，违反它，所有计算框架都会莫名失败。

5.3 网络与安全配置的连锁反应：HTTPS、Kerberos、反向代理的三角困局

当集群启用HTTPS和Kerberos后，yarn命令和API经常出现“证书验证失败”或“Negotiate失败”。这不是YARN的问题，而是客户端环境配置的锅。

典型场景：你在跳板机上执行yarn application -list成功，但用curl调API失败。原因往往是：

• yarn命令使用Java的HttpsURLConnection，默认信任JDK内置CA证书；
• curl默认使用系统CA证书，如果跳板机没更新CA证书，就会报SSL certificate problem: unable to get local issuer certificate。

解决方案分三步：

1. 统一证书信任源：将JDK的cacerts导出为PEM，配置curl使用它：

   # 导出JDK证书 $JAVA_HOME/jre/bin/keytool -exportcert -alias cacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -file /tmp/java-cacerts.pem # curl使用该证书 curl --cacert /tmp/java-cacerts.pem https://rm:8090/ws/v1/cluster/apps

2. Kerberos票据传递：确保kinit后，curl --negotiate -u :能成功。如果失败，检查/etc/krb5.conf中default_realm是否匹配，且klist输出的principal域名与RM的SPN（Service Principal Name）一致。
3. 反向代理陷阱：如果RM前端有Nginx反向代理，必须在Nginx配置中透传Authorization头：

   location /ws/v1/cluster/ { proxy_pass http://rm-backend; proxy_set_header Authorization $http_authorization; # 关键！ proxy_pass_request_headers on; }

这些细节，官方文档一笔带过，但线上故障80%都源于此。我的经验是：任何安全加固措施上线前，必须用yarn命令和curlAPI双重验证，缺一不可。

6. 工具链与最佳实践：构建属于你的YARN运维知识库

命令和API只是工具，真正的效率提升来自体系化的知识沉淀和流程固化。分享我在多个项目中验证有效的三个实践。

6.1 建立YARN命令速查卡片：把高频操作变成肌肉记忆

我用Markdown维护一份yarn-cheatsheet.md，放在团队共享Wiki上，内容不是罗列命令，而是按场景组织：

## 【紧急故障】5分钟定位法 - 第一步：`yarn top` 看全局资源水位和应用列表 → 判断是集群级还是应用级问题 - 第二步：`yarn node -list -states UNHEALTHY,LOST` → 排查节点异常 - 第三步：`yarn application -list -appStates FAILED -startTime $(date -d '1 hour ago' +%s%3N)` → 锁定最近失败应用 - 第四步：`yarn application -status <appid>` → 查`finalStatus`和`diagnostics` - 第五步：`yarn logs -applicationId <appid> -size 10485760` → 下载完整日志分析 ## 【日常巡检】自动化脚本模板 # 检查集群健康度（返回0=健康，1=异常） yarn node -list -states all 2>/dev/null | grep -q "UNHEALTHY\|LOST" && exit 1 || exit 0

这份卡片的好处是：新同事入职第一天就能独立处理90%的常见问题，无需翻文档。

6.2 API监控看板：用Grafana+Prometheus实现YARN指标可视化

单纯看API返回的JSON不够直观，必须转化为趋势图。我们用yarn-rest-exporter（一个开源Prometheus Exporter）抓取YARN API指标，配置关键看板：

• 集群资源利用率：yarn_cluster_metrics_memory_mb_used/yarn_cluster_metrics_memory_mb_total
• 应用失败率：rate(yarn_applications_final_status_failed_total[1h])/rate(yarn_applications_total[1h])
• Container启动成功率：yarn_containers_launched_totalvsyarn_containers_failed_total

当“Container启动成功率”曲线突然下跌，我们立刻知道是NM资源不足或镜像仓库故障，比等用户报障快10分钟。

6.3 配置版本化与变更审计：用Git管理yarn-site.xml

YARN的稳定性极度依赖配置。我们把所有yarn-site.xml、capacity-scheduler.xml放入Git仓库，每次修改必须：

• 提交PR，描述变更原因（如“为支持Flink Checkpoint大文件，增大yarn.nodemanager.vmem-pmem-ratio至4.0”）
• 关联Jira工单号
• 经过至少两名资深工程师Review

这样，当某天集群出现诡异问题，git blame能瞬间定位到是谁改了yarn.resourcemanager.scheduler.class，避免了“谁动了我的配置”的扯皮。

我个人在实际操作中的体会是：YARN的复杂性不在命令有多难记，而在于它把分布式系统的所有脆弱点都暴露了出来——网络、时钟、磁盘、内存、权限、配置。掌握这些命令和API，本质上是在训练一种系统性思维：看到一个现象，能快速在RM、NM、AM三层之间建立因果链，用数据代替猜测。这能力，远比记住yarn application -kill的拼写重要得多。