所谓推测式执行,就是计算框架判断,如果有一个task执行的过慢,则会启动备份任务,最终使用原任务+备份任务中执行较快task的结果。产生原因一般是程序bug、负载倾斜。
那么这个较慢,是怎么判断的呢?
有如下具体的算法:
比较两个时间。一是根据推测式算法计算出来的task最终完成时刻,也就是按着任务当前的运行速度,推测出来的时刻。暂且命名为oldtime
二是如果此刻启动该任务,则推测出来将要完成的时刻,这个是按着已运行完的任务推测出来的时刻。暂且命名为newtime
如果newtime的时间点在oldtime之后,则不会启动推测任务。因为即使启动了,最终完成时间是更晚的,没有意义。
oldtime计算方式: (timestamp – start) / Math.max(0.0001, progress) +taskbegintime
解释:
timestamp是当前时刻
start是任务已经运行的时间
progress是任务运行的比例(0.1-1)
taskbegintime是任务启动所用时间
加号前面计算出,按当前这个task已运行完部分的速度,计算出整个运行完会占用多少时间。
newtime计算方式:当前的时刻+已经运行完的task的平均所使用的时间是多长。
那么执行这个推测任务,都有什么先决条件呢?
1、每个task只能有一个备份任务
2、当前job已完成的task必须不小于0.05(5%)
那么,MRv2就会选择oldtime-newtime值最大的task执行推测式任务。
那么是谁来执行这个推测任务的呢?
是一个叫DefaultSpeculator(实现了Speculator)的服务,定时扫一遍task,判断是否有task需要启动备份任务。
题外话:看到大牛blog里有这么一段话,摘抄过来:
hadoop中有三种特殊的任务,failed task,killed task和speculative task,其中,failed task是由于硬件、程序bug等原因异常退出的任务,比如磁盘空间不足等,是task自己退出, killed task是Hadoop主动将其杀死的任务,比如一个任务占用过多的内存,为了不影响其他作业的正常运行,Hadoop需将这种恶心的任务杀死,以保证为所有作业提供一个“和谐”的任务执行环境。在容错方面,failed task再次调度时不会在那些曾经失败的节点上运行,而killed task则可能被再次调度到任何一个节点上(包括曾经失败多的节点),因此,如果你目测一个作业的任务运行很慢,你可以使用“bin/hadoop job -fail-task xxx”让这个任务换一个节点重新运行,而不是使用“bin/hadoop job -kill-task xxx”。 speculative task是Hadoop针对那些慢任务(慢任务会拖慢一个作业的完成时间),为他们额外启动一个备份任务,一起处理同一份数据,哪个先执行完,则采用哪个的处理结果,同时将另外一个任务杀死。也就是说,推测执行是Hadoop对慢任务的一种优化机制(实际上就是“空间换时间”的经典优化思想),不属于容错调度范畴。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· [AI/GPT/综述] AI Agent的设计模式综述