CN103064728A

CN103064728A - 一种MapReduce任务的容错调度方法

Info

Publication number: CN103064728A
Application number: CN2012105358926A
Authority: CN
Inventors: 刘扬; 魏蔚; 王珂; 杨卫东; 刘灿
Original assignee: Henan University of Technology
Current assignee: Henan University of Technology
Priority date: 2012-12-13
Filing date: 2012-12-13
Publication date: 2013-04-24

Abstract

本发明涉及云计算环境中并行任务的调度处理方法，公开一种针对MapReduce作业的容错调度方法，以提高MapReduce作业的整体性能，减少节点失效时的作业延迟。本发明结合检查点和主动复制两种技术，在Mapper任务执行时创建本地检查点和索引检查点两种检查点，当任务发生失效时，本地检查点能够将出错任务的状态和执行恢复到检查点处，减少了任务的重复执行时间；当发生节点失效时，副本节点能够根据索引检查点快速构造出失效节点上执行的mapper任务的中间结果数据，大大减少了重调度任务的执行时间。实验结果表明该方法能够比Hadoop的运行时性能提高30%以上，同时并不明显增加系统的存储和网络开销。

Description

一种MapReduce任务的容错调度方法

技术领域

本发明涉及到云计算环境中并行任务调度方法，是一种结合检查点和主动复制的MapReduce任务的容错调度方法。

背景技术

云环境中，节点和任务失效不再是个意外，而成为大规模系统的特征。LADIS 2009大会发布数据显示，一个集群每年会有1%~5%的硬盘会报废，20个机架和3个路由器会宕机一次，服务器每年会平均宕机两次，报废几率在2%~4%。即使对于一个由1万个超级可靠的服务器（MTBF为30年）组成的分布式系统，每天也都会发生失效问题。因此，对于由大量廉价计算机所组成的云环境而言，由各种故障带来的节点和任务失效成为更频繁和普遍的问题，必须视失败为常态，系统必须提供有效的容错方法。

MapReduce提供了一种以大规模并行处理模式来处理数据密集型任务的编程模型。在Google公司内部，通过大规模集群和MapReduce软件，每天有超过20PB的数据得到处理，每个月处理的数据量超过400PB。Yahoo公司实现了基于MapReduce的开源版本Hadoop，Facebook每天用它来处理数据导入、提交时报等任务，Amazon公司采用弹性MapReduce来处理大量的数据密集型任务。MapReduce由于它的易于编程、数据分布和容错等特性而受到越来越多的关注和应用。

Google在2006年的研究报告中指出，在一个平均由268个工作节点组成的计算环境中，每一个MapReduce作业都伴随着5个工作节点的失效。MapReduce采用了一种基于重调度执行（re-schedule）的容错机制来确保失效任务的正确执行，但是系统在重调度失效任务时，未能充分考虑任务的数据分布、重调度失效任务的性能开销延迟，因而常常一个简单的节点失效就会导致作业的整体完成时间延长50%。而对于一个采用了MapReduce计算模型的查询任务而言，如果每个输入数据片段中包含一个错误记录，将会导致整个MapReduce作业增加100%的运行时间开销，这对于SLA需求较高的应用是不能接受的，因而需要采用更加优化的容错调度算法来减少由于系统故障或错误所带来的时间延迟。

发明内容

本发明采用基于检查点的主动复制方法进行任务的容错调度CROFT(Checkpoint and Replication Oriented Fault Tolerant scheduling algorithm)，对任务失效和节点失效均有较好的容错支持，并且能明显减少节点失效时的作业延迟，从而提高Mapreduce作业的性能。算法分为两个部分，分别为运行master节点上的worker节点上，默认前提是：首先，master节点会将所有的mapper任务和reducer任务进行预分配。另外，master节点地位重要且数目较少，通过为其维护多个完全一致的“热备份”，可以保证故障发生时的无缝处理。

每个计算节点在执行每个Mapper任务前，会为该任务创建一个本地local检查点文件和一个全局索引index检查点文件。本地local检查点文件负责记录当前任务的执行进度，从而能够在任务失效情况下避免重复执行过程。而全局索引index检查点文件负责记录当前任务的执行特征，从而能够在节点失效情况下根据快速构造出中间结果数据，减少任务的再执行时间。

该算法可明显减少作业的平均完成时间，算法会将发生失效节点上的任务重新调度到可用的副本工作节点(worker)上，但是与传统的MapReduce容错方法不同，失效节点上任务不会从头重新执行，而是将任务调度到可用的副本worker节点上，新的节点会根据检查点文件快速构造出中间结果数据。通过实验验证了算法的有效性，CROFT能够比Hadoop的运行时性能提升30%以上。支持容错的MapReduce任务调度算法如算法1和算法2所示。

支持容错的任务调度算法如算法1和算法2所示。

当发生任务失效时，只需读取保存在本地的检查点文件，将出错任务的状态和执行恢复到检查点处，减少了任务的重复执行时间。这样，这些中间结果就像被重新调度的mapper任务刚刚输出一样。

当发生节点失效时，master节点上的调度器负责将失效节点上被中断的mapper任务进行排队，在对任务进行重调度时，mapper任务会被重新调度到可用的副本节点上执行，副本节点能够根据索引检查点快速构造出失效节点上执行的mapper任务的中间结果数据，大大减少了重调度任务的执行时间。

如果失效节点上有正在执行的reducer任务被中断，那么将该reducer任务重新调度到备份节点上进行执行，已经完成的mapper任务所产生的中间结果已经主动复制到该备份节点，因而无须再重复执行失效节点上的mapper任务，因而会大大缩短Mapreduce作业的整体完成时间。

附图说明

图1 任务失效场景下作业完成时间比较

图2 节点失效场景下作业完成时间对比

图3 任务和节点均失效场景下作业完成时间对比

图4 节点失效场景下网络平均开销对比

图5 节点失效场景下平均存储开销对比

具体实施方式

我们通过部署Hadoop来进行算法验证，从延迟和开销来考察算法在节点和任务失效情况下的性能。延迟是影响用户体验的一个非常重要的因素，追求低延迟是大规模云环境中部署应用的重要指标。算法的原型实现是在Hadoop 0.20.1上，运行在Java1.6和HDFS文件系统，HDFS的数据块大小为256MB。实验是在一个具有20个节点的HP刀片集群上进行的，节点具有四核的Xeon 2.6GHz CPU，8G内存，320G硬盘，具有2个Gigabit网卡。节点运行Ubuntu Linux操作系统，并配置4个Xen虚拟机，这样将部署出80个虚拟节点，分别组成40个节点构成的hadoop集群，和40节点组成的本系统集群，其中一个节点部署成master节点，其余节点部署成worker节点。目前一个集群中拥有39个虚拟化的worker节点，单个worker节点能同时运行2个mapper任务和1个reducer任务。实验用作业是典型的过滤型任务，在海量数据中过滤出特定词条，该类任务计算量大，中间结果较少。所用测试数据为120万个全英文网页，网页平均尺寸为1MB, 通过调整split大小，一个mapper任务平均处理约120M的输入split数据，每个节点平均分到约250个任务。

MapRuduce作业是针对这组html页面的查询任务，包括三种作业类型，分别是查询词密集型任务、稀疏型任务和混合型任务。查询词密集型任务中，被查询词在目标数据中的位置比较集中；稀疏型任务中，被查询词的位置较为分散；而在混合型任务中，被查询词的位置同时具上述两种特征。

图1比较了在Mapper任务失效情况下，本算法原型和Hadoop的执行性能比较。横坐标是任务出错概率，以每100个任务的出错个数表示，纵坐标是MapReduce作业执行总时间。任务失败次数没有限制，我们可以看到，在有CROFT情况下，随着出错概率增加，作业的执行时间会有所增加，但作业完成时间相比Hadoop而言会有明显改善，总体时间优于Hadoop性能。

图2对比了在不同失效节点数量下MapReduce作业的执行时间。横坐标是失效节点数量，纵坐标是MapReduce作业执行总时间。当发生节点出错，即将该节点标记为失效，从集群中移出。实验结果发现，随着失效节点的增多，CROFT算法会显著缩短mapper任务的再执行时间，因为Hadoop简单的重调度机制会将失效节点的大量mapper任务在备份节点上重新调度执行，推迟了中间结果数据的Shuffle和reduce阶段的开始，而CROFT能够在相同时间内能完成更多的任务，会比Hadoop节约更多的时间，因而达到了比Hadoop原始机制好得多的效果。

图3比较了单个MapReduce作业的执行时间，横坐标是每100个任务出错概率和工作节点的出错概率，分别以每100个任务的出错个数和每100个节点的失效节点个数表示；纵坐标是MapReduce作业的执行完成总时间。节点出错即标记为失效，从集群中移出。实验结果显示，CROFT在有错的情况下，能缩短任务完成时间，且随着失败概率增加，能完成更多的任务。

图4是CROFT的网络开销情况，显示在节点失效场景下，重新调度MapReduce作业时，CROFT所产生的额外网络开销。横坐标是失效节点数量，纵坐标是平均网络开销。我们可以看到，在节点失效情况下，所产生的网络开销主要来自于全局index文件的主动复制，相较于Hadoop中间结果数据复制所产生的网络开销而言，该网络开销是相当有限的。

图5显示了在有20个节点失效的场景下，对三种不同类型的MapReduce作业，CROFT与Hadoop的存储开销对比情况。我们可以看到，CROFT所增加的存储开销主要用于存储全局索引文件，与Hadoop的中间结果数据存储开销相比较而言，所引入的额外存储开销非常有限。

Claims

1.一种支持容错的MapReduce任务调度算法，其特征在于：算法分为两个部分，分别为运行master节点和worker节点上。

2.master节点会将所有的mapper任务和reducer任务进行预分配。

3.master节点周期性地发送探测消息，以检测worker节点的状态，判断是否有worker节点发生故障或失效。

4.每个worker节点会具有k个副本节点。

5.worker节点会为每个mapper任务创建一个本地(local)检查点文件和一个全局索引(index)检查点文件。

6.当mapper任务内存缓冲区充满时，启动一次中间结果保存操作，将中间结果数据缓存到本地文件系统；缓存完成后，将输入流的读写位置和本次任务ID(position_i, map_id) 记录到local检查点文件中。

7.当mapper完成中间结果保存时，根据输入流产生key-value输出的稀疏情况，选择下述两种方法之一，将任务执行过程中的统计信息，记录到全局index检查点文件中。

8.针对产生输出的输入流，记录输入流产生key-value对的offset位置 (T₁,offset)到全局index文件中，在副本节点上执行时可以直接从该offset处开始。

9.针对无输出的输入流范围，一条记录格式为(T₂,offset_s,offset_e)，offset_s为该输入流范围的起始偏移，offset_e为结束偏移，表示输入流在offset_s,和offset_e之间没有输出，当在副本节点上重新执行时可直接跳过该范围。

10.当发生任务失效时，只需读取保存在本地的检查点文件，将出错任务的状态和执行恢复到检查点处，当发生节点失效时，失效节点上的mapper任务会被重新调度到可用的副本节点上执行，副本节点能够根据索引检查点快速构造出失效节点上执行的mapper任务的中间结果数据，大大减少了重调度任务的执行时间。