给数据团队分 YARN 配额时，一个常见算法是统计上个月平均使用率，再按比例切队列。A 部门平均用了 40%，就给 40% capacity；B 部门平均 20%，就给 20%。报表看起来有数据依据，到了每天凌晨，两个部门的关键任务一起跑，队列还是排满。

平均值描述长期资源消耗，不描述任务在 SLA 窗口内是否碰到一起。一个队列每天只忙两小时，平均使用率很低；这两小时如果正好承担日结、报表和下游出数，它需要的保证容量可能比全天平滑运行的队列更高。

CapacityScheduler 的 capacity 本来就不是一堵静态资源墙。它给队列保证一部分容量，空闲资源可以被其他队列借用，maximum-capacity 再限制弹性上界。配额设计的重点应该是关键时间窗口内的并发需求、可等待时间和资源回收速度，而不是把集群按月均比例永久切开。

YARN 页面显示队列还有容量，作业却长时间处于 ACCEPTED，或者 ApplicationMaster 已经启动、后续 Container 一直拿不到。遇到这种情况，只看“队列使用率 70%”往往不够。

调度器分配的不是一个抽象百分比，而是落到具体节点上的一组资源。任务要申请 8 GB 内存和 4 个 vCore，某个节点只剩 16 GB 内存但只有 2 个 vCore，这个节点对它仍然不可用。把所有节点的空闲内存相加，看起来还有很多容量，也不代表存在一个能容纳当前请求的节点。

还有一个更容易忽略的前提：CapacityScheduler 使用哪个 ResourceCalculator。Hadoop 3.3.0 默认的计算器只比较内存，切换到 DominantResourceCalculator 后，内存与 CPU 才以多维资源参与比较。两种模式下同一个“50% 队列”的含义并不完全相同。