第十一篇:Map/Reduce 工作机制分析 - 错误处理机制

Posted 穆晨

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了第十一篇:Map/Reduce 工作机制分析 - 错误处理机制相关的知识,希望对你有一定的参考价值。

前言

       对于Hadoop集群来说,节点损坏是非常常见的现象。

       而Hadoop一个很大的特点就是某个节点的损坏,不会影响到整个分布式任务的运行。

       下面就来分析Hadoop平台是如何做到的。

硬件故障

       硬件故障可以分为两种 - JobTracker节点损坏和TaskTracker节点损坏。

1. JobTracker节点损坏

       这是Hadoop集群中最为严重的错误。

       出现了这种错误,那就只能重新选择JobTracker节点,而在选择期,所有的任务都必须停掉,而且当前已经完成了的任务也必须通通重来。

2. TaskTracker节点损坏

       这是Hadoop集群中最常见的错误。对于这类错误,Hadoop有完好的错误处理机制。

       JobTracker和TaskTracker的心跳通信机制要求TaskTracker保证在1分钟之内向JobTracker汇报进展。

       如果超过时间JobTracker没有收到汇报,就会将该TaskTracker从等待调度的集合中移除出去;

       而如果收到任务失败的的报告,就把这个TaskTracker移动到等待调度队列尾部重新排队。但是若一个TaskTracker连续汇报了四次失败,那么也会被移出任务等待队列。

小结

       关于故障的处理维护,一般会由专人来进行管理。

       这部分内容就暂且不做深究了。

以上是关于第十一篇:Map/Reduce 工作机制分析 - 错误处理机制的主要内容,如果未能解决你的问题,请参考以下文章

第九篇:Map/Reduce 工作机制分析 - 作业的执行流程

第九篇:Map/Reduce 工作机制分析 - 数据的流向分析

第十一篇:setState 到底是同步的,还是异步的?

第十一篇|基于SparkSQL的电影分析项目实战

第十一篇:Spark SQL 源码分析之 External DataSource外部数据源

第十一篇:基于TCP的一对回射客户/服务器程序及其运行过程分析( 下 )