JobTracker概述

JobTracker主要负责资源监控和作业调度 。JobTracker会跟踪任务的执行进度、资源使
用量等信息，并将这些信息告诉任务调度器，而调度器会在资源出现空闲时，选择合适
的任务使用这些资源。
JobTacker涉及MR生命周期的步骤有：

1. 作业提交到JobTracker
2. 任务的调度与监控
   其中做的操作包括：
   a. 为作业创建JobInProgress对象
   b. 检查用户是否具有指定队列的作业提交权限
   c. 检查作业配置的内存使用量是否合理
   d. 通知任务调度器按照一定策略调度任务

拓展观察者模式

1. 主题Subject
   首先定义一个观察者数组，并实现增、删及通知操作。它的职责很简单，就是定义谁能观察，
   谁不能观察
2. 抽象观察者Observer
   观察者一般是一个接口，每一个实现该接口的实现类都是具体观察者。
3. 具体主题
   继承Subject类，在这里实现具体业务。
4. 具体观察者
   实现Observer接

拓展观察者模式
优点
观察者和被观察者是抽象耦合的
建立了一套触发机制
缺点
如果观察者对象有很多的话，通知一遍到会花费很多时间
如果观察者和观察目标间有循环依赖，可能导致系统崩溃

JobTracker核心功能 — 作业控制
(1)作业控制
JobTracker在其内部以“三层多叉树”的方式描述和跟踪每个作业的运行状态

JobTracker核心功能 — 资源管理
(2)资源管理
JobTracker不断接收各个TaskTracker周期性发送过来的资源量和任务状态等信息，为
TaskTracker分配最合适的任务。
Hadoop引入了“slot”概念表示各个节点上的计算资源。为了简化资源管理，Hadoop将各个节
点上的资源(CPU、内存和磁盘等)等量切分成若干份，每一份用一个slot表示，同时规定一个Task
可根据实际需要占用多个slot

TaskTacker概述
TaskTracker是JobTracker与
Task之间的“沟通桥梁”:
• 它从JobTracker端接收并执
行各种命令，比如运行任务、
提交任务、杀死任务等
• 它将本节点上的各个任务状
态通过周期性心跳汇报给
JobTracker

TaskTracker核心功能介绍 — 心跳机制*
心跳是Jobtracker和Tasktracker的桥梁，它实际上是一个RPC函数，Tasktracker周期
性的调用该函数汇报节点和任务状态信息，从而形成心跳。在hadoop中，心跳主要有
三个作用：
1、判断Tasktracker是否活着
2、及时让Jobtracker获取各个节点上的资源使用情况和任务运行状态
3、为Tasktracker分配任务
Tasktracker周期性的调用RPC函数heartbeat向Jobtracker汇报信息和领取任务，函数
定义是：
HeartbeatResponse heartbeat(TaskTrackerStatus status,
boolean restarted,
boolean initialContact,
boolean acceptNewTasks,
short responseId

拓展*心跳机制源码剖析
心跳是JobTracker和TaskTracker的桥梁，它实际上是一个RPC函数，TaskTracker周
期性的调用该函数汇报节点和任务状态信息，从而形成心跳。在hadoop中，心跳主
要有三个作用：

1. 判断TaskTracker是否活着
2. 及时让JobTracker获取各个节点上的资源使用情况和任务运行状态
3. 为TaskTracker分配任务
   JobTracker与TaskTracker之间采用了Pull而不是Push模型，是JobTracker不会主动
   向TaskTracker发送任何信息，而是由TaskTracker主动通过心跳领取属于自己的消息
   ，JobTracker只能通过心跳应答的形式为各个TaskTracker分配任务

容错机制概述
在1.0.0以及之前版本中，Hadoop采用了任务级别的恢复机制，即以任务为基本单位进
行恢复，这种机制是基于事务型日志完成作业恢复的，它只关注两种任务：运行完成的
任务和未运行完成的任务。
一旦JobTracker重启，则可从日志中恢复作业的运行状态，其中已经运行完成的任务无
须再运行，而未开始运行或者运行中的任务需重新运行。这种方案实现比较复杂，需要
处理的特殊情况比较多。
为了简化设计，从0.21.0版本开始，Hadoop采用了作业级别的恢复机制。该机制不再
关注各个任务的运行状态，而是以作业为单位进行恢复，它只关注两种作业状态：运行
完成或者未运行完成。当JobTracker重启后，凡是未运行完成的作业将自动被重新提交
到Hadoop中重新运行

JobTracker的容错
作业恢复的机制处理比较简单。每个新的作业(Job)会在JobTracker的工作目录下为该作业
创建一个以该作业的JobId为命名的目录，目录底下放该作业的Job-info和JobToken文件
。如果该作业成功运行结束，那么就会在作业的Cleanup工作中删除掉该文件夹。
所以，当某个时刻JobTracker如果突然因为故障重启了，那么该工作目录下如果JobId工作
目录，就说明重启之前还有作业未运行结束（因为运行结束的Job都会把自己的目录清除掉
），此时就会把目录中包含的作业重新提交运行，并且JobTracker会把这些重新提交运行
的Job的Id信息通过心跳信息的回复告知TaskTracker。
那些之前就已经运行在TaskTracker上的任务就是根据TaskID和JobID来更新JobTracker中
的作业和任务的信息状态的。原本就正在运行的任务仍然能够正常的更新JobTracker。已
经运行结束的Task会把新提交的作业的Task直接更新为运行结束

利用MapReduce编写程序
题目：给出一些英文文本，用mapreduce求频率最高的K个单词（Top K）
思路：分成两个MR作业，第一MR就是wordcount，其输出作为第二个MR作业的输入，map函数
中求前K个高频词， reduce()函数汇总并输出频率最高的前K个词

利用MapReduce编写程序
题目：给出一些英文文本，用mapreduce求频率最高的K个单词（Top K）
思路：分成两个MR作业，第一MR就是wordcount，其输出作为第二个MR作业的输入，map函数
中求前K个高频词， reduce()函数汇总并输出频率最高的前K个词。