Yarn与MapReduce作业提交全过程深度解析

1. 项目概述这不是“提交按钮”那么简单的事Yarn和MapReduce的作业提交全过程听起来像教科书里一个被反复咀嚼的流程图——客户端敲下hadoop jar然后箭头指向ResourceManager再分发给NodeManager最后任务跑起来。但我在某高校大数据实验室带学生做分布式计算实训时发现超过七成的初学者卡在“为什么我的作业卡在ACCEPTED状态不动了”“为什么日志里报ApplicationMaster failed to start却找不到具体错在哪”“明明配置文件没改换台机器就提交失败”这类问题上。这些问题根本不是命令写错了而是对Yarn和MapReduce之间那层看不见的契约关系缺乏体感。Yarn不是MapReduce的“快递员”它是整套资源调度与生命周期管理的操作系统内核而MapReduce v2即YARN模式下的MR早已不是独立框架它只是运行在Yarn之上的一个可插拔的计算范式实现。所谓“作业提交全过程”本质是客户端、ResourceManager、NodeManager、ApplicationMaster四者之间完成三次关键握手第一次是申请初始容器AM Container第二次是AM启动后向RM申请计算资源Map/Reduce Container第三次是AM与NM协同拉起Task进程并维持心跳。这三步中任意一环的参数失配、权限越界、网络策略或资源水位异常都会让作业在某个状态“悬停”。我试过用yarn application -status查状态看到的是ACCEPTED但背后可能是AM容器因内存超限被NM直接kill也见过因为yarn.nodemanager.resource.memory-mb设得比物理内存还大导致所有NodeManager启动失败整个集群连SUBMITTED都进不去。所以这篇内容不讲API调用顺序也不贴一段hadoop jar命令完事——我们要拆开Yarn的Resource Manager服务线程、AM的启动引导逻辑、Container的沙箱初始化过程把每个环节的输入输出、校验规则、失败回滚机制用真实调试日志和配置对照表说清楚。适合正在搭建Hadoop集群的运维工程师、需要深度调优MR作业的开发人员以及想真正搞懂Yarn调度原理的大数据方向研究生。如果你只想要“5分钟跑通WordCount”那本文可能太重但如果你曾对着ApplicationState: FAILED的日志抓耳挠腮两小时那你来对地方了。2. 核心设计思路为什么必须是“三层解耦”架构2.1 从MRv1到YARN不是升级是范式重构很多人把YARN理解为“MapReduce的资源管理模块升级版”这是最危险的认知偏差。MRv1时代JobTracker既管资源又管计算逻辑JobTracker崩溃整个集群瘫痪且无法支持Spark、Flink等新计算框架。YARN的设计哲学是彻底解耦把集群资源管理Resource Management和应用生命周期管理Application Management拆成两个独立服务。这个决策不是为了炫技而是解决三个刚性约束资源复用率瓶颈MRv1中一个Map Task占用的JVM进程即使中间空闲也无法被其他作业借用。YARN通过Container抽象让CPU、内存、磁盘IO成为可动态切分的“时间片”同一物理节点可同时运行Map Task、Spark Executor、甚至自定义的Python脚本容器。多框架共存需求某公司生产环境同时跑着MR做ETL、Spark做实时统计、Tez做交互式查询。如果每个框架都自带资源管理器集群将变成“多套调度系统打架”的修罗场。YARN作为统一资源仲裁者所有框架只需实现自己的ApplicationMasterAM即可接入同一套资源池。故障隔离等级提升MRv1中一个烂写的Mapper导致JobTracker OOM全集群停工。YARN中单个AM崩溃只影响本作业ResourceManagerRM和NodeManagerNM服务持续可用新作业照常提交。提示YARN本身不关心你运行的是MapReduce还是其他框架——它只认Container请求和心跳报告。所谓“Yarn和MapReduce的作业提交”准确说是“MapReduce框架如何作为YARN的客户端遵循YARN协议发起资源请求”。2.2 作业提交的“三次握手”模型YARN作业提交不是线性流程而是由客户端触发、RM协调、NM执行、AM反向驱动的闭环协作。我把这个过程提炼为“三次握手”每一步都对应明确的协议动作和失败域第一次握手客户端 → ResourceManager申请AM容器客户端如hadoop jar命令向RM提交ApplicationSubmissionContext包含AM启动命令、所需内存/CPU、安全凭证等。RM验证资源池水位、队列配额、用户权限后返回ApplicationId并在内部创建Application对象。此时作业状态为SUBMITTED。若失败常见原因队列已满Queue default is full、用户无提交权限User xxx not allowed to submit applications to queue default、AM内存请求超限Requested memory 2048 beyond max threshold。第二次握手ApplicationMaster → ResourceManager申请Task容器AM启动后主动向RM注册开始周期性发送AllocateRequest声明需要多少个Map Container、多少个Reduce Container、每个Container的资源规格如memory-mb1024, vcores1。RM根据调度策略如CapacityScheduler的队列权重、FairScheduler的公平性算法分配Container并通过AllocateResponse返回ContainerId和NM地址。此时作业状态进入ACCEPTED。若卡在此处90%是AM未正确解析RM返回的Container信息或NM地址不可达防火墙阻断、DNS解析失败。第三次握手ApplicationMaster → NodeManager启动Task容器AM拿到ContainerId和NM地址后向对应NM发送StartContainerRequest携带Task运行脚本、JAR包路径、环境变量。NM校验ContainerId有效性、检查本地磁盘空间、启动Linux Container ExecutorLCE沙箱最终fork出JVM进程执行Mapper/Reducer。此时作业状态变为RUNNING。失败高发点NM磁盘空间不足Disk space is low、LCE权限配置错误Cannot run sudo command、JAR包路径在NM节点不存在客户端上传的JAR未同步到所有NM。注意这三次握手不是严格串行。AM在第一次握手成功后立即开始第二次握手即AM启动过程中就发资源请求而第三次握手在AM收到Container后并发执行。这种异步设计提升了吞吐量但也增加了调试复杂度——你看到ACCEPTED状态时AM可能已在后台疯狂请求资源只是RM还没分配到位。2.3 MapReduce v2的特殊性AM即MR框架的“总控大脑”MapReduce框架在YARN上运行时其ApplicationMasterMRAppMaster不是简单代理而是承担了MRv1中JobTracker的全部核心逻辑解析InputSplit生成Map Task列表实现Shuffle Service管理Map输出的分区、排序、溢写供Reduce拉取监控Task进度处理Speculative Execution推测执行汇总Counter指标生成作业报告。这意味着MR作业的性能瓶颈往往不在YARN资源层而在MRAppMaster自身的调度策略。例如当Reduce Task数远大于Map Task数时MRAppMaster会提前启动Reduce但若Reduce Container迟迟未分配它会不断重试请求导致RM线程积压。我实测过一个1000个Map、500个Reduce的作业在yarn.scheduler.capacity.maximum-am-resource-percent0.1AM最大资源占比10%的配置下Reduce Container分配延迟高达47秒——因为AM自身占用了大量RM调度线程。解决方案不是调大这个参数而是减少Reduce并发数或启用mapreduce.job.reduce.slowstart.completedmaps0.8让Reduce等到80%的Map完成后再启动降低AM资源争抢。3. 核心环节深度拆解从命令敲下到Container启动3.1 客户端提交阶段hadoop jar背后的12个关键动作当你执行hadoop jar wordcount.jar WordCount /input /output时客户端通常是运行该命令的机器并非简单转发请求而是完成一套完整的预处理流水线。以下是实际调试中抓取的12个关键动作按执行顺序排列配置加载读取core-site.xml、hdfs-site.xml、yarn-site.xml合并-D参数如-D mapreduce.map.memory.mb2048。注意客户端配置优先级最高会覆盖集群默认值。HDFS路径解析检查/input是否存在、是否为目录、用户是否有读权限。若/input是相对路径自动补全为hdfs://namenode:8020/user/$USER/input。InputFormat验证实例化TextInputFormat调用isSplitable()确认文件可分片。若输入是.gz压缩文件不可分片则整个文件作为一个InputSplit导致Map Task数1严重拖慢大文件处理。InputSplit计算调用getSplits()根据mapreduce.input.fileinputformat.split.minsize和maxsize计算分片数。例如1GB文件minSize128MB则生成8个Split1024/1288。JAR包上传将wordcount.jar及所有依赖JAR通过-libjars指定上传至HDFS临时目录如/user/$USER/.staging/application_1234567890_0001/。这是关键若客户端与HDFS网络不通上传失败直接报Failed to upload resources。ApplicationSubmissionContext构建组装核心对象包括AMContainerLaunchContextAM启动命令java -Xmx1024m org.apache.hadoop.mapreduce.v2.app.MRAppMaster...ResourceAM所需资源memory-mb1536, vcores1SecurityTokensHDFS和YARN的Delegation Token用于跨服务认证RPC连接RM通过YarnClient建立到ResourceManager的RPC连接端口8032。若yarn.resourcemanager.address配置错误报Connection refused。提交Application调用submitApplication()RM返回ApplicationIdapplication_1234567890_0001状态变SUBMITTED。监控Application状态客户端启动轮询线程每秒调用getApplicationReport()查询状态。若RM响应慢可通过yarn.client.failover-retries增加重试次数。日志聚合开关检查yarn.log-aggregation-enabletrue决定是否启用日志聚合作业结束后自动收集各NM日志到HDFS。历史服务器注册若mapreduce.jobhistory.address配置有效客户端向JobHistory Server注册作业元数据供后续Web UI查询。退出客户端进程客户端在作业状态变为ACCEPTED或FAILED后退出不等待作业完成。这就是为什么hadoop jar命令很快返回但作业仍在后台运行。实操心得调试提交失败第一件事不是看AM日志而是检查客户端控制台输出。我遇到过一次ClassNotFoundException: org.apache.hadoop.mapreduce.v2.app.MRAppMaster根源是客户端hadoop-mapreduce-client-app.jar版本与集群不一致客户端用3.3.0集群是3.2.1导致AM类加载失败。解决方案统一所有节点的Hadoop版本或使用hadoop classpath确认客户端类路径。3.2 ResourceManager侧资源仲裁的四大核心组件ResourceManager不是单体服务而是由四个核心组件协同工作。理解它们的职责是诊断ACCEPTED卡顿的关键ClientRMService监听8032端口处理客户端提交请求。它只做轻量级校验如队列存在性、用户权限不参与资源分配。若此处失败日志在$HADOOP_LOG_DIR/yarn-*-resourcemanager-*.log中搜索ClientRMService。ApplicationMasterService管理所有Application生命周期。当AM向RM注册时它创建ApplicationAttempt对象维护AM心跳、状态变更。若AM注册超时默认10分钟RM会标记Application为FAILED。ResourceScheduler真正的“大脑”负责Container分配。YARN默认使用CapacityScheduler容量调度器其核心是队列树结构。每个队列有capacity最小保障容量、maximum-capacity最大弹性容量、state运行/停止。例如property nameyarn.scheduler.capacity.root.default.capacity/name value50/value !-- 默认队列占总资源50% -- /property property nameyarn.scheduler.capacity.root.default.maximum-capacity/name value80/value !-- 但最多可用80% -- /property若所有队列usedCapacity已达100%新作业将永远卡在ACCEPTED。RMContainerAllocatorAM与RM通信的桥梁。它接收AM的AllocateRequest调用ResourceScheduler.allocate()获取Container再封装成AllocateResponse返回。若此处积压说明RM调度线程繁忙需检查yarn.resourcemanager.scheduler.client.thread-count默认50是否足够。常见陷阱yarn.scheduler.capacity.root.queues配置错误。例如误写为default,dev,test但实际只创建了default队列则dev和test作业提交时因队列不存在直接失败。正确做法先用yarn queue -list确认队列列表再提交。3.3 ApplicationMaster启动从JVM进程到MR调度中枢MRAppMaster的启动是作业成败的“临门一脚”。它不是一个简单的Java进程而是一个嵌入了完整MR调度逻辑的复杂服务。启动过程可分为四个阶段阶段1JVM进程启动耗时1sRM通过NM启动AM Container执行命令类似java -Xmx1536m -Djava.security.auth.login.config/etc/hadoop/conf/yarn_jaas.conf \ -Dyarn.app.mapreduce.am.envHADOOP_MAPRED_HOME/opt/hadoop \ org.apache.hadoop.mapreduce.v2.app.MRAppMaster \ --config /etc/hadoop/conf \ --container-id container_e01_1234567890_0001_01_000001 \ --resource-manager-address namenode:8032关键参数-Xmx必须≥yarn.app.mapreduce.am.resource.mb否则JVM启动失败--container-id是RM分配的唯一标识AM用它向RM注册。阶段2RM注册与心跳建立耗时1-5sAM启动后立即调用registerApplicationMaster()向RM注册传入hostAM所在NM的IP用于RM反向连接rpcPortAM的RPC端口默认10020trackingUrlAM Web UI地址如http://nm1:8088/proxy/application_1234567890_0001/RM验证ContainerId有效性后返回RegisterApplicationMasterResponseAM开始以1s间隔发送心跳。阶段3InputSplit解析与Task规划耗时与数据量正相关AM从HDFS读取客户端上传的job.split文件含所有InputSplit信息调用JobSplitReader.readSplitFile()解析。对于1TB数据此步骤可能耗时30秒以上。若HDFS NameNode压力大AM会卡在此处表现为ACCEPTED状态长时间不变但AM日志无报错。阶段4Shuffle Service初始化耗时2sAM启动内置的ShuffleHandler服务端口13562用于接收Map Task的输出数据。它会在本地磁盘创建$YARN_LOCAL_DIRS/usercache/$USER/appcache/application_1234567890_0001/output/目录。若yarn.nodemanager.local-dirs磁盘空间不足ShuffleHandler启动失败AM直接退出。实操技巧快速定位AM启动失败点。在NM节点上执行# 查看AM容器日志 yarn logs -applicationId application_1234567890_0001 -am ALL # 或直接查NM本地日志 tail -f $YARN_LOG_DIR/userlogs/application_1234567890_0001/container_e01_1234567890_0001_01_000001/stderr若日志首行是Exception in thread main java.lang.OutOfMemoryError: Java heap space说明-Xmx设置过小若是java.io.IOException: Failed on local exception: java.io.IOException: Resource temporarily unavailable大概率是yarn.nodemanager.vmem-pmem-ratio内存比例配置不当导致Linux OOM Killer干掉了AM进程。3.4 NodeManager侧Container沙箱的七道安检NodeManager是YARN的“执行终端”每个Container都在其管控的沙箱中运行。从AM发送StartContainerRequest到Task JVM启动NM要完成七道严格安检ContainerId校验检查container_e01_1234567890_0001_01_000001是否在NM内存中存在且状态为ALLOCATED。若RM已回收该Container如超时未启动NM拒绝启动。资源配额检查对比yarn.nodemanager.resource.memory-mb和vcores确认请求资源未超节点上限。例如节点总内存32GByarn.nodemanager.resource.memory-mb2457624GB若请求memory-mb25600NM直接拒绝。磁盘空间检查扫描yarn.nodemanager.local-dirs如/data1/yarn/local,/data2/yarn/local确保每个目录剩余空间yarn.nodemanager.disk-health-checker.min-allowed-space默认1GB。若任一目录不足NM标记该目录为UNHEALTHY不再分配Container。Linux Container ExecutorLCE权限检查若启用LCEyarn.nodemanager.container-executor.classorg.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutorNM以yarn用户执行sudo -u $USER命令启动Container。需确保/etc/passwd中有yarn用户且/etc/sudoers包含yarn ALL(ALL) NOPASSWD: ALL。JAR包本地化从HDFS下载AM指定的job.jar、job.split等到本地$YARN_LOCAL_DIRS/usercache/$USER/appcache/application_1234567890_0001/filecache/。若HDFS客户端配置错误下载失败报Failed to localize resources。环境变量注入将mapred.child.java.opts-Xmx1024m等参数注入Container环境。注意mapred.child.java.opts作用于Task JVM而yarn.app.mapreduce.am.env作用于AM JVM二者不能混淆。进程启动与沙箱隔离调用LinuxContainerExecutor.launchContainer()通过cgroups限制CPU、内存通过chroot或mount namespace隔离文件系统最终执行java -Xmx1024m WordCountMapper ...。关键参数对照表以下参数直接影响Container能否成功启动必须在yarn-site.xml中全局配置并在客户端提交时显式指定参数名典型值作用不匹配后果yarn.nodemanager.resource.memory-mb24576NM节点总内存上限请求超限则Container分配失败yarn.nodemanager.resource.cpu-vcores8NM节点总CPU核数请求vcores超限RM不分配Containeryarn.nodemanager.vmem-pmem-ratio2.1虚拟内存与物理内存比例过低导致Task被OOM Killer杀死yarn.nodemanager.local-dirs/data1/yarn/localContainer本地磁盘路径路径不存在或无写权限启动失败yarn.nodemanager.log-dirs/data1/yarn/logsContainer日志存储路径日志无法写入Task静默失败4. 实操全流程与避坑指南一次真实的WordCount调试记录4.1 环境准备三节点伪分布式集群精简版为还原真实场景我搭建了一个三节点伪分布式集群非完全分布式但复现了所有关键组件Master节点运行NameNode、ResourceManager、JobHistoryServerWorker1节点运行DataNode、NodeManagerWorker2节点运行DataNode、NodeManager核心配置摘要yarn-site.xml!-- RM地址 -- property nameyarn.resourcemanager.address/name valuemaster:8032/value /property !-- NM向RM汇报地址 -- property nameyarn.resourcemanager.hostname/name valuemaster/value /property !-- NM本地资源 -- property nameyarn.nodemanager.resource.memory-mb/name value8192/value !-- 8GB -- /property property nameyarn.nodemanager.resource.cpu-vcores/name value4/value /property !-- 启用LCE生产环境必需 -- property nameyarn.nodemanager.container-executor.class/name valueorg.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor/value /property property nameyarn.nodemanager.linux-container-executor.group/name valuehadoop/value /property注意伪分布式模式下yarn.nodemanager.resource.memory-mb不能设得过大否则NM启动时因内存不足失败。我测试过设为1228812GB在8GB物理内存机器上必然OOM。4.2 提交WordCount作业从成功到失败的完整链路第一步准备数据# 在HDFS创建输入目录 hdfs dfs -mkdir -p /input # 上传10MB测试文件避免小文件过多 dd if/dev/zero oftest.txt bs1M count10 hdfs dfs -put test.txt /input/第二步提交作业成功案例hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.0.jar \ wordcount -D mapreduce.map.memory.mb2048 \ -D mapreduce.reduce.memory.mb2048 \ -D yarn.app.mapreduce.am.resource.mb2048 \ /input /output_$(date %s)预期结果客户端输出Running job: job_1234567890_0001约15秒后作业完成/output目录生成part-r-00000。关键观察点yarn application -list显示状态FINISHEDyarn logs -applicationId application_1234567890_0001可查看完整日志Web UIhttp://master:8088/cluster/apps中点击Application看到Map/Reduce进度条流畅推进。第三步人为制造失败模拟真实问题我修改yarn-site.xml将yarn.nodemanager.resource.memory-mb从8192改为1638416GB重启NM服务。再次提交相同作业现象客户端显示Running job: job_1234567890_0002但10分钟后仍卡在ACCEPTEDWeb UI显示State: ACCEPTED, Final-State: UNDEFINED。排查过程查RM日志grep application_1234567890_0002 $HADOOP_LOG_DIR/yarn-*-resourcemanager-*.log发现INFO org.apache.hadoop.yarn.server.resourcemanager.rmapp.RMAppImpl: application_1234567890_0002 State change from SUBMITTED to ACCEPTED证明第一次握手成功。查AM日志yarn logs -applicationId application_1234567890_0002 -am 1发现ERROR org.apache.hadoop.yarn.server.nodemanager.containermanager.ContainerManagerImpl: Failed to start container但无具体原因。查NM日志tail -f $YARN_LOG_DIR/yarn-*-nodemanager-*.log | grep application_1234567890_0002终于看到关键错误WARN org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Container [pid12345,containerIDcontainer_e01_1234567890_0002_01_000001] is running beyond virtual memory limits. Current usage: 2.1 GB of 2 GB physical memory used; 4.3 GB of 4.2 GB virtual memory used.—— 这是因为vmem-pmem-ratio2.18GB物理内存对应16.8GB虚拟内存但NM配置了16GB内存上限导致cgroups强制kill了Container。第四步修复并验证将yarn.nodemanager.resource.memory-mb改回8192重启NM。为防虚拟内存超限追加参数-D yarn.nodemanager.vmem-pmem-ratio3.0提高容错。重新提交作业12秒内完成。实操心得不要迷信“配置越大越好”。我见过生产环境将yarn.nodemanager.resource.memory-mb设为节点总内存的90%结果NM自身因内存不足频繁GC反而降低吞吐量。经验公式yarn.nodemanager.resource.memory-mb 总内存 × 0.7 - NM进程预留内存约1GB。4.3 常见问题速查表与独家避坑技巧以下是我整理的高频问题速查表按发生阶段分类附带根因分析和一键修复命令问题现象发生阶段根本原因快速诊断命令修复方案Application rejected by queue placement policy客户端提交队列配额满或用户无权限yarn queue -status default调整yarn.scheduler.capacity.root.default.capacity或切换队列Application state is KILLED提交后立即RM侧AM容器启动失败如JAR包路径错误yarn logs -applicationId id -am 1检查-files、-libjars路径确保HDFS可读卡在ACCEPTED超5分钟AM启动后AM未收到ContainerRM调度阻塞yarn top查看Active Apps数yarn scheduler查看队列使用率增加yarn.resourcemanager.scheduler.client.thread-count检查队列maximum-capacityContainer exited with a non-zero exit code 143NM侧Container被Linux OOM Killer杀死dmesg -T | grep -i killed process降低mapreduce.map.memory.mb调大yarn.nodemanager.vmem-pmem-ratioShuffle output lost for attempt_xxx_m_000001_0AM运行中ShuffleHandler端口被占用或磁盘满netstat -tuln | grep 13562df -h $YARN_LOCAL_DIRS修改mapreduce.shuffle.port清理yarn.nodemanager.local-dirsjava.lang.ClassNotFoundException: org.apache.hadoop.mapreduce.lib.input.FileInputFormatTask启动客户端未上传依赖JARhadoop classpath对比客户端与NM类路径提交时加-libjars /path/to/hadoop-mapreduce-client-core.jar独家避坑技巧血泪总结技巧1用-D参数覆盖配置而非改XML生产环境严禁直接改yarn-site.xml用-D参数临时覆盖。例如-D yarn.app.mapreduce.am.resource.mb3072。这样不同作业可差异化配置互不影响。技巧2AM日志永远比客户端日志重要客户端报错往往是表象AM日志yarn logs -applicationId id -am ALL才揭示真相。我养成了习惯只要作业失败第一件事就是拉AM日志第二件事才是查RM/NM。技巧3用yarn top代替jps看实时负载jps只能看进程是否存在yarn top能看实时Container数、内存使用率、活跃Application数是判断集群健康度的黄金指标。技巧4为MRAppMaster单独配置GC参数MRAppMaster内存压力大易Full GC。在mapred-site.xml中添加property namemapreduce.map.java.opts/name value-Xmx1024m -XX:UseG1GC -XX:MaxGCPauseMillis200/value /property5. 深度扩展超越WordCount的生产级实践5.1 大作业调优从“能跑”到“快跑”的三把钥匙一个10TB数据的WordCount作业在默认配置下可能跑2小时经过调优可压缩到25分钟。这不是玄学而是基于对YARN-MR交互链路的精准干预钥匙1InputSplit粒度优化默认mapreduce.input.fileinputformat.split.minsize1导致小文件过多。对10TB数据应设为128MBHDFS块大小-D mapreduce.input.fileinputformat.split.minsize134217728效果Map Task数从8万降至8万×(128/1)8万不是降到10TB/128MB≈8万但每个Task处理数据更均衡避免“长尾Task”。钥匙2Shuffle阶段内存调优Shuffle是MR瓶颈占总耗时40%以上。关键参数mapreduce.task.io.sort.mb2048Map端排序内存从默认100MB提至2GB减少磁盘溢写次数。mapreduce.reduce.shuffle.input.buffer.percent0.7Reduce端缓冲区占比从0.7提至0.9加快Map输出拉取速度。mapreduce.reduce.merge.inmem.threshold1000内存中Map输出数阈值避免过早归并。钥匙3YARN资源抢占策略在capacity-scheduler.xml中为高优队列开启抢占property nameyarn.scheduler.capacity.root.default.allow-preemption/name valuetrue/value /property property nameyarn.scheduler.capacity.root.default.preemption-weight/name value1.0/value /property当高优作业提交时RM可强制回收低优作业的Container实现资源动态腾挪。5.2 安全加固Kerberos环境下作业提交的额外关卡在启用了Kerberos的集群中作业提交多了两道认证关卡客户端票据获取提交前必须kinit -kt user.keytab userREALM否则报GSSException: No valid credentials provided。Delegation Token传递客户端需将HDFS和YARN的Token注入ApplicationSubmissionContext。若hadoop.security.token.service.use_iptrue而DNS解析不稳定会导致Token验证失败。解决方案在core-site.xml中设false用IP直连。注意Kerberos环境下yarn logs命令需额外参数yarn logs -applicationId id -am ALL -containerId cid否则因Token过期无法拉取日志。5.3 故障演练模拟RM单点故障的恢复流程YARN的HAHigh Availability是生产必备。模拟RM故障kill -9主RM进程观察备用RMStandby RM是否在30秒内切换为Activeyarn rmadmin -getServiceState提交新作业验证是否正常检查yarn.resourcemanager.ha.automatic-f