上次在做内部培训的时候,我讲了这么一句:
一个Job里的Stage都是串行的,前一个Stage完成后下一个Stage才会进行。
显然上面的话是不严谨的。
看如下的代码:
![1063603-dadbb6057f2007a8.png](https://i-blog.csdnimg.cn/blog_migrate/aa905967a16398bbb2ab37fd415adbb9.webp?x-image-process=image/format,png)
这里的话,我们构建了两个输入(input1,input2),input2带有一个reduceByKey,所以会产生一次Shuffle,接着进行Join,会产生第二次Shuffle(值得注意的是,join 不一定产生新的Stage,我通过强制变更join后的分区数让其发生Shuffle ,然后进行Stage的切分)。
所以这里一共有两次Shuffle,产生了四个Stage。 下图是Spark UI上呈现的。那这四个Stage的执行顺序是什么呢?
![1063603-5bb1a793a13bed69.png](https://i-blog.csdnimg.cn/blog_migrate/28b121fdc64fcd1ad2aacdda0534d663.webp?x-image-process=image/format,png)
再次看Spark UI上的截图:
![1063603-fc49cecc1484ef85.png](https://i-blog.csdnimg.cn/blog_migrate/647d1efd1923450569012bde783fbd45.webp?x-image-process=image/format,png)
我们仔细分析下我们看到现象:
首先我们看到 Stage0,Stage 1 是同时提交的。
Stage0 只有两条记录,并且设置了两个Partition,所以一次性就能执行完,也就是3s就完成了。
Stage1 有四个分区,六条记录,记录数最多的分区是两条,也就是需要执行10秒,如果完全能并行执行,也就是最多10s。但是这里消耗了13秒,为什么呢?点击这个13秒进去看看:
![1063603-69eb5e82d3941931.png](https://i-blog.csdnimg.cn/blog_migrate/965e1999ccf9ff6612e57eafd23e7f78.webp?x-image-process=image/format,png)
我们看到有两个task 延迟了3秒后才并行执行的。 根据上面的代码,我们只有四颗核供Spark使用,Stage0 里的两个任务因为正在运行,所以Stage1 只能运行两个任务,等Stage0 运行完成后,Stage1剩下的两个任务才接着运行。
之后Stage2 是在Stage1 执行完成之后才开始执行,而Stage3是在Stage2 执行完成才开始执行。
现在我们可以得出结论了:
- Stage 可以并行执行的
- 存在依赖的Stage 必须在依赖的Stage执行完成后才能执行下一个Stage
- Stage的并行度取决于资源数
我么也可以从源码的角度解释这个现象:
![1063603-739574b213730bd4.png](https://i-blog.csdnimg.cn/blog_migrate/c4b4493d57c0d5492972af16094558b1.webp?x-image-process=image/format,png)
我们看到如果一个Stage有多个依赖,会深度便利,直到到了根节点,如果有多个根节点,都会通过submitMissingTasks 提交上去运行。当然Spark只是尝试提交你的Tasks,能不能完全并行运行取决于你的资源数了。
这里再贡献一张画了很久的示意图,体现了partition,shuffle,stage,RDD,transformation,action,source 等多个概念。
![1063603-4780613a66b1aea5.png](https://i-blog.csdnimg.cn/blog_migrate/38b635e898633cd4e7b67aa119c60b48.webp?x-image-process=image/format,png)