大数据：YARN 资源调度怎么调优？队列配置与任务排队、资源争抢解决方案

一、问题的本质：调度不是调参，而是履约

很多团队在 YARN 调优上的第一反应是改参数：把 yarn.scheduler.maximum-allocation-mb 调大、把队列 capacity 调高、把 yarn.nodemanager.resource.memory-mb 顶到物理内存上限。改完之后短期似乎“不排队了”，过两周又回到原点。原因在于：调度参数只是表达资源分配意图的语言，真正决定体验的是资源承诺与负载形态是否匹配。

Apache Hadoop 官方文档对 Capacity Scheduler 的定位是“多租户共享集群、以容量保证为核心”的调度器，其设计目标明确包含“允许组织共享集群、为每个组织提供容量保证、支持队列内 FIFO 与队列间容量分配”等要点（Hadoop 官方文档，CapacityScheduler，2024 版）。这其实已经点明了调优的本质：容量保证是一种契约——你承诺给业务 A 多少资源，业务 A 就据此规划作业规模；如果契约长期不被兑现，业务方就会用“超量申请、长时间占位”来对冲不确定性，反过来加剧争抢。

本文评述：把“队列契约”作为主线，并非造概念，而是把运维经验里那些模糊的“应该够用”“大概能跑”转成可度量、可审计的条款。契约一旦写清楚，参数就有了标定依据，排队和争抢也就有了归责路径。

笔者认为，YARN 调优的成熟度可以分三级：一级是“救火式调参”，出了问题改参数；二级是“指标驱动”，有队列利用率、排队时长、抢占次数等指标；三级是“契约驱动”，每个队列有明确的容量、优先级、抢占边界与 SLA，参数变更走评审与灰度。多数团队卡在一级到二级之间，缺的不是工具，而是把契约写下来的动作。

1.1 一个典型的“契约失效”场景

某数据平台把集群按业务线切成 A、B、C 三个队列，capacity 分别 50%、30%、20%。上线三个月后，A 队列白天利用率不足 15%，C 队列夜间排队超过 4 小时。运维查看配置发现 C 队列的 maximum-capacity 被设成了 20%，也就是说即使集群空闲，C 也用不到 A 的闲置资源。这是一个典型的“契约写死、弹性缺失”问题：容量保证写成了容量上限，保证变成了天花板。

这个案例说明，队列配置里最容易被误用的两个参数就是 capacity 与 maximum-capacity。前者是“保底”，后者是“封顶”，两者语义完全不同。把封顶设成保底，等于主动放弃了集群的弹性红利。

二、调度器机制复盘：Capacity 与 Fair 的差异到底在哪

选调度器是调优的前置决策。Hadoop 生态里主流是 Capacity Scheduler（下称 CS）与 Fair Scheduler（下称 FS），两者都支持多队列、层级队列、资源抢占，但设计哲学不同。CS 强调“容量保证 + 队列内 FIFO 为主”，FS 强调“公平份额 + 动态调整”。

CS 的层级队列通过“父子队列”表达组织架构，父队列的 capacity 是子队列之和的上界，子队列可以配置自己的 capacity 与 maximum-capacity。FS 的层级队列则通过权重（weight）表达相对份额，权重越大分到的空闲资源越多。两者都支持 yarn.scheduler.capacity.root.<queue>.state 之类的队列启停控制，但 CS 在容量语义上更“硬”，FS 在弹性上更“软”。

本文评述：选型不应只看“哪个更先进”，而要看业务对“可预测性”与“弹性”的偏好。批处理为主的离线集群，CS 的容量保证更契合契约思维；交互式与批混合、负载波动大的场景，FS 的公平份额更省心。很多团队同时跑两套调度器，反而增加了运维复杂度，得不偿失。

2.1 资源模型：内存只是冰山一角

YARN 的资源模型早期以内存为主，后来引入 vCore、GPU、FPGA 等扩展资源。NodeManager 上报的资源由 yarn.nodemanager.resource.memory-mb 与 yarn.nodemanager.resource.cpu-vcores 决定，容器申请则受 yarn.scheduler.minimum-allocation-mb 与 yarn.scheduler.maximum-allocation-mb 约束。一个常见误区是把 vCore 设成物理核数，忽略了超线程与 IO 密集型作业的差异，导致 CPU 争抢但指标看不出来。

更隐蔽的是“资源碎片”：容器申请的内存不是最小分配单位的整数倍时，会被向上取整，长期运行后产生大量无法利用的碎片。把 minimum-allocation-mb 设得过大，碎片率上升；设得过小，调度器心跳与分配开销上升。这个权衡需要结合集群规模实测。

三、队列契约的设计：分层、容量、优先级与抢占边界

契约设计是全文的主线。一份可执行的队列契约至少包含五项条款：容量承诺、弹性上限、优先级、抢占边界、SLA 指标。下面逐项展开。

3.1 分层：按组织还是按负载

队列分层有两种常见思路：按组织（部门/业务线）分层，或按负载类型（ETL、报表、机器学习、交互查询）分层。按组织分层便于成本核算与权限隔离，但同一组织内负载差异大，容易在队列内部形成新的争抢；按负载分层便于资源形态匹配（比如 GPU 队列单独切分），但成本归属需要额外打标。

笔者的建议是“两层混合”：第一层按负载类型切（批处理、交互、ML、流），第二层在批处理下按业务线切。这样既保证资源形态匹配，又保留成本归属。层级不宜超过三层，否则容量计算与排障成本陡增。

3.2 容量承诺与弹性上限

CS 中 capacity 是保底份额，maximum-capacity 是封顶。契约里应明确：保底份额在集群资源紧张时是否被完全兑现、封顶是否允许突破。实践中，保底份额之和通常设为 100%，封顶可以设为 100% 甚至更高（表示可借用全部空闲资源），但要注意“借出去容易、收回来难”——一旦某队列长期占用超额资源，回收会触发抢占，影响作业稳定性。

一个可操作的规则：保底之和 = 100%，封顶按队列重要性分档。核心队列封顶 100%（可吃满空闲），一般队列封顶 60%~80%，实验队列封顶 30% 并配合低优先级。这样既保留弹性，又限制“噪声邻居”的扩张。

3.3 优先级与抢占边界

YARN 支持作业优先级（job priority）与容器优先级（container priority），CS 还支持队列内的优先级排序。抢占（preemption）是契约的“执法手段”：当高优先级队列的资源需求无法被满足时，调度器可以回收低优先级队列的容器。CS 的抢占由 yarn.scheduler.capacity.preemption.enabled 控制，配合 monitoring-interval 与 max_allowable_preemption 等参数。

抢占不是免费的：被抢占的容器需要重跑，浪费算力；频繁抢占会让业务方对集群失去信任。因此契约里应写明“抢占边界”——哪些队列可被抢占、抢占的宽限期多长、被抢占作业是否有重试补偿。笔者的经验是给被抢占队列设置 5~15 分钟的宽限期，并优先抢占“运行时间短、checkpoint 频繁”的作业，减少重算损失。

四、关键参数标定：一份可直接对照的配置清单

参数标定要围绕契约展开，而不是“看到参数就调”。下面按“集群级—队列级—作业级”三层给出清单，并说明每项的标定依据。

4.1 集群级参数

4.2 队列级参数（以 CS 为例）

CS 的队列配置以 yarn.scheduler.capacity.root.<queue>.* 为前缀。核心项包括 capacity、maximum-capacity、state、acl_submit_applications、maximum-am-resource-percent、user-limit-factor 等。其中 maximum-am-resource-percent 控制 ApplicationMaster 可占用的资源比例，设得过小会导致作业提交排队，设得过大则 AM 挤占计算资源。

user-limit-factor 是另一个易被忽视的参数：它限制单个用户可使用的队列容量倍数。默认 1 表示单用户最多用满队列容量，设成 2 则允许单用户在队列空闲时用到两倍容量。多用户共享队列时，这个参数直接决定“一个人能否吃满整个队列”。

本文评述：参数清单的价值不在于“照抄”，而在于每项都有标定依据。没有依据的参数调整，本质上是把集群当实验场。建议把每项参数的“当前值、标定依据、变更记录”写进配置管理，形成可追溯的契约附件。

4.3 作业级参数

作业侧的调优同样影响排队：MapReduce 的 mapreduce.map.memory.mb、mapreduce.reduce.memory.mb 与 JVM 堆参数不匹配，会导致容器被 kill 或资源浪费；Spark on YARN 的 spark.executor.memory、spark.executor.cores 与 spark.yarn.executor.memoryOverhead 的配比，直接决定 executor 能否稳定申请到资源。

一个常见坑是 executor 内存申请值略大于队列剩余资源，导致作业长期 pending。解决办法是让 executor 内存对齐 minimum-allocation-mb 的整数倍，并在提交前用集群剩余资源做预检。

五、任务排队诊断：从现象到根因的排查路径

排队是契约失效最直观的信号。诊断排队要区分“真排队”与“假排队”：真排队是集群资源确实不足，假排队是资源够但分配不出去（比如队列封顶、AM 限额、标签约束、调度器心跳异常）。

5.1 诊断清单

1. 看队列利用率：队列已用资源 / 队列容量。若长期接近 100% 且 pending 容器多，是真不足。
2. 看集群空闲资源：若集群有空闲但目标队列 pending，检查 maximum-capacity 与标签约束。
3. 看 AM 限额：pending 的是 AM 容器还是普通容器，前者查 maximum-am-resource-percent。
4. 看用户限额：单用户是否触达 user-limit-factor，导致同队列其他用户也排队。
5. 看资源碎片：空闲内存不足以放下一个最小容器，属于碎片型排队。
6. 看调度器日志：RM 日志中的 assign 与 preempt 记录，能定位分配失败原因。

YARN 的 Web UI 与 RM REST API 提供了队列指标，包括 availableResources、pendingContainers、allocatedContainers 等。工程上建议把这些指标接入监控（如 Prometheus + Hadoop 指标导出），设置“排队时长 P95”告警，而不是只看瞬时队列长度。

5.2 一个排查实例（模拟数据）

以下为模拟数据，用于说明排查逻辑，非真实集群测量：某集群 100 节点，每节点 64GB/16vCore，总资源约 6400GB/1600vCore。队列 C 配置 capacity=20%、maximum-capacity=20%，夜间提交 200 个 Spark 作业，每个 executor 8GB。按 20% 封顶计算，C 最多用 1280GB，约 160 个 executor，200 个作业若每个需 4 个 executor，则需 800 个 executor，排队不可避免。把 maximum-capacity 调到 60% 后，可用资源升至 3840GB，排队显著缓解。这个模拟说明：很多排队问题不是调度器不行，而是封顶写死了弹性。

六、资源争抢治理：抢占、隔离与配额的三层防线

争抢的本质是“多个队列同时想要超过保底份额的资源”。治理争抢不能只靠抢占，要建三层防线：配额（事前）、隔离（事中）、抢占（事后）。

6.1 第一层：配额与准入

配额是契约的数字化表达。除了 capacity/maximum-capacity，还可以用节点标签（Node Label）做物理隔离：把 GPU 节点打上 gpu 标签，只允许 ML 队列访问，避免批处理作业挤占 GPU 节点。标签配置需要 yarn.node-labels.enabled=true 并在队列上配置 accessible-node-labels。

准入控制还包括提交侧的限流：对低优先级队列设置最大并发作业数，避免“海量小作业”把调度器打满。这一点在交互式查询场景尤其重要。

6.2 第二层：隔离与资源形态匹配

隔离不仅是队列隔离，还包括资源形态隔离。CPU 密集型与 IO 密集型作业混跑会互相拖累，内存密集型作业与 GPU 作业混跑会导致节点资源利用率失真。工程上可以通过节点标签 + 队列绑定实现“同类同池”，再用 CS 的容量保证池内公平。

容器化（Docker on YARN）进一步强化了隔离：yarn.nodemanager.container-executor.class 切换为 DockerContainerExecutor 后，可以用 cgroup 限制 CPU 与内存，减少“邻居噪声”。但容器化也带来镜像分发与启动开销，需要权衡。

6.3 第三层：抢占与回收

抢占是最后手段。CS 的抢占策略会计算“被抢占队列超出其保底份额的部分”，按容器优先级从低到高回收。配置时要关注 yarn.scheduler.capacity.preemption.monitoring-interval（监控间隔）与 yarn.scheduler.capacity.preemption.max_allowable_preemption（单次最大抢占比例）。间隔太短会频繁抢占，太长则高优先级作业等不及。

FS 的抢占基于最小份额（minShare）与超时，配置项包括 yarn.scheduler.fair.preemption、preemptionTimeout 等。无论哪种调度器，抢占都应配合“作业可重试”的设计，否则回收即失败。

笔者认为，抢占治理的关键不是“抢得准”，而是“少抢”。把配额与隔离做好，抢占次数自然下降。把抢占次数作为运维 KPI 之一，能反向推动契约设计的合理性。

七、工程落地：灰度、回滚与持续校准的操作步骤

调度配置变更的风险不亚于一次线上发布。建议按以下步骤落地，避免“改一个参数、崩一片作业”。

7.1 操作步骤

1. 基线采集：变更前 7 天采集队列利用率、排队时长 P95、抢占次数、作业失败率，作为对照基线。
2. 配置评审：每项变更写明依据、预期影响、回滚方案，评审通过后进入灰度。
3. 灰度队列：先在非核心队列或小比例节点上变更，观察 24~48 小时。
4. 滚动生效：CS 支持 refreshQueues 动态刷新，无需重启 RM；但部分参数需重启，需提前规划窗口。
5. 指标对比：对比变更前后基线，重点看排队时长与抢占次数是否改善、失败率是否上升。
6. 回滚预案：保留旧配置文件，异常时一键回滚并记录事件。
7. 契约归档：把最终配置与依据写入契约文档，季度复审。

7.2 监控指标建议

关于指标采集，Hadoop 官方提供了 RM REST API 与指标文档，社区也有 Prometheus 的 Hadoop 指标导出方案。工程上建议把“排队时长”作为一等公民指标，而不是只看 CPU/内存利用率——利用率高不一定体验差，排队时长才是业务感知的直接来源。

八、前沿与预判：弹性、容器化、异构算力与 Gang 调度

YARN 不是静止的。近几年调度领域的研究与工程实践有几个明显方向，值得在契约设计时提前考虑。

8.1 弹性与混合部署

把 YARN 与 Kubernetes 混合部署、按需伸缩节点，是降低闲置成本的常见做法。学术上，DRF（Dominant Resource Fairness）及其后续工作为多维资源公平分配提供了理论基础（Ghodsi 等，NSDI 2011）。工程上，弹性伸缩的难点不在扩容，而在缩容时的作业迁移与数据本地性。笔者认为，弹性能力必须写进契约：哪些队列允许跨云/跨池溢出、溢出的资源上限是多少、回收时的宽限期多长。没有这些条款，弹性会变成“抖动”。

8.2 容器化与安全隔离

Docker on YARN 让资源隔离更细，但也带来镜像管理、网络与存储挂载的复杂度。近年的工程实践倾向于“YARN 管批、K8s 管服务”的分工，而不是把所有负载都塞进 YARN。这个分工对契约设计的影响是：YARN 队列的 SLA 只需覆盖批处理与部分 ML 训练，交互式服务交给 K8s，避免两类负载在同一调度器里互相干扰。

8.3 异构算力与 GPU 共享

GPU 资源的调度是当前热点。YARN 通过 yarn.resource-types 支持自定义资源，配合节点标签可以把 GPU 队列独立出来。但 GPU 共享（如 MIG、时间片共享）在 YARN 上的支持仍不如 K8s 生态成熟。笔者的判断是：短期用“整卡分配 + 标签隔离”保证稳定性，中期关注 GPU 共享插件的成熟度，长期看异构资源统一调度框架的演进。

8.4 Gang 调度与批作业协同

Spark、MPI 类作业需要“全有或全无”的 Gang 调度，避免部分 executor 起来后长期等待。YARN 原生不提供严格 Gang 语义，社区有通过预留 + 超时释放的近似方案。近年的研究关注“队列级 Gang 预留”与“作业感知调度”，目标是在保证吞吐的同时减少死锁。笔者认为，Gang 需求应写进契约的“作业形态”条款：哪些队列支持 Gang、预留资源的上限与超时，避免预留资源变成新的闲置。

8.5 学习资源与拓展链接

拓展阅读建议：Apache Hadoop 官方 Capacity Scheduler 与 Fair Scheduler 文档（hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/）；YARN 资源模型与调度器配置参考官方 “Hadoop: YARN” 文档；社区实践可参考 Cloudera 与 Apache 邮件列表中的调度器调优讨论。视频方面，可在 YouTube 搜索 “YARN Capacity Scheduler tuning” 与 “Hadoop YARN Fair Scheduler” 的会议分享，配合官方文档对照学习。

九、结语：把调度当成产品来运营

回到主线：YARN 调优的终点不是一组“最优参数”，而是一份被持续履约的队列契约。参数会随负载变化而过时，契约的评审与校准机制才是长期有效的。把队列当产品运营，意味着有明确的用户、有 SLA、有变更流程、有复盘。做到这一点，排队和争抢就不再是“玄学问题”，而是可以被度量、被归因、被解决的工程问题。

最后提醒一句：任何调度变更都要有回滚方案。集群是生产系统，不是实验室。契约可以迭代，但业务不能停摆。

主要参考文献