由于第二章为 Hadoop 环境安装内容，此处略过。环境安装可以参考：Ambari 的安装文档
1. Hadoop 架构的变迁
YARN 提供了运行非 MapReduce 应用的新能力，为 Hadoop 生态增加了很多新特性。
2. YARN 的架构介绍
YARN 依赖三个核心组件来实现资源管理和任务调度：
- ResourceManager（RM）：集群资源的仲裁者，主要由可插拔的调度器 Scheduler 和管理应用生命周期的 ApplicationsManager 组成。
- NodeManager（NM）：NM 位于每个计算节点上，负责管理该节点上的 Container，并向 ResourceManager 汇报节点资源和 Container 状态。
- ApplicationMaster（AM）：用户作业生命周期的管理者。每个应用都会启动自己的 ApplicationMaster，用于向 ResourceManager 申请资源，并协调 NodeManager 运行具体任务。
这三个组件共同提供了一个可扩展、灵活、高效的环境来运行各种类型的大数据处理作业。
2.1 ResourceManager
- ResourceManager 拥有为系统中所有应用分配资源的决定权，可以基于内存、CPU、磁盘以及网络等多个资源维度为各个应用分配资源。
- ResourceManager 是一个纯粹的调度器，它根据应用程序的资源请求，严格限制系统的可用资源，在保证容量、公平性以及服务等级（SLA）的前提下，优化集群资源利用率，让所有资源都被充分利用。
- ResourceManager 有一个可插拔的调度器（Scheduler）来使用不同的调度算法。Scheduler 负责应用不同的调度算法为运行中的各个应用分配资源，有些算法注重容量，有些注重公平等，分配资源时会受到容量队列以及其他因素的制约。
- Scheduler 基于应用程序的资源需求来执行调度功能，使用了资源 Container 这个抽象概念，其中包括了多种资源维度，如内存、CPU、磁盘以及网络等。
- Scheduler 是一个纯粹的调度器，不负责对应用程序的状态进行监控与追踪，也不会在应用程序失败的情况下对任务进行重启。
2.2 NodeManager
NodeManager 是部署在计算节点上的从属进程，负责启动应用程序的 Container，并监控它们的资源（内存、CPU、磁盘以及网络等）使用情况，然后将其报告给 ResourceManager。
NodeManager 和 ResourceManager 组成了新的通用系统以分布式的方式管理应用。
2.3 ApplicationMaster
- ApplicationMaster 是特定框架库的一个实例。
- ApplicationMaster 也是一个普通的 Container。
- ApplicationMaster 与应用程序一一对应，为一组应用提供一个 ApplicationMaster 也是可行的，例如 Hive 的 ApplicationMaster。
- ApplicationMaster 向 ResourceManager 申请应用程序所需的资源 Container。
- ApplicationMaster 与 NodeManager 协同工作，监控 Container 的状态、执行进度和资源使用情况。
ApplicationMaster 的增加使 YARN 可以提供以下新的特性：
- 扩展性：将容错功能转移到 ApplicationMaster 中，控制就变得局部化而不是全局化，也使 ResourceManager 可以作为纯粹的调度器，不必提供跨集群的资源容错等功能。ApplicationMaster 与应用程序一一对应，基本不会成为集群的瓶颈。
- 开放性：将所有应用框架相关代码都转移到 ApplicationMaster，使系统变得通用。这样就可以支持 MapReduce、MPI、图计算等多种框架。
ApplicationMaster 本质上还是客户端代码，不能完全信任。因此 YARN 必须保护自身，避免受到错误或恶意 ApplicationMaster 的影响，并控制所有资源授权。
2.4 Container
- Container 是一个单节点上内存、CPU、磁盘等物理资源的集合。
- Container 由 ResourceManager 进行调度，由 NodeManager 进行监控。
- 单个节点上可以有多个 Container。
- 单个节点可以被划分为多个 Container，每个 Container 都对应一定数量的内存和 CPU 资源。
- ApplicationMaster 可以请求 Container 来占据最小容量整数倍的资源。一个应用程序从 ApplicationMaster 开始，而 ApplicationMaster 本身就是一个 Container。
- ApplicationMaster 启动后会向 ResourceManager 申请更多的 Container，并在运行中动态申请和释放 Container。例如，一个 MapReduce 作业可以请求一定数量的 Map Container。当 Map 计算结束时，它会释放 Map Container，并请求更多的 Reduce Container。
2.5 资源模型
YARN 提供了非常通用的资源模型。一个应用（ApplicationMaster）可以请求非常具体的资源：
- 资源名称（包括主机名称、机架名称、复杂的网络拓扑等）
- 内存
- CPU（核数、类型）
- 其他资源（disk、network I/O、GPU 等）
2.6 资源请求
ResourceManager 在调度资源时能够感知集群的网络拓扑，以便尽可能减少数据移动，优化数据访问。
ResourceManager 内的调度器会保存应用程序的资源需求信息，以帮助集群中的所有应用做出更优的调度决策。
ApplicationMaster 请求特定资源来满足计算需求，Scheduler 会分配一个 Container 来响应请求，以满足 ApplicationMaster 的 ResourceRequest 需求。
ResourceRequest 会提出 <资源名称，优先级，资源需求，Container 数> 需求：
- 资源名称：资源期望所在的主机名，机架等
- 优先级：应用内部请求的优先级
- 资源需求：需求的资源量，常见资源维度包括内存和 CPU
- Container 数：需要的 Container 数量
2.7 应用提交流程
YARN 的架构可以通过一次应用提交过程串起来理解：
- Client 向 ResourceManager 提交应用程序，包括启动 ApplicationMaster 所需的 jar 包、命令、环境变量和资源需求。
- ResourceManager 接收请求后，为 ApplicationMaster 分配第一个 Container。
- 对应节点上的 NodeManager 启动 ApplicationMaster。
- ApplicationMaster 启动后向 ResourceManager 注册，并根据任务需求继续申请 Container。
- ResourceManager 通过 Scheduler 分配 Container，ApplicationMaster 再和对应 NodeManager 通信，让 NodeManager 启动具体任务。
- 任务运行过程中，NodeManager 持续汇报 Container 状态，ApplicationMaster 负责跟踪任务进度和失败重试。
- 应用完成后，ApplicationMaster 向 ResourceManager 注销，相关 Container 资源被释放。
