MapReduce:job在Job Tracker上的初始化

小雨涵

这篇来说道说道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执行的过程，也就是那个“奇迹发生的地方”。