【Spark篇】---Spark资源调度和任务调度

1、前述数据库

 

Spark的资源调度是个很重要的模块,只要搞懂原理,才能具体明白Spark是怎么执行的,因此尤为重要。app

自愿申请的话,本文分粗粒度和细粒度模式分别介绍。spa

 

2、具体线程

 

  • Spark资源调度流程图:

        

 

 

  • Spark资源调度和任务调度的流程:

                 一、启动集群后,Worker节点会向Master节点汇报资源状况,Master掌握了集群资源状况。对象

              二、当Spark提交一个Application后,根据RDD之间的依赖关系将Application造成一个DAG有向无环图。任务提交后,Spark会在Driver端建立两个对象:DAGScheduler和TaskScheduler。blog

              三、DAGScheduler是任务调度的高层调度器,是一个对象。DAGScheduler的主要做用就是将DAG根据RDD之间的宽窄依赖关系划分为一个个的Stage,而后将这些Stage以TaskSet的形式提交给TaskScheduler(TaskScheduler是任务调度的低层调度器,这里TaskSet其实就是一个集合,里面封装的就是一个个的task任务,也就是stage中的并行度task任务)ip

             四、TaskSchedule会遍历TaskSet集合,拿到每一个task后会将task发送到计算节点Executor中去执行(其实就是发送到Executor中的线程池ThreadPool去执行)。资源

             五、task在Executor线程池中的运行状况会向TaskScheduler反馈,spark

             六、当task执行失败时,则由TaskScheduler负责重试,将task从新发送给Executor去执行,默认重试3次。若是重试3次依然失败,那么这个task所在的stage就失败了。pip

             七、stage失败了则由DAGScheduler来负责重试,从新发送TaskSet到TaskSchdeuler,Stage默认重试4次若是重试4次之后依然失败,那么这个job就失败了。job失败了,Application就失败了。

             八、TaskScheduler不只能重试失败的task,还会重试straggling(落后,缓慢)task(也就是执行速度比其余task慢太多的task)。若是有运行缓慢的task那么TaskScheduler会启动一个新的task来与这个运行缓慢的task执行相同的处理逻辑。两个task哪一个先执行完,就以哪一个task的执行结果为准。这就是Spark的推测执行机制。在Spark中推测执行默认是关闭的。推测执行能够经过spark.speculation属性来配置。

 

             总结:

                       一、对于ETL类型要入数据库的业务要关闭推测执行机制,这样就不会有重复的数据入库。

                   二、若是遇到数据倾斜的状况,开启推测执行则有可能致使一直会有task从新启动处理相同的逻辑,任务可能一直处于处理不完的状态。(因此通常关闭推测执行)

                   三、一个job中多个action, 就会有多个job,通常一个action对应一个job,若是一个application中有多个job时,按照顺序一次执行,即便后面的失败了,前面的执行完了就完了,不会回滚。

                   四、有SparkContext端就是Driver端。

                   五、通常到以下几行时,资源就申请完了,后面的就是处理逻辑了

                             val conf = new SparkConf()
                             conf.setMaster("local").setAppName("pipeline");
                             val sc = new SparkContext(conf)

 

  • 粗粒度资源申请和细粒度资源申请

               粗粒度资源申请(Spark

               Application执行以前,将全部的资源申请完毕,当资源申请成功后,才会进行任务的调度,当全部的task执行完成后,才会释放这部分资源。

               优势:Application执行以前,全部的资源都申请完毕,每个task运行时直接使用资源就能够了,不须要task运行时在执行前本身去申请资源task启动就快了,task执行快了,stage执行就快了,job就快了,application执行就快了。

               缺点:直到最后一个task执行完成才会释放资源,集群的资源没法充分利用。当数据倾斜时更严重

              细粒度资源申请(MapReduce

             Application执行以前不须要先去申请资源,而是直接执行,让job中的每个task在执行前本身去申请资源,task执行完成就释放资源。

             优势:集群的资源能够充分利用。

 

             缺点:task本身去申请资源,task启动变慢,Application的运行就相应的变慢了。

相关文章
相关标签/搜索