Hadoop中作业调度算法的研究与改进文档格式.docx

Hadoop中作业调度算法的研究与改进文档格式.docx

《Hadoop中作业调度算法的研究与改进文档格式.docx》由会员分享，可在线阅读，更多相关《Hadoop中作业调度算法的研究与改进文档格式.docx（37页珍藏版）》请在冰豆网上搜索。

ABSTRACT

Inrecentyears,anworld-widerevolutionhastakenplaceintheInternetareaafterGoogleproposedtothepublictheMapReducedistributedcomputingframework.AstheopensourceimplementationforMapReduce,HadoopdistributedsystemhasbeenusedinpracticewidelythroughoutmajorInternetcompanieshomeandabroad.Especially,themulti-usersharedclustersceneisoneofHadoop’stypicalapplicationcontexts.AndthekeytothemaximizationofthedistributedcomputingadvantageistheactualperformanceofthejobschedulerunderHadoop.Inotherwords,everythingwillbeokifthejobschedulercouldpromotethewholeclusterthroughputwhileensuringthejobschedulingfairness.

AllthecurrentjobschedulersunderHadoopareline-based,theessenceofwhichisagreedyalgorithm.Itmakesjobschedulingdecisionverycurtlyinaimofthemaximizationfortasklocalityexecuting,whenonlygraspingsomelocalinformationaboutthesharedcluster.Thewholeclusterthroughputwouldusuallybeconsumedinexcessivepursuitoftasklocalityexecuting.Thispaperbringsthe“min-costflowgraph”conceptintothejobschedulermechanismunderHadoop,proposesthe“min-costflow”basedjobschedulingalgorithm,andmakesadetailedtheoryresearchonhowtomodelasaflowgraphthejobschedulingprocessuponamulti-usersharedclusterinaimofovercomingshortcutsofline-basedgreedyalgorithm.Furthermore,thispaperalsoimplementsa“min-costflow”basedjobschedulersystemupontheHadoopdistributedcomputingplatformonthebasisoftheorymodeling.

Bydeployingcomparativeexperimentsbetweenthe“min-costflow”basedjobschedulerandHadoop’sexistingjobscheduler,itisprovedthat“min-costflow”basedjobschedulingalgorithmindeedimprovethewholeclusterthroughputefficientlywhileofferingtheguaranteeforthejobschedulingfairnessundermulti-usersharedclusterenvironment.

KEYWORDS:

jobscheduler,MapReduce,line-based,Hadoop,min-costflow

第一章绪论

1.1.课题背景及意义

自从Google的工程师们发表了《MapReduce:

SimplifiedDataProcessingonLargeClusters》之后[1]，MapReduce就日趋火爆，逐渐成为当今互联网领域的新宠，被越来越多的人关注和研究。

作为一个分布式计算框架，MapReduce可以将与当今互联网上最火的应用——搜索引擎相关的各种应用，诸如网页爬虫、日志处理、文本分析等[2]进行并行化处理，从而大大提高了应用处理效率，进一步激发出了各种网络应用处理客户请求的潜力，深远的影响了整个互联网领域。

Apache软件基金资助的开源项目Hadoop[3]，作为Google提出的Mapreduce框架的开源实现，一经问世，便受到各大互联网公司的青睐，并被迅速部署到各自的服务器集群上，成为除Google的MapReduce平台之外互联网上分布式计算平台的主流[4]。

Hadoop可以对用户屏蔽分布式系统的底层细节，用户只需通过api简单调用就可以使用分布式系统提供的各种服务。

这就使得用户可以从具体的分布式操作中解脱出来，并完全专注于自身应用的实现。

Hadoop实现了一个分布式文件系统（HadoopDistributedFileSystem），简称HDFS。

HDFS具有很高的容错能力。

其设计初衷就是要在廉价硬件上进行部署。

而且它可以为应用程序的数据访问提供高传输速率，使得它特别适合运行需要处理大规模数据的应用程序。

此外，HDFS还放宽了对POSIX标准的要求，使得用户可以以流的形式对HDFS中的数据进行访问。

[5]

多用户共享式集群是Hadoop系统部署应用的典型场景。

与非共享式集群相比，多用户共享式集群有以下两个优点：

一方面，多用户共享式集群可以使用廉价服务器（commoditycomputer）进行架构[6]，通过在其上部署Hadoop[7]，可以有效的整合集群资源，较大限度的发挥集群整体性能，实现“1+1>

2”的效果；

另一方面，通过Hadoop实现多用户共享式集群，可以使企业不必为各个业务独立的部门专门建立私有集群系统，既节省了大笔投入公司基础设施建设的开支，又能提高整个企业的集群资源管理效率[8]。

因此，很多互联网公司纷纷对公司原有基础设施进行改造，架设Hadoop多用户共享式集群，以适应互联网领域瞬息万变的发展形势。

虽然多用户共享式集群在实际应用中具有明显的成本优势，但它同时也有着与生俱来的问题，那就是集群管理的复杂性。

比如，有些与公司出售的信息服务有关的日常性生产作业需要长时间的占用集群资源，而且要保证它们能够得到足够的集群资源以支持其正常运行；

但同时，一些随机性质的adhoc类小规模作业需要能得到及时响应，而不能被大作业长时间阻塞，否则这类作业就失去了存在的意义。

除此之外，在保证不同用户服务质量的同时，如何保证整个集群的吞吐效率，也是一个很难两全的问题[9]。

这其中，作业调度策略对于保证用户作业服务质量和维护集群整体吞吐量起着至关重要的作用[10]。

所谓作业调度算法，就是将集群中的共享资源分配给未完成作业的任务执行使用的策略。

其算法目标是要在多用户共享式集群环境下均衡实现作业调度过程的公平性和共享集群整体吞吐效率的最大化。

具体到实现时，作业大小以及作业的类型（如计算密集型或数据密集型）都是必须考虑的因素。

针对Hadoop分布式系统，先后有多种不同的作业调度器出现，比如FIFO调度器、HOD调度器、公平调度器等。

每种调度算法都有其一定适用性，但面对同时处理生产型的大作业、机器学习型计算、即席查询混合的集群，其局限性愈加突出。

在多用户共享式集群环境下，需要找到一种调度策略，使得它既能充分利用集群资源、合理调度作业并串行执行序列，从而最大限度的挖掘共享集群的整体吞吐效率；

又能兼顾公平，使提交的作业无论大小都能得到及时响应，并保证企业的日常生产性作业无论何时都能够得到足够的资源，确保企业日常业务的正常运转不受影响。

作业调度策略是诸如像Hadoop这样的分布式计算系统下的关键技术之一，也是本文的研究对象。

1.2.研究现状

Hadoop分布式系统中的作业调度策略通过Hadoop下的作业调度器实现。

Hadoop中有多种作业调度器，包括FIFO调度器，HOD调度器、公平调度器（FairScheduler）等。

其中FIFO是Hadoop的默认调度器，而公平调度器则是由Facebook的工作人员开发实现并免费贡献给Apache软件基金会的。

1.2.1.FIFO（FirstInFirstOut）调度

Hadoop默认的调度策略是带有优先级的FIFO（FirstInFirstOut）。

在FIFO下，所有已提交的作业不论属于哪个用户，都被提交到一个全局唯一的队列中。

FIFO按照作业优先级的高低以及提交时间的先后，对队列中的作业进行排序。

当集群中有空闲资源时，FIFO将把资源分配给排在队列头部的作业使用。

FIFO的实现很简单，并且其自身运行调度的开销也较少。

但它有个致命的缺陷，那就是当集群中有大作业存在的时候，小作业的响应时间将会变得异常糟糕。

比如那些交互性质的小作业，它们的交互性将会因长时间得不到响应而变得难以容忍。

大小作业共存的情况在共享集群中是经常出现的。

在Hadoop中这个问题的第一个解决方案是HOD（HadoopOnDemand）。

1.2.2.HOD（HadoopOnDemand）调度

HOD使用TORQUE管理器对共享集群的资源进行管理。

通过TORQUE，HOD能够把一个共享集群划分成多个独立的集群实例。

每个集群实例包括一个MapReduce实例和一个HDFS实例。

用户在HOD下可以根据需要定制集群实例，并独享集群实例中的所有资源[11]。

相比于FIFO，HOD很好的改善了小作业的响应时间性能。

但其在系统设计上却也存在无法克服的本质性弊端：

首先在HOD下，作业任务的本地性执行性能通常都比较差。

因为HDFS中的数据文件是以数据块（block）的形式分散存储在组成集群的各个节点之上的，而那些由TORQUE划分出来的独立集群实例却需要运行在固定的节点集合中。

这就导致在实际运行中，会有很多作业任务由于其执行所需数据不在自身集群实例的节点上而需要通过共享集群的网络来读取数据，从而严重影响自身作业的响应时间和整个集群的吞吐效率；

其次在HOD下，共享集群资源的整体利用率通常都很低。

同样是因为HOD把每个用户的活动范围都局限在一个个独立且固定不变的集群实例中，使得某些集群实例可能存在空闲资源而某些集群实例却有作业任务挂起等待[12]。

1.2.3.公平调度器（FairScheduler）

Facebook提出了公平调度器（FairScheduler）[13]。

公平调度器以“作业池”作为分配资源的基本单位，并使用“公平调度算法”（fairscheduling）在作业池间分配资源。

保证共享资源分配的公平性是其第一要务。

如果集群中只有一个池的话，那么这个池的作业将独享整个集群资源。

当集群中存在多个作业池时，公平调度器会按照默认或自定义的作业池权重，等比例的分配共享集群资源。

这样的话，每个作业池就都能得到与自身权重值成正比的、相对公平的资源份额。

此外，公平调度器还为每个作业池设置了一个“最小资源配额”（minshare）。

当作业池所需资源的数量大于其“最小资源配额”时，公平调度器会使作业池至少获得其“最小资源配额”数量的集群资源，从而保证池内作业的基本服务质量。

当某个作业池没有使用完它的“最小资源配额”时，其剩余资源会被分配给其他作业池使用。

默认情况下，公平调度器会将同一用户的作业组织在同一个作业池内。

至于同一池内作业间的资源分配，则可由用户定制选择不同的调度策略，比如FIFO、公平调度算法等。

公平调度器在保证多用户共享式集群环境下作业调度过程的公平性方面具有很好的性能，使得任何用户在任何时候都能够得到及时响应。

但其在效率方面却存在着两个不容忽视的问题——“头队列问题”和“槽粘滞”问题：

所谓“头队列问题”，是指公平调度器调度位于队列头部的小作业时所发生的效率问题。

在像Hadoop这样的分布式系统中，文件数据通常都是在组成集群的各个节点上分散存储的。

由于小作业的输入数据规模往往很小，存有其输入数据的节点占整个集群的比值也会相对较小。

这就导致当小作业被调度到队列头部时，无论哪个节点请求分配任务，公平调度器都会将这个小作业的任务调度到其上执行，而不管其有无任务执行所需的数据，从而影响这个小作业的执行效率；

而“槽粘滞问题”则是另一个在公平调度器下经常发生的效率问题。

这主要是由公平调度器分配集群资源的公平调度策略造成的。

当集群中某个任务执行完成并释放资源后，该任务所属作业占有的集群资源数量会相应减一。

按照公平调度器分配资源的策略，该作业此时具有获得集群资源的相对优先权。

这样情况下，公平调度器就会将刚刚被释放的资源重新分配给该作业使用。

如果资源所在节点上并没有该作业执行所需数据的话，那么该作业自身的执行性能以及整个集群的吞吐效率都会因此而遭受严重损失。

1.3.论文内容与研究点

针对于目前Hadoop下作业调度器存在的问题，即由于采用“基于队列”（queue-based）的贪心算法只关注集群局部信息进行作业调度，而无法实现作业调度公平性和共享集群整体吞吐效率的均衡，本文将探索在Hadoop框架下的作业调度器中引入一种“基于最小代价流”（min-costflow）的调度算法，研究利用最小代价流图寻求最优解时考察网络全局信息的特点，避免目前Hadoop已有作业调度器使用贪心算法的弊端。

打破以往“基于队列”的作业调度算法模式，推陈出新，另辟蹊径，寻求在多用户共享式集群环境下综合考虑作业调度公平性和集群整体吞吐效率的作业调度策略。

1.3.1.调度算法建模

对“基于最小代价流”的作业调度算法进行建模，将多用户共享式集群环境下的作业调度过程映射成一个最小代价流图（min-costflowgraph）。

根据集群拓扑信息，诸如节点数、机架数等，作业调度公平性限制，诸如用户允许运行作业数的最大值和最小值、作业响应时间等，当前提交未完成的作业数以及各个作业任务在集群中的数据本地性信息，设计流图中各个边的最大流量值（capacity）、单位流量代价（cost）以及相关节点的平衡流量值（balance）；

然后使用最小代价流图的经典算法进行求解；

求解后，还要将流图的最小代价解映射成为多用户共享式集群环境下作业调度器的调度方案。

1.3.2.作业调度器的实现

Hadoop框架下的作业调度器是通过插件方式加载的。

作业调度器插件需要实现TaskScheduler抽象类和assignTasks抽象方法[15]，并在Hadoop的conf目录下的配置文件中配置作业调度器信息，默认使用FIFO调度。

部署在多用户共享式集群上的Hadoop启动后，会自动加载作业调度器信息并创建作业调度器实例。

Hadoop框架主要通过两个实体进行分布式计算，分别是JobTracker和TaskTracker：

用户将作业提交给JobTracker，然后JobTracker会对用户提交的作业进行初始化并切分成若干个任务；

作业任务的执行由部署在各个集群节点上的TaskTracker具体负责。

集群中启动的TaskTracker会定期向JobTracker发送“心跳信息”（heartbeat），向JobTracker报告TaskTracker的状态和作业任务执行情况，包括最大可执行任务数、正在执行中的任务数、已完成任务数以及当前空闲槽个数等；

如果发送心跳信息的TaskTracker的当前空闲槽个数大于0，JobTracker就会调用实现了TaskScheduler抽象类的作业调度器的assignTasks方法，然后将方法返回的需要执行的作业任务数组——Task数组的信息通过对心跳信息的响应（response）反馈给TaskTracker，最后由TaskTracker具体执行作业任务。

本文将在对“基于最小代价流”的作业调度算法进行建模的基础上，并根据Hadoop下作业调度器的实现机制，对“基于最小代价流”的作业调度器进行实现。

1.3.3.验证作业调度器的调度效果

实现了“基于最小代价流”的作业调度器之后，本文将对作业调度器在多用户共享式集群环境下的作业调度性能进行验证，设计并实施与Hadoop中已有作业调度器的比较实验（本文选择Hadoop下的公平调度器作为比较实验对象，选择它的具体原因将在后文中阐述），考察在采用“基于最小代价流”的作业调度算法之后，调度器在作业调度的公平性和多用户共享式集群的整体吞吐效率上，与Hadoop中已有的“基于队列”的调度器相比，是否有所改善和提高。

并在实验结果的基础上，对“基于最小代价流”的作业调度器的性能进行分析和总结。

1.4.论文结构

本论文按以下章节进行组织：

第一章是绪论部分。

简要介绍了本文研究课题的相关背景和研究意义、该课题的研究现状、本文包括的基本内容与研究点以及论文结构。

第二章具体提出“基于最小代价流”的作业调度算法。

主要内容包括：

“基于最小代价流”作业调度算法的算法思想、最小代价流图问题的概念与解法、对多用户共享式集群环境下的作业调度问题进行流图建模以及具体构造流图过程的详细细节，包括流图中各条边、各个节点上属性的设置等。

第三章具体描述了“基于最小代价流”作业调度器的实现细节。

Hadoop框架下作业调度器的实现机制、“基于最小代价流”作业调度器的类图、系统中重要类的部分实现细节以及它们所完成的主要功能。

第四章对本文进行的比较实验进行阐述。

实验所用集群的软硬件环境、实验使用的应用程序、实验具体设计、部署实施的细节以及实验结果的展示和分析。

第五章是总结与展望，针对全文做出总结，并简要的阐述本课题今后的研究方向。

文章的最后是参考文献、致谢以及攻读硕士学位期间发表的学术论文。

第二章“基于最小代价流”作业调度算法的理论研究

2.

2.1.Hadoop已有作业调度器存在的问题

目前Hadoop中使用的作业调度器总体来说，都无法实现多用户共享式集群环境下作业调度高效性和公平性的均衡，包括FIFO调度器、HOD调度器和公平调度器等。

根本原因在于这些调度算法无一例外的都是“基于队列”（Queue-based）进行调度的。

无论FIFO、HOD还是公平调度器，作业调度的核心都是围绕一个或者多个队列进行的。

以公平调度器为例，调度器在启动时会根据配置文件中用户自定义或者默认项目值创建、初始化并维护多个队列，默认情况下一个用户对应一个队列。

用户将作业提交到属于自己的队列中进行调度。

首先调度器会分配给每个队列最小资源配额（minshare）的集群资源，然后再按照公平调度算法将剩余资源进行“公平的”分配，每个队列会得到自己的公平资源份额（fairshare）。

通过最小资源配额（minshare）和公平资源额度（fairshare），公平调度器可以基本保证作业调度过程的公平性，使得每个作业无论大小以及提交早晚，都能够获得及时响应；

在每一个队列中，公平调度器会根据作业优先级、提交时间、运行所需资源、用户当前运行作业数、用户允许运行作业数以及用户当前公平资源额度差值对队列中的作业进行排序，并在作业调度过程中使用“延迟调度算法”（delayscheduling）从队列头部选择合适的作业，然后将作业的任务发送给集群节点（在Hadoop中，由TaskTracker具体执行作业的任务）执行。

可以看出，公平调度器调度作业执行的实质，是先按某种提前制定的规则，对于公平调度器来说就是它的公平调度算法（fairscheduling），使用这种规则对队列中的作业进行排序，然后从队列头部选择合适的作业调度执行。

其本质是一种贪心算法的思想。

而贪心算法的根本缺陷就是由于只根据集群的局部信息作决策，因此很难实现最优结果。

公平调度器虽然通过最小资源配额、公平资源额度、作业提交时间、用户运行作业数、用户当前公平资源额度差值等因素，可以在多用户共享式集群环境下实现较好的作业调度公平性，但集群整体吞吐效率却不是很理想，特别是延迟调度算法（delayscheduling）的引入，虽在一定程度上改善了公平调度器的效率，但它只能保证尽可能满足待运行作业执行任务的数据本地运行要求，并不对实际的调度结果进行优化，有时甚至会由于片面追求任务执行的数据本地性而造成集群资源的浪费，最终难以实现作业调度公平性和共享集群整体吞吐效率的均衡。

FIFO和HOD调度在性能上则更加不理想。

2.2.“基于最小代价流”作业调度算法的算法思想

多用户共享式集群环境下的作业调度所要解决的核心问题，就是决定已提交作业中的哪些任务（task）需要在当前执行、需要在哪些节点上执行以及哪些任务当前不适合执行而需要在之后执行。

本质是要求作业调度器能够在了解整个集群状态的前提下最大化利用集群资源，从而实现作业调度公平性和整个集群吞吐效率的均衡。

而“基于队列”的作业调度算法的实质是贪心算法，即只根据共享集群的局部信息，在所了解局部信息的范围内“尽力而为”的优化作业调度过程。

“基于队列”的算法无法满足多用户共享式集群环境下作业调度的本质要