引言
在大数据平台上，最让运维团队头疼的不是任务失败，而是任务"活着但不干活"——资源明明有，任务却在队列里排队，一排就是几个小时。业务方催得急，运维看着监控干着急，日志里全是"等待资源分配"的提示。问题出在哪？十有八九，是YARN的队列资源分配和优先级调度策略没配好。YARN作为大数据集群的资源调度核心，它的调度策略直接决定了每一份算力被谁用、什么时候用、用多久。策略配得好，集群吞吐拉满、任务延迟可控；策略配得差，核心任务被低效任务拖死，整条数据链路瘫痪。天翼云大数据平台翼MR基于YARN构建了完整的资源调度体系，但工具再强，也需要懂策略的人来驾驭。本文将从YARN队列模型出发，深入拆解资源分配与优先级调度的核心机制，并给出一套经过实战验证的调优方案。
一、先诊断：你的任务为什么"卡"在队列里
在动手调优之前，必须先搞清楚任务延迟高的真实原因。根据大量生产环境的排查经验，YARN任务延迟高通常由以下四种情况导致：
第一，队列资源不足。 集群总资源是固定的，但如果某个队列被分配的资源过少，提交到该队列的任务就会长期排队等待。这是最常见、也最容易被忽视的原因——很多团队只关注集群总资源利用率，却从不看单个队列的资源占用情况。
第二，队列间资源争抢。 当多个队列共享集群资源时，如果没有合理的资源隔离机制，低优先级队列的任务可能因为抢占了高优先级队列的资源而导致核心任务被阻塞。反过来，高优先级队列如果独占了过多资源，又会导致其他队列的任务永远排不上。
第三，任务优先级设置不合理。 YARN支持任务级别的优先级，但很多团队要么全部设为默认值，要么随意设置，导致真正紧急的任务和日常报表任务混在一起排队，紧急任务得不到优先调度。
第四，资源碎片化严重。 当集群中同时运行大量小任务时，每个任务只需要少量资源，但这些零散的资源无法被大任务利用，形成"有资源但用不了"的碎片化困境。大任务因此被迫等待，延迟急剧上升。
这四个问题，前两个是"分资源"的问题，后两个是"排顺序"的问题。解决YARN任务延迟，必须同时从资源分配和优先级调度两个维度入手。
二、YARN队列模型：资源分配的基石
YARN的队列模型是资源分配的核心框架。理解队列，是理解一切调度策略的前提。
YARN支持层级队列结构，即队列可以嵌套。根队列下可以有多个子队列，子队列下还可以有孙队列，形成一棵树形结构。每个队列都可以独立配置资源配额、用户限制、调度策略。
资源配额的两种模式：绝对配额与弹性配额。 绝对配额是指队列被分配了固定比例的资源，无论是否使用，这部分资源都被预留给该队列。弹性配额则不同——队列可以使用超过其配额的资源，但前提是其他队列有闲置资源。弹性配额的优势在于提升集群整体利用率，但劣势是当所有队列都需要资源时，弹性队列可能被"挤出去"，导致任务延迟波动。
在天翼云大数据平台翼MR中，建议采用"核心队列用绝对配额、弹性队列用弹性配额"的混合策略。核心业务队列（如实时计算、核心报表）使用绝对配额，确保资源底线；非核心队列（如日志分析、历史数据回溯）使用弹性配额，在不影响核心业务的前提下充分利用闲置资源。
队列容量的配置原则。 每个队列的容量（Capacity）决定了它最多能使用多少集群资源。建议根据业务重要性分级设置：核心队列容量设为40%到50%，保证核心任务始终有充足资源；一般业务队列容量设为20%到30%；开发测试队列容量设为10%到15%，避免测试任务影响生产。所有队列容量之和不应超过100%，否则会出现资源超卖，导致调度器无法正常分配。
三、三种调度器：选对了事半功倍
YARN提供了三种内置调度器，每种调度器的资源分配逻辑完全不同，选错了调度器，再怎么调参数也没用。
第一种：FIFO调度器（先进先出）。 这是最简单的调度器，任务按提交顺序排队，先到先得。它的优点是实现简单、开销低，缺点是没有任何优先级概念——一个紧急任务和一个日常报表任务完全平等地排队。FIFO调度器只适合单用户、小规模集群，生产环境中几乎不应该使用。
第二种：容量调度器（Capacity Scheduler）。 这是生产环境中最常用的调度器。它为每个队列分配固定比例的资源，队列内部再按FIFO或公平策略调度任务。容量调度器的核心优势是资源隔离——每个队列有自己的资源池，互不干扰。即使某个队列提交了大量任务，也不会影响其他队列的资源分配。天翼云大数据平台翼MR默认采用容量调度器，并在此基础上做了大量增强优化。
第三种：公平调度器（Fair Scheduler）。 与容量调度器不同，公平调度器不为队列预设固定配额，而是动态调整。当某个队列任务较少时，其闲置资源会被自动分配给任务较多的队列，实现"按需分配"。公平调度器的优势是集群利用率更高，但劣势是资源分配不稳定——核心业务队列可能在高峰期被其他队列"借走"资源，导致核心任务延迟上升。
选择建议： 对于多租户、多业务线的生产集群，强烈推荐容量调度器，因为它的资源隔离特性是稳定性的底线保障。对于单业务线、资源利用率要求极高的场景，可以考虑公平调度器，但必须配合严格的队列优先级配置。
四、优先级调度：让紧急任务"插队"
资源分配解决了"每个人分多少"的问题，优先级调度解决的是"谁先用"的问题。
YARN支持两级优先级：队列优先级和任务优先级。
队列优先级决定了队列之间的资源分配顺序。高优先级队列会优先获得集群资源，低优先级队列只有在高优先级队列资源用不完时才能获得分配。在翼MR中，建议将实时计算队列设为最高优先级，核心报表队列设为次高优先级，开发测试队列设为最低优先级。
任务优先级决定了同一队列内任务的执行顺序。YARN允许为每个任务设置0到5的优先级，数值越大优先级越高。但这里有一个陷阱：如果一个队列内所有任务的优先级都相同，那么任务仍然按FIFO顺序执行，优先级设置形同虚设。正确的做法是：在核心队列中，为紧急任务设置高优先级（如4或5），为常规任务设置中优先级（如2或3），让调度器在队列内部也能区分轻重缓急。
抢占机制是优先级调度的"杀手锏"。 当高优先级任务提交时，如果集群资源不足，YARN可以抢占低优先级任务正在使用的资源，将其分配给高优先级任务。被抢占的任务不会失败，而是被放回队列等待资源释放后重新执行。这一机制确保了紧急任务能够"插队"，但也带来了一个风险：如果高优先级任务频繁提交，低优先级任务可能被反复抢占，永远无法完成——这就是所谓的"饥饿问题"。
解决饥饿问题的方案是：为每个队列设置最小资源保障（Minimum Resource Guarantee）。即使该队列当前没有任务运行，这部分资源也会被预留，不会被其他队列抢占。这样，低优先级队列在空闲时不会被完全剥夺资源，一旦有任务提交，就能立即获得最小保障资源，避免长期饥饿。
五、实战调优：五个立竿见影的策略
理论讲完，给出五个可以直接落地的调优策略。
策略一：核心队列资源绝对保障。 将实时计算和核心报表队列设为绝对配额，容量不低于40%，并开启最小资源保障，确保这些队列在任何情况下都有资源可用。
策略二：非核心队列使用弹性配额。 日志分析、历史数据回溯等队列使用弹性配额，容量设为20%到30%，让它们在不影响核心业务的前提下"捡漏"闲置资源。
策略三：启用队列内优先级调度。 不要让所有任务都用默认优先级。在核心队列中，为SLA要求高的任务设置优先级4或5，为常规任务设置优先级2或3，让队列内部也有明确的执行顺序。
策略四：限制单个队列的任务数。 当某个队列同时运行的任务过多时，新提交的任务会被无限期排队。建议为每个队列设置最大任务数上限，超出上限的任务进入等待状态，避免队列被"撑爆"。
策略五：开启资源预emption（抢占）但设上限。 允许高优先级任务抢占低优先级任务的资源，但设置抢占比例上限（如不超过集群总资源的20%），避免低优先级任务被过度挤压导致饥饿。
六、监控与持续优化：别等延迟了才发现问题
所有调度策略的前提，是你能在问题发生之前就感知到它。天翼云大数据平台翼MR提供了完善的YARN监控指标，建议重点关注三个核心指标：队列待处理任务数（反映排队压力）、队列资源使用率（反映资源分配是否合理）、任务平均等待时间（反映调度效率）。
当某个队列的待处理任务数持续高于阈值时，说明该队列资源不足，需要扩容或提升配额。当任务平均等待时间突然飙升时，说明可能发生了资源争抢或优先级配置不当，需要立即介入。
建议设置两级告警：第一级在队列待处理任务数达到50时触发，通知运维关注；第二级在达到100时触发，自动触发队列资源扩容或任务限流策略。
结语
YARN任务延迟高，表面上是"资源不够用"，本质上是"资源没分对、优先级没排好"。队列资源分配决定了每条业务线能拿到多少算力，优先级调度决定了紧急任务能不能插队。天翼云大数据平台翼MR在底层已经提供了容量调度器、队列优先级、任务抢占等完整能力，但最终能不能让任务跑得快，取决于你是否把队列配对了、优先级设准了、抢占机制用活了。资源调度这件事，不是"设完就忘"的一次性操作，而是需要持续监控、持续调优的动态过程。把这套策略吃透，你的大数据集群才能真正做到"忙而不乱、急而有序"。
