1、DAG

DAG图中，每个节点都是RDD

窄依赖（也叫narrow依赖）

从父RDD角度看：一个父RDD只被一个子RDD分区使用。父RDD的每个分区最多只能被一个Child RDD的一个分区使用

从子RDD角度看:依赖上级RDD的部分分区     精确知道依赖的上级RDD分区，会选择和自己在同一节点的上级RDD分区，没有网络IO开销，高效。

窄依赖包括：

OneToOneDependency
PruneDependency
RangeDependency

对应的RDD方法包括：

map
  mapValues
  flatMap
  filter
  mapPartitions
  mapPartitionsWithIndex

宽依赖（也叫shuffle依赖/wide依赖）

从父RDD角度看：一个父RDD被多个子RDD分区使用。父RDD的每个分区可以被多个Child RDD分区依赖

从子RDD角度看:依赖上级RDD的所有分区     无法精确定位依赖的上级RDD分区，相当于依赖所有分区（例如reduceByKey）  计算就涉及到节点间网络传输。 

宽依赖通常的dependency为ShuffleDependency

对应的RDD方法包括：（有些RDD方法支持参数可配置是否进行shuffle）

cogroup
groupWith
join
leftOuterJoin
rightOuterJoin
groupByKey
reduceByKey
combineByKey
distinct
intersection
repartition
coalesce

 

Spark之所以将依赖分为narrow和 shuffle：

(1) narrow dependencies可以支持在同一个集群Executor上，以pipeline管道形式顺序执行多条命令，例如在执行了map后，紧接着执行filter。分区内的计算收敛，不需要依赖所有分区的数据，可以并行地在不同节点进行计算。所以它的失败恢复也更有效，因为它只需要重新计算丢失的parent partition即可，

(2)shuffle dependencies 则需要所有的父分区都是可用的，必须等RDD的parent partition数据全部ready之后才能开始计算，可能还需要调用类似MapReduce之类的操作进行跨节点传递。从失败恢复的角度看，shuffle dependencies 牵涉RDD各级的多个parent partition。

 

划分stage：

由于shuffle依赖必须等RDD的parent RDD partition数据全部ready之后才能开始计算，因此spark的设计是让parent RDD将结果写在本地，完全写完之后，通知后面的RDD。后面的RDD则首先去读之前的本地数据作为input，然后进行运算。

由于上述特性，将shuffle依赖就必须分为两个阶段(stage)去做：

第一个阶段(stage)需要把结果shuffle到本地，例如reduceByKey，首先要聚合某个key的所有记录，才能进行下一步的reduce计算，这个汇聚的过程就是shuffle。

第二个阶段(stage)则读入数据进行处理。

同一个stage里面的task是可以并发执行的，下一个stage要等前一个stage ready

（和mapreduce的reduce需要等map过程ready 一脉相承）

为什么要写在本地？

后面的RDD多个partition都要去读这个信息，如果放到内存，如果出现数据丢失，后面的所有步骤全部不能进行，违背了之前所说的需要parent RDD partition数据全部ready的原则。

为什么要保证parent RDD要ready？

如果有一个partition未生成或者在内存中丢失，那么直接导致计算结果是完全错误的。

写到文件中更加可靠。Shuffle会生成大量临时文件，以免错误时重新计算，其使用的本地磁盘目录由spark.local.dir指定，缓存到磁盘的RDD数据。最好将这个属性设定为访问速度快的本地磁盘。可以配置多个路径到多个磁盘，增加IO带宽。

 

Spark任务层级基本关系：

一个spark submit的任务 称为一个job，一个job下会按照宽依赖分为多个stage，每个stage中 又会根据并行度被分成多个task。

 

任务结果的获取

一个具体的任务在Executor中执行完毕以后，其结果需要以某种形式返回给DAGScheduler，根据任务类型的不同，任务的结果的返回方式也不同

对于FinalStage所对应的任务（对应的类为ResultTask）返回给DAGScheduler的是运算结果本身，而对于ShuffleMapTask，返回给DAGScheduler的是一个MapStatus对象，MapStatus对象管理了ShuffleMapTask的运算输出结果在BlockManager里的相关存储信息，而非结果本身，这些存储位置信息将作为下一个Stage的任务的获取输入数据的依据

而根据任务结果的大小的不同，ResultTask返回的结果又分为两类，如果结果足够小，则直接放在DirectTaskResult对象内，如果超过特定尺寸（默认约10MB）则在Executor端会将DirectTaskResult先序列化，再把序列化的结果作为一个Block存放在BlockManager里，而后将BlockManager返回的BlockID放在IndirectTaskResult对象中返回给TaskScheduler，TaskScheduler进而调用TaskResultGetter将IndirectTaskResult中的BlockID取出并通过BlockManager最终取得对应的DirectTaskResult。当然从DAGScheduler的角度来说，这些过程对它来说是透明的，它所获得的都是任务的实际运算结果。