这篇来说道说道job在到达Job Tracker后会有哪些动作,涉及上篇job生命周期的第五步和第六步。因为job在初始化后紧接着需要应付Job Tracker对Task Tracker的task分发响应,所以我们从Job Tracker的分发过程倒着来看job初始化。
Task Tracker在运行时会周期性地向Job Tracker发送心跳请求,汇报Task Tracker的状态数据、本Task Tracker上task执行状态及希望从Job Tracker得到可以执行的task来做。在这里再得明确下task的概念。Task是job的基本单元,由Job Tracker分发到Task Tracker来执行。task分为两类: map task与reduce task。map task处理输入数据,它就应该是输入数据、job相关信息等组成的对象;reduce task汇总map task的输出结果,最后生成job的输出,它也应是由job相关信息组成。task是在Task Tracker上执行,所以task需要的信息须与Job Tracker的状态信息有关,以便task执行时需要。
在前一节Job提交过程中说到,job将所有输入数据组装成了逻辑分片,这些逻辑分片只是HDFS上物理数据block的索引及存储信息。map task依赖于这些信息来决定将task分发到哪些Task Tracker上。Job Tracker可以取到job相关的metadata信息,然后由这些信息来决定如何分发task。因此,上一节的这些分片的相关信息就存放在特定的目录下,Job Tracker通过jobId可以访问到。
Reduce task不管在哪个Task Tracker上执行,都得从其它那些执行map task的Task Tracker上拉取数据,所以对它的分发Job Tracker不需要准备什么,只要在合适的时候放到某台Task Tracker上执行即可。Job Tracker主要还是关注map task的准备工作(Reduce task并不是从所有map task拉取临时数据。如果有多个reduce task的话,每个reduce task只拉取一部分map task的临时数据。关于partition等相关的细节以后会说到)。
这里介绍Job Tracker分发task过程中比较重要的一步:data locality级别。map task的执行效率依赖于读取输入数据的效率。输入数据越靠近执行task的Task Tracker,map task就执行的越快。根据数据所处的位置与Task Tracker的距离,有如下几种data locality级别:
引用
0 node-local 输入分片就在Task Tracker本地
1 rack-local 输入分片在Task Tracker所在的rack内其它Task Tracker上
2 off-switch 输入分片在其它的rack内
Job Tracker在task分发时应充分考虑data locality级别。分发策略对job执行效率的影响很大程度是如何优化map task的locality。
Job Tracker可以从job的metadata中得到并维护这样一种映射关系:job split ----> HDFS block && slave node。这种映射关系就是生成map task的基础。有多少个split,就会有map task。如上所述,响应心跳而选择map task的处理就像这样:
1. 根据Task Tracker的机器,查看Job Tracker中是否存在一个map task,它关联的block(假设一个block划分为一个split)存储在Task Tracker的本地磁盘上,那么就优先执行这个map task。
2. 如果没有1可选的map task,那么查看是否有map关联的block在Task Tracker所在的rack内。
3. 如果上面两步都没有选到某个map task,那么就根据情况看是否执行跨rack的task或其它推测式执行task。
初始化的基本工作就很少一些,主要的选择逻辑还是task scheduler应该做的事情。既然提到Scheduler,还得说MapReduce默认的JobQueue scheduler在理论上有个严重的问题。如果它没有从1或2中选取到map task,那么它就会执行某个跨rack的map task。理想情况下应该尽量避免这样做,当前的Task Tracker本地或rack内不存在task所需的split,但其它rack内的Task Tracker上肯定会存在那个split的,那个有split存在的Task Tracker之后也会从Job Tracker取task,把这种map task放到有数据的Task Tracker上做肯定比跨rack取数据快。所以如果可能的话,尽量按照实际情况选取合适的scheduler(以上之所以是理论,也是因为大部分的执行环境都没有与rack有关物理拓扑结构)。
Scheduler还得注意的一点是,当用户开启task推测式执行,那推测式执行就会发生在Job Tracker意识到某个task执行效率低的时候,尽量要让推测式task是node local级别的。如果推测式task要跨rack取数据,比原来的task执行还慢,就没有现实意义了。
Job初始化过程主要是在Job Tracker建立一个slave node对task的映射模型,其它都是附属工作。我会把job生命周期的重点放在task执行的过程,也就是那个“奇迹发生的地方”。To be continued...
- 大小: 50.3 KB
分享到:
相关推荐
这是谷歌三大论文之一的 MapReduce: Simplified Data Processing on Large Clusters 英文原文。我的翻译可以见https://blog.csdn.net/m0_37809890/article/details/87830686
MapReduce: Simplified Data Processing on Large Clusters from google.
来自于GOOGLE的mapreduce的开山之作,此文是原英文的中文版本,希望能互相参照,加深理解
Google并行计算,分布式处理模型MapReduce: Simplified Data Processing on Large Clusters
MapReduce: Simplified Data Processing on Large Clusters翻译
NULL 博文链接:https://langyu.iteye.com/blog/962529
MapReduce:Nkeys,Nfiles终极解决方案.docx
mapreduce创建代码项目mvn原型:generate -DarchetypeGroupId = org.apache.maven.archetypes -DgroupId = org.conan.mymahout -DartifactId = myPro -DpackageName = org.conan.mymahout -Dversion = 1.0-SNAPSHOT ...
Google的MapReduce并行计算原始论文详解。
用户自定义的map函数,接受一个输入对,然后产生一个中间key/value对集.MapReduce库把所有具有相同中间key I的中间value聚合在一起,然后把它们传递给reduce函数. 用户自定义的reduce函数,接受一个中间key I和相关的一...
MapReduce的翻译,我只是个搬运工qwq
Google那篇著名的论文的ppt,MapReduce开山之作,介绍了Google对MapReduce的实现。
在2010年1月的ACM上,有两篇文章非常吸引人注意。一篇文章是Google的Jeffrey Dean、Sanjay Ghemawat发表的标题为《MapReduce:一个灵活的数据库处理工具》,另一篇文章是Michael Stonebraker、Daniel Abadi、David J....
MapReduce原始论文
NULL 博文链接:https://langyu.iteye.com/blog/970405
MapReduce:简单字数
MapReduce教程视频,难度不算太高。这个是上半部分,下半部分在下一个资源。。嘿嘿
i2MapReduce:用于挖掘不断发展的大数据的增量MapReduce
本文介绍了用Java编写并运行第一个mapreduce作业的步骤及遇到的问题和解决方案。
在前面《MapReduce实例分析:单词计数》教程中已经介绍了用 MapReduce 实现单词计数的基本思路和具体执行过程。下面将介绍如何编写具体实现代码及如何运行程序。 首先,在本地创建 3 个文件:file00l、file002 和 ...