Apache Hadoop YARN (Yet Another Resource Negotiator,另一种资源协调者)是一种新的 Hadoop 资源管理器。
YARN把Job Tracker的两个主要功能(资源管理和作业调度/监控)分成了两个独立的服务程序——全局的资源管理(RM)和针对每个应用的应用 Master(AM),这里说的应用要么是传统意义上的MapReduce任务,要么是任务的有向无环图(DAG).
MRv1 的缺陷
MapReduce 的第一个版本既有优点也有缺点。MRv1 是目前使用的标准的大数据处理系统。但是,这种架构存在不足,主要表现在大型集群上。当集群包含的节点超过 4,000 个时(其中每个节点可能是多核的),就会表现出一定的不可预测性。其中一个最大的问题是级联故障,由于要尝试复制数据和重载活动的节点,所以一个故障会通过网络泛洪形式导致整个集群严重恶化。
但 MRv1 的最大问题是多租户。随着集群规模的增加,一种可取的方式是为这些集群采用各种不同的模型。MRv1 的节点专用于 Hadoop,所以可以改变它们的用途以用于其他应用程序和工作负载。当大数据和 Hadoop 成为云部署中一个更重要的使用模型时,这种能力也会增强,因为它允许在服务器上对 Hadoop 进行物理化,而无需虚拟化且不会增加管理、计算和输入/输出开销
Yarn的优点
大大减小了 JobTracker(也就是现在的 ResourceManager)的资源消耗,并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了,更安全、更优美。
在新的 Yarn 中,ApplicationMaster 是一个可变更的部分,用户可以对不同的编程模型写自己的 AppMst,让更多类型的编程模型能够跑在 Hadoop 集群中,可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中,没有考虑 cpu 的占用 ),比之前以剩余 slot 数目更合理。
老的框架中,JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况,现在,这个部分就扔给 ApplicationMaster 做了,而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster),它是监测 ApplicationMaster 的运行状况,如果出问题,会将其在其他机器上重启。
Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作,目前是一个框架,仅仅提供 java 虚拟机内存的隔离,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量,那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。
Apache Hadoop 的经典版本 (MRv1)
新的 Hadoop MapReduce 框架(Yarn)架构
新Hadoop MapReduce 框架(Yarn)架构