TaskTracker内部原理——行为分析

启动新任务

• TaskTracker出现空闲资源，将资源使用情况通过心跳汇报给JobTracker
• JobTracker收到信息后，解析心跳信息，发现TaskTracker上有空闲资源，则调用调度器模块的assignTasks()函数为TaskTracker分配任务。
• JobTracker将新分配的任务封装成一个或者多个LaunchTaskAction对象，将其添加到心跳应答中返回给TaskTracker。
• TaskTracker收到心跳后，解析出LaunchTaskAction对象，创建JVM启动任务。
• 当Counter值或者进度发生变化时，任务通过RPC函数将最新Counter值和进度汇报给TaskTracker
• TaskTracker通过心跳将任务的最新Counter值和进度汇报给JobTracker

提交任务

任务提交是指任务处理完数据后，将最终结果从临时目录转移到最终目录的过程，只有将输出结果直接写到HDFS上的任务才会经历这个过程，hadoop中的Reduce Task和map-only类型作业的Map Task有这个过程。

hadoop的任务提交采用了两阶段提交协议(2PC)实现，两阶段提交协议是分布式事务中经常采用的协议。

两阶段提交协议：
将分布式事务的某一个代理指定为协调者，所有其他代理称为参与者，规定只有协调者才有提交或撤销事务的决定权，而其他参与者各自负责在本地执行写操作，并向协调者提出撤销或提交子事务的意向。
第一阶段（准备阶段）：各个参与者执行完自己的操作后，将状态变为”可以提交",并向协调者发送“准备提交”请求。
第二阶段（提交阶段）：协调者按照一定原则决定是否允许参与者提交，如果允许，则发出“确认提交”请求，参与者收到请求后，把“可以提交”状态改为“提交完成”，然后返回应答；如果不允许，则发出“提交失败”请求，参与者收到后改为“提交失败”，然后退出。
在MapReduce中，JobTracker扮演协调者，TaskTracker扮演参与者。

步骤：

• Task Atttempt处理完最后一条记录，运行状态由RUNNING变为COMMIT_PENDING，并通过RPC将该状态和任务提交请求发送给TaskTracker。（2PC的第一阶段，后面都是第二阶段）
• TaskTracker得知一个Task Attempt状态变为COMMIT_PENDING之后，立刻缩短心跳间隔，快速将任务状态汇报给JobTracker
• JobTracker收到心跳信息后，检查它是否为某个TaskInProgress中第一个状态变为COMMIT_PENDING的Task Attempt，如果是，则批准它进行任务提交，在心跳中添加CommitTaskAction命令，以通知TaskTracker准许该任务提交最终结果
• TaskTracker收到CommitTaskAction后，将对应任务加入可提交任务列表commitResponses中
• Task Attempt通过RPC检测自己位于列表commitResponses中后，将结果进行提交，即将数据从临时目录转移到最终目录下，并告诉TaskTracker任务提交完成。
• TaskTracker得知任务提交完成后，将任务运行状态由COMMIT_PENDING变为SUCCEEDED，并在下次心跳中将该任务状态汇报给JobTracker。

杀死任务

• JobTracker收到来自JobClient的杀死任务请求后，将任务添加到待杀死任务列表tasksToKill中
• 之后某个时刻，Task Attempt所在的Task Tracker向Job Tracker发送心跳，JobTracker收到心跳后，将该任务封装到KillTaskAction命令中，并通过心跳应答发送给TaskTracker
• TaskTracker收到KillTaskAction后，将该任务从作业列表runnningJobs中清除，并将运行状态从RUNNING转化为KILED_UNCLEAN，同时同时directoryCleanupThread线程清理其工作目录，释放所占slot，最后缩短心跳时间间隔， 以便将该任务状态迅速通过带外心跳告诉JobTracker
• JobTracker收到状态为KILLED_UNCLEAN的Task Attempt后，将其类型改为task-cleanup task（这种任务的输入数据为空，但ID与被杀Task Attempt的ID相同，其目的是清理被杀Task Attempt已经写入HDFS的临时数据），并添加到待清理任务队列mapCleanup Tasks/reduceCleanupTasks中，在接下来的某个TaskTracker的心跳中，JobTracker将其封装到LaunchTaskAction中发送给TaskTracker。
• TaskTracker收到LaunchTaskAction后，启动JVM执行该任务，由于该任务属于task-cleanup task，因此只需清理被杀死的Task Attempt已写入HDFS的临时数据（如果没有则直接跳过），之后其运行状态变为SUCCEEDED，并由TaskTracker通过下一次心跳告诉JobTracker
• JobTracker收到运行状态为SUCCEEDED的Task Attempt后，首先检查它是否位于任务列表taskToKill中，在该表中说明已经被杀死，于是将其状态转为KILLED，通过修改相应的各个数据结构

杀死作业

任何一个作业成功运行完成后，JobTracker会向各个TaskTracker广播KillJobAction，清空各个节点上该作业的工作目录。
用户也可以用shell命令杀死迆。

用户输入一条“杀死作业”的shell命令后， JobClient通过RPC函数KillJob向JobTracker发送杀死作业的请求，JobTracker收到请求后：

• 作业的JobInProgress对象将jobKilled变量设置为true，并杀死该作业所有的job-setup task、map task和reduce task（job-cleanup task保留）
• 此后假设TaskTracker1第一个向JobTracker汇报心跳，则JobTracker将该作业的job-cleanup task封装成LaunchTaskActino命令，将该TaskTracker对应的已被杀死任务封装成KillTaskAction命令，并将这些命令添加到心跳应答中返回给TaskTracker1。
• 对于接下来发送心跳的TaskTracker，JobTracker将对应的被杀死任务封装成KillTaskAction命令，并将这些命令添加到心跳应答中返回给TaskTracker。
• TaskTracker1收到来自JobTracker的命令后，执行相应的操作：若为KillTaskAction命令，将作业状态KILLED_UNCLEAN汇报给JobTracker；若为LunchTaskAction，TsakTracker将创建JVM执行该任务，执行完状态转为SUCCEEDED，并由TaskTracker通过心跳告诉JobTracker。
• JobTracker收到TaskTracker汇报的心跳后，若心跳信息包含任务状态变为KILLED_UNCLEAN，由于任务所属作业已被杀死（jobKilled=true)，则将任务由KILLED_UNCLEAN状态转为KILLED；若心跳信息包含job-cleanup task运行成功（状态为SUCCEEDED），则向各个TsakTracker广播KillJobAction命令，以清理作业的工作目录和相关的内存结构。