YARN架构与调度优化：Hadoop资源管理实战指南-三亩地-编程学习日记

1. YARN架构解析：Hadoop资源管理的核心引擎

在Hadoop生态中，YARN（Yet Another Resource Negotiator）作为第二代资源管理框架，彻底改变了MapReduce v1中JobTracker既做资源管理又做任务调度的架构缺陷。这种解耦设计让Hadoop从单一的批处理系统蜕变为支持多种计算范式（如流处理、图计算、交互式查询）的数据平台。

YARN采用经典的主从架构，包含三个核心组件：

ResourceManager (RM)：全局资源仲裁者，由Scheduler和ApplicationsManager组成。Scheduler只负责资源分配（不关心应用状态），而ApplicationsManager负责接受提交、协调执行和容错。实际生产中我们通常配置ZKFC实现RM高可用，避免单点故障。

NodeManager (NM)：每个工作节点上的资源"管家"，负责启动/监控Container（资源隔离的基本单位），定期向RM汇报心跳（默认1秒间隔）。关键配置项包括：

<property> <name>yarn.nodemanager.resource.memory-mb</name> <value>8192</value> <!-- 该节点可分配总内存 --> </property> <property> <name>yarn.nodemanager.vmem-pmem-ratio</name> <value>2.1</value> <!-- 虚拟内存与物理内存比率 --> </property>

ApplicationMaster (AM)：每个应用独享的"指挥官"，向RM申请资源，与NM协作执行任务。例如Spark on YARN时，SparkSubmit会先启动一个AM进程。AM需要实现重试逻辑应对NM故障——我在实际运维中发现，AM最大重试次数（yarn.resourcemanager.am.max-attempts）设置为5是个平衡点。

提示：在容量调度器中，队列的minimum-user-limit-percent参数常被忽视。该值决定当队列资源紧张时，单个用户能获取的最低资源比例。设置过高会导致小作业饿死，过低则可能引发资源碎片。

2. 调度器内核机制：从基础策略到生产调优

2.1 三大调度器对比与选型指南

YARN内置的调度器直接决定集群资源利用率与作业响应速度：

FIFO Scheduler：
- 原理：严格按提交顺序排队，前一个作业用完资源才轮到下一个
- 痛点：大作业会阻塞小作业，实测在20节点集群中，一个耗时2小时的作业会导致后续50+小作业平均延迟45分钟
- 场景：仅适合测试环境或绝对独占集群
Capacity Scheduler（推荐生产使用）：
- 核心设计：划分逻辑队列（如etl、ad-hoc），每个队列保障最低容量（如30%），允许借用闲置资源
- 优势：避免单一用户/团队垄断资源，我们为财务部门设置独立队列后，月末报表作业完成时间从6小时降至2.5小时
- 关键配置：
```
<property> <name>yarn.scheduler.capacity.root.etl.capacity</name> <value>40</value>  </property> <property> <name>yarn.scheduler.capacity.root.etl.user-limit-factor</name> <value>2</value>  </property>
```
Fair Scheduler：
- 动态平衡：所有运行中的作业平分资源，新提交作业会立即获得公平份额
- 陷阱：默认配置下短作业可能被长作业反复抢占，需通过minResources参数设置最小资源保障
- 典型案例：某社交平台使用Fair调度器后，实时推荐作业的P99延迟从8秒降至1.3秒

2.2 调度算法深度优化策略

针对生产环境中常见的资源竞争问题，我们通过以下策略提升调度效率：

延迟调度（Delay Scheduling）：
- 问题：数据本地性（Data Locality）与公平性的矛盾。当请求本地资源时，默认等待10ms（yarn.scheduler.capacity.node-locality-delay）后降级为机架本地。
- 优化：对于HDFS副本数3的集群，将延迟提高到30ms可使本地化率从75%提升至92%，但需监控作业响应时间变化。

资源预留（Resource Reservation）：

机制：当当前资源不足时，AM可请求未来某个时间点的资源预留

命令示例：

# 请求2小时后开始的4个Container，每个2vcore+4GB ResourceRequest reservation = ResourceRequest.newInstance( Priority.newInstance(1), "*", Resources.createResource(4096, 2), 4, true, ReservationId.newInstance(123456, 1));

动态资源配置（Dynamic Resource Configuration）：
- 场景：白天处理交互式查询，夜间运行ETL批处理
- 操作：通过REST API动态调整队列容量
```
curl -X PUT -H "Content-Type: application/json" \ -d '{"etl.capacity":"60","ad-hoc.capacity":"20"}' \ http://rm-address/ws/v1/cluster/scheduler-conf
```

3. Container资源模型与隔离实战

3.1 资源分配精细控制

YARN将CPU和内存抽象为可分配资源，但早期版本仅支持内存隔离。从Hadoop 2.6开始支持CPU通过Cgroups隔离：

内存模型：
- 每个Container请求必须是增量单位（yarn.scheduler.minimum-allocation-mb）的整数倍
- 常见误区：忘记计入堆外内存（如Netty的Direct Buffer），导致物理内存超用触发NM强制kill

CPU模型：

采用虚拟核（vcore）概念，通常设置物理核:虚拟核=1:2

启用Cgroups需添加配置：

<property> <name>yarn.nodemanager.resource.percentage-physical-cpu-limit</name> <value>90</value> <!-- 保留10%CPU给系统进程 --> </property> <property> <name>yarn.nodemanager.linux-container-executor.cgroups.mount</name> <value>true</value> </property>

3.2 隔离机制选型与问题排查

内存隔离：
- 默认使用ProcessTree监控，但无法限制物理内存。替换为LinuxContainerExecutor后，我们遇到/dev/shm不足导致Spark作业失败的问题，通过调整NM配置解决：
```
<property> <name>yarn.nodemanager.linux-container-executor.mount-tmpfs</name> <value>false</value> </property>
```
CPU隔离：
- Cgroups的cpu.shares存在"突发占用"问题——某次Spark SQL查询导致同节点HBase RegionServer延迟飙升。最终采用CFS带宽控制：
```
echo 100000 > /sys/fs/cgroup/cpu/yarn/cpu.cfs_period_us echo 20000 > /sys/fs/cgroup/cpu/yarn/cpu.cfs_quota_us
```
磁盘隔离：
- 通过Disk Checker限制Container磁盘使用量，但需要定期清理NM本地目录：
```
yarn nodemanager -cleanup
```

4. 性能调优全景指南

4.1 关键参数矩阵

根据集群规模和工作负载类型，推荐以下配置模板：

场景	参数	小集群(<50节点)	大集群(>=50节点)
高吞吐批处理	yarn.scheduler.maximum-allocation-mb	16GB	32GB
低延迟交互查询	yarn.am.liveness-monitor.expiry-interval	60000ms	30000ms
混合负载	yarn.resourcemanager.scheduler.class	Capacity	Fair

4.2 监控与瓶颈定位

资源利用率监控：
- 通过RM的/metrics接口获取关键指标：
```
curl http://rm-address:8088/ws/v1/cluster/metrics | jq '.clusterMetrics'
```
- 重点关注allocatedMB与availableMB的比值，持续超过80%需考虑扩容
慢作业分析：
- 使用Timeline Server存储历史作业数据，结合Spark事件日志定位阶段耗时
- 典型瓶颈模式：
  - 调度延迟高 → 检查队列配置和AM请求策略
  - 本地化率低 → 优化Delay Scheduling参数
  - GC时间长 → 调整Container内存与JVM参数比例

4.3 高级优化技巧

AM资源预热：

// 在ApplicationMasterService启动时预注册Container amRMClient.addContainerRequest( new ContainerRequest(capability, nodes, racks, priority));

基于标签的调度：

给GPU节点打标签：

yarn rmadmin -addToClusterNodeLabels "GPU" yarn rmadmin -replaceLabelsOnNode "node1:1234=GPU"

Spark提交时指定标签：

spark-submit --conf spark.yarn.executor.nodeLabelExpression=GPU

弹性资源分配：

# 在PySpark中动态调整Executor数量 if stage_input_size > 100GB: sc._conf.set("spark.dynamicAllocation.maxExecutors", "100")

在金融行业某实时风控系统中，通过组合标签调度和动态资源分配，作业平均执行时间缩短了68%。关键点在于根据数据特征（如Kafka分区数）动态调整并行度，而非静态配置。

日记详情

YARN架构与调度优化：Hadoop资源管理实战指南