hadoop MapReduce Job失效模型
2012-03-20 10:04
176 查看
http://news.newhua.com/news1/program_net/2009/99/099914374148D4FHKAFAD4HB77CH4H6IJCB963K89A26AK018J607I6_2.html?lt=common
hadoop设计的初衷就是容错.计算任务(MapReduce task)能够在节点宕机或其它随机错误下自行恢复.
但是hadoop并不完美,在实际运营中,我发现MapReduce Job仍然经常会因为一些偶发性错误而
运行失败.所以我决定深入探究一下各种不同因素是如何导致job失败的.
如果一个hadoop job的某个给定task在失败预定次(默认是4)后,整个job就会失败.
这可以通过"mapred.map.max.attempts"和"mapred.reduce.max.attempts"属性来设置.
一个task可能由于各种偶发原因而失败 - 比如我发现的情况就有磁盘满,hadoop本身的bug,或者硬件失效(e.g.: 磁盘只读).
下面是针对job失败的概率总结的一个大致公式:
P[个别task失败的最大次数] = P[task失败] ^ (task总失败次数)
P[task成功] = 1 - P[个别task失败的最大次数]
P[job成功] = P[task成功] ^ (task数量)
P[job失败] = 1 - P[job成功]
P[job失败] = 1 - (1 - P[task失败] ^ (task总失败次数) ) ^ (task数量)
task失败的最大次数通过mapred.max.max.tracker.failures设置(默认为4).
我们来分析一个负载为100000个map task的job:
task数量 最大失败数 P[task失败] P[job失败]
100000 4 0.01 0.00099950017664
100000 4 0.02 0.015872681207036
100000 4 0.03 0.077806338804489
100000 4 0.04 0.22585828487781
100000 4 0.05 0.46473961691604
100000 4 0.06 0.72637819455556
100000 4 0.01 0.00099950017664
100000 3 0.01 0.095162627208542
100000 3 0.005 0.012422200279389
100000 2 0.005 0.91791756653541
如果task失败概率低于1%的话,job失败概率几乎可以不计. 重点就是保证集群稳定,保持较小失败概率 .
我们同样可以看到"mapred.max.tracker.failures"参数的重要性, 如果其取值小于4时,job失败的概率明显上升,就算task失败概率降低到0.5% .
相较mapper而言, reducer运行的时间更长,这意味着其更容易遭受意外事故.也就是说,我们可以肯定reducer的失败概率比mapper要大很多.但是从另一方面来说,通常reducer task的数量要小于mapper数量,这个又作了一定补偿.
下面我们来看看一组基于reducer的失效概率分析:
task数量 最大失败数 P[task失败] P[job失败]
300 1
0.1 0.99999999999998
300 2
0.1 0.95095910592871
300 3
0.1 0.2592929678439
300 4
0.1 0.029555922215749
300 ; 4 0.01 0.00000299999553
300 4
0.05
0.001873249134037
300 4 0.1 0.029555922215749
300 4
0.2 0.38145442906123
300 4
0.3 0.9128299934708
从上述数据中可以发现, 只有当reducer失败的概率超过10%时才会导致一定的job失败几率.(同样可发现, task最大失败数低于3时,job失败率显著上升).
坏节点(有故障的机器节点)
在整个失效模型中还有一个很重要的因子需要考虑,那就是失效节点.通常若出现整个节点失效,那么在此节点上运行的所有task都会失败,失效原因可能是因为磁盘损坏(通常的症状是出现 磁盘只读 或 盘符丢失 ), 磁盘写满等.一旦出现坏节点,你会发现在此节点被列入黑名单之前(被job列入黑名单的节点不会被job再次分配其任务),会有一大堆 map/reduce task失败.为了简化我们的分析,我假设给定坏节点会导致固定数量的task失败.另外,我假设给定task只会在给定坏节点上中招一次, 因为节点会在不久后被列入黑名单.我们用"b-tasks"来标记在坏节点上失败过的task,
其它task标记为"n-tasks"."b-task"会在坏节点上遭受一次失败, 所以后续如果job再出现"最大task失败数 - 1"次失败task就会导致job失败.在我们的集群中,我曾发现一个坏节点引发3个task失败, 那么我就以此为据, 给出reduce阶段失效概率的公式:
b-tasks数量 = 坏节点数量 * 3
P[所有b-task都成功] = (1 - P[task失败概率] ^ (最大task失败数 - 1)) ^ (b-tasks数量)
P[所有n-task都成功] = (1 - P[task失败] ^ (最大task失败数)) ^ (task数量 - b-task数量)
P[job成功] = P[所有b-task成功] * P[所有n-task成功]
P[job成功] = (1-P[task失败]^(最大task失败数 - 1))^(b-task数量) * (1-P[task失败]^(最大task失败数))^(最大task数 - b-task数)
P[job失败] = 1 - P[job成功]
因为mapper数量通常较多,所以少数坏节点对于以上公式计算的结果并没有太大的出入.但对reducer而言,其数量较少,所以以上公式计算出
的结果就有比较明显的变化:
task数量 最大失败数 P[task失败] 坏节点数量 P[job失败]
300 4 0.1 0
0.02955592221574
300 4 0.1 1
0.03217402532872
300 4 0.1 2
0.03478506521768
300 4 0.1 5
0.04257599583811
300 4 0.05 0 0.00187324913403
300 4 0.05
5
0.00364969637240
300 4 0.05 10
0.00542298192335
300 4 0.05 20
0.00896009046141
值得庆幸的是结果并没有发生戏剧性的变化 - 在5个坏节点的情况下,只导致失败率提高到了排除坏节点条件下的1.5~2倍.
最后的结论就是, hadoop在task失效概率保持较低的情况下,容错性还是很好的.基于前面的一些数据分析,我们发现"最大task失败数 " 最好设置为4, 当task失败率达到1%时,你需要开始考虑集群的稳定性了.当然,你可以通过增大"最大task失败数"来提高稳定性,但是如果有太多task失败, 那么job执行的性能也会降低.所以再强调一次, 重点还是 --- 保持集群稳定 .
hadoop设计的初衷就是容错.计算任务(MapReduce task)能够在节点宕机或其它随机错误下自行恢复.
但是hadoop并不完美,在实际运营中,我发现MapReduce Job仍然经常会因为一些偶发性错误而
运行失败.所以我决定深入探究一下各种不同因素是如何导致job失败的.
如果一个hadoop job的某个给定task在失败预定次(默认是4)后,整个job就会失败.
这可以通过"mapred.map.max.attempts"和"mapred.reduce.max.attempts"属性来设置.
一个task可能由于各种偶发原因而失败 - 比如我发现的情况就有磁盘满,hadoop本身的bug,或者硬件失效(e.g.: 磁盘只读).
下面是针对job失败的概率总结的一个大致公式:
P[个别task失败的最大次数] = P[task失败] ^ (task总失败次数)
P[task成功] = 1 - P[个别task失败的最大次数]
P[job成功] = P[task成功] ^ (task数量)
P[job失败] = 1 - P[job成功]
P[job失败] = 1 - (1 - P[task失败] ^ (task总失败次数) ) ^ (task数量)
task失败的最大次数通过mapred.max.max.tracker.failures设置(默认为4).
我们来分析一个负载为100000个map task的job:
task数量 最大失败数 P[task失败] P[job失败]
100000 4 0.01 0.00099950017664
100000 4 0.02 0.015872681207036
100000 4 0.03 0.077806338804489
100000 4 0.04 0.22585828487781
100000 4 0.05 0.46473961691604
100000 4 0.06 0.72637819455556
100000 4 0.01 0.00099950017664
100000 3 0.01 0.095162627208542
100000 3 0.005 0.012422200279389
100000 2 0.005 0.91791756653541
如果task失败概率低于1%的话,job失败概率几乎可以不计. 重点就是保证集群稳定,保持较小失败概率 .
我们同样可以看到"mapred.max.tracker.failures"参数的重要性, 如果其取值小于4时,job失败的概率明显上升,就算task失败概率降低到0.5% .
相较mapper而言, reducer运行的时间更长,这意味着其更容易遭受意外事故.也就是说,我们可以肯定reducer的失败概率比mapper要大很多.但是从另一方面来说,通常reducer task的数量要小于mapper数量,这个又作了一定补偿.
下面我们来看看一组基于reducer的失效概率分析:
task数量 最大失败数 P[task失败] P[job失败]
300 1
0.1 0.99999999999998
300 2
0.1 0.95095910592871
300 3
0.1 0.2592929678439
300 4
0.1 0.029555922215749
300 ; 4 0.01 0.00000299999553
300 4
0.05
0.001873249134037
300 4 0.1 0.029555922215749
300 4
0.2 0.38145442906123
300 4
0.3 0.9128299934708
从上述数据中可以发现, 只有当reducer失败的概率超过10%时才会导致一定的job失败几率.(同样可发现, task最大失败数低于3时,job失败率显著上升).
坏节点(有故障的机器节点)
在整个失效模型中还有一个很重要的因子需要考虑,那就是失效节点.通常若出现整个节点失效,那么在此节点上运行的所有task都会失败,失效原因可能是因为磁盘损坏(通常的症状是出现 磁盘只读 或 盘符丢失 ), 磁盘写满等.一旦出现坏节点,你会发现在此节点被列入黑名单之前(被job列入黑名单的节点不会被job再次分配其任务),会有一大堆 map/reduce task失败.为了简化我们的分析,我假设给定坏节点会导致固定数量的task失败.另外,我假设给定task只会在给定坏节点上中招一次, 因为节点会在不久后被列入黑名单.我们用"b-tasks"来标记在坏节点上失败过的task,
其它task标记为"n-tasks"."b-task"会在坏节点上遭受一次失败, 所以后续如果job再出现"最大task失败数 - 1"次失败task就会导致job失败.在我们的集群中,我曾发现一个坏节点引发3个task失败, 那么我就以此为据, 给出reduce阶段失效概率的公式:
b-tasks数量 = 坏节点数量 * 3
P[所有b-task都成功] = (1 - P[task失败概率] ^ (最大task失败数 - 1)) ^ (b-tasks数量)
P[所有n-task都成功] = (1 - P[task失败] ^ (最大task失败数)) ^ (task数量 - b-task数量)
P[job成功] = P[所有b-task成功] * P[所有n-task成功]
P[job成功] = (1-P[task失败]^(最大task失败数 - 1))^(b-task数量) * (1-P[task失败]^(最大task失败数))^(最大task数 - b-task数)
P[job失败] = 1 - P[job成功]
因为mapper数量通常较多,所以少数坏节点对于以上公式计算的结果并没有太大的出入.但对reducer而言,其数量较少,所以以上公式计算出
的结果就有比较明显的变化:
task数量 最大失败数 P[task失败] 坏节点数量 P[job失败]
300 4 0.1 0
0.02955592221574
300 4 0.1 1
0.03217402532872
300 4 0.1 2
0.03478506521768
300 4 0.1 5
0.04257599583811
300 4 0.05 0 0.00187324913403
300 4 0.05
5
0.00364969637240
300 4 0.05 10
0.00542298192335
300 4 0.05 20
0.00896009046141
值得庆幸的是结果并没有发生戏剧性的变化 - 在5个坏节点的情况下,只导致失败率提高到了排除坏节点条件下的1.5~2倍.
最后的结论就是, hadoop在task失效概率保持较低的情况下,容错性还是很好的.基于前面的一些数据分析,我们发现"最大task失败数 " 最好设置为4, 当task失败率达到1%时,你需要开始考虑集群的稳定性了.当然,你可以通过增大"最大task失败数"来提高稳定性,但是如果有太多task失败, 那么job执行的性能也会降低.所以再强调一次, 重点还是 --- 保持集群稳定 .
相关文章推荐
- Hadoop导航:版本、生态圈及MapReduce模型
- Hadoop学习笔记—4.初识MapReduce 一、神马是高大上的MapReduce MapReduce是Google的一项重要技术,它首先是一个编程模型,用以进行大数据量的计算。对于大数据
- Hadoop 第七课 从wordCount 看MapReduce模型
- Hadoop: MapReduce2多个job串行处理
- Distributed System: Hadoop MapReduce框架的角色和Job提交过程
- Hadoop中MapReduce模型
- Hadoop计算模型MapReduce及其体系结构
- Hadoop源码分析23:MapReduce的Job提交过程
- solution:No job file jar和ClassNotFoundException(hadoop,mapreduce)
- Creating Hadoop MapReduce Job with Spring Data Apache Hadoop
- hadoop的mapreduce编程模型中GroupingComparator的使用
- Hadoop基本概念及MapReduce编程模型
- Hadoop中MapReduce运行剖析-Anatomy of a MapReduce Job Run with Hadoop
- Hadoop MapReduce编程模型之InputFormat接口学习
- hadoop2 如何在执行mapreduce的时候指定job的名字
- hadoop MapReduce Job失效模型
- Hadoop运行任务时一直卡在: INFO mapreduce.Job: Running job
- Hadoop系列之二:大数据、大数据处理模型及MapReduce
- hadoop初识之十:mapreduce编程模型与数据传输格式
- 【Hadoop】MapReduce Job Submission Files