Standalone
Standalone-client模式:启动集群的时候worker现象master汇报情况(都有什么资源);client用spark-submit提交任务:提交任务的时候会在本机上启动driver进程;
接着向master申请资源(在跑任务之前);然后driver进程就会发送到任务到节点上的excutor运行;运行完成后回收结果
总结:
Client模式,会在客户端启动diver,并且可以看到log和总结果
注意:此种方式一般是用于测试用的。这么做的原因是,假设有10个application任务在本机上运行,会造成网卡流量激增,严重情况下会挤掉其他进程
Standalone-cluster模式:启动集群的时候worker现象master汇报情况(都有什么资源);client用spark-submit提交任务的时候:想master申请启动driver进程;master会根据worker提供的资源情况,了来随机调一台合适的机器启动diver进程;这个diver进程就会向master申请APPalication资源;master就会给diver返回一批符合资源要求的worker节点;然后driver进程就会发送到任务到节点上的excutor运行;运行完成后回收结果
总结:
Cluster模式:driver进程随机运行worker节点
Yarn
Yarn-client模式:client中的saprk -submit提交任务是,会在本机上面启动diver;然后向ResouceManager(简称RM)申请启动ApplicationMaster(简称AM);RM会随机选择以后合适的节点开启AM;然后AM向RM申请资源;RM然会返回携带符合资格的continer资源的NM;client将任务(task)发送给AM;AM向excutor发送任务并返回结果。
总结:
Yarn-client模式同样是适用于测试,因为Driver运行在本地,Driver会与yarn集群中的Executor进行大量的通信,会造成客户机网卡流量的大量增加.
Yarn-cluster:client用spark-submit提交任务的时候:向ResouceManager(简称RM)申请启动driver进程;RM会根据worker提资源情况,了来随机调一台合适的机器启动diver(AM)进程;这个diver进程就会向RM申请APPalication资源;RM就会给diver返回一批符合cantiner资源要求的NM节点;然后driver进程就会发送到任务到节点上的excutor运行;excutor运行完成后回收结果
总结:
Yarn-Cluster主要用于生产环境中,因为Driver运行在Yarn集群中某一台nodeManager中,每次提交任务的Driver所在的机器都是随机的,不会产生某一台机器网卡流量激增的现象,缺点是任务提交后不能看到日志。只能通过yarn查看日志。
术语技术解释:
宽窄依赖
宽依赖与窄依赖
RDD之间的一系列的依赖关系分为窄依赖和宽依赖
当父RDD中的patition对子RDD的patition是一对一或者,多对一个也是窄依赖,当反过来,父RDD的patition对子RDD的patition的一对多的时候是宽依赖。当窄依赖时就不会产生shafull,宽依赖的时候会产生shafull,影响速度。算子决定了是宽依赖和窄依赖:。。。。。。。。。
stage
数据一直在管道里面什么时候数据会落地?
- 对RDD进行持久化。
- shuffle write的时候。
如何改变RDD的分区数?
例如:reduceByKey(XXX,3),GroupByKey(4)
流程
1. spark 会根据RDD的依赖关系产生DAG有向无环图
2.DAGScehdule会将有向无环图进行切割
3.从finalRDD往前追溯,遇到宽依赖,产生一个stage,遇到窄依赖继续往前追溯.
几个小点
Patition里边不是数据而是计算逻辑
宽依赖算子可以改变分区。因为它已经产生了shuafull,数据都已经放在了磁盘里,所以我模拟可以重新分配
Stage不能跨job:RDD只有结束才会触发JOB。
Stage的task并行度是由stage的最后一个RDD的分区数来决定的 。
Spark资源调度和任务调度的流程
启动集群后,Worker节点会向Master节点汇报资源情况,Master掌握了集群资源情况。当Spark提交一个Application后,根据RDD之间的依赖关系将Application形成一个DAG有向无环图。任务提交后,Spark会在Driver端创建两个对象:DAGScheduler和TaskScheduler,DAGScheduler是任务调度的高层调度器,是一个对象。DAGScheduler的主要作用就是将DAG根据RDD之间的宽窄依赖关系划分为一个个的Stage,然后将这些Stage以TaskSet的形式提交给TaskScheduler(TaskScheduler是任务调度的低层调度器,这里TaskSet其实就是一个集合,里面封装的就是一个个的task任务,也就是stage中的并行度task任务),TaskSchedule会遍历TaskSet集合,拿到每个task后会将task发送到计算节点Executor中去执行(其实就是发送到Executor中的线程池ThreadPool去执行)。task在Executor线程池中的运行情况会向TaskScheduler反馈,当task执行失败时,则由TaskScheduler负责重试,将task重新发送给Executor去执行,默认重试3次。如果重试3次依然失败,那么这个task所在的stage就失败了。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重新启动处理相同的逻辑,任务可能一直处于处理不完的状态。
图解Spark资源调度和任务调度的流程
粗粒度资源申请和细粒度资源申请
- 粗粒度资源申请(Spark)
在Application执行之前,将所有的资源申请完毕,当资源申请成功后,才会进行任务的调度,当所有的task执行完成后,才会释放这部分资源。
优点:在Application执行之前,所有的资源都申请完毕,每一个task直接使用资源就可以了,不需要task在执行前自己去申请资源,task启动就快了,task执行快了,stage执行就快了,job就快了,application执行就快了。
缺点:直到最后一个task执行完成才会释放资源,集群的资源无法充分利用。
- 细粒度资源申请(MR)
Application执行之前不需要先去申请资源,而是直接执行,让job中的每一个task在执行前自己去申请资源,task执行完成就释放资源。
优点:集群的资源可以充分利用。
缺点:task自己去申请资源,task启动变慢,Application的运行就响应的变慢了。