MapReduce任务调度和资源管理
MapReduce任务调度和资源管理
MapReduce任务调度和资源管理主要的目的是解决如何去选择一个合适的节点去执行 Task。一个集群里有很多台机器，每台机器都拥有各自的资源，如剩余内存量，核数，网络带宽，磁盘容量等。资源管理者必须要知道这些节点的可用资源才能对任务进行合理分配调度，那么MapReduce是如何进行任务调度的呢？这就涉及到MapReduce的任务调度模型了。
在MapReduec任务调度模型中，主要包含以下几个角色：
- JobClient:接收客户端提交的程序jar包，并进行一系列的操作，具体会在下面进行详细分析。
- JobTracker:负责接收
JobTracker分配的作业，将Task分配到各个节点上去运行，并提供诸如监控工作节点状态及任务进度等管理功能，一个MapReduce集群只有一个jobtracker。 - TaskTracker:负责监控任务的执行情况，并通过心跳连接周期性地向
jobtracker汇报任务进度，资源使用量等。每台执行任务的节点都会有一个TaskTracker，其使用“slot”等量划分本节点上的资源量。“slot”代表计算资源（CPU、内存等）。一个Task 获取到一个slot 后才有机会运行，slot 分为Map slot和Reduce slot两种，分别供MapTask 和Reduce Task 使用。TaskTracker通过slot 数目（可配置参数）限定Task 的并发度。 - HDFS:用于提供数据存储服务和和作业间的文件共享。
JobClient进行了哪些操作？
JobClient作为MapReduec任务调度模型最重要的模块，其承担了很多工作，主要工作如下：
-
获取Block元数据信息并计算切片(Job.Split)
我们知道，数据是存储在HDFS上的，所以每当要执行计算任务时，JobClient都会去找NameNode获取需要计算的Block块的元数据，假设这个Block块有10个副本，那么就会返回这10个副本所在的节点位置并计算切片，切片大小默认是block块的大小，我们可以自定义这个split的大小。最终得到了一个切片【清单】，这个清单描述了这批数据总共切成了多少个切片，而这个切片数量又决定了map的数量。此外，切片中包含了偏移量offset，以及从block块中获取到的location，这个location决定了切片对应的map任务应该迁移到哪些节点(即得到了可以执行这些任务的候选节点)上去运行，这样就实现了计算向数据移动。 -
生成计算程序未来运行时的相关【配置文件】(Job.xml)
这个配置文件中包含了各种运行时配置，如运行时需要的内存大小，磁盘大小，序列化、反序列化需要的类等等，就像我们日常开发时所需要的Properties文件一样。 -
将jar包、job.split、job.xml文件上传到HDFS
为保证未来计算向数据移动的可靠性，JobClient会将计算程序的jar包、job.spllit以及job.xml上传到HDFS组成一个【任务清单】，未来哪个节点需要进行计算时，TaskTracker就会将这些文件从HDFS中下载到本地节点。 -
调用JobTracker执行计算任务，并告知数据文件放在HDFS的哪些位置
JobClient告诉JobTracker【任务清单】放在HDFS的哪个位置，最终做决策的是JobTracker，因为只有JobTracker才知道各个DataNode的状态，下面举例说明JobTracker的决策过程，假设数据block块有3个副本，分别存放在A,B,C 3台DataNode上，JobTracker首先会查看这些DataNode是否有足够的资源供任务的执行，假设A,B有足够的资源进行计算，那么JobTracker会挑选距离【任务清单】最近的节点分配任务，如果3台DataNode都没有足够的资源进行计算，那么就会挑选3台中一台的机架上的一台DataNode进行任务分配，数据会通过网络传输拉取到那台DataNode
JobTracker进行了哪些操作
- 从
HDFS中取回【任务清单】 - 根据自己收到的
TaskTracker汇报的资源，确定每一个split对应的map应该去到哪一个节点。 TaskTracker在向JobTracker汇报心跳的时候，会向JobTracker询问是否有属于它的计算任务，如果有，就从JobTracker中取回属于它的MapTask。
TaskTracker进行了哪些操作
- 在心跳连接的过程中取回属于它的MapTask。
- 从
HDFS中下载【任务清单】到本机(用户编写的jar包，job.split，job.xml) - 最终启动任务描述中的MapTask/ReduceTask。
这个资源管理和任务调度模型产生的问题
- 单点故障：单点故障是所有主从模型都面临的问题，
JobTracker只有一个，一旦挂了，那么整个计算任务就会失败。 - 压力过大：
JobTracker既要进行任务调度又要进行资源管理，如果有多个JobClient向JobTracker提交任务，那么JobTracker就会比较忙，可能导致无法及时处理那么多任务。 - 框架无法复用，资源争抢：如果要执行不同类型的计算任务，那么就得实现新的框架，新的框架必须自己重新实现资源管理和任务调度功能(重复造轮子)，又因为这两套框架是隔离的，互相无法感知到，就可能造成资源争抢。
总结
MapReduce任务调度和资源管理框架解决了一些问题，但是又引入了新的问题，为了解决这些问题，在MapReduce2.0中，引入YARN作为任务调度的框架，关于YARN的理论基础可用参考YARN理论基础。
