RDD的依赖关系笔记

窄依赖和宽依赖：

窄依赖：每个父RDD的一个Partition最多被子RDD的一个Partition所使用。如map，filter，union操作都会产生窄依赖。
宽依赖：一个父RDD的Partition会被多个子RDD的Partition所使用。如groupByKey，reduceByKey，sortByKey等操作都会产生宽依赖。宽依赖会产生Shuffle操作。
也就是说，如果父RDD的一个Partition被一个子RDD的Partition所使用就是窄依赖，或者，对父RDD的Partition依赖的子RDD的Partition数量不会随着RDD数据规模的改变而改变，也是窄依赖，否则就是宽依赖。
join操作有两种情况：如果在join操作时，每个Partition只和已知的Partition进行join（确定的Partition数量的依赖关系），此时为窄依赖，其他情况的join操作是宽依赖。只要是确定的Partition数量的依赖关系，就是窄依赖。窄依赖不仅仅包含一对一的情况，还有一对固定个数的情况，也就是对父RDD的依赖Partition的数量不会随着RDD数据规模的改变而改变。

如果将所有RDD操作放在同一个具体的Stage中，各RDD操作不同，需要串行执行，任务无法并行执行，会产生大量的中间数据，并且内存无法释放，会严重影响运行效率。
如果假设G为最后一个RDD，G中有三个Partition，为每个Partition分片分配一个Task，G中的第一个Partition数据分片同时来源于B中的一个数据分片和F中的四个数据分片，B中一个数据分片来源于A中的三个分片，此时Task太大，并且在遇到Shuffle级别的依赖关系时，必须计算依赖的RDD的所有Partition，这都在一个Task中计算，在计算G中第二个和第三个分片时前面的数据又要重复计算。
以上两种假设方法都不可靠，主要是因为在遇到Shuffle依赖时，无法进行pipeline。但其可取之处在于回溯的思想。我们可以进行回溯，在遇到Shuffle级别依赖时，将其断开划分出新的Stage，遇到窄依赖就把当前RDD加入该Stage。由于groupByKey和此处的join为Shuffle级别，故A为一个Stage，C、D、E为一个Stage，B和G为一个Stage。
每个Stage里面的Task的数量是由该Stage中最后一个RDD的Partition的数量决定的。
代表当前Stage的算子一定是该Stage的最后一个计算步骤。
Hadoop中的MapReduce操作中的Mapper和Reducer在Spark中的基本等量算子是map和reduceByKey。
表面上是数据在流动，实质是算子在流动：
1.数据不动代码动
2.在一个Stage中算子流动的原因：首先是算子合并，也就是函数式编程执行的时候最终会进行函数的展开，从而把一个Stage内部的多个算子合并成一个大算子（其内部包含了当前Stage中所有算子对数据的计算逻辑）；其次是由于Transformation的Lazy特性。在具体算子交给集群的Executor计算之前，首先会通过Spark框架（DAGScheduler）进行算子的优化（基于数据本地性的Pipeline）。