本专栏文章持续更新 ，新增内容使用蓝色表示。
Yarn （Yet Another Resource Negotiator）被广泛视为 Hadoop 生态中的"操作系统"，主要负责集群资源的管理与调度，为上层计算应用提供统一的资源分配和服务支持。
一、基本架构
Yarn 作为 Hadoop 的资源调度层，承担集群资源的统一管理、ApplicationMaster 的启动与协调等职责。与 HDFS 的 NameNode/DataNode 结构类似，Yarn 也采用主从架构，包含 ResourceManager 和 NodeManager 两种核心组件。
具体的作业执行逻辑（如任务划分与调度）则由每个应用的 ApplicationMaster 负责实现。这种架构解耦了资源管理与应用调度，使 Yarn 能够支持多种计算框架。
1.1 ResourceManager（RM）
是整个集群的资源调度器 ，通常部署在控制节点上，（逻辑上）全局唯一。
主要职责包括：
1）处理客户端提交的应用请求；
2）启动并监控 ApplicationMaster；
3）监控各个 NodeManager 的状态；
4）对集群资源进行分配与调度。
1.2 NodeManager（NM）
每个计算节点部署一个，负责本节点的资源管理 与任务执行。
主要职责包括：
1）管理单节点上的计算资源；
2）执行来自 ResourceManager 和 ApplicationMaster 的命令。
1.3 ApplicationMaster（AM）
每个应用单独一个，负责应用级别 的调度 与管理。
主要职责包括：
1）对输入数据进行逻辑切分；
2）向 RM 申请资源，并进一步将资源分配给内部任务（如 MapTask 和 ReduceTask）；
3）处理任务的容错与监控。
1.4 Container（盒子）
是 Yarn 对任务运行资源的抽象，可理解为一个动态分配的资源容器。
包含以下信息：
1）任务运行资源（内存、CPU、所在节点）；
2）任务启动命令；
3）任务运行环境配置。
⚠️ 注意：Yarn 中的 Container 是一种资源抽象，不同于 Docker 等容器技术。
二、执行一次数据分析的流程
以MapReduce作业为例：
1）客户端向 ResourceManager 提交应用后，ResourceManager 会为该应用分配一个容器，并寻找合适（通常是资源利用率较低）的节点，然后指令该节点的 NodeManager 启动 ApplicationMaster。
注意：此处"容器"指YARN中的资源单位，不同于微服务中的容器概念。
2）ApplicationMaster 向 ResourceManager 申请资源，并依照程序逻辑对任务进行分解。
具体来说，ApplicationMaster 将申请到的资源按需划分为多个 Map Task，并将这些任务分配至由 ResourceManager 协调安排的计算节点上执行。ResourceManager 通过各节点上的 NodeManager 监控 ApplicationMaster 的运行状态，若 ApplicationMaster 运行失败，可自动重启以保证任务可靠性。
3）待所有 Map Task 执行完成后，ApplicationMaster 会进一步分配和启动 Reduce Task，对 Map 阶段输出的中间结果进行归约处理。
4）整个 MapReduce 作业完成后，ApplicationMaster 会向 ResourceManager 注销应用并主动退出，完成一次作业生命周期。
2.1 容错机制
ResourceManager：存在单点故障，可通过 ZooKeeper 实现高可用（HA）。
补充：后续会出 ZooKeeper 相关章节。
NodeManager：失败后，RM 会通知相关 AM，由 AM 决定如何重新调度任务。
ApplicationMaster：失败后由 RM 重启；AM 自身需处理其内部任务的容错，已完成的任务通常不需重新运行，RM/AppMaster会保存。
2.2 推测执行机制
推测执行 是 MapReduce 设计中的一种优化策略 。它的核心思想是：当一个作业的中绝大多数任务已完成，仅剩少数任务因运行缓慢而拖延整体进度时，系统会在其他可用节点上启动与原任务完全相同的"备份任务"（Speculative Task）。原始任务与备份任务并行执行，系统将采纳最先完成的任务结果，并立即终止另一冗余任务。
2.2.1 为什么要用推测执行？
"拖后腿的任务"在分布式系统中被称为 "落伍者"（Straggler） 。落伍者的产生通常不是代码问题，而是由一些不可控的系统层面原因造成的，例如：
1）硬件故障或性能瓶颈：该任务所在的机器磁盘读写速度慢、CPU高负载、内存不足。
2）资源竞争：同一台节点上可能运行着其他繁重的进程，抢占了资源。
3）网络问题：节点与集群其他部分网络连接不佳。
一个落伍者会拖慢整个作业的进度，因为Reduce阶段必须等所有Map都完成才能开始，最终作业的完成时间取决于最慢的那个任务。
2.2.2 推测执行不能启用的场景
1）任务间负载严重不均衡；
2）任务涉及外部状态写入（如数据库操作）。
三、运行在YARN上的计算框架
▪ 流式计算框架 Storm
适用于对数据流进行实时持续处理，解决了传统实时系统在自动化、健壮性和伸缩性上的不足。
传统做法：由消息队列和消息处理者组成的实时处理网络
▪ 内存计算框架 Spark
通过引入弹性分布式数据集（RDD），有效克服了 MapReduce 在迭代和交互计算中的性能瓶颈。
RDD是一个有容错机制，可以被并行操作的数据集合，能够被缓存到内存或磁盘上。
▪ DAG 计算框架 Tez
运行在 Yarn 之上，充分利用YARN的资源管理和容错等功能，提供更灵活的数据流 API 和动态物理图生成机制，适用于复杂依赖的作业图。
▪ MapReduce 离线计算框架
经典批处理模型，包含 Map、Shuffle、Reduce 三个阶段。适合海量静态数据的处理，但因磁盘和网络开销较大，不适用于实时、流式或 DAG 型计算场景。
3.1 离线计算框架 MapReduce
3.1.1 处理流程概述
MapReduce采用分阶段数据处理模式，其核心处理流程如下：
输入数据被划分为多个固定大小的分片（默认为 128MB），由多个Map Task 并行处理；Shuffle 阶段负责将相同 Key 的数据收集到同一个 Reducer（不进行计数）；Reduce阶段则对Map的输出结果进行汇总。
3.1.2 Combiner本地归约
Combiner 是一种本地归约机制，可视为运行在 Map 端的局部 Reducer。它会在 Shuffle 之前对相同 Key 的 Value 进行合并（例如在 WordCount 中提前累加计数），通常其逻辑与 Reducer 一致。好处是显著减少 Map Task 的输出数据量（降低磁盘 I/O）以及 Map 到 Reduce 之间的数据传输量（节省网络 I/O）。
3.1.3 Shuffle连接机制
Shuffle 连接了 Map 和 Reduce 两个阶段，核心任务是将相同 Key 的数据发送至同一 Reducer。使用 Combiner 可在 Map 端进行数据预聚合，减轻Shuffle阶段的数据传输负担。
3.1.4 任务阶段划分
MapReduce 将作业分为两个主要阶段：
1）Map阶段
由多个Map Task并行执行：
-
输入解析：InputFormat负责数据分片和解析
-
数据处理：Mapper执行用户定义的映射逻辑
-
数据分组：Partitioner确定数据分发策略
2）Reduce阶段
由多个Reduce Task协作完成：
-
数据远程拷贝：从各个Map Task拉取数据
-
按Key排序：对输入数据进行排序处理
-
数据处理：Reducer执行归约计算
-
数据输出：OutputFormat处理结果写入
3.1.5 优势
1）易于编程：提供简洁的编程模型，降低开发复杂度
2）良好的扩展性：可线性扩展至数千个节点
3）高容错性：自动处理节点故障，保证任务完成
4）海量数据处理：适合PB级以上离线批处理场景
3.1.6 局限性
1）启动开销大：任务调度和初始化耗时较长
2）磁盘I/O瓶颈：过度依赖磁盘读写，影响处理效率
3）实时性不足：无法满足毫秒或秒级响应需求
4）流式处理欠缺：仅支持静态数据集处理
5）复杂依赖受限：不适用于DAG计算场景，难以处理多阶段任务依赖
补充：Shuffle 阶段涉及大量跨节点数据传输，因此性能较差。对性能有更高要求的场景可选用基于内存的计算框架（如 Spark）。
3.1.7 典型应用场景
-
基础数据统计（如 PV/UV）；
-
搜索引擎索引构建；
-
海量数据查询；
-
复杂机器学习算法（聚类、分类、推荐、图计算等）。
预告后续内容
Hive、ZooKeeper、HBase
如有问题或建议，欢迎在评论区中留言~