共计 4311 个字符，预计需要花费 11 分钟才能阅读完成。
这篇文章跟大家分析一下“如何实现 MRv1 和 Yarn 对比”。内容详细易懂，对“如何实现 MRv1 和 Yarn 对比”感兴趣的朋友可以跟着丸趣 TV 小编的思路慢慢深入来阅读一下，希望阅读后能够对大家有所帮助。下面跟着丸趣 TV 小编一起深入学习“如何实现 MRv1 和 Yarn 对比”的知识吧。
YARN 并不是下一代 MapReduce（MRv2），下一代 MapReduce 与第一代 MapReduce（MRv1）在编程接口、数据处理引擎（MapTask 和 ReduceTask）是完全一样的， 可认为 MRv2 重用了 MRv1 的这些模块，不同的是资源管理和作业管理系统，MRv1 中资源 管理和作业管理均是由 JobTracker 实现的，集两个功能于一身，而在 MRv2 中，将这两部分分开了， 其中，作业管理由 ApplicationMaster 实现，而资源管理由新增系统 YARN 完成，由于 YARN 具有通用性，因此 YARN 也可以作为其他计算框架的资源管理系 统，不仅限于 MapReduce，也是其他计算框架，比如 Spark、Storm 等， 通常而言，我们一般将运行在 YARN 上的计算框架称为“X on YARN”，比如“MapReduce On YARN”, Spark On YARN，“Storm On YARN”等。
这在官网上描述的很清楚：
Hadoop Common: The common utilities that support the other Hadoop modules.
Hadoop Distributed File System (HDFS™): A distributed file system that provides high-throughput access to application data.
Hadoop YARN: A framework for job scheduling and cluster resource management.
Hadoop MapReduce: A YARN-based system for parallel processing of large data sets.
原 Hadoop MapReduce 框架的问题
对于业界的大数据存储及分布式处理系统来说，Hadoop 是耳熟能详的卓越开源分布式文件存储及处理框架，对于 Hadoop 框架的介绍在此不再累述，读者可参考 Hadoop 官方简介。使用和学习过老 Hadoop 框架（0.20.0 及之前版本）的同仁应该很熟悉如下的原 MapReduce 框架图：
图 1.Hadoop 原 MapReduce 架构
从上图中可以清楚的看出原 MapReduce 程序的流程及设计思路：
首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上，需要管理所有 job 失败、重启等操作。
TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。
TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat 发送给 JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。上图虚线箭头就是表示消息的发送 – 接收的过程。
可以看得出原来的 map-reduce 架构是简单明了的，在最初推出的几年，也得到了众多的成功案例，获得业界广泛的支持和肯定，但随着分布式系统集群的规模和其工作负荷的增长，原框架的问题逐渐浮出水面，主要的问题集中如下：
JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。
源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行，，造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。
从操作的角度来看，现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 (例如 bug 修复，性能提升和特性化) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应 用程序是不是适用新的 Hadoop 版本而浪费大量时间。
新 Hadoop Yarn 框架原理及运作机制
从业界使用分布式系统的变化趋势和 hadoop 框架的长远发展来看，MapReduce 的 JobTracker/TaskTracker 机制需要大规模的调整来修复它在可扩展性，内存消耗，线程模型，可靠性和性能上的缺陷。在过去的几年中，hadoop 开发团队做了一些 bug 的修复，但是最近这些修复的成本越来越高，这表明对原框架做出改变的难度越来越大。
为从根本上解决旧 MapReduce 框架的性能瓶颈，促进 Hadoop 框架的更长远发展，从 0.23.0 版本开始，Hadoop 的 MapReduce 框架完全重构，发生了根本的变化。新的 Hadoop MapReduce 框架命名为 MapReduceV2 或者叫 Yarn，其架构图如下图所示：
图 2. 新的 Hadoop MapReduce 框架（Yarn）架构
重构根本的思想是将 JobTracker 两个主要的功能分离成单独的组件，这两个功能是资源管理和任务调度 / 监控。新的资源管理器全局管理所有应用程序计算资源的分配，每一个应用的 ApplicationMaster 负责相应的调度和协调。一个应用程序无非是一个单独的传统的 MapReduce 任务或者是一个 DAG(有向无环图) 任务。ResourceManager 和每一台机器的节点管理服务器能够管理用户在那台机器上的进程并能对计算进行组织。
事实上，每一个应用的 ApplicationMaster 是一个详细的框架库，它结合从 ResourceManager 获得的资源和 NodeManager 协同工作来运行和监控任务。
上图中 ResourceManager 支持分层级的应用队列，这些队列享有集群一定比例的资源。从某种意义上讲它就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务。
ResourceManager 是基于应用程序对资源的需求进行调度的 ; 每一个应用程序需要不同类型的资源因此就需要不同的容器。资源包括：内存，CPU，磁盘，网络等等。可以看出，这同现 Mapreduce 固定类型的资源使用模型有显著区别，它给集群的使用带来负面的影响。资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序。调度 插件可以基于现有的能力调度和公平调度模型。
上图中 NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU，内存，硬盘，网络) 并且向调度器汇报。
每一个应用的 ApplicationMaster 的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控它们的进程，处理任务的失败原因。
Yarn 执行任务流程
它的基本设计思想是将 MapReduce 中的 JobTracker 拆分成了两个独立的服务：一个全局的资源管理器 ResourceManager 和每个应 用程序特有的 ApplicationMaster。其中 ResourceManager 负责整个系统的资源管理和分配，而 ApplicationMaster 则负责单个应用程序的管理。
当用户向 YARN 中提交一个应用程序后，YARN 将分两个阶段运行该应用程序：第一个阶段是启动 ApplicationMaster；第二个阶段是 由 ApplicationMaster 创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行成功。如图 2 - 7 所示，YARN 的工作流程分为以下 几个步骤：
步骤 1 用户向 YARN 中提交应用程序，其中包括 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序等。
步骤 2 ResourceManager 为该应用程序分配第一个 Container，并与对应的 NodeManager 通信，要求它在这个 Container 中启动应用程序的 ApplicationMaster。
步骤 3 ApplicationMaster 首先向 ResourceManager 注册，这样，用户可以直接通过 ResourceManage 查看应用程序的运行状态，然后，它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤 4~7。
步骤 4 ApplicationMaster 采用轮询的方式通过 RPC 协议向 ResourceManager 申请和领取资源。
步骤 5 一旦 ApplicationMaster 申请到资源后，则与对应的 NodeManager 通信，要求其启动任务。
步骤 6 NodeManager 为任务设置好运行环境（包括环境变量、jar 包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
步骤 7 各个任务通过某个 RPC 协议向 ApplicationMaster 汇报自己的状态和进度，以让 ApplicationMaster 随时掌握各个任务的运行 状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过 RPC 向 ApplicationMaster 查询应用程序的当前运行状 态。
步骤 8 应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销，并关闭自己。
关于如何实现 MRv1 和 Yarn 对比就分享到这里啦，希望上述内容能够让大家有所提升。如果想要学习更多知识，请大家多多留意丸趣 TV 小编的更新。谢谢大家关注一下丸趣 TV 网站！
