上次在做内部培训的时候，我讲了这么一句：
<b>一个job里的stage都是串行的，前一个stage完成后下一个stage才会进行。</b>
显然上面的话是不严谨的。
看如下的代码：
snip20160903_17.png
这里的话，我们构建了两个输入(input1,input2)，input2带有一个reducebykey,所以会产生一次shuffle,接着进行join,会产生第二次shuffle(值得注意的是，join 不一定产生新的stage,我通过强制变更join后的分区数让其发生shuffle ，然后进行stage的切分)。
所以这里一共有两次shuffle,产生了四个stage。 下图是spark ui上呈现的。那这四个stage的执行顺序是什么呢？
snip20160903_11.png
再次看spark ui上的截图：
snip20160903_16.png
我们仔细分析下我们看到现象：
首先我们看到 stage0,stage 1 是同时提交的。
stage0 只有两条记录，并且设置了两个partition,所以一次性就能执行完,也就是3s就完成了。
stage1 有四个分区，六条记录，记录数最多的分区是两条，也就是需要执行10秒，如果完全能并行执行，也就是最多10s。但是这里消耗了13秒，为什么呢？点击这个13秒进去看看：
snip20160903_15.png
我们看到有两个task 延迟了3秒后才并行执行的。 根据上面的代码，我们只有四颗核供spark使用，stage0 里的两个任务因为正在运行，所以stage1 只能运行两个任务，等stage0 运行完成后，stage1剩下的两个任务才接着运行。
之后stage2 是在stage1 执行完成之后才开始执行，而stage3是在stage2 执行完成才开始执行。
现在我们可以得出结论了：
stage 可以并行执行的
存在依赖的stage 必须在依赖的stage执行完成后才能执行下一个stage
stage的并行度取决于资源数
我么也可以从源码的角度解释这个现象：
snip20160903_18.png
我们看到如果一个stage有多个依赖，会深度便利，直到到了根节点，如果有多个根节点，都会通过submitmissingtasks 提交上去运行。当然spark只是尝试提交你的tasks,能不能完全并行运行取决于你的资源数了。
这里再贡献一张画了很久的示意图，体现了partition，shuffle，stage,rdd,transformation,action,source 等多个概念。