如果你管过一台几十个节点、同时跑着几十个作业的 Hadoop 集群你一定对 YARN 调度器的脾气有深刻体会大作业占住所有容器小作业在 ACCEPTED 状态排队半天某个队列的作业一飚起来把别人家的资源吃得干干净净你打开 ResourceManager 的 Web UI看着一排黄黄绿绿的队列百分比根本不知道是哪个参数让作业卡住。这篇文章想聊的就是 YARN 调度器算法背后的那套逻辑FIFO、容量调度器、公平调度器各自是怎么算的DRF 是怎么把 CPU 和内存这两种没法直接比较的资源摆到同一个天平上的以及作业从提交到容器启动的完整链路里调度器到底在哪些环节做了决策。可能你平时不需要天天改调度器但把算法框架理解了排查“任务不跑、队列饿死、资源被抢”这类问题时你会一下子知道该去看哪里。1. 为什么需要一个专门的“调度器”问题域与核心角色1.1 资源不是“抢”出来的是“算”出来的先想一个极端情况没有调度器会怎样。两个作业同时启动各自认为自己应该占满整个集群任务往每个 NodeManager 上发容器一到就被对方挤掉两边都在反复失败重试最后谁也跑不完。这就是共享资源集群最原始的冲突每个应用都只关心自己没人关心全局。调度器解决的本质上是一个多目标优化问题公平性多个用户、多个队列之间每个人大概能拿到和其权重匹配的资源。利用率空闲资源要能被临时借用不能因为“这是别人的队列”就空转。SLA/优先级某些生产队列必须有保障某些临时队列只能在别人不用的时候捡漏。本地性尽量把任务分到数据所在的节点或机架减少网络IO。这些目标互相打架。要保障利用率就得允许队列互相借用要保障 SLA 就得在关键时刻从别的队列“抢”资源回来也就是抢占。YARN 的三种原生调度器其实就是对这几个目标做了不同的优先级排序。1.2 调度器在 YARN 架构里的位置先复习一下 YARN 里几个角色后面聊算法都要用到ResourceManagerRM集群的中央大脑调度器就住在 RM 里它是一个可插拔的ResourceScheduler实现。NodeManagerNM每个节点上的代理管理本节点的资源通过心跳把节点状态汇报给 RM。ApplicationMasterAM每个作业的“项目经理”负责申请容器、分配任务、监控进度。YARN 调度器的直接客户其实是 AM不是用户代码。Container资源分配的最小单位本质是“多少内存 多少 vcore”的一个组合。调度器干的事情可以压缩成一句话接收 AM 发来的资源请求在某个时刻把某个节点上的一部分资源分配给某个应用的某个容器并保证整体不违反队列容量和公平性约束。这个“某个时刻”很关键。调度不是集中式地把所有待分配任务排成一个大队列慢慢算而是由 NodeManager 的心跳驱动RM 每次收到节点心跳就看看哪些应用在这个节点上能放下请求然后决定要不要分配。后面讲容量调度器的算法时你会发现它的主循环就是处理 NodeUpdate 事件。2. 三种原生调度器的算法骨架FIFO、容量型与公平型2.1 FIFO只解决“谁先来”解决不了“谁该让步”FIFO 是 YARN 里最早也最简单的调度器逻辑和它的名字一样一个全局队列按作业提交时间排序先提交先跑。作业来了就排在队尾前面的作业全部完成后才开始下一个。它的算法本质是单队列、无抢占、无权重。好处是零配置、行为可预测、几乎没有性能开销坏处是被一句老话概括了队头阻塞。一个跑 10 小时的离线大作业排在队首后面几十个小作业全部干等哪怕集群资源明明够跑好几个小作业也只能眼睁睁看着。所以现在几乎没人把 FIFO 用在生产环境顶多单用户学习实验时用一用。它最大的价值反而是作为参照系你看到其他调度器的复杂度就能理解它们到底在解决 FIFO 留下的什么坑。2.2 容量调度器用百分比划分势力范围Capacity Scheduler 的思路是“分蛋糕”把集群资源按百分比切成多个队列可以一级一级往下切形成树结构。每个队列有一个保证容量capacity还有一个可以设定的最大容量maximum-capacity。它的算法核心是只要有队列没用到自己的保证容量其他队列可以临时借用一旦被借用的队列有需求资源要归还。归还的强制手段就是抢占。在 Apache Hadoop 3.x 里Capacity Scheduler 是默认调度器也是我见过的大多数生产集群实际在用的那一个。它天生适合多部门、多业务共用一个集群的场景每个部门一个队列写死“离线分析占 50%、实时任务占 30%、临时查询占 20%”互不干扰。2.3 公平调度器一切向“份额”看齐Fair Scheduler 的思路不是划百分比而是算“每个人应得的份额”。默认情况下所有活跃的作业平分工集群资源两个作业就是各 50%三个就是各 33%如果某个作业很早提交、占了 70%新作业一进来老的就要吐出来让它俩重回 50/50。当然实际不会裸奔它支持给队列配置weight权重、minResources最少资源和maxResources最多资源也支持抢占。所以公平调度器的算法难点就变成了份额怎么算、什么时候可以夺回资源、夺回时先杀哪个容器。CDH 历史上把 Fair Scheduler 作为默认和 Capacity Scheduler 形成了两大流派现在新出的集群里 Capacity 更多见但 Fair 在需要“所有作业平等竞争”的场景里仍然顺手。2.4 一张表说清三者的区别维度FIFOCapacity SchedulerFair Scheduler队列结构单队列层级树队列层级队列可嵌套分配依据提交时间各队列保证容量百分比队列/作业的公平份额与权重资源隔离无队列容量隔离可临时借用按份额动态调整抢占不支持支持需显式开启监控策略支持需显式开启典型场景单用户开发集群多租户、有SLA的离线仓库作业类型混杂、强调全局公平配置复杂度低中高中高这里有个容易混淆的点Capacity 和 Fair 的差别不在“有没有队列”而在“资源怎么分”。Capacity 是绝对比例写进去就要长期遵守Fair 是动态目标随着活跃作业数量变化不断重算。理解这一点后面看它们的算法代码时就不会绕晕。3. 多资源公平的核心算法最大最小公平与 DRF3.1 最大最小公平从一盆水分给一堆花说起先讲一个很朴素的公平概念假设有一池子水要分给几盆土质不同、缺水程度不同的花。最大最小公平的做法是把所有花按需求排好大家先均匀加水直到哪一盆先浇满就把它移出队伍剩下的水继续在其余花之间均匀分配。反复进行直到水用完或全部浇满。这个“水盆”算法用一句话概括就是让分到最少的一方尽可能多拿不让任何一方被饿死。YARN 里的份额计算、抢占触发条件本质上都是这个思想的变体。但现实有个麻烦——YARN 里的“水”不是一种是两种内存和 CPU vcore。如果只按内存算公平一个 CPU 密集型的作业会说“我内存需求小凭啥只能拿一样的份额”3.2 DRF与主导份额一个两步计算的例子DRFDominant Resource Fairness主导资源公平就是来解决多资源公平问题的。它的核心定义只有一句话一个应用在某个资源维度上占用集群总量的比例叫这个维度上的份额所有维度份额里最大的那个叫主导份额。调度时永远给当前主导份额最小的应用分配资源。听起来抽象直接看例子。假设集群总共 10 个 vcore、10GB 内存两个应用应用 A每个容器要 2 vcore 1GB属于 CPU 型。应用 B每个容器要 1 vcore 2GB属于内存型。按主导份额分配的过程如下记 A 用 (CPU, 内存) 表示初始都是 (0,0)A 拿一个容器变成 (2,1)主导份额 max(2/10, 1/10)0.2。B 的主导份额还是 0拿一个容器变成 (1,2)主导份额挂到 0.2。两者都是 0.2随便选一个比如 A 再拿变 (4,2)主导份额 0.4B 还是 0.2。B 主导份额小B 再拿变 (2,4)主导份额 0.4。交替进行直到 A 拿满 3 个容器 (6,3)B 拿满 3 个容器 (3,6)。最终两者主导份额都是 0.6剩余 1 vcore 1GB 不够任何一方再开一个容器只能空着。这个结果就是“两个应用在各自最缺的资源维度上达到了平等”而纯内存公平计算根本做不到这一点——按内存看 A 只用了 30%、B 用了 60%会错误地把资源继续倾向 A最后 CPU 被 A 吃光B 饿死。轮次判给谁A 已用(CPU,内存)A 主导份额B 已用(CPU,内存)B 主导份额1A(2,1)0.2(0,0)02B(2,1)0.2(1,2)0.23A(4,2)0.4(1,2)0.24B(4,2)0.4(2,4)0.45A(6,3)0.6(2,4)0.46B(6,3)0.6(3,6)0.63.3 YARN里的DRF开关与资源计算器YARN 不是默认就按 DRF 跑的。Capacity Scheduler 里有两个资源计算器DefaultResourceCalculator只认内存忽略 vcore。早期 Hadoop 的默认值简单但有明显缺陷。DominantResourceCalculator内存和 vcore 都参与计算也就是 DRF。生产集群如果 CPU 密集型作业多我建议别用默认显式在capacity-scheduler.xml里配置property nameyarn.scheduler.capacity.resource-calculator/name valueorg.apache.hadoop.yarn.util.resource.DominantResourceCalculator/value /propertyFair Scheduler 则直接在队列上指定策略fair是经典的内存公平drf是多资源公平。队列里schedulingPolicy填drf就能打开。要注意的是DRF 不是银弹它解决的是“多维资源如何公平比较”的问题但队列容量、用户限制、抢占门限这些约束仍然要靠调度器其他部分配合。4. 容量调度器是怎么“算”的心跳驱动、队列选择与本地性放宽4.1 一次心跳引发的资源再分配Capacity Scheduler 的分配动作不是定时跑一遍全局规划而是被 NodeManager 的心跳牵着走。每个节点心跳到达 RM 后调度器会进入 NodeUpdate 流程大概以下几步拿到该节点空闲资源空闲内存、空闲 vcore。从根队列开始深度优先地扫描所有队列找出“有 pending 请求、未达到最大容量、父队列也没超容量”的叶子队列。在每个符合条件的叶子队列里按该队列配置的作业排序策略挑一个应用。用应用当前的资源请求去匹配节点资源请求大小不能超过节点空闲资源也不能超过单容器最大分配。匹配成功就生成一个 Container交给 AM。这个流程的复杂点不在“扫描”而在“队列怎么选、作业怎么排序、本地性怎么放宽”这三件事上每个都是一套独立算法。4.2 队列内部怎么挑作业有序策略与用户限制一个叶子队列里往往排着几十个作业内部用ordering-policy决定谁优先。历史上默认是 FIFO新版本提供了多种fifo先来先得、fair队列内再按份额平分、drf队列内按主导资源公平还有按优先级、按容量等组合方式。我见过不少生产集群把叶子队列的ordering-policy配成fair避免同一个部门内部总是大作业插队。光有作业排序还不够还得防“一个用户把整个队列吃光”。Capacity Scheduler 有用户限制机制每个队列里单个用户最多使用的资源由user-limit-factor乘以队列容量决定。比如队列容量是 60%user-limit-factor默认是 1那么单个用户最多占用 60%如果两个活跃用户瓜分每个还会进一步收缩。这个限制是为了保证“队列内部也能对多个用户公平”很多刚上手的人只配了队列容量忘了看 user 维度结果一个数据团队的用户把整个部门的队列占满其他团队投诉都找不到原因。4.3 本地性延迟调度宁可等一拍也别跨机架MapReduce 这类作业的数据放在 HDFS 上任务放到数据所在节点跑就是“节点本地”性能最好。但调度器不可能期望每个请求立刻就有节点本地可放如果为了本地性死等节点空闲浪费如果立刻给任意节点又会有大量网络传输。YARN 采用的是延迟调度Delay Scheduling一个任务的请求首先只能匹配节点本地等错过一定次数的心跳调度窗口后允许放宽到机架本地再往后才允许放到任意节点。这样既给了短作业“等等就能本地化”的机会又不会让长尾任务无限等下去。这个参数在 Capacity Scheduler 里对应yarn.scheduler.capacity.node-locality-delay含义大概是可以容忍错过多少个心跳默认值在不同版本里不一样生产上要看实际文档确认。公平调度器也有类似的yarn.scheduler.fair.locality.delay.node和yarn.scheduler.fair.locality.delay.rack。还有一点容易被忽视当一个应用已经有很多任务分散在各个节点后继续等本地性意义不大。YARN 会动态计算“本地性收益下降”的临界点所以延迟调度只在应用启动早期作用明显。你如果监视过 Spark/Flink 在 YARN 上的运行日志会发现前几批任务分配慢后面越来越快跟这个机制直接相关。4.4 一份可以抄的容量调度配置假设集群要分两个一级队列batch离线生产和 adhoc临时分析各占 60% 和 40%batch 内按 fair 策略选作业!-- capacity-scheduler.xml -- configuration property nameyarn.scheduler.capacity.root.queues/name valuebatch,adhoc/value /property property nameyarn.scheduler.capacity.root.batch.capacity/name value60/value /property property nameyarn.scheduler.capacity.root.batch.maximum-capacity/name value80/value /property property nameyarn.scheduler.capacity.root.batch.ordering-policy/name valuefair/value /property property nameyarn.scheduler.capacity.root.adhoc.capacity/name value40/value /property property nameyarn.scheduler.capacity.root.adhoc.maximum-capacity/name value60/value /property /configuration注意maximum-capacity是“上限”含义是即便有空闲资源这条队列最多也只能用到 80%。如果你希望队列之间可以充分借力就不要把上限设得太低如果业务上有硬隔离要求再把上限打到 100%、90% 这样去“封顶”。capacity之和最好等于 100不然未被分配的部分就真的闲置了大于 100 则 RM 启动校验会直接报错。5. 公平调度器的份额计算与抢占博弈5.1 公平份额是怎么从权重里长出来的Fair Scheduler 的分配单位是队列队列套队列形成层级。对每个队列调度器会算两个份额steadyFairShare稳态份额把所有队列包括暂时没有作业的空队列都算进去按权重和 min/max 资源算出来的长期均衡值。instantaneousFairShare瞬时份额只算当前活跃的队列资源在这些活跃队列之间按权重分。为什么分两个因为调度器需要区分“长期该这样”和“现在立刻该这样”。比如一个高权重队列暂时没作业它的份额就应当被其他队列借用一旦它提交作业调度器不会要求其他队列立刻归还而是逐步收敛回去这个收敛过程就是看瞬时份额和稳态份额之间的差距。权重计算很简单某队列的公平份额 集群可用资源 × 该队列权重 / 所有活跃队列权重之和。如果再加上minResources就先给每个队列填到最少资源再对剩余部分按权重分配。maxResources相当于硬顶超过之后即使权重再高也不能拿更多。5.2 当“公平”违约抢占线程的完整决策链公平调度器的抢占是一个独立线程定期跑的不是每一次分配时实时判断。它大致做这几件事定时检查每个队列的使用量与公平份额、最小资源之间的差距。只有“差距超过阈值且持续了一段时间”才动手避免震荡。决定抢占后选出那些“超出自身份额最多的队列”里的容器作为牺牲品。先发警告给一段时间让超额队列自己释放比如作业自己降并发、或者等容器自然结束过了等待期仍不释放才真正 kill 容器。关键时刻的配置是yarn.scheduler.fair.preemption.enabled。配套的还有触发前等待时间、集群总使用率阈值等参数不同 Hadoop 版本命名略有差异建议以官方 Configuration 文档为准。我的实践体会是抢占的参数必须成套调只开一个开关、其他全默认很容易出现“杀过来的容器刚算出结果前一刻被抢走”的惨案。5.3 抢占的代价与关闭时机这里要给两个泼冷水的观点。第一抢占不是免费的。被 kill 的容器里如果正在跑 Map 任务作业会重新执行浪费的是整个计算过程抢占频繁时集群的整体吞吐反而下降。第二并非所有集群都需要抢占。如果队列之间容量边界清晰、作业类型差异不大关掉抢占、靠队列容量的自然流动就够了。一个相对稳妥的开启策略是只对“有 SLA 的队列”开启抢占保证让它们低于 minResources 时能抢回来对一般队列主要用maximum-capacity和权重来控制避免全局抢占。我踩过的坑是某个流批一体的集群开了全局抢占结果每小时都在杀任务最后查日志发现全是 preemption kill而不是资源不够。6. 从作业提交到容器启动调度器在整条链路上的作用6.1 提交阶段客户端、HDFS暂存目录与RM的第一次接触用户执行一条hadoop jar xxx.jar MainClass之后发生的第一件事不是直接进调度器而是先准备“作业描述文件”。客户端会做三件事对输入数据计算分片split生成作业计划。把 jar 包、配置、分片信息上传到 HDFS 的暂存目录通常是/user/用户名/application_时间戳这种路径。通过 RPC 向 ResourceManager 提交一个ApplicationSubmissionContext里面包含了 jar 路径、AM 需要的资源大小、队列名、优先级等。RM 收到提交请求后会先把这条记录写入状态存储用于故障恢复再交给内部的 AppManager 创建应用对象。到这一步为止调度器还没参与它看到的只是一个“新应用等待启动”的事件。6.2 调度器第一次分配给ApplicationMaster找个窝每个 YARN 应用要跑起来第一步是先启动一个 ApplicationMaster。这个 AM 本身也需要一台节点、一份资源所以 RM 要向调度器申请一个“AM 容器”。这个申请和普通任务申请走的是同一个调度流程只不过优先级特殊、请求次数少。刚好这就是很多人定位问题卡住的点如果 AM 容器要求的资源超过yarn.scheduler.maximum-allocation-mb调度器永远找不到能放下的节点作业就一直停在 ACCEPTED。这种问题在日志里反而不容易看到具体原因因为 RM 端只显示“等待资源”。我排查过不少次最后都是把 AM 的资源要求降到单容器上限之内或者把上限调大。6.3 AM的循环心跳ResourceRequest与Allocation的往返AM 启动后会向 RM 的ApplicationMasterProtocol注册。它向调度器提交的不是“我要跑 100 个 Map”而是一批批ResourceRequest对象。每个请求包含三件关键信息资源量需要多少内存和 vcore。本地性偏好指定节点、指定机架还是任意节点。优先级先满足哪些任务。调度器把请求吃进去不停产出Allocation回应里面有被分配的Container列表。AM 拿到这些 Container 后再通过 NodeManager 启动具体任务。这个过程不是一次性的AM 通过周期心跳反复“申请 - 拿容器 - 启动任务 - 汇报进度”直到作业完成。6.4 调度器的决策点到底在哪里把整条链路摊开调度器的决策点其实就两个第一次决定 AM 容器放哪个节点这是“作业能不能启动”的闸门。之后无数次决定各种资源的容器分配给哪些作业的哪些任务这是“作业跑得快不快”的闸门。需要刷新认知的是YARN 调度器从来不会替 AM 决定“任务在容器里怎么执行”。任务调度Map 阶段、Reduce 阶段内部的任务编排是 MRAppMaster 自己干的YARN 调度器只负责“给资源”。很多新手把两者混在一起出了问题以为调度器算法有 bug其实调度器早就把容器发出去了是 AM 自己没用好。7. 生产环境里的选型、调参与踩坑实录7.1 选型原则先问你需要SLA还是需要和谐如果集群要承载多个业务线、每个业务线有明确的资源预算和响应时间要求选 Capacity Scheduler。它的百分比模型和用户限制天然适合“按部门/业务划分势力范围”。如果集群是一群临时分析作业、每个人谈好的共享池希望所有作业尽量平等地分资源选 Fair Scheduler再配合权重点出重要作业。FIFO 我基本只在单机实验环境用。还有一个真实情况是很多发行版和大数据中间件已经在yarn-site.xml里写好了默认调度器比如阿里云 EMR 默认就是 Capacity 系你要改之前先确认到底用的是哪个免得改了一套配置但没生效。7.2 三个我踩过的坑坑一队列容量加起来超过 100%。有一次同事手滑把两个队列都配成了 70%RM 启动直接拒绝集群怎么也起不来。这也是 Capacity Scheduler 的一个“好处”配置校验做得很严格提前暴露问题。所以上线前养成习惯用yarn scheduler相关命令或者直接看启动日志确认一下Queues的容量总和。坑二maximum-allocation-mb 太小导致所有作业的 AM 都卡在 ACCEPTED。这个我前面提过是生产环境最高频的“集群没坏作业就是不动”的原因。默认的单容器上限在不同发行版里不一样有 8GB、16GB、甚至 32GB如果你的作业 AM 要求 8GB而上限刚好也是 8GB看似相等其实可能因为一点点 overhead 就被拒。建议把最大分配值放宽到集群单节点内存的一半或更高避免这种无谓的边界问题。坑三用户限制害死人。某个部门二十个人共用一个队列队列容量 70%user-limit-factor 默认 1表面看没问题。但实际某个同事一次提交了 20 个作业因为“单个用户不能超过队列容量”这些作业加起来只能吃到 70%每个作业分到的资源非常有限全部慢悠悠地跑。最后把user-limit-factor调到 2、3 才让多作业用户能充分用资源。这种问题在 RM 队列页面上能看到“单用户已用资源明显高于/低于预期”的信号关键是要有意识去查用户维度。7.3 能救命的监控命令与日志线索最后列几个我排查调度问题时必定会用的命令都是 YARN 自带能力yarn application -list -appStates RUNNING,ACCEPTED yarn applicationattempt -list application_id yarn queue -status queue_name yarn logs -applicationId application_id yarn scheduler # 通过 RMActive 进程的管理命令具体以发行版为准yarn queue -status能直接看到队列的 usedCapacity、absoluteCapacity、numPendingApplications 这些指标用来确认“是队列满了还是调度器没分配”非常快。RM 的 Web UI默认 8088 端口/cluster/scheduler页面里每个队列的颜色块能直观反映容量占用看到某队列长期是深色、另一个队列几乎全灰基本可以断定是 maximum-capacity 限制了弹性共享。我自己在新集群上线前的调参顺序通常是这样的先把minimum-allocation和maximum-allocation设好让容器规格符合绝大多数作业的请求再配队列容量和 user-limit-factor先保证硬隔离能立起来最后才考虑抢占而且一定从小阈值开始放观察一天日志再决定要不要加大力度。调度器这东西没有一口吃成胖子的方案它更像一个动态的平衡器你给它多一点现场数据它就给你少一点玄学故障。写到这里刚好想起一个经验很多时候用户在群里喊“集群死了”其实不是节点挂掉更不是调度器算法出 bug而是某个队列的maximum-capacity设成了 100%另一个关键队列又设了很低的capacity两边凑不出弹性。看懂了调度器怎么算的之后这种“你以为的资源空闲”和“实际上的资源被锁死”的落差就会变成一眼能识破的配置问题。