【Debug跟踪Hadoop3.0.0源码之MapReduce Job提交流程】第三节 Job提交前的初始化

回顾
Job提交前的初始化
后记
跳转

回顾

上一节中我们对 jobSubmitter（提交器对象）的初始化过程进行了跟踪，查看了相关初始化的内容，下面进入==submitJobInternal(Job job, Cluster cluster)==方法中查看cluster与yarn的一些交互过程。

Job提交前的初始化

将提交器构造出来以后，接着使用构造器提交作业：
在这里插入图片描述
进入submitJobInternal(Job job, Cluster cluster)方法，checkSpecs(job)方法是用来检查我们的conf里的一些参数规格正确性（如何reduces数目是否为空，缓存是否开启等）：

然后获取一个conf对象，addMRFrameworkToDistributedCache(conf)是将MapReduce框架添加到分布式缓存中，JobSubmissionFiles.getStagingDir(cluster, conf)方法是向申请了一个存放规划文档的地址（/user/deploy_man/.staging）：
在这里插入图片描述
接着是获取客户端本机ip及主机名，并将其赋值给mapreduce.job.submithostname和mapreduce.job.submithostaddress：

接着获取一个jobId，该jobId将伴随着作业的整个生命历程，出现在WebUi和History等地方（它可视作为作业的唯一标识）：
在这里插入图片描述
接着将之前申请的存放规划文档的地址（/user/deploy_man/.staging）+jobId拼接成一个新的路径，这就是存放我们作业相关文档的地方了：

我们先去hdfs上的/user/deploy_man/.staging/job_1577273840515_134821下看一下：

呃呃呃，没有搜到，看来还没有建立，我们继续向下，接着是将之前我们获取的一些参数值初始化为conf的一些属性（mapreduce.job.user.name、hadoop.http.filter.initializers、mapreduce.job.dir）：
在这里插入图片描述
TokenCache.obtainTokensForNamenodes(job.getCredentials(), new Path[]{submitJobDir}, conf)是获得路径的授权令牌，简单来说就是获取在该路径下进行一些操作的授权令牌，this.populateTokenCache(conf, job.getCredentials())是将NameNode令牌缓存TokenCache中（其实还是一些参数的设置）：
在这里插入图片描述
下一步，是生成一个key，关于该key的作用，我的猜测是验证洗牌（Shuffle）期间发生数据交换时数据的一致性：

向下，this.copyAndConfigureFiles(job, submitJobDir)就是将我们的主程序jar（BigData-1.0.jar）copy到之前分配的路径下（/user/deploy_man/.staging/job_1577273840515_134821）：
在这里插入图片描述
去该路径下看一看，果然已经上传：

接着获取作业相关的文档（规划文档）的长传路径（和主程序jar的上传位置是一致的，因为其就是用submitJobDir获取的）：

根据文件的split情况确定MapTask的数目：

进入writeSplits(JobContext job, Path jobSubmitDir)方法：
在这里插入图片描述
可以看到，它就是根据数据源的一些分布情况，根据我们设定的最大、最小的切片限制生成了作业规划（每块分成几块切片，每块切片从几行到几行等），那么由于我们的测试数据集实在是太小了，还不足以达到最小split切片限制，所以它最后获取的maps数目为0，这个时候我们可以去看看切片信息（ job.split）和切片元数据信息（ job.splitmetainfo）：
在这里插入图片描述
好吧，可能是我的测试数据太小太小的缘故，所以规划信息也少的可怜，根本看不出来什么（因为被序列化了）：

那继续往下，将获取到的maps（0个）数量写入到conf中后，获取maxMaps数量（默认-1），验证maxMaps在大于零的情况下，maps是否小于maxMaps（肯定是不成立的）：
在这里插入图片描述
下一步获取job队列名（默认为default，我们这里获取到的就是默认值），然后根据job队列名，获取队列中访问控制列表（Access Control List ：访问控制列表, 是经常使用流量控制工具，常用来控制流量和匹配感兴趣流），最后将mapred.queue.default. acl-administer-jobs的值设为允许所有用户（*即代表所有用户都能查看任务详情、改动任务优先级或者是杀掉任务），删除jobtoken引用（清空缓存的令牌）：
在这里插入图片描述
接着判断是否需要追踪令牌ID（mapreduce.job.token.tracking.ids.enabled参数未配置默认为false，就是不追踪）：

如果预留ID存在，则将其设置为mapreduce.job.reservation.id的值（这里是不存在的）：
下一步，this.writeConf(conf, submitJobFile)是将job对象序列化为一个xml文件，并提交到资源路径中（/user/deploy_man/.staging/job_1577273840515_134821）：
在这里插入图片描述
我们查看该路径下果然多了一个xml文件：

查看job.xml内容，可以看到都是一些规则的标签记录：

this.writeConf(conf, submitJobFile)是打印jobId和token信息，接着正式提交作业（资源提交至相关路径完毕，向ResourceManager申请运作业），接收返回的状态，判断状态是否为空，为空则直接抛异常：
在这里插入图片描述
之后我们的任务就被提交至yarn ResourceManager队列中，等待被NameManager领取并去/user/deploy_man/.staging/job_1577273840515_134821路径下拿到配置文件，然后开启MapReduceApplication Master，开启MapReduceApplication Master之后，MapReduceApplication Master再向ResourceManager申请开启MapTask……
贴一下运行明细图（0个map和100个reduce）:
在这里插入图片描述
生成100个文件（多少个ReduceTask就有多少个文件，这里多出来的一个是_SUCCESS空文件）：