简要描述hadoop的心跳机制

转载

mob64ca13fe1aa6 2024-11-07 14:14:06

文章标签 简要描述hadoop的心跳机制 hadoop yarn mapreduce 框架 文章分类 Hadoop 大数据

YARN（Yet Another Resource Negotiator）该框架已经不再是一个传统的MapReduce框架，甚至与MapReduce无关，是一个通用的运行时框架，用户可以编写自己的计算框架，在该运行环境中运行。用户自己编写的框架作为客户端的一个lib，在运用提交作业时打包即可。

为啥要开发YARN？那么MR存在哪些缺点和不足？

经典 MapReduce 的最严重的限制主要关系到可伸缩性、资源利用和对与 MapReduce 不同的工作负载的支持。在 MapReduce 框架中，作业执行受两种类型的进程控制：

一个称为 JobTracker 的主要进程，它协调在集群上运行的所有作业，分配要在 TaskTracker 上运行的 map 和reduce 任务。
许多称为 TaskTracker 的下级进程，它们运行分配的任务并定期向 JobTracker 报告进度。

大型的 Hadoop 集群显现出了由单个 JobTracker 导致的可伸缩性瓶颈。

此外，较小和较大的 Hadoop 集群都从未最高效地使用他们的计算资源。在 Hadoop MapReduce中，每个从属节点上的计算资源由集群管理员分解为固定数量的 map 和 reduce slot，这些 slot 不可替代。设定 map slot 和 reduce slot 的数量后，节点在任何时刻都不能运行比 map slot 更多的 map 任务，即使没有 reduce任务在运行。这影响了集群的利用率，因为在所有 map slot 都被使用（而且我们还需要更多）时，我们无法使用任何 reduce slot，即使它们可用，反之亦然。

Hadoop 设计为仅运行 MapReduce 作业。随着替代性的编程模型（比如 Apache Giraph 所提供的图形处理）的到来，除 MapReduce 外，越来越需要为可通过高效的、公平的方式在同一个集群上运行并共享资源的其他编程模型提供支持。

原MapReduce框架的不足

JobTracker是集群事务的集中处理点，存在单点故障
JobTracker需要完成的任务太多，既要维护job的状态又要维护job的task的状态，造成过多的资源消耗
在taskTracker端，用map/reduce task作为资源的表示过于简单，没有考虑到CPU、内存等资源情况，当把两个需要消耗大内存的task调度到一起，很容易出现OOM
把资源强制划分为map/reduce slot,当只有map task时，reduce slot不能用；当只有reduce task时，map slot不能用，容易造成资源利用不足。

解决可伸缩性问题

在 Hadoop MapReduce 中，JobTracker 具有两种不同的职责：

管理集群中的计算资源，这涉及到维护活动节点列表、可用和占用的 map 和 reduce slots 列表，以及依据所选的调度策略将可用slots 分配给合适的作业和任务
协调在集群上运行的所有任务，这涉及到指导 TaskTracker 启动 map 和 reduce任务，监视任务的执行，重新启动失败的任务，推测性地运行缓慢的任务，计算作业计数器值的总和，等等

为单个进程安排大量职责会导致重大的可伸缩性问题，尤其是在较大的集群上，JobTracker 必须不断跟踪数千个TaskTracker、数百个作业，以及数万个 map 和 reduce 任务。相反，TaskTracker通常近运行十来个任务，这些任务由勤勉的 JobTracker 分配给它们。

为了解决可伸缩性问题，一个简单而又绝妙的想法应运而生：减少单个 JobTracker 的职责，将部分职责委派给 TaskTracker，因为集群中有许多 TaskTracker。在新设计中，这个概念通过将 JobTracker 的双重职责（集群资源管理和任务协调）分开为两种不同类型的进程来反映。

这样的设计使得系统有一个全局的资源管理器和以及每个程序有一个应用程序管理器（Application Master）

Application：不是job。在Hadoop2.X中，一个程序可以指传统概念上的一个单独的MR作业，也可以是一系列作业组成的有向无环图（DAG，Spark的作业处理方式）
DAG是一个由许多节点相连构成的图，图中没有循环。多个作业组成了DAG意味着这些作业之间存在这层属关系

经过重新设计的新框架可以使得整个Hadoop系统对其提供一支的原生支持。这使得关于安全和资源管理的系统级策略能以一致的方式应用，所有系统都能共享相同的底层HDFS。

YARN系统由以下几个部分组成：

全局资源管理器（Global Resource Manager）
节点管理器（Node Manager）
针对每个应用程序的应用程序管理器（Application-specific Application Master）
调度器（Scheduler）
容器（Container）

一部分CPU和内存构成一个Container，一个Application运行在一组Container中
Application Master的一个实例会像Global Resource Manager请求获取资源
Scheduler会通过Node Manager来分配资源（Container）
Node Manager会像Global Resource Manager汇报每个Container的使用情况

YARN 的优点

更快地MapReduce计算
对多框架支持
框架升级更容易

简要描述hadoop的心跳机制_yarn

图中的client可以提交任何YARN支持的类型的程序

ResourceManager 代替集群管理器，它的核心是Scheduler（Hadoop自带计算能力调度器和公平调度器）当多个App竞争使用集群资源的时候，它负责分配调度，确保集群资源的优化合理使用。追踪活着的的NM和可用的资源，定位可用资源分配给app和task，并且监控App Master
ApplicationMaster 代替一个专用且短暂的 JobTracker，这是1.0和2.0的一个关键区别，调整所有任务在应用程序中的执行，请求适当的资源来运行任务，它通过和RM协商沟通资源，并通过NM获得这些资源，然后执行任务

App Master为YARN带来的的好处：
1、提高扩展性
2、框架更通用
3、带来的一个最大的好处就是，Hadoop系统现在不仅支持MR类型的计算，它并的插件化，如果系统要增加某种类型的计算框架，就开发一个对于的App Master，并把这个App Master以插件的形式整合到Hadoop系统中

NodeManager 代替 TaskTracker，它运行在集群中的一个节点上，集群中的每个节点都会运行一个自己的节点管理器。以容器的形式分配计算资源，管理在container中运行的进程，并像ResourceManager汇报资源使用情况

NodeManager的主要任务：
1、接受RM的请求，为作业分配Container
2、与RM交换信息，保证集群稳定运行
3、管理已启动的容器的生命周期
4、管理节点日志
5、运行各种YARN应用程序的辅助服务（auxiliary service，在yarn-site.xml中需要设置这个属性，一般为MR程序设置shuffle服务）
NM只对抽象出来的Container进行管理，而对单个APP一无所知，这部分是App Master负责的

Container是YARN框架中的计算单元，是一个任务进行工作的单元子系统。可以运行不同类型的任务，也可以运行App Master，每一个容器都有不同规模的内存和cpu【集群、节点和容器的关系：一个节点可以运行多个容器，但是一个容器只能运行在一个节点内】
一个分布式应用程序代替一个 MapReduce 作业

一个Global Resource Manager主要以后台进程的形式运行，它通常在专用机器上运行，在各种竞争的应用程序之间仲裁可用的集群资源。

在用户提交一个应用程序时，一个称为 ApplicationMaster 的轻量型进程实例会启动来协调应用程序内的所有任务的执行。这包括监视任务，重新启动失败的任务，推测性地运行缓慢的任务，以及计算应用程序计数器值的总和。有趣的是，ApplicationMaster 可在容器内运行任何类型的任务。

NodeManager 是 TaskTracker 的一种更加普通和高效的版本。没有固定数量的 map 和 reduce slots，NodeManager 拥有许多动态创建的资源容器。