RDD的依赖关系

RDD的依赖关系_第1张图片
1.窄依赖是指每个父RDD的一个Patition最多被子RDD的一个Pation所使用,例如map、filter、union等都会产生窄依赖
2.宽依赖就是指一个父RDD的Patition会被多个子RDD的Partiton所使用,例如goupdByKey、filter、union等操作都会产生宽依赖

总结:如果父RDD的一个Partition被一个子RDD的Partition所使用就是窄依赖,否则的话就是宽依赖。如果子RDD中的Partition对父RDD的Partition依赖的数量不会随着RDD数据规模的改变而改变的话,就是窄依赖,否则的话就是宽依赖。

特别说明:对join操作有两种情况,如果说join操作的使用每个pation仅仅和已各的patition进行join,这次是join操作就是窄依赖
因为是确定的partition数量的依赖关系,所有就是窄依赖,得出一个推论,窄依赖不仅包含一对一的窄依赖,还包含一对固定个数的窄依赖(也就是说对父RDD的依赖的Partition的数量不会随着RDD数据规模的改变而改变)

3.rdd基于依赖构成stage。

RDD的依赖关系_第2张图片
4.如果把整个看做一个stage会导致:

产生大量中间结果(因为要挨个算);Task太大,遇到Shuffle级别的依赖关系必须计算依赖的RDD的所有的Partitions,并且都发生在一个Task中计算;重复计算;难管理;

上面两种假设的核心问题都是在遇到Shuffle依赖的时候无法进行pipeline。

注意:

1)从后往前推理,遇到宽依赖就断开,遇到窄依赖就把当前的RDD加入到该stage;

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

3)最后一个stage里面的任务的类型是ResultTask,前面其他所有的stage里面的任务的类型都是ShuffleMapTask。

4)代表当前stage的算子一定是该stage的最后一个步骤。

补充:Hadoop中的mapreduce操作的mapper和reducer在spark中基本等量算子是:

Map,reduceByKey

表面上是数据在流动,实质上是算子在流动(函数编程):

  1. 数据不动代码动

  2. 在一个stage内部算子为何会流动(Pipeline)?首先是算子合并,也就是所谓的函数式编程的执行的时候最终进行函数的展开从而把一个stage内部的多个算子合并成为一个大算子(其内部包含了当前stage中所有的算子对数据的计算逻辑);其次是由于Tranformation的Lazy特性!!!在具体算子交给集群的Executor计算之前首先会通过SparkFramework(DAGScheduler)进行算子的优化(基于数据本地性的pipeline)

你可能感兴趣的:(spark,RDD,窄依赖,宽依赖)