大数据开发要学会看yarn日志：Task容错机制，任务推测执行，计数器_yarn job 日志 task 日志(1)

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

1.2 Task type与Attemp Type的区别

MapRecue/Hive 任务分成maptask和reducetask，每个类型的task的总数一般是根据数据量和参数配置决定，在任务起始阶段已经确定。yarn界面的Task Type统计的就是提交yarn时需要执行的task任务数量。而实际一个task允许尝试多次运行，每次运行尝试的实例就被称Task Attempt，也就是yarn任务日志界面Attempt Type里统计的数据。这也就是为啥map/reduce的实例都是以attmp_****开头的原因，因为任务的运行实例是attemp。

注意：任务还是task开头的，两个查看的入口是不同的，我们一般关注的是task的进度，一个task任务可以有多个attmpt实例在跑，具体牵扯到推测执行。

1.3Task的容错机制的使用

实际生产中，map/reduce task会因为多方面原因如机器老化，资源不足，进程崩溃，带宽限制等出现部分map/reduce task实例失败的情况，这是极其正常且容易发生的事。如果这个时候整个任务就直接报错了，那么代价就太大了。所以hadoop就引入了task容错机制。map/reduce实例失败后，在退出之前向APPMaster发送错误报告，错误报告会被记录进用户日志，APPMaster然后将这个任务实例标记为failed,将其containner资源释放给其他任务使用。

通过如下两个参数控制map/reduce的task一旦失败了map/reduce实例可以重试的次数，一般直接使用默认值就可以，所以实际开发中，不要关注单个map的失败，只要不失败四次，对任务就没有影响。每次失败后APPMaster都会试图避免在以前失败过的节点上重新调度该任务，直到任务成功，或者超过4次，超过4次则不会在尝试，默认作业容错率是0，这时候整个任务失败。

1.控制Map Task失败最大尝试次数,默认值4
mapred.map.max.attempts  ---废弃参数
mapreduce.map.maxattempts ---推荐新参数

2.1.控制Reduce Task失败最大尝试次数,默认值4
mapred.reduce.max.attempts ---废弃参数
mapreduce.reduce.maxattempts---推荐新参数

1.3.1任务任务实例出现failed/killed的场景

1.任务实例attempt长时间没有向MRAPPMaster报告，后者一直没收到其进度的更新，一般attempt实例与APPMaster3s通信一次，前者像后者报告任务进度和状态；超出阈值，任务变会被认为僵死“”被标记失败failed，然后MRAPPMaster会将其JVM杀死，释放资源。然后重新尝试在其他节点启动一个新的任务实例。

mapreduce.task.timeout=600000 ms，10分钟
The number of milliseconds before a task will be terminated if it neither reads an input, writes an output, nor updates its status string. A value of 0 disables the timeout.

2.任务attempt失败fialed的其他原因比较多，比如代码有问题，outofmemory,GC.

3.一个任务实例attempt被killed一般就两种情况，一是客户端主动请求杀死任务，二是框架主动杀死任务。对于后者，一般是由于作业被杀死或者该任务的备任任务（推测执行）已经执行完成，这个任务不需要继续执行了，所以被Killed。比如nodemanager节点故障，比如停止等，这时候上面的所有任务实例都会被标记为killed。其他再比如任务执行超出某些阈值范围，比如动态分区超过最大文件数，所有任务都会被杀死killed.

如下任务被杀死就是因为MRAPPMaster主动要求杀死的备份任务

2.任务的推测执行

实际开发中查看yarn日志可能会遇到，为啥显示有257reduce没跑完，下面attempt里却有261redcues 处于running状态呢？

MRappMaster当监控到一个任务实例的运行速度慢于其他任务实例时，会为该任务启动一个备份任务，让这个两个任务同时处理一份数据，如map/reduce。谁先处理完，成功提交给MRappMaster就采用谁的，另一个则会被killed，这种方式可以有效防止那些长尾任务拖后腿。是为任务推测speculative execution。

任务推测执行的好处就是空间换时间，防止长尾拖后腿的，比如某个实例所在的机器不行跑的贼慢，重启一个很快执行完了。任务推测的坏处就是两个重复任务，浪费资源，降低集群的效率，尤其redcue任务的推测执行，拉群map数据加大网络io，而且推测任务可能会相互竞争。

默认集群开启推测执行，可以基于集群计算框架，也可以基于任务类型单独开启,map任务建议开启，reduce可以结合实际谨慎开启。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

531)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！