两个团队抢资源天天吵架——YARN队列配置和多租户管理
本文目录
先说结论
YARN通过队列（Queue）实现多租户资源隔离。每个队列有资源配额（最小保障量和最大使用量），不同团队/应用的作业提交到不同队列，互不影响。YARN有两种调度器：Capacity Scheduler（容量调度器，Apache默认）和Fair Scheduler（公平调度器，CDH默认）。生产环境最常用的是Capacity Scheduler。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
YARN队列管理是大数据团队的日常痛点。在某知名出海硬件品牌，数据组和算法组共用一个EMR集群，算法组的训练任务经常把资源用完，数据组的ETL作业只能干等。两个团队的leader在群里吵了好几次。最后我设计了一套队列方案才解决。YARN的队列配置看起来简单，但要平衡公平性、效率和优先级，需要考虑很多细节。
两种调度器对比
| 维度 | Capacity Scheduler | Fair Scheduler |
|---|---|---|
| 默认使用 | Apache Hadoop默认 | CDH默认 |
| 资源分配 | 按队列配额预留 | 按权重公平分配 |
| 空闲资源 | 可以被其他队列弹性使用 | 自动均匀分配 |
| 抢占机制 | 支持（需配置） | 内置支持 |
| 配置复杂度 | 中等 | 较低 |
| 适用场景 | 多团队严格隔离 | 灵活共享 |
Capacity Scheduler队列配置实战
<!-- capacity-scheduler.xml 配置示例 -->
<!-- 根队列下分3个子队列 -->
<!-- ETL队列：占集群60%资源，最大可弹性到80% -->
yarn.scheduler.capacity.root.etl.capacity = 60
yarn.scheduler.capacity.root.etl.maximum-capacity = 80
yarn.scheduler.capacity.root.etl.user-limit-factor = 2
<!-- 算法队列：占集群30%资源，最大可弹性到50% -->
yarn.scheduler.capacity.root.algo.capacity = 30
yarn.scheduler.capacity.root.algo.maximum-capacity = 50
<!-- 临时查询队列：占集群10%资源，最大可弹性到30% -->
yarn.scheduler.capacity.root.adhoc.capacity = 10
yarn.scheduler.capacity.root.adhoc.maximum-capacity = 30
<!-- 三个队列的capacity之和必须等于100 -->
<!-- maximum-capacity允许弹性使用其他队列的空闲资源 -->
<!-- 当其他队列需要资源时，弹性使用的资源会被回收 -->capacity vs maximum-capacity的区别：capacity是'保底资源'——即使队列空着，这些资源也预留给它。maximum-capacity是'最大可用'——当其他队列空闲时可以弹性借用。比如ETL队列capacity=60、maximum=80，意味着至少有60%资源保障，最多可以用到80%（多出的20%是从空闲队列借的）。
队列提交作业
# 提交作业到指定队列
spark-submit \
--master yarn \
--queue etl \
--num-executors 20 \
my_etl_job.py
# Hive查询指定队列
SET mapreduce.job.queuename = adhoc;
SELECT * FROM my_table WHERE dt = '2024-01-15';
# 默认队列配置（如果不指定queue）
yarn.scheduler.capacity.root.default.capacity = 10
# 建议：不要让大量作业跑在default队列
# 每个团队/应用都应该有自己的队列资源抢占（Preemption）——解决资源借用后不归还的问题
弹性资源借用有一个问题：如果ETL队列借用了算法队列的空闲资源，当算法队列有新作业提交时，ETL队列不会主动释放借来的资源（Container正在运行中）。这时候就需要Preemption（抢占）：
<!-- 开启资源抢占 -->
yarn.resourcemanager.scheduler.monitor.enable = true
yarn.resourcemanager.scheduler.monitor.policies =
org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.
ProportionalCapacityPreemptionPolicy
<!-- 抢占等待时间：15秒后开始抢占 -->
yarn.resourcemanager.monitor.capacity.preemption.
monitoring_interval = 3000
yarn.resourcemanager.monitor.capacity.preemption.
max_wait_before_kill = 15000
<!-- 抢占的工作方式：
1. 算法队列提交新作业，但资源被ETL占着
2. RM等15秒看ETL会不会主动释放
3. 超时后RM标记ETL队列中最低优先级的Container
4. 被标记的Container被kill，资源归还给算法队列
5. ETL的作业会重试被kill的Task -->抢占的代价：被kill的Container正在运行的Task会失败，需要重试。如果是Spark作业，被kill的Executor上的数据需要重新计算。所以抢占是有代价的——要在'快速获得资源'和'浪费已计算的结果'之间取舍。我在出海硬件品牌把抢占等待时间设为30秒（比默认的15秒长），给借用方更多时间主动释放。
实战经验：我设计的队列方案
在某知名出海硬件品牌，EMR集群20个节点（320核1280GB），数据组+算法组+分析师三方共用。我设计的队列方案：
| 队列 | capacity | max-capacity | 使用方 | 作业类型 |
|---|---|---|---|---|
| etl | 60% | 80% | 数据组 | 日常ETL（100+作业） |
| algo | 25% | 50% | 算法组 | 模型训练 |
| adhoc | 10% | 30% | 分析师 | 临时查询 |
| default | 5% | 10% | 其他 | 测试、调试 |
核心设计原则：① ETL保障最大（60%），因为ETL有SLA要求（必须在每天早上8点前完成）；② 算法队列容量25%但弹性到50%，利用ETL的低峰期（白天ETL不跑时算法可以用更多资源）；③ adhoc队列容量小（10%）但弹性大（30%），白天分析师用的多但不需要持续大量资源；④ 开启Preemption，ETL高峰期能快速回收资源。
方案上线后两个团队再没有因为资源吵过架，因为各自有保底的队列资源，空闲时又能弹性使用。
面试高频追问
追问一：队列可以嵌套吗？
可以。Capacity Scheduler支持多级嵌套队列。比如root下有etl和algo两个队列，etl下面还可以再分etl_daily和etl_realtime两个子队列。子队列的capacity之和等于父队列的100%。嵌套队列适合大型组织——按部门分一级队列，部门内部按项目分二级队列。
追问二：Capacity Scheduler和Fair Scheduler哪个好？
没有绝对的好坏。Capacity Scheduler适合需要严格资源保障的场景（ETL有SLA），Fair Scheduler适合多个同等优先级的作业公平共享资源。大部分公司用Capacity Scheduler因为它的可控性更强。CDH/HDP默认用Fair Scheduler。在EMR上我用的是Capacity Scheduler。
追问三：YARN队列和Doris的Workload Group有什么关系？
思路完全一样——都是给不同用户/团队分配资源配额做隔离。区别是YARN队列管的是Spark/Hive等作业的CPU+内存，Doris Workload Group管的是SQL查询的CPU+内存。我在Doris面试系列里也讲过这个（第15篇），原理是相通的。
实战踩坑：队列配置改错导致ETL全部延迟
有一次我在调整队列配置时，把ETL队列的capacity从60%改成了6%（少打了一个0）。结果ETL队列只有6%的资源保障，100+个Spark作业全部排队等资源。等我发现时已经是凌晨4点，ETL延迟了2小时。
修复：紧急修改capacity-scheduler.xml，YARN支持热加载队列配置（yarn rmadmin -refreshQueues），不需要重启RM。30秒内配置生效，ETL作业开始恢复。
教训：① 队列配置修改要经过Code Review，不能一个人直接改；② 对关键队列设监控——ETL队列的Pending Containers超过阈值立刻告警；③ YARN支持热加载配置是个救命功能，不需要重启RM。
总结
YARN队列管理面试讲清楚三点：① 两种调度器的对比（Capacity按配额预留，Fair按权重均分）；② capacity vs maximum-capacity的区别（保底 vs 弹性上限）；③ Preemption抢占机制（资源回收的工作方式和代价）。能讲出为多个团队设计队列方案的经验和因为配置错误导致的事故处理，面试官会觉得你有团队级别的资源治理能力。
下一篇聊YARN的容错机制：作业跑到一半Task失败了怎么办？推测执行是什么？
你们YARN的队列是怎么配的？有没有因为资源抢得吵架？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长