大数据系列(六) YARN：集群资源调度大管家

YARN集群资源调度大管家大数据系列第 6 篇Spark 和 Flink 要跑起来得有人给它们分配资源。YARN 就是这个大管家。从一个抢资源的故事说起假设你们公司有 100 台机器组成的大数据集群同时有几个团队在用数据仓库团队每天晚上跑批处理作业把原始数据清洗成报表算法团队白天跑机器学习模型训练需要大量 GPU 资源实时计算团队7×24 小时跑 Flink 作业处理实时数据流临时查询团队分析师们时不时提交个 Ad-hoc 查询问题来了这 100 台机器怎么分如果没有统一的管理可能就是谁抢到算谁的数据仓库晚上一跑占了 80% 的资源实时计算直接卡死算法团队提交了个大作业把内存全吃光了其他作业全 OOM有人写了个死循环CPU 跑满整个集群瘫痪这时候就需要一个大管家来统筹资源分配——YARN 就是这个角色。YARN 是什么解决了什么问题YARNYet Another Resource Negotiator是 Hadoop 2.x 引入的集群资源管理系统。在 Hadoop 1.x 时代MapReduce 自己管资源、自己跑计算JobTracker 既是资源调度员又是作业监督员。结果集群规模大了超过 4000 台JobTracker 扛不住只能跑 MapReduceSpark、Storm 等其他框架没法用这套集群资源隔离做得差一个作业把资源吃光其他作业全挂YARN 的做法是把资源管理和作业执行彻底分开。┌─────────────────────────────────────────────────────────────────┐ │ YARN 的设计思想 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Hadoop 1.x紧耦合 │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ JobTracker │ │ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ │ │ 资源管理 │ │ 作业调度 │ │ │ │ │ │ 任务监控 │ │ 任务分配 │ │ │ │ │ └─────────────┘ └─────────────┘ │ │ │ │ 一个人干所有活累死 │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Hadoop 2.x YARN解耦 │ │ ┌─────────────────┐ ┌─────────────────────────────┐ │ │ │ ResourceManager │ │ ApplicationMaster │ │ │ │ 资源大管家 │ │ 作业小管家 │ │ │ │ │ │ │ │ │ │ • 管全局资源 │ │ • 向 RM 申请资源 │ │ │ │ • 分配 Container│ │ • 和 NM 一起跑 Task │ │ │ │ • 不 care 你跑啥│ │ • 监控 Task 状态 │ │ │ └─────────────────┘ │ • 失败了自己申请重试 │ │ │ └─────────────────────────────┘ │ │ │ │ 好处 │ │ • RM 只管资源不管业务逻辑职责清晰 │ │ • 不同框架MapReduce/Spark/Flink都有自己的 AM │ │ • 一套集群跑多种框架资源统一调度 │ │ │ └─────────────────────────────────────────────────────────────────┘YARN 的核心组件YARN 的架构就三种角色咱们一个个聊ResourceManagerRM资源大管家RM 是整个集群的一把手负责接收作业提交根据调度策略把资源分配给各个应用监控 NodeManager 的健康状态RM 内部有两个关键模块Scheduler调度器纯资源分配器只负责把资源给谁不跟踪应用的状态。它是可插拔的有三种实现后面细说。ApplicationsManager应用管理器负责接收作业、启动第一个 Container 来跑 ApplicationMaster以及 AM 挂了之后的重启。NodeManagerNM节点小管家每台工作机器上都有一个 NM负责管理这台机器的资源CPU、内存、磁盘启动和监控 Container资源容器定期向 RM 汇报“我还活着资源用了多少”ApplicationMasterAM作业小管家每个应用Job都有自己的 AM负责向 RM 申请资源“我需要 10 个 4G 内存的 Container”和 NM 协作在申请到的 Container 里启动 Task监控 Task 的执行失败了申请新资源重试不同框架有自己的 AM 实现MapReduce → MRAppMasterSpark → Spark Driver内部实现了 AM 接口Flink → JobManager在 YARN 模式下就是 AMContainer资源容器Container 是 YARN 的资源抽象封装了多少内存MB多少 CPU 核vCores运行在哪个 NodeManager 上你可以把 Container 理解成一个资源包RM 把这个包分配给 AMAM 在这个包里跑自己的 Task。作业提交流程一个 Spark 作业是怎么跑起来的┌─────────────────────────────────────────────────────────────────┐ │ YARN 上跑 Spark 作业的流程 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 你客户端 │ │ │ │ │ │ 1. 提交作业spark-submit --master yarn ... │ │ ▼ │ │ ResourceManager │ │ │ │ │ │ 2. RM 找个空闲的 NodeManager │ │ ▼ │ │ NodeManager X │ │ │ │ │ │ 3. 在这个 NM 上启动 ApplicationMaster │ │ │ Spark Driver 就是 AM │ │ ▼ │ │ ApplicationMasterSpark Driver │ │ │ │ │ │ 4. AM 向 RM 申请资源我需要 10 个 Executor │ │ ▼ │ │ ResourceManager │ │ │ │ │ │ 5. RM 根据调度策略分配 10 个 Container │ │ ▼ │ │ NodeManager A ──→ 启动 Container 1 ──→ 运行 Spark Executor │ │ NodeManager B ──→ 启动 Container 2 ──→ 运行 Spark Executor │ │ NodeManager C ──→ 启动 Container 3 ──→ 运行 Spark Executor │ │ ... │ │ NodeManager J ──→ 启动 Container 10 ──→ 运行 Spark Executor │ │ │ │ │ │ 6. Spark Driver 把 Task 分发给各个 Executor 执行 │ │ ▼ │ │ 作业运行中... │ │ │ │ │ │ 7. Executor 定期向 Driver 汇报进度 │ │ │ Driver 定期向 RM 汇报心跳 │ │ ▼ │ │ 作业完成Container 释放资源归还集群 │ │ │ └─────────────────────────────────────────────────────────────────┘关键点双层调度RM 把资源分配给 AMAM 再决定怎么用这些资源AM 是应用级别的每个作业有自己的 AM互不干扰Container 是临时资源作业完成后Container 被回收资源释放三种调度器资源怎么分才公平YARN 提供了三种调度器适用于不同的场景FIFO Scheduler先来后到最简单的调度器作业按提交顺序排队前一个跑完了才跑下一个。队列Job1 ──→ Job2 ──→ Job3 ──→ Job4 │ ▼ 资源███████████████████████████████████████████████ Job1 独占所有资源 特点 • 简单不用配置 • 大作业阻塞小作业 • 不适合多租户 • 生产环境基本不用问题很明显如果 Job1 是个跑 6 小时的大作业Job2、Job3、Job4 就得干等着。这在多团队共享的集群里显然不可接受。Capacity Scheduler按容量分配这是 CDHCloudera的默认调度器。思路是把集群资源划分成多个队列每个队列有固定的容量队列之间资源隔离。┌─────────────────────────────────────────────────────────────────┐ │ Capacity Scheduler容量调度器 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 队列结构 │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Root根队列 │ │ │ │ 100% 集群资源 │ │ │ ├────────────────────┬────────────────────┬───────────────┤ │ │ │ Production │ Development │ Test │ │ │ │ 生产队列 │ 开发队列 │ 测试队列 │ │ │ │ 60% 容量 │ 30% 容量 │ 10% 容量 │ │ │ │ │ │ │ │ │ │ ┌─────┐┌─────┐ │ ┌─────┐┌─────┐ │ ┌─────┐ │ │ │ │ │ETL ││报表 │ │ │实验A││实验B│ │ │单元测试│ │ │ │ │ │团队 ││团队 │ │ │ ││ │ │ │ │ │ │ │ │ └─────┘└─────┘ │ └─────┘└─────┘ │ └─────┘ │ │ │ └────────────────────┴────────────────────┴───────────────┘ │ │ │ │ 关键特性 │ │ • 容量保证每个队列至少获得配置的容量 │ │ • 弹性共享本队列空闲时资源可被其他队列借用 │ │ • 最大容量限制防止单个队列独占集群 │ │ • 用户限制单个用户不能用光整个队列的资源 │ │ • ACL 权限控制谁能往哪个队列提交作业 │ │ │ │ 配置示例 │ │ production 队列60% 容量最大可用 80% │ │ development 队列30% 容量最大可用 50% │ │ test 队列10% 容量最大可用 20% │ │ │ └─────────────────────────────────────────────────────────────────┘Capacity Scheduler 适合企业环境不同部门/团队有自己的资源配额保证核心业务生产队列有资源可用同时允许非高峰期借用空闲资源。Fair Scheduler公平共享这是 HDPHortonworks的默认调度器。思路是所有作业平分资源大作业不能饿死小作业。┌─────────────────────────────────────────────────────────────────┐ │ Fair Scheduler公平调度器 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 场景集群总资源 100 GB同时运行多个作业 │ │ │ │ t1 时刻只有 Job1 提交 │ │ 资源███████████████████████████████████████████████ │ │ Job1: 100 GB公平份额: 100 GB │ │ │ │ t2 时刻Job2 提交 │ │ 资源████████████████████ ████████████████████████ │ │ Job1: 50 GB Job2: 50 GB各分一半 │ │ │ │ t3 时刻Job3 提交 │ │ 资源████████████████ ████████████████ ████████████ │ │ Job1: 33 GB Job2: 33 GB Job3: 33 GB各分 1/3 │ │ │ │ 关键特性 │ │ • 公平共享资源按作业数量平均分配 │ │ • 权重支持重要作业可设置更高权重获得更多资源 │ │ • 抢占机制资源不足的队列可抢占超额分配的队列 │ │ • 最小份额保证队列可设置最小资源确保基本运行 │ │ │ │ 公平份额计算 │ │ 每个队列/作业的公平份额 总资源 × (自身权重 / 总权重) │ │ │ └─────────────────────────────────────────────────────────────────┘Fair Scheduler 适合多用户共享环境比如大学的计算集群、公有云的共享集群保证每个用户的作业都能获得公平的资源份额。三种调度器对比特性FIFOCapacityFair设计目标简单顺序多租户容量保证公平共享队列支持无多层次队列层次化队列池资源隔离无容量限制 ACL权重 最小份额弹性共享无支持支持抢占无不支持支持适用场景测试环境企业多部门多用户共享Container 隔离怎么防止邻居搞破坏多租户环境下一个作业的 Task 不能把其他作业的资源吃光。YARN 通过以下机制实现隔离内存隔离NodeManager 监控每个 Container 的内存使用量如果超出申请值直接kill -9干掉。简单粗暴但有效。CPU 隔离Linux 环境下YARN 通过cgroup限制 Container 的 CPU 使用软限制默认允许弹性共享空闲时可以用更多 CPU硬限制严格按申请的核数分配超了就被限制磁盘隔离每个 Container 有独立的本地工作目录防止磁盘空间被单个 Container 占满。┌─────────────────────────────────────────────────────────────────┐ │ YARN Container 资源隔离 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ NodeManager 上的 Container 隔离 │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ NodeManager │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ │ │ Container 1 │ │ Container 2 │ │ Container 3 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ 内存: 2GB │ │ 内存: 4GB │ │ 内存: 2GB │ │ │ │ │ │ CPU: 1核 │ │ CPU: 2核 │ │ CPU: 1核 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ cgroup 限制 │ │ cgroup 限制 │ │ cgroup 限制 │ │ │ │ │ │ • memory.limit│ │ • memory.limit│ │ • memory.limit│ │ │ │ │ │ • cpu.cfs_quota│ │ • cpu.cfs_quota│ │ • cpu.cfs_quota│ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ │ │ │ │ 超内存 → kill │ │ │ │ 超 CPU → cgroup 限制硬限制或降级软限制 │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘YARN vs Kubernetes谁才是未来这几年 KubernetesK8s火得不行很多人问YARN 会不会被 K8s 取代维度YARNKubernetes设计定位大数据资源管理通用容器编排资源抽象ContainerJVM 进程Pod容器组调度模型请求-分配声明式调度大数据生态深度集成HDFS、Hive 等需额外适配服务发现有限支持原生 Service Ingress自动扩缩容有限HPA / VPA 原生支持云原生较弱原生设计安全认证Kerberos 集成成熟RBAC 其他方案现状是传统 Hadoop 生态企业YARN 仍是主流迁移成本高云原生新架构Spark on K8s、Flink on K8s 越来越流行趋势大数据正在逐步向 K8s 迁移但 YARN 短期内不会消失Spark on K8s 的例子# 以前跑在 YARN 上spark-submit--masteryarn--deploy-mode cluster...# 现在可以直接跑在 K8s 上spark-submit\--masterk8s://https://k8s-apiserver-host:443\--deploy-mode cluster\--confspark.kubernetes.container.imagespark:3.4.0\...K8s 的优势统一的基础设施、更好的弹性伸缩、更丰富的生态服务发现、配置管理、监控。YARN 的优势大数据生态成熟、Kerberos 安全集成、队列调度精细。小结今天咱们聊了 YARN设计思想资源管理和作业执行解耦一套集群跑多种框架核心组件ResourceManager资源大管家、NodeManager节点小管家、ApplicationMaster作业小管家双层调度RM 分配资源给 AMAM 决定怎么跑 Task三种调度器FIFO简单但不公平、Capacity企业多租户、Fair多用户共享资源隔离内存限制超了就杀、CPU 限制cgroup、磁盘隔离与 K8s 的关系大数据正在向 K8s 迁移但 YARN 短期内仍是主流YARN 的价值在于它让多种计算框架MapReduce、Spark、Flink能够共享同一套集群资源避免了每个框架一套集群的资源浪费。理解 YARN 的调度机制对于排查资源争抢、作业排队等问题非常有帮助。你们公司的集群用的是 YARN 还是 K8s有没有遇到过资源争抢导致的作业失败欢迎聊聊