2013年10月09日 14:17:53
failed task
failed task出现的原因可分为以下几种情况：
1 child task失败，比如map/reduce任务中抛出了异常，child JVM会将这个error汇报给tasktracker，tasktracker再回将这个error汇报给jobtracker
2 child JVM失败，比如启动child task的JVM本身出现了bug，导致进程直接死掉，此时tasktracker会知道child JVM已经退出，并汇报给jobtracker此次task attempt失败
3 任务超时，如果某个任务很长时间都没有更新状态，则认为任务超时。有的任务虽然执行时间非常长，但它不停的在更新自己的状态，所以系统也不会认为这是个超时任务
4 tasktracker由于软件或硬件的原因直接挂掉了。对于这种情况，tasktracker会停止向jobtracker发送心跳，jobtracker会认为这是个dead node并把该节点加入黑名单，从此不再给这个节点分配任务，直到问题被修复后tasktracker重新汇报心跳。我遇到最囧的情况就是当各节点hosts不一致的时候，会出现tasktracker向jobtasker发送心跳，但jobtracker不能正确向tasktracker，形成了半死不活的节点～。
hadoop本身的一个设计理念就是在普通的pc硬件上构建高可靠性的系统，任何failed task都不会引起整个job的失败，因为所有失败的任务都会被重新执行（reschedule execution），只有当重新执行的次数超过4次，才会把这任务标记为失败，导致整个job的失败。
killed task
在介绍killed task之前，先介绍一下speculative execution。举个简单的例子，如果某个job有2000个map task，已经完成了1999个，只剩下一个task由于硬件比较慢而成为拖尾任务，为了减少拖尾任务对整个job运行时间的影响，jobtracker会重新启动一个一模一样的duplicate task和原有的task并行的执行，这样有一个task执行成功，整个map过程就会结束。speculative execution只有个处理拖尾任务的优化策略，并不能提高系统的可靠性。
介绍完speculative execution后我们来看看killed task的情况。killed task可能在两种情况下发生，一个是speculative execution中两个并行duplicate task中如果有一个执行成功，另一个将被kill掉；第二种情况是如果某个tasktracker挂了，那么正在该节点上面跑的任务都将被标记为killed。
===================================================================================================================================
首先说说Task容错机制
Task的运行情况由对应的一个TaskInProgress对象来跟踪，它允许一个Task尝试运行多次，每次成为一个Task Attempt
Hadoop提供了两个可配置的参数：
mapred.map.max.attempts
mapred.reduce.max.attempts
hadoop提交作业时可通过设置这两个参数来设置Map Task和Reduce Task尝试运行最大次数。
默认情况下，这两个值均为4。
如果尝试4次之后仍旧为运行成功，则TaskInProgress对象将该任务运行状态标注成FAILED。
未成功运行的Task Attempt分为两种，killed task 和failed task，他们分别对应的状态为KILLED,FAILED其中killed task 是MapReduce框架主动杀死的Task Attempt，一般产生于一下3中场景。
1.认为杀死Task Attempt：用户使用命令bin/hadoop job -kill-task task_id将一个Task Attempt杀死
2.磁盘空间或者内存不够：任务运行过程中，出现磁盘或者内存磁盘不足的情况，MapReduce框架需要采用一定策略杀次若干个Task已释放资源，其选择杀死Task的策略是优先选择Reduce Task，其实是进度最慢的Map Task。
3.TaskTracker丢失：如果TaskTracker在一定时间内未想JobTracker回报心跳，则JobTracker认为该TaskTracker已经死掉，它上面的任务将被杀掉。
Failed Task是自身运行失败的Task Attempt，通常产生一下几种场景：
1.人为使Task Attempt失败：用户使用命令bin/hadoop job -fail-task task_id 是一个Task Attempt杀死。
2.本地文件读写错误：Task 运行过程中，由于磁盘坏道等原因，导致文件读写错误。
3.Shuffle阶段错误：Reduce Task从Map Task端远程读取数据过程中出错。
4.Counter数目过多：用户自定义的Counter或者Counter Group数据木超过系统要求的上线。
5.一定时间内未汇报进度：由于程序Bug或者数据格式问题，任务在一定时间间隔内未汇报进度。
6.使用内存量超过期望值：用户提交作业时可指定每个Task预期使用的内存量，如果在运行过程中超过该值，则会运行失败。
7.任务运行过程中的其他错误：如初始化错误，其他可能的致命错误。
Failed Task 和killed Task除了产生场景不同以外，还有以下两个重要区别：
调度策略：一个Task Attempt在某个节点运行失败之后，调度器变不会将同一个Task的Task Attempt分配给该节点。而Task Attempt 被杀死后，仍可能被调度到同一个节点上运行。
尝试次数：Task容错机制是针对faile task的。也就是说，任何一个Task允许的失败次数是有限的。而对于killed task，由于他们是被框架主动杀死的，他们自身并不存在问题，因此会不断尝试运行，直到运行成功。
failed task
failed task出现的原因可分为以下几种情况：
1 child task失败，比如map/reduce任务中抛出了异常，child JVM会将这个error汇报给tasktracker，tasktracker再回将这个error汇报给jobtracker
2 child JVM失败，比如启动child task的JVM本身出现了bug，导致进程直接死掉，此时tasktracker会知道child JVM已经退出，并汇报给jobtracker此次task attempt失败
3 任务超时，如果某个任务很长时间都没有更新状态，则认为任务超时。有的任务虽然执行时间非常长，但它不停的在更新自己的状态，所以系统也不会认为这是个超时任务
4 tasktracker由于软件或硬件的原因直接挂掉了。对于这种情况，tasktracker会停止向jobtracker发送心跳，jobtracker会认为这是个dead node并把该节点加入黑名单，从此不再给这个节点分配任务，直到问题被修复后tasktracker重新汇报心跳。我遇到最囧的情况就是当各节点hosts不一致的时候，会出现tasktracker向jobtasker发送心跳，但jobtracker不能正确向tasktracker，形成了半死不活的节点～。
hadoop本身的一个设计理念就是在普通的pc硬件上构建高可靠性的系统，任何failed task都不会引起整个job的失败，因为所有失败的任务都会被重新执行（reschedule execution），只有当重新执行的次数超过4次，才会把这任务标记为失败，导致整个job的失败。
killed task
在介绍killed task之前，先介绍一下speculative execution。举个简单的例子，如果某个job有2000个map task，已经完成了1999个，只剩下一个task由于硬件比较慢而成为拖尾任务，为了减少拖尾任务对整个job运行时间的影响，jobtracker会重新启动一个一模一样的duplicate task和原有的task并行的执行，这样有一个task执行成功，整个map过程就会结束。speculative execution只有个处理拖尾任务的优化策略，并不能提高系统的可靠性。
介绍完speculative execution后我们来看看killed task的情况。killed task可能在两种情况下发生，一个是speculative execution中两个并行duplicate task中如果有一个执行成功，另一个将被kill掉；第二种情况是如果某个tasktracker挂了，那么正在该节点上面跑的任务都将被标记为killed。
===================================================================================================================================
首先说说Task容错机制
Task的运行情况由对应的一个TaskInProgress对象来跟踪，它允许一个Task尝试运行多次，每次成为一个Task Attempt
Hadoop提供了两个可配置的参数：
mapred.map.max.attempts
mapred.reduce.max.attempts
hadoop提交作业时可通过设置这两个参数来设置Map Task和Reduce Task尝试运行最大次数。
默认情况下，这两个值均为4。
如果尝试4次之后仍旧为运行成功，则TaskInProgress对象将该任务运行状态标注成FAILED。
未成功运行的Task Attempt分为两种，killed task 和failed task，他们分别对应的状态为KILLED,FAILED其中killed task 是MapReduce框架主动杀死的Task Attempt，一般产生于一下3中场景。
1.认为杀死Task Attempt：用户使用命令bin/hadoop job -kill-task task_id将一个Task Attempt杀死
2.磁盘空间或者内存不够：任务运行过程中，出现磁盘或者内存磁盘不足的情况，MapReduce框架需要采用一定策略杀次若干个Task已释放资源，其选择杀死Task的策略是优先选择Reduce Task，其实是进度最慢的Map Task。
3.TaskTracker丢失：如果TaskTracker在一定时间内未想JobTracker回报心跳，则JobTracker认为该TaskTracker已经死掉，它上面的任务将被杀掉。
Failed Task是自身运行失败的Task Attempt，通常产生一下几种场景：
1.人为使Task Attempt失败：用户使用命令bin/hadoop job -fail-task task_id 是一个Task Attempt杀死。
2.本地文件读写错误：Task 运行过程中，由于磁盘坏道等原因，导致文件读写错误。
3.Shuffle阶段错误：Reduce Task从Map Task端远程读取数据过程中出错。
4.Counter数目过多：用户自定义的Counter或者Counter Group数据木超过系统要求的上线。
5.一定时间内未汇报进度：由于程序Bug或者数据格式问题，任务在一定时间间隔内未汇报进度。
6.使用内存量超过期望值：用户提交作业时可指定每个Task预期使用的内存量，如果在运行过程中超过该值，则会运行失败。
7.任务运行过程中的其他错误：如初始化错误，其他可能的致命错误。
Failed Task 和killed Task除了产生场景不同以外，还有以下两个重要区别：
调度策略：一个Task Attempt在某个节点运行失败之后，调度器变不会将同一个Task的Task Attempt分配给该节点。而Task Attempt 被杀死后，仍可能被调度到同一个节点上运行。
尝试次数：Task容错机制是针对faile task的。也就是说，任何一个Task允许的失败次数是有限的。而对于killed task，由于他们是被框架主动杀死的，他们自身并不存在问题，因此会不断尝试运行，直到运行成功。