任务调度，你懂吗？来听阿里大老一张图解释spark任务调度

 

 

关于任务调度，主要通过上面的这张图进行一个相应的讲解，在这张图里面主要分为两个部分，一是关于任务调度的流程，二是关于任务调度的重试机制，这也是我们spark优化的其中一个方面

首先是RDD Object，

这也就相当于我们的应用程序，当我们在开发一个application的时候我们会将一个个的RDD之间有了一个依赖关系，形成一个有向无环图，然后我们将这个有向无环图提交给DAGScheduler，它存在于Driver中，而我们都知道Driver的作用就是根绝RDD的宽窄以来的关系对job进行切割，划分Stage，每一个stage中包含一组并行执行的task，并将Stage封装到taskSet中然后分发到TaskScheduler中， taskScheduler会将taskSet中的任务抽取出来然后分发到各个不同的Executor中进行执行

相信大家又有疑问了，那这个数据的分发是怎么进行的呢？

他会根据我们的数据位置进行分发，那为什么会这样呢？大家应该都知道，大数据的一个工作原理是计算向数据移动，节省了磁盘和网络IO，提高了运行的效率，这是他的一个标准，所有的任务的执行都会遵循这个标准进行工作的处理，然后taskScheduler将数据分发到worker节点上的Executor进行处理。

但是我们也都知道，有的时候车一次性启动不起来，那我相信正常人的做法就是在启动一次，不会直接放弃这辆车然后重新买车吧，当然了，要是家里有矿的话咱另说，你是土豪我也没办法，在spark的任务调度中也是存在这种机制的，他就是重试机制，当task在Executor中执行失败之后TaskScheduler负责重试，默认重试3次，如果三次重试之后还是失败那怎么办呢？我会打电话找4s店，让他们委派专业的人员来进行操作，也就是DAGScheduler继续进行重试，如果默认重试3次，如果还是失败了，那么这个job也就结束了，无法执行，这辆车也就要重新回厂了

但是有的时候车子启动不了可能不是因为你的原因，而是车子的原因，比如车钥匙或者继电器不好用了，那么我会直接联系4s店，在spark中也是这样的，当task的失败是由于Shuffle file not find造成的，那么TaskScheduler是不会负责重试的，会直接联系4S店，DAGScheduler进行重试

就像本田的机油门事件，你能说它性能不好吗？不是的，他只是那一部分车拖了后腿，在spark中叫做推测执行机制（拖后腿），那遇到拖后腿的怎么办，本田的做法是将这个型号的车进行了召回，那spark呢，他会启动一个和拖后腿的task完全一样的task进行比赛，这两个task谁先执行完就以谁的执行时间为准

那么拖后腿的任务是怎么选择的呢？

在默认的情况下，如果有75%的任务已经执行完毕了，剩下的task去一个中位数然后乘1.5得到一个新的时间节点，然后进行比对，超过这个时间的就是拖后腿的任务，但是重试机制会有一个重复数据的问题，当数据出错后会重新执行，先前产生的数据就会和后来的数据重复，或者进行ETL的时候，task进行的操作多而且时间会很长，当推测执行机制启动之后我们会认为它是拖后腿任务然后会启动一个完全一样的任务进行执行，那这两个task的执行结果就会产生冲突，造成数据的重复，解决方法就是采用幂等操作，对于幂等操作的简单解释就是别人打你10巴掌你就感觉到了一巴掌，反射神经有点长

这就是关于spark任务调度的相关过程，难吗？不难！简单吗？不简单吧，但是，随着大数据以及人工智能的发展，spark，flink这样的一些处理技术如日中天的发展起来，但是我们该如何去准备呢？明知道是高薪产业却啃不到这块蛋糕，难受吗？

那就看我给你们准备的资料吧，私信“资料”获取

 

 

需要更多大数据，架构资料，私信“资料”获取偶，小编为你们准备了大量的文档视频以及面试资料呦