Hadoop学习笔记 - 04MapReduce调度原理

胖DA
409 阅读4分钟

写在前面： 本篇文章由介绍MapReduce调度原理开始，引出Hadoop1.x版本中MapReduce运行架构的弊端，最后介绍Hadoop2.x以后MapReduce on Yarn模式的架构原理。解释大数据的一个基本问题：计算向数据移动如何实现。

MapReduce架构

MapReduce采用Master/Slave架构，Master为JobTracker，Slave为TaskTracker。

JobTracker主要功能包括：

  • 资源管理
  • 任务调度

TaskTracker主要功能包括：

  • 任务管理
  • 资源汇报

MapReduce架构中除了JobTracker和TaskTracker，还有客户端client。

MapReduce执行过程

hadoop1.x调度原理.png

client执行过程

  1. client根据每次的计算数据，咨询NameNode获取元数据，也就是block信息。随后得到split清单，即这次计算的数据共有多少split（map的数量）。split清单中包含了block的offset范围以及位置信息，知道这些信息后就可以支持计算向数据移动了，但是client还没有和TaskTracker进行联系，所以并不知道将MapTask运行在哪个节点；
  2. client生成计算程序未来运行时的相关配置文件xml（比如配置这个计算程序，可以使用多大的堆栈内存等）；
  3. 未来的移动应该相对可靠，client会将jar包、split清单和配置文件上传到HDFS的目录中；
  4. 调用JobTracker并通知启动一个计算程序，告知文件存放在HDFS的位置。

JobTracker处理流程

  1. 接收client请求后，从HDFS取回split清单；
  2. 根据自己收到的TaskTracker汇报的资源，确定每一个split对应的map应该发送至哪个节点，即确定清单；
  3. 未来Tasktracker在心跳的时候取回自己的任务信息，确定跑哪些MapTask。

TaskTracker处理流程

  1. Tasktracker在心跳的时候取回自己的任务信息，确定跑哪些MapTask；
  2. 从HDFS中下载jar包、配置文件到本机；
  3. 最终启动任务描述中的MapTask或ReduceTask；

最终，代码在某一个节点被启动，是通过client上传，TaskTracker下载，完成了计算向数据移动的过程。

JobTracker的问题

  1. 主从架构存在单点故障问题
  2. 主从架构会导致压力过大问题，可能会导致JVM full gc、调度延迟等问题
  3. 集成资源管理和任务调度两大功能，存在功能耦合的问题，未来新的计算框架无法复用资源管理。

为了解决以上问题，Hadoop 2.x使用MapReduce on Yarn的方式解决了以上问题。

MapReduce on Yarn

Yarn简单介绍

yarn架构.gif

Yarn是一个资源管理、任务调度的框架，主要包含三大模块：ResourceManager（RM）、 NodeManager（NM）、ApplicationMaster（AM）。

  • ResourceManager 负责所有资源的监控、分配和管理；
  • ApplicationMaster负责每一个具体应用程序的调度和协调；
  • NodeManager负责每一个节点的维护，向ResourceManager汇报心跳，提交资源情况。

对于所有的applications，ResourceManager拥有绝对的控制权和对资源的分配权。而每个ApplicationMaster则会和ResourceManager协商资源，同时和NodeManager通信来执行和监控 task。

关于Container，它可以是虚拟的也可以是物理的。

  • 虚拟的：因为Container在没运行成为一个JVM进程前，包含了客户端所定义的属性，比如cpu，内存，io量等。所以此时只是概念层次，并没有变现跑起来，是虚拟的。
  • 物理的：可以是JVM进程，并且监控资源的方式有三种：
    1. NodeManager会有线程监控Container资源，若超额，则NodeManager直接kill掉进程
    2. 使用cgroup内核级的技术，在启动jvm进程时由kernel约束死资源
    3. 整合docker

MapReduce on Yarn运行流程

  1. MapReduce的client启动后，上传split清单、配置、jar包到HDFS。client访问ResourceManager申请ApplicationMasater
  2. ResourceManager选择一台不忙的NodeManager，启动一个Container，在里面反射一个MapReduce的ApplicationMasater
  3. ApplicationMasater从HDFS下载切片清单，向ResourceManager申请资源
  4. ResourceManager根据掌握的资源情况，得到一个确定清单，通知NodeManager来启动Container
  5. Container启动后，反向注册到已经启动的MapReduce的ApplicationMasater进程，
  6. ApplicationMasater相当于JobTracker（少了资源管理功能），最终将任务发送给Container，根据发送的是消息来启动map/reduce
  7. Container反射相应的task类为对象，调用方法执行，其结果就是业务代码
  8. 利用Yarn的失败重试的机制保证容错率

结论

  1. 单点故障：Jobtracker是全局的，如果宕机了，那么整个计算层无法调度任务

使用Yarn之后，每个MapReduce应用程序都有自己的ApplicationMasater调度程序，拥有计算程序级别的调度，而不是全局的。且支持ApplicationMasater失败重试

  1. 压力过大

使用Yarn之后，每个计算程序自由ApplicationMasater，每个ApplicationMasater只负责自己计算程序的任务调度，相比之前更加轻量了。且ApplicationMasaters是在不同的NodeManager中启动，默认有了负载的功能

  1. 资源管理和任务调度两者耦合

Yarn只是资源管理，不负责任务调度。且无论是什么计算框架，只要继承了Yarn的ApplicationMasater，都可以使用一个统一的资源管理机制

avatar
文章
阅读
粉丝