【大数据2025】Yarn 总结

分布式资源管理系统讲解总结

一、引言

• 围绕分布式资源管理系统展开，重点涵盖 Yarn 的简介、原理、资源调度策略以及运维和管理，旨在让学员全面掌握相关知识。
• Yet Another Resource Negotiator

二、Yarn 诞生背景

• 在 Hadoop 1.X 中仅有 HDFS 和 MapReduce 两个框架，HDFS 负责存储，MapReduce 兼具计算与资源管理双重职能，负责将计算任务调度到 HDFS 数据存储节点。

三、MapReduce 架构及问题 （Hadoop 1.x)

• 架构：采用主从架构，主节点为 job tracker，从节点是 task tracker。客户端向 job tracker 提交作业请求，job tracker 在数据节点申请 CPU 和内存等资源，作业在申请到的资源中运算，并向 job tracker 汇报，任务完成后释放资源。
• 问题
  • 单点故障率高：job tracker 管理任务繁重，既要管理资源分配又要管理作业，任务量大时易超负荷挂掉，且无高可用机制，一旦挂掉整个集群瘫痪。
  • 资源描述模型简单：仅依据 task 数量分配固定资源，未考虑 CPU 和内存实际需求，导致资源浪费和任务运行效率低下，并且强制拆分资源为 map 和 reduce，无法兼容其他计算框架，通用性差。

四、Yarn 介绍及解决问题方式

• Yarn 是分布式通用资源管理系统，处于通用计算和数据存储中间位置。
• 解决了 MapReduce 的问题，使资源调度更精细且通用性增强，可调度多种计算框架作业到 HDFS 运行，同时对 MapReduce 单点故障率高的问题也有相应解决措施（后续内容应会提及具体架构优化方式）。

主从架构

• 架构组成：主节点为 resource manager，负责资源管理；从节点是 node manager，所有 node manager 地位平等，无层级管理关系。
• 单点故障解决方案：采用热备节点（stand by），当活跃主节点（active）故障时，热备节点可接替工作，减轻单点故障风险，但未完全解决问题。进一步通过将作业管控工作从主节点分离来分散压力。

作业管理机制

• 作业提交与资源分配：客户端向 resource manager 提交作业，后者在 node manager 中为作业分配资源（包括 CPU、内存、环境变量等），并分装到 container 中。首次提交作业通常分配一个 container 用于运行作业的管理进程 application master。
• 作业解析与资源再申请：application master 运行后解析作业，若需更多资源则向 resource manager 申请，resource manager 再次分配 container 给 application master。
• 任务分发与运行监控：application master 获得资源后将作业 task 分发到 container 中运行，task 实时向 application master 汇报状态，若有 task 故障，application master 会尝试重启。
• 资源释放与作业完成：当 application master 检测到所有 task 运行完毕，向 resource manager 申请释放资源，resource manager 释放相关 container，作业执行流程结束。

架构通用性

• 该架构具有通用性，客户端可提交 map reduce 作业、spark 作业或自行编写的 job。只要任务实现 application master 接口，就能在集群中运行。例如 spark 作业提交后，同样先由 resource manager 分配 container 运行其 application master，后续流程类似其他作业，由 application master 自主解析任务、申请资源、分发 task 并监控运行。

高可用机制总结

一、多主节点与状态管理架构

• 架构组成：高可用架构由多台主节点构成，其中一台主节点处于 active 管理状态，其余为 stand by 热备状态。
• 状态决策机制：主节点间状态由 zookeeper 管控。zookeeper 主节点中选定管理节点并设为 active，当 active 节点故障，zk 会将其 resource manager 状态降为 stand by，并从 stand by 节点中选新管理主节点升级为 active，确保管理连续性。

二、元数据同步策略

hdfs 同步方式：在 hdfs 中，原数据通过 journal node 集群实现同步，保障数据一致性与完整性，使新 active 节点获取最新原数据管理集群。

• Yarn 同步方式：Yarn 系统将元数据置于 zk 内，standby 节点可从中获取并同步，同步完成后经 ZK 切换为 active 进行集群管理，简化同步流程。

三、主从切换对任务的影响及应对操作

• 任务阻塞现象：主从切换期间，集群运行任务会阻塞，直至新 active 状态的 resource manager 选出才继续执行，防止数据不一致与错误操作。
• 命令操作功能：利用 yarn rmadmin 加参数可执行高可用操作，如获取节点状态，超级管理员可强制切换节点状态（stand by 转 active 或反之），便于灵活调整集群架构。

YARN 资源调度策略总结

YARN 作为重要的资源管理框架，其资源调度策略对任务执行效率影响重大。主要包括 FIFO、容量调度和公平调度三种策略。

一、FIFO 调度策略

• 核心机制：采用单队列架构，任务依提交顺序依次执行。先提交的作业会独占集群全部资源运行，后续作业需等待前面作业完成才能获取资源启动。
• 缺陷分析：对紧急且执行时间短的小任务极不友好。例如，若紧急小任务在大任务之后提交，即便其所需执行时间很短，也会因 FIFO 规则而长时间等待，可能错过最佳执行时机，严重影响系统对多样化任务的处理效率。

二、容量调度策略

• 核心原理
  • 基于多队列设计理念，将集群资源预先分配给不同队列。如划分队列 A 用于处理大作业，分配集群 80%资源；队列 B 用于处理紧急小作业，分配 20%资源。作业提交时按类型进入相应队列获取资源运行，各队列作业可并行处理。
  • 每个队列资源占比并非绝对固定，可设置最大资源占用量。例如，可配置队列 B 在特定情况下（如队列 A 空闲时）最大可占用集群 100%资源，有效避免资源闲置浪费。
• 配置要点
  • 在配置文件（如 yarn-site.xml）中需指定使用容量调度器。
  • 借助自定义配置文件详细设定各队列及子队列资源占比等参数。如在根队列下创建队列 A、B，并可在队列 A 下进一步设置子队列 A1、A2，同时明确各队列资源分配比例（如队列 A 占 80%，队列 B 占 20%，队列 A1 占队列 A 资源的 40%，队列 A2 占 60%等）。
    

三、公平调度策略

• 核心原则 见面分一半
  • 同样采用多队列架构，但队列间无预设固定资源占比，资源分配遵循公平原则。默认新任务提交时，若已有任务占用资源，会让出部分资源给新任务，使各队列按公平方式共享集群资源。例如，作业一提交至空闲队列 A 可占用全部资源，作业二提交后，队列 A 会在作业二执行前让出一半资源给作业二；队列内部也遵循类似机制。
  • 虽默认按公平方式分配资源，但在实际生产中，由于各队列任务资源需求差异，可通过调整队列权重实现灵活分配。默认每个队列权重为 1，若某队列需更多资源，可提升其权重。如将某队列权重设为 2，则该队列在资源分配时将获取更多比例资源，以满足不同任务对资源的实际需求。

• 配置步骤
  • 首先在全局配置中选定公平调度器。
  • 然后在自定义配置环节针对不同队列设置权重等关键参数。例如，设置 sample query 队列权重为 2，确保公平调度器能根据实际业务场景进行合理资源调配。

YARN 运维

• 作业查看与管理命令：
  • 使用“yarn application -list”可查看集群中所有作业的 ID；
  • “yarn application -status”用于查看作业运行状态；找到作业 ID 后，
  • 用“yarn application -kill”能终止作业。

YARN 监控

• 集群监控：默认端口是 8088，在此端口可查看整个集群的监控信息，如服务器数量、节点状态（例如有四个从节点处于 running 状态）、内存使用量以及 call 使用量等。
• 作业监控：在监控界面左侧点击“applications”可进入作业监控界面，能查看集群中作业的运行和完成情况。

yarn 命令

一、资源管理命令

1. yarn node -list

   • 功能：列出 YARN 集群中的节点信息。
   • 示例：

     yarn node -list
     

   • 解释：该命令将显示 YARN 集群中所有节点的详细信息，包括节点的地址、节点的状态（如 RUNNING、DECOMMISSIONED、LOST 等）、节点的资源容量（如 CPU 核心数、内存大小）、已使用的资源量、剩余可用资源量等。这对于查看集群资源的整体使用情况非常有用。

2. yarn queue -status <queue-name>

   • 功能：查看指定队列的状态信息。
   • 示例：

     yarn queue -status default
     

   • 解释：YARN 中的队列用于管理资源分配，不同的应用程序可以提交到不同的队列中，以实现资源的隔离和调度。此命令可查看指定队列（如示例中的 default 队列）的资源使用情况，包括该队列已使用的资源、可用资源、等待运行的应用程序数量、正在运行的应用程序数量等。

3. yarn application -list

   • 功能：列出 YARN 中正在运行的应用程序。
   • 示例：

     yarn application -list
     

   • 解释：显示 YARN 集群中当前正在运行的所有应用程序的信息，如应用程序的 ID、名称、用户、启动时间、状态（如 RUNNING、ACCEPTED、FINISHED 等）、应用程序类型（如 MapReduce、Spark 等）以及应用程序占用的资源情况。

二、应用程序管理命令

1. yarn application -kill <application-id>

   • 功能：终止指定的 YARN 应用程序。
   • 示例：

     yarn application -kill application_12345_6789
     

   • 解释：通过提供应用程序的唯一 ID（如 application_12345_6789），可以终止该应用程序。这在需要停止某个长时间运行的异常应用程序或测试时需要强制结束某个应用程序时非常有用。

2. yarn application -status <application-id>

   • 功能：查看指定应用程序的状态。
   • 示例：

     yarn application -status application_12345_6789
     

   • 解释：该命令将给出应用程序的详细状态信息，包括应用程序的最终状态（如 SUCCEEDED、FAILED、KILLED 等）、运行进度（如果适用）、分配给该应用程序的容器信息（容器的数量、使用的资源等）、应用程序日志的 URL 等。

三、集群维护命令

1. yarn rmadmin -getServiceState <service-name>

   • 功能：获取 YARN 服务的状态。
   • 示例：

     yarn rmadmin -getServiceState ResourceManager
     

   • 解释：可以检查 YARN 服务（如 ResourceManager）的状态，以确定服务是否正常运行，服务状态可以是 ACTIVE、STANDBY 等。

2. yarn rmadmin -refreshQueues

   • 功能：刷新队列配置。
   • 示例：

     yarn rmadmin -refreshQueues
     

   • 解释：当修改了 YARN 的队列配置文件（如 capacity-scheduler.xml）后，使用此命令可以使新的队列配置生效，而无需重启 YARN 服务。

四、日志管理命令

1. yarn logs -applicationId <application-id>
   • 功能：查看指定应用程序的日志。
   • 示例：

     yarn logs -applicationId application_12345_6789
     

   • 解释：对于故障排除和监控，此命令允许查看特定应用程序的日志，包括应用程序运行时的标准输出和标准错误输出。可以帮助开发人员和管理员找出应用程序失败或性能不佳的原因。

五、容量调度器相关命令

1. yarn schedulerconf -list
   • 功能：列出 YARN 容量调度器的配置信息。
   • 示例：

     yarn schedulerconf -list
     

   • 解释：对于使用 YARN 容量调度器的集群，此命令可以显示调度器的配置信息，如队列的容量、最大容量、最小用户限制、队列之间的资源分配策略等。

六、YARN 集群信息查看命令

1. yarn cluster -info
   • 功能：显示 YARN 集群的总体信息。
   • 示例：

     yarn cluster -info
     

   • 解释：该命令会提供关于 YARN 集群的一些基本信息，例如 ResourceManager 的地址、Web 界面的 URL、集群的版本信息、集群的资源总容量等。

这些 YARN 命令可以帮助你在大数据环境中进行资源管理、应用程序管理、集群维护和故障排除等操作，在面试中熟悉这些命令可以展示你对 YARN 资源管理框架的操作能力和理解。根据不同的场景和需求，灵活使用这些命令可以更好地管理和维护 YARN 集群。