【YARN 权威指南】1. YARN 的发展史

Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器。它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度。它的引入为集群利用率、资源统一管理和数据共享等方面带来了明显收益。

----百度百科

1. YARN 经历的四个阶段

阶段	说明
阶段 0 Ad Hoc 阶段	标志着 Hadoop 的兴起，集群以 Ad Hoc、单用户方式建立。
阶段 1 Hadoop on Demand（HOD）阶段	HOD 是演进中的下一个阶段。它以通用系统的形式，在商用硬件组成的共享集群上提供和管理私有 Hadoop MapReduce 和 HDFS 实例。
阶段 2 共享计算集群的黎明	始于大量 Hadoop 安装转向共享 HDFS 实例和共享 MapReduce 集群。
阶段 3 YARN 的出现	用于解决以往架构的需求与缺陷。

2. Ad Hoc 阶段

Ad Hoc 出现之前，用户使用 Hadoop 的方式是在少量节点上手工建立集群，将数据载入 HDFS，通过 MR 计算数据，然后拆分集群。
采用这种方式有两个原因：

1. 没有在 HDFS 上持久存储数据的迫切需求
2. 没有共享数据和计算结果的动机

HDFS 实现了 POSIX 标准权限模型，支持多用户环境。随着共享 HDFS 实例出现，建设共享计算平台成为急需解决的问题。

3. Hadoop on Demand（HOD）阶段

HOD 项目是一个能在商用硬件上共享和管理 MapReduce 和 HDFS 实例的系统。HOD 采用传统的资源管理器（Torque）和集群调度器（Maui）一起分配与共享集群。

HOD 的基本架构包括：

• 调度器 ResourceManager（RM）
• RM/Scheduler 交互以及管理 Hadoop 的多种 HOD 组件
• Hadoop MR 和 HDFS 守护进程
• HOD shell 和 Hadoop 客户端

HOD 用户会话流程：

1. 用户调用 HOD shell 向 Torque 提交适当规模的计算集群请求，包括所需节点数和期望的 Hadoop 部署规范。
2. Torque 将请求放入队列。当有节点可用时，Torque 会在可用节点上启动 RingMaster 进程。
3. RingMaster 是一个 HOD 组件，通过 ResourceManager（RM）接口运行 HODRing。分配到的每个计算节点都会启动 HODRing。
4. HODRing 初始化之后与 RingMaster 通信，并执行获取到的 Hadoop 指令。Hadoop 守护进程启动后，HODRing 会向 HODMaster 注册，并提供相关守护进程信息。
5. HOD 客户端保持和 RingMaster 的通信，找出 JobTracker 和 HDFS 守护进程的位置。
6. 前面执行完之后，用户即可知道 JobTracker 和 HDFS 的位置。HOD 会退出，并允许用户在相应的集群上执行数据运算。
7. 当计算作业执行完成后，用户即可释放集群。

HOD 的优点

1. 日志管理：通过删除 HDFS 上超时的日志文件来管理日志的保留。

2. 多用户和单用户多集群：用户可以使用 HOD 同时分配多个 MapReduce 集群，并通过 list 和 info 命令协助管理多个并行集群。

   • list 命令列出分配给单个用户的所有集群。
   • info 命令显示指定集群的信息。

3. 配置：HOD 提供了便捷机制，用于启动 HOD 软件本身，并配置它提供的 Hadoop 守护进程。该机制也可以帮助管理在客户端生成的配置文件。

4. 空闲集群的自动释放：每个 HOD 分配都包含一个监视功能，会定时检查 Hadoop 作业运行情况。当没有作业执行时，HOD 会自动释放集群。

HOD 的缺点

1. 数据本地化：Torque 不知道 HDFS 上的 Block 分布，分配节点时无法考虑数据本地化。
2. 集群使用率：HOD 无法调整单个作业内部或不同作业阶段之间的集群规模，集群资源在大多数时间都处于部分空闲状态。在极端情况下，一个节点上运行的 Reduce 任务可能导致由数百个节点组成的集群无法被回收。
3. 可伸缩性：HOD 只能依赖少量启发式算法来评估节点的资源需求。这对用户来说可能是合适的策略，但对集群使用率来说并不理想。HOD 没有根据需求扩容或缩容 MapReduce 集群的能力。

4. 共享计算集群

HOD 无法对资源分配做出智能决策，资源管理粒度也太粗。因此，大多数人选择了包含共享 HDFS 实例和共享 MapReduce 集群的模式。这种共享计算框架主要有以下组件：

1. JobTracker 是中央守护进程，负责运行集群上的所有作业。
2. TaskTracker 是系统里的从进程，根据 JobTracker 的指令执行任务。

共享集群的演进

1. HDFS 实例：共享 HDFS 实例一直在持续发展。在此阶段，HDFS 提升了可扩展性，设计了新的 FileContext API，并增加了 file-append 操作、基于 Kerberos 的安全性和高可用性等功能。
2. 中央 JobTracker 守护进程：集群调度器被放置在 JobTracker 内部，同时也暴露出许多曾被 HOD 掩盖的竞争和死锁问题。
3. JobTracker 内存管理：随着集群规模扩大，JobTracker 需要管理更多作业以及每个作业可运行的并行任务数，内存压力随之增加。
4. 已完成作业的管理：JobTracker 不再记录任何已经完成的作业信息，而是使用 JobHistoryServer 管理。
5. 中心调度：HOD 被放弃后，与传统资源管理器协同工作的中央调度器也随之取消。为了促进调度算法更新，很快实现了注重吞吐量的 Capacity 调度器，同时注重公平性的 Fair 调度器也出现了。
6. 单个节点上的隔离：MapReduce 是内存密集计算。在某些情况下，用户作业会拖垮集群的 DataNode，导致 HDFS 无法工作。解决这个问题的方式是杀死超过预设内存限制的进程树。
7. 安全性：为避免以特权用户运行 TaskTracker，系统通过创建 task-controller 的 setuid 可执行文件来处理特权操作。需要时，TaskTracker 通过命令调用 task-controller，先以 root 身份执行必要的本地操作，再通过 setuid 降权机制切换为普通用户执行剩余操作。
8. 身份认证和访问控制：管理员在集群初始化之前设置 Queue ACLs。管理员可以在运行时动态改变 ACLs，从而允许一个用户或者用户组访问。

使用共享 MapReduce 集群存在的问题

1. 可扩展瓶颈：MapReduce 集群急速扩张，但内存管理以及 JobTracker 中各种特性的粗粒度锁成为可扩展性的瓶颈。
2. 可靠性和可用性：JobTracker 失效会引发集群中所有作业的中断。
3. MapReduce 编程模型的滥用：MapReduce 并不适用于所有大型计算。很多机器学习任务需要在同一数据集上多次迭代，如果使用 MapReduce 执行这类计算，调度开销会导致结果延迟，图计算效率也不高。
4. 资源模型：MapReduce 的 slot 资源模型较为固定，Map slot 和 Reduce slot 不能灵活共享，降低了整体资源利用率。
5. 用户日志管理：用户日志被截断后一般由 TaskTracker 保留在节点中。如果节点死亡或下线，其日志将不可用。

5. YARN 出现

吸取了 Apache Hadoop MapReduce 发展史的教训，YARN 被设计用来解决之前遇到的问题，具体要求如下：

1. 可扩展性：可以平滑地扩展至数万节点和并发的应用。
2. 可维护性：保证集群软件的升级与用户应用程序完全解耦。
3. 多租户：需要支持在同一个集群中多个租户并存，同时支持在多个用户之间细粒度地共享单个节点。
4. 位置感知：支持位置感知，对于很多应用来说将计算移动到数据所在的位置是一个重大的进步。
5. 高集群使用率：实现底层物理资源的高使用率。
6. 安全和可审计的操作：继续以安全的可审计的方式使用集群资源。
7. 可靠性和可用性：有高度可靠的用户交互，并支持高可用性。
8. 对编程模型多样性的支持：支持多样化的编程模型，演进为不再仅以 MapReduce 为中心。
9. 灵活的资源模型：支持各个节点的动态资源配置以及灵活的资源模型。
10. 向后兼容：保持现有 MapReduce 应用程序并完全向后兼容。