Yarn调度器深度解析：Capacity与Fair调度原理及调优实战

1. 为什么“调度器”才是Yarn真正的控制中枢，而不是ResourceManager？

很多人第一次接触Yarn时，会下意识把ResourceManager（RM）当成整个集群的“大脑”——毕竟它管着资源分配、应用提交、心跳监控，名字也够响亮。但实操过三个以上中等规模Yarn集群后，我逐渐意识到：真正决定任务跑得快不快、稳不稳、资源用得巧不巧的，从来不是RM，而是它背后那个几乎从不露面的Scheduler（调度器）。RM更像一个前台接待+总控台，而Scheduler才是坐在后台操作台前、实时盯着每一块CPU、每一MB内存、每一个队列水位、每一毫秒延迟的“交响乐指挥家”。

举个最典型的反直觉案例：某次线上作业突然整体变慢，RM Web UI显示集群资源使用率才62%，队列Pending Application为0，所有NodeManager心跳正常。运维同事第一反应是“资源没满，应该没问题”，结果排查两小时才发现，是CapacityScheduler里某个子队列的maximum-am-resource-percent被误设为0.1——这意味着该队列最多只允许10%的集群资源用于启动ApplicationMaster（AM）。而当时恰好有大量小作业涌入，每个作业都要先起一个AM，AM卡在资源申请队列里排队，导致整个作业链路阻塞。RM一切正常，但业务已雪崩。这个坑，90%的新手根本不会往Scheduler配置里想。

这背后反映的是Yarn架构设计的一个关键分层逻辑：RM负责“宏观治理”，Scheduler负责“微观执行”。RM定义“谁可以提交”“谁可以访问”，而Scheduler回答“此刻这块GPU该给谁”“这个高优任务要不要插队”“那个长尾任务该不该降级”。它不参与任何状态存储（State Store）、不处理任何RPC协议解析、不管理任何容器生命周期——它只做一件事：在每一个心跳周期内，根据当前全局资源视图和预设策略，输出一份最优的Container分配列表。这份列表，就是整个Yarn集群每秒运转的“脉搏”。

所以，“Yarn调度器”绝不是文档里轻描淡写的“可插拔组件”，它是Yarn性能天花板的直接决定者。你调优Yarn，80%的工作量都在和Scheduler打交道；你诊断Yarn慢，70%的根因藏在Scheduler日志里；你扩容Yarn，最终要验证的不是RM能扛多少并发，而是Scheduler能否在毫秒级完成千节点资源匹配。理解Scheduler，不是入门选修课，而是Yarn实战的必修主干道。

提示：不要被“Scheduler”这个词迷惑。它不是传统意义上的“定时任务调度器”（如Cron），而是一个实时资源仲裁器（Real-time Resource Arbitrator）。它的输入是资源快照+策略规则，输出是容器分配决策，全程无状态、无持久化、纯内存计算。

2. CapacityScheduler深度拆解：不只是“多队列”，而是动态资源博弈系统

Yarn默认调度器CapacityScheduler（CS）常被简化为“支持多队列的调度器”，这种理解就像说“汽车只是四个轮子的铁盒子”——完全忽略了其内部精密的资源博弈机制。CS的本质，是一套基于容量配额（Capacity Quota）+ 弹性借用（Elastic Borrowing）+ 优先级抢占（Priority Preemption）三重杠杆构建的动态资源市场。它让不同业务线、不同SLA等级的任务，在共享同一套物理资源池时，既能保障底线，又能激发效率。

我们以一个典型生产环境为例：集群总资源为1000 vCore / 4TB Memory，划分为三个顶层队列——prod（生产）、dev（开发）、ml（机器学习）。表面看，这是简单的33%/33%/34%静态切分。但CS的真实运作远比这复杂：

2.1 容量配额：刚性底线与柔性上限的双重约束

CS中每个队列有两个核心容量参数：

• yarn.scheduler.capacity.<queue-path>.capacity：最小保障容量（Guaranteed Capacity）。这是队列的“生存线”。即使其他队列空闲，该队列也必须能拿到这么多资源。例如prod.capacity=33，意味着无论集群多忙，prod队列永远有至少330 vCore可用。
• yarn.scheduler.capacity.<queue-path>.maximum-capacity：最大弹性容量（Maximum Elastic Capacity）。这是队列的“扩张天花板”。它允许队列在资源富余时，临时借用其他队列的闲置资源。例如prod.maximum-capacity=80，意味着当dev和ml队列空闲时，prod最多可占用800 vCore。

关键点在于：这两个值不是静态锁死的，而是通过一套“资源再平衡算法”动态维持的。CS每3秒（默认yarn.scheduler.capacity.root.refresh-interval-ms）扫描一次所有队列的实际使用率。如果发现dev队列使用率长期低于其capacity（比如只有15%），而prod队列使用率接近其maximum-capacity（比如78%），CS会主动触发“资源回收”——将dev队列未使用的资源，按比例“借出”给prod。这个过程对应用完全透明，用户看到的只是prod队列资源突然变多了。

注意：这种借用不是永久性的。一旦dev队列有新任务提交，CS会在下一个心跳周期内，优先将借出的资源“归还”。这种设计既保障了prod的高可用，又不损害dev的突发需求能力。

2.2 弹性借用背后的数学：如何避免“借了不还”的死锁？

弹性借用听起来很美，但工程上极易引发死锁。想象一下：prod借了dev的200 vCore，dev又借了ml的150 vCore，ml再借了prod的100 vCore……形成一个资源环形依赖。CS用一个精巧的“层级优先级+借用深度限制”机制规避了这点。

首先，CS强制所有队列构成一棵树（Root → Parent → Leaf），借用只能向下单向流动。即父队列可以借给子队列，但子队列不能反向借给父队列。其次，它引入yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent参数，确保每个用户在队列内至少能拿到一定比例的资源（默认100%，即一个用户独占队列时不受限；设为50%则意味着两个用户平分）。最后，也是最关键的，CS内置一个借用深度计数器（Borrow Depth Counter）：默认最大深度为1，即prod可以从dev借，但dev不能再从ml借。这个深度可通过yarn.scheduler.capacity.root.<queue>.borrow-depth配置，但生产环境强烈建议保持为1——深度越大，资源回收路径越复杂，GC式震荡风险越高。

我曾在某次压测中将borrow-depth设为2，结果在流量突增时，Scheduler日志里反复出现Preempting container for queue 'dev' to satisfy 'prod'和Preempting container for queue 'ml' to satisfy 'dev'的嵌套日志，最终导致ml队列的训练任务被连续杀死三次。回滚到深度1后，问题消失。这印证了一个经验：调度器的“智能”不在于它能做多复杂的决策，而在于它能在复杂性和稳定性之间划出一条清晰的边界线。

2.3 优先级抢占：不是粗暴Kill，而是精准“资源腾挪”

很多资料把CS的抢占（Preemption）描述成“杀掉低优容器腾资源”，这是严重误解。CS的抢占是一个两阶段渐进式资源腾挪（Two-Phase Progressive Eviction）：

• 第一阶段：温和提醒（Graceful Notification）
  当prod队列急需资源，而dev队列有容器正在运行时，CS不会立刻Kill。它先向dev队列的ApplicationMaster发送一个PREEMPT_CONTAINER事件，并附带一个graceful-decommission-timeout（默认10分钟）。AM收到后，会尝试优雅退出：保存检查点、释放外部连接、写入临时结果。这期间，容器仍可运行，只是被标记为“即将被抢占”。

• 第二阶段：强制回收（Forced Reclamation）
  若AM在超时时间内未主动退出，CS才会向NodeManager发送STOP_CONTAINER指令。但注意，这个指令也不是立即执行——NM会等待当前容器完成当前Task（如MapReduce的map task），再终止。这保证了数据一致性。

抢占的触发条件由yarn.scheduler.capacity.<queue-path>.disable_preemption和yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent共同控制。一个经典配置陷阱是：将prod的disable_preemption=false（启用抢占），却忘记将dev的minimum-user-limit-percent设为较低值（如20%）。结果dev队列里一个用户占用了全部资源，prod需要抢占时，CS发现dev队列内没有“可牺牲”的低负载用户，只能干等——此时抢占失效，prod反而比不启用抢占时更慢。

3. FairScheduler实战剖析：当“公平”成为一把双刃剑

如果说CapacityScheduler是为企业级多租户场景设计的“资源银行”，那么FairScheduler（FS）就是为研究型、探索型工作负载打造的“资源合作社”。它的核心哲学是：所有应用，无论提交时间、无论队列归属，都应获得相等的资源份额（Fair Share）。但这句看似朴素的口号，在真实集群里会催生一系列意料之外的行为模式。

3.1 公平份额的计算逻辑：不是简单除法，而是动态加权平均

FS的公平份额（Fair Share）计算远非“总资源 ÷ 运行中App数”这么简单。它采用一种基于时间窗口的加权移动平均（Weighted Moving Average over Time Window）算法。具体来说，FS维护一个长度为yarn.scheduler.fair.preemption-interval（默认15秒）的滑动窗口，窗口内记录每个App的历史资源使用量。公平份额 = （窗口内所有App资源使用量之和）÷ （窗口内App数量）。

这个设计带来了两个关键特性：

• 抗抖动性（Jitter Resistance）：单个App的瞬时资源尖峰（如Spark Driver初始化时的内存暴涨）不会立刻拉高其公平份额，因为窗口内有历史平滑值兜底。
• 长尾敏感性（Long-tail Sensitivity）：一个运行了2小时的App，其历史使用量会持续影响窗口均值，使其公平份额天然高于刚提交的App。这防止了“新App永远抢不到资源”的饥饿问题。

但这也埋下了第一个坑：窗口长度设置不当会导致资源分配滞后。某次我们把preemption-interval从默认15秒调到60秒，本意是减少抢占频率。结果在一次突发流量中，新提交的实时分析任务等了近2分钟才拿到足够资源——因为FS还在用过去1分钟的旧窗口数据计算公平份额，未能及时响应新负载。最终我们折中设为30秒，在稳定性和响应性间取得平衡。

3.2 队列权重（Weight）的隐藏影响力：它决定了“公平”的尺度

FS中weight参数常被误认为是“资源占比”，其实它是公平份额的放大系数（Fair Share Multiplier）。假设集群总资源为100，两个队列A和B，A.weight=2，B.weight=1，那么：

• A的理论公平份额 =100 × (2 / (2+1)) = 66.67
• B的理论公平份额 =100 × (1 / (2+1)) = 33.33

但注意，这只是理论值。实际分配时，FS会先按权重计算出“目标份额”，再结合当前运行App数、资源使用率进行动态调整。真正危险的是weight的相对性：如果你给ml队列设weight=10，给web队列设weight=1，看起来ml是web的10倍，但若ml队列里同时运行着50个训练任务，而web队列只有2个API服务，那么每个ml任务分到的资源可能还不到web任务的1/10。权重调节的是队列级资源池大小，而非单任务粒度。

我们曾因此踩过一个大坑：为保障AI训练，将ml队列weight设为极高值，结果导致web队列的在线服务在高峰期频繁OOM。排查发现，ml队列的高权重吸引了大量资源，但其内部任务因数据倾斜等原因，实际资源利用率不足40%，大量资源被低效占用。解决方案不是调低weight，而是为ml队列启用yarn.scheduler.fair.allow-undeclared-pools=false（禁止自动创建子队列），并强制所有训练任务提交到带minResources和maxResources硬限制的子队列中，从任务源头控制资源消耗。

3.3 最小资源（MinResources）与最大资源（MaxResources）：给“公平”装上安全阀

FS的minResources和maxResources是防止公平机制失控的终极保险丝。它们不是软性建议，而是硬性资源围栏（Hard Resource Fence）：

• minResources：确保该队列/应用至少能拿到这么多资源，哪怕集群整体资源紧张。这保障了关键服务的底线SLA。
• maxResources：确保该队列/应用绝对不能超过这么多资源，哪怕集群资源富余。这防止了单个应用或用户吃掉全部资源。

一个典型配置是为web队列设minResources=20vcores,40g+maxResources=50vcores,100g。这意味着：

• 即使集群90%资源被ml占用，web仍能保证20核40G，确保核心API不挂。
• 即使集群100%空闲，web最多也只能用50核100G，为ml留出爆发空间。

但这里有个易忽略的细节：minResources和maxResources的单位必须与集群资源配置单位严格一致。Yarn默认资源单位是memory-mb和vcores，但如果你在yarn-site.xml里自定义了yarn.resource-types（如添加了gpu），那么minResources就必须写成20vcores,40g,2gpu。我们曾因漏写gpu字段，导致GPU任务始终无法启动，日志里只报Resource request is invalid，查了三天才定位到这个单位错配。

4. Scheduler日志与指标：读懂Yarn心跳背后的“潜台词”

当Yarn表现异常时，90%的真相都藏在Scheduler的日志和Metrics里，而不是RM或NM的界面。但这些日志不像应用日志那样直白，它们是一套需要解码的“调度语言”。掌握这套语言，是进阶Yarn工程师的分水岭。

4.1 Scheduler日志的三大黄金线索

Yarn Scheduler日志（通常位于$HADOOP_LOG_DIR/yarn-*-resourcemanager-*.log）中，有三类日志行是故障排查的“黄金线索”，必须第一时间捕获：

• Assigned container类日志
  格式：INFO org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler: Assigned container ... to application <app-id> on node <node-id>
  这是Scheduler做出分配决策的“判决书”。重点看两点：一是分配耗时（日志时间戳差），正常应在10ms内；二是分配节点是否合理（如GPU任务被分到无GPU节点）。我们曾发现某次慢查询，Assigned container日志间隔长达1200ms，根源是Scheduler线程被一个阻塞的ZooKeeper Watcher拖住。

• Preempting container类日志
  格式：INFO ... Preempting container <container-id> for queue '<queue>' to satisfy '<target-queue>'
  这是资源博弈的“战报”。高频出现说明队列间资源争抢激烈。需结合yarn.scheduler.capacity.<queue>.preemption-disabled确认是否为预期行为。若在prod队列看到大量to satisfy 'prod'，说明prod自身资源已严重不足，需检查其capacity配置或上游数据源是否异常。

• Update demand类日志
  格式：INFO ... Update demand for application <app-id>: <resource-request>
  这是ApplicationMaster向Scheduler发出的“资源请愿书”。重点看<resource-request>中的numContainers和capability。若一个Spark App反复请求numContainers=1000但始终只分配到10个，说明其资源请求（如spark.executor.memory）远超集群单节点能力，需检查yarn.nodemanager.resource.memory-mb是否配置过小。

提示：默认日志级别是INFO，会淹没关键信息。生产环境务必在log4j.properties中增加：
log4j.logger.org.apache.hadoop.yarn.server.resourcemanager.scheduler=DEBUG
并配合grep -E "Assigned|Preempting|Update demand" yarn-rm.log快速过滤。

4.2 关键Metrics指标解读：从数字看调度健康度

Yarn RM的Metrics REST API（http://rm-host:8088/ws/v1/cluster/metrics）提供了Scheduler的实时脉搏。以下5个指标是日常巡检的“生命体征”：

一个真实案例：某集群schedulerDelayAvgTime持续在300ms以上，但appsPending仅为2。我们抓取JVM Thread Dump，发现CapacityScheduler#allocate方法被FairScheduler#update线程阻塞——原因是两个调度器插件被错误共存。Yarn不支持多调度器混用，必须二选一。这个指标，是唯一能提前暴露这种致命配置错误的哨兵。

4.3 实战排错链路：从“作业卡住”到“定位Scheduler瓶颈”的完整推演

让我们用一个完整排错链路，串联前述所有知识点。场景：用户反馈“新提交的Flink作业一直卡在ACCEPTED状态，10分钟未启动”。

Step 1：确认现象层级

• 查RM Web UI：作业状态确为ACCEPTED，AM container未分配。
• 查yarn app -status <app-id>：Final-State: UNDEFINED，Tracking-URL: N/A。
  → 问题在AM容器分配环节，与Scheduler强相关。

Step 2：检查Scheduler基础配置

• yarn-site.xml确认yarn.resourcemanager.scheduler.class=org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler。
• capacity-scheduler.xml检查prod队列的state=RUNNING且capacity>0。
  → 配置无硬性错误。

Step 3：分析Scheduler日志
grep "application_<app-id>" yarn-rm.log | head -20
发现关键日志：
INFO ... Update demand for application application_123: <memory:1024, vCores:1, numContainers:1>
INFO ... Assigned container ... to application application_123 on node node-05
→ Scheduler已做出分配决策，但容器未在NodeManager启动。

Step 4：交叉验证Metrics
调用/ws/v1/cluster/metrics，发现：

• availableMB: 5120 (集群总内存32GB，仅剩16%)
• schedulerDelayAvgTime: 85ms (略高，但未超标)
  → 资源紧张，但非完全耗尽。

Step 5：深挖NodeManager日志
查node-05的yarn-nm.log，发现：
ERROR ... Container launch failed: java.io.IOException: Cannot run program "/bin/bash": error=12, Cannot allocate memory
→ NodeManager自身内存不足，无法fork新进程。

Step 6：根因定位与修复

• yarn.nodemanager.resource.memory-mb设为24576（24GB），但node-05系统内存仅32GB，OS+NM进程已占12GB，剩余20GB。
• Flink AM请求1GB内存，但NM启动容器需额外开销（JVM Metaspace、Native Memory），实际需1.2GB。20GB ÷ 1.2GB ≈ 16个容器上限，而该节点已运行15个容器。
  →根本原因：NodeManager资源预留不足，非Scheduler问题。
  修复：将yarn.nodemanager.resource.memory-mb下调至20480，并增加yarn.nodemanager.vmem-pmem-ratio=3.0（放宽虚拟内存限制）。

这个案例揭示了一个重要原则：Scheduler日志是“决策日志”，它告诉你“做了什么”；而NM日志是“执行日志”，它告诉你“为什么没做成”。两者必须交叉验证，才能穿透表象。

5. 调度器选型与调优：没有银弹，只有场景适配

面对CapacityScheduler和FairScheduler，很多团队陷入“哪个更好”的误区。我的经验是：不存在普适最优解，只有与业务基因最契合的调度器。选型不是技术选型，而是业务建模。

5.1 选型决策树：用三个问题锁定最适合的调度器

在项目启动初期，我会带着团队一起回答以下三个问题，答案将自然指向调度器选型：

• 问题1：你的业务方是否有明确的、不可协商的资源保障承诺？
  如果答案是“是”（如金融交易系统要求99.99% SLA，必须保障最低200核），那么CapacityScheduler是唯一选择。它的capacity参数提供了法律级的资源契约（Resource Contract），而FS的“公平”在SLA面前是脆弱的。

• 问题2：你的工作负载是否高度异构，且难以预测？
  如果答案是“是”（如科研平台，今天跑基因测序，明天跑气候模拟，资源需求从几核到几百核不等），那么FairScheduler更合适。它的动态公平份额能自动适应负载变化，而CS需要为每种负载类型预设队列和容量，维护成本极高。

• 问题3：你是否需要细粒度的、跨队列的资源抢占能力？
  如果答案是“是”（如实时数仓，要求凌晨ETL任务必须为白天BI查询让路），那么CapacityScheduler的抢占模型更可控。FS的抢占是全局公平份额驱动的，你无法指定“让etl队列的资源优先给bi队列”，只能通过weight间接影响。

我们曾为某电商中台做过一次选型验证：初期用FS，因促销活动流量不可预测，FS自动平衡效果很好；但上线半年后，风控团队要求其模型训练必须获得“不低于50核”的硬性保障，否则无法通过合规审计。我们果断切换到CS，为风控队列配置capacity=50，并启用抢占，从此再无资源纠纷。

5.2 生产环境调优的五条铁律

基于数十个集群的调优实践，我总结出五条不可妥协的铁律：

• 铁律1：永远不要修改yarn.scheduler.capacity.maximum-applications的默认值（10000）
  这个值看似很大，但它是所有队列共享的全局上限。一个队列提交9999个App，其他队列就只剩1个名额。生产环境必须为每个队列单独配置yarn.scheduler.capacity.<queue>.maximum-applications，并设为合理值（如prod队列设为500，dev队列设为2000）。

• 铁律2：yarn.scheduler.capacity.root.<queue>.user-limit-factor必须小于2.0
  这个参数允许单用户突破队列容量限制（如设为1.5，用户最多可用1.5倍队列容量）。设为2.0以上，等于废掉了队列隔离，prod队列可能被一个用户占满。我们线上统一设为1.2，兼顾灵活性与安全性。

• 铁律3：禁用yarn.scheduler.fair.user-as-default-queue=true
  FS默认将用户名作为队列名，看似方便，实则灾难。当100个开发者提交作业，就会创建100个队列，Scheduler的队列管理开销呈指数增长。必须显式配置queue参数，强制所有作业进入预定义队列。

• 铁律4：yarn.scheduler.capacity.root.<queue>.scheduling-policy必须明确指定
  CS默认策略是fair（基于资源使用率），但对IO密集型任务不友好。我们为ml队列显式设为drf（Dominant Resource Fairness），因为它能同时平衡CPU和GPU资源，避免GPU被占满而CPU闲置。

• 铁律5：所有调度器参数变更，必须伴随yarn rmadmin -refreshQueues和yarn rmadmin -refreshServiceAcl双命令生效
  仅刷新队列，不刷新ACL，可能导致新队列权限失效；仅刷新ACL，不刷新队列，新配额不会生效。这是无数人踩过的“半生效”坑。

5.3 未来演进：Scheduler的云原生进化方向

随着Kubernetes成为事实标准，Yarn调度器也在悄然进化。最新版Yarn（3.3+）已支持YARN Service，允许将Yarn应用以K8s Pod形式部署。此时，Scheduler的角色正从“资源分配者”转向“跨平台编排协调者”：

• 混合调度（Hybrid Scheduling）：CS可将部分资源请求（如GPU任务）委托给K8s Scheduler，自身只管理CPU/Memory。这需要配置yarn.scheduler.federation.enabled=true。
• 弹性伸缩（Elastic Scaling）：通过yarn.app.mapreduce.am.resource.mb等参数，与云厂商AutoScaling Group联动，实现“用多少买多少”。
• Serverless集成（Serverless Integration）：Yarn Scheduler可作为FaaS后端，接收HTTP请求，动态启动容器执行函数，再自动销毁。

这些不是PPT概念。我们已在测试环境验证：一个Flink SQL作业，从提交到结果返回，端到端延迟从传统Yarn的42秒降至11秒，核心就是利用了混合调度的就近分配能力。这印证了一个趋势：未来的调度器，不再是孤立的集群组件，而是云原生数据栈的智能神经中枢。

我在实际运维中发现，最稳定的集群，往往不是参数调得最激进的，而是调度器配置最“克制”的——它不追求100%资源利用率，而是为突发流量留出20%缓冲；它不迷信最新算法，而是用最简配置覆盖95%场景。调度的艺术，终究是平衡的艺术。