Spark宽窄依赖详解

1.宽窄依赖

 

图中左边是宽依赖,父RDD的4号分区数据划分到子RDD的多个分区(一分区对多分区),这就表明有shuffle过程,父分区数据经过shuffle过程的hash分区器(也可自定义分区器)划分到子RDD。例如GroupByKey,reduceByKey,join,sortByKey等操作。

图右边是窄依赖RDD的每个分区的数据直接到子RDD的对应一个分区(一分区对一分区),例如1号到5号分区的数据都只进入到子RDD的一个分区,这个过程没有shuffle。Spark中Stage的划分就是通过shuffle来划分。shuffle可理解为数据的从原分区打乱重组到新的分区)如:map,filter

总结:如果父RDD的一个Partition被一个子RDD的Partition所使用就是窄依赖,否则的话就是宽依赖。

2.宽窄依赖&&容错性

Spark基于lineage的容错性是指,如果一个RDD出错,那么可以从它的所有父RDD重新计算所得,如果一个RDD仅有一个父RDD(即窄依赖),那么这种重新计算的代价会非常小。

 

Spark基于Checkpoint(物化)的容错机制何解?在上图中,宽依赖得到的结果(经历过Shuffle过程)是很昂贵的,因此,Spark将此结果物化到磁盘上了,以备后面使用

对于join操作有两种情况,如果join操作的每个partition 仅仅和已知的Partition进行join,此时的join操作就是窄依赖;其他情况的join操作就是宽依赖;因为是确定的Partition数量的依赖关系,所以就是窄依赖,得出一个推论,窄依赖不仅包含一对一的窄依赖,还包含一对固定个数的窄依赖(也就是说对父RDD的依赖的Partition的数量不会随着RDD数据规模的改变而改变)

3.Stage的划分

名词解析

1.一个 job,就是由一个 rdd 的 action 触发的动作,可以简单的理解为,当你需要执行一个 rdd 的 action 的时候,会生成一个 job。

2.stage : stage 是一个 job 的组成单位,就是说,一个 job 会被切分成 1 个或 1 个以上的 stage,然后各个 stage 会按照执行顺序依次执行。

3.task :即 stage 下的一个任务执行单元,一般来说,一个 rdd 有多少个partition,就会有多少个 task,因为每一个 task 只是处理一个partition 上的数据。

划分规则

1.从后向前推理,遇到宽依赖就断开,遇到窄依赖就把当前的RDD加入到Stage中;

2.每个Stage里面的Task的数量是由该Stage中最后 一个RDD的Partition数量决定的;

3.最后一个Stage里面的任务的类型是ResultTask,前面所有其他Stage里面的任务类型都是ShuffleMapTask;

4.代表当前Stage的算子一定是该Stage的最后一个计算步骤;

总结:由于spark中stage的划分是根据shuffle来划分的,而宽依赖必然有shuffle过程,因此可以说spark是根据宽窄依赖来划分stage的。

Spark优化

窄依赖对优化很有利。逻辑上,每个RDD的算子都是一个fork/join(此join非上文的join算子,而是指同步多个并行任务的barrier):把计算fork到每个分区,算完后join,然后fork/join下一个RDD的算子。如果直接翻译到物理实现,是很不经济的:一是每一个RDD(即使 是中间结果)都需要物化到内存或存储中,费时费空间;二是join作为全局的barrier,是很昂贵的,会被最慢的那个节点拖死。如果子RDD的分区到 父RDD的分区是窄依赖,就可以实施经典的fusion优化,把两个fork/join合为一个;如果连续的变换算子序列都是窄依赖,就可以把很多个 fork/join并为一个,不但减少了大量的全局barrier,而且无需物化很多中间结果RDD,这将极大地提升性能。Spark把这个叫做流水线(pipeline)优化。

Spark流水线优化:

 

变换算子序列一碰上shuffle类操作,宽依赖就发生了,流水线优化终止。在具体实现 中,DAGScheduler从当前算子往前回溯依赖图,一碰到宽依赖,就生成一个stage来容纳已遍历的算子序列。在这个stage里,可以安全地实施流水线优化。然后,又从那个宽依赖开始继续回溯,生成下一个stage。

Pipeline

spark中pipeline是一个partition对应一个partition,所以在stage内部只有窄依赖。pipeline详解

stage与stage之间是宽依赖

4. 分布式计算过程

 

上图是一个Spark的wordcount例子,根据上述stage划分原则,这个job划分为2个stage,有三行,分别是数据读取、计算和存储过程。

仅看代码,用户根本体会不到数据在背后是并行计算。从图中能看出数据分布在不同分区(也可以理解不同机器上),数据经过flapMap、map和reduceByKey算子在不同RDD的分区中流转。(这些算子就是上面所说对RDD进行计算的函数)

下图从更高角度看:

 

Spark的运行架构由Driver(可理解为master)和Executor(可理解为worker或slave)组成,Driver负责把用户代码进行DAG切分,划分为不同的Stage,然后把每个Stage对应的task调度提交到Executor进行计算,这样Executor就并行执行同一个Stage的task。

(这里Driver和Executor进程一般分布在不同机器上)

这里有人可能不理解Stage和task,下图就是Spark的作业划分层次:

 

Application就是用户submit提交的整体代码,代码中又有很多action操作,action算子把Application划分为多个job,job根据宽依赖划分为不同Stage,Stage内划分为许多(数量由分区决定,一个分区的数据由一个task计算)功能相同的task,然后这些task提交给Executor进行计算执行,把结果返回给Driver汇总或存储。

这体现了 Driver端总规划–Executor端分计算–结果最后汇总回Driver 的思想,也就是分布式计算的思想。

文章仅作个人总结,部分内容摘自他处,不断更新

  • 14
    点赞
  • 108
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
Spark的执行流程可以分为以下几个步骤。 首先,任务调度器(TaskScheduler)将序列化好的任务递交给执行器(Executor)。执行器将任务放入线程池中进行运行。 其次,当程序触发Action算子时,就会产生一个作业(Job),并调用DagScheduler中的runjob方法来提交任务。 接着,Master收到应用程序的注册请求后,根据自己的资源调度算法,在Spark集群的worker上启动一个或多个Executor进程。 然后,DagScheduler根据作业的依赖关系生成有向无环图(DAG),确定任务的执行顺序。 之后,任务分发器(TaskSetManager)将任务分发给Executor,并监控任务的执行状态。 每个Executor在执行任务之前会将依赖的数据分片(RDD)从存储节点(如HDFS)中读取到内存中。 任务执行器(TaskRunner)根据任务的类型(如map、reduce等)执行计算并生成结果。 最后,计算结果会被返回给Driver程序,供后续处理或输出。 总结起来,Spark的执行流程包括任务调度、作业提交、资源分配、任务分发、数据读取、任务执行和结果返回等步骤。这些步骤保证了Spark的高效计算和数据处理能力。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [Spark执行流程详解](https://blog.csdn.net/qq_42456324/article/details/124499170)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值