day22:RDD的依赖关系彻底解密
本文整理来源于DT大数据梦工厂:
1、窄依赖：每个父RDD的一个Partition最多被子RDD的一个Partition所使用。例如map，filter都会产生窄依赖
2、宽依赖：一个父RDD的Partition会被多个子RDD的partition所使用：例如groupbyKey， reduceBykey，sortByKey
总结：如果父RDD 的一个partition被一个子RDD 的partition所使用就是窄依赖，否则则的话就是宽依赖。如果子RDD
的partition对父RDD的partition依赖的数量不会随着RDD数据规模的改变而改变的话，就是窄依赖，否则的话就是宽依赖。
特别说明：
前后所有关联的RDD构成一个Stage，将所有的Stage放在一个stage，会有一个严重的问题，这个问题是什么：会挨个执行，会产生大量的中间数据。
因为中间数据重组起来才会重新计算。每个Partition之间数据会彼此不干扰，有3个partition，为每一个partition分配一个Task
产生问题：1、 Task太大 2、shuffle级别的依赖关系必须计算依赖RDD的所有partition并且都发生在一个Task中计算。（Task过大，进行重复性计算）
回溯血统pipeline，2种假设的核心都是在遇到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
遇到shuffle 一定要断开计算：任务太多，数据太大，
satge1 和stage2 都是 Stage的pater（父）
二： 数据在流动， 实际上是算子在流动
数据不动，代码动：
在一个Stage内幕算子为何会流动（pipeline）？首先算子合并也就是所谓的函数式编程执行的时候最终进行函数的展开，从把一个人stage内部的多个算子合并成为一个算子（其内部包括了当前stage中所有算子对数据的计算逻辑）；其次是由于Tranformation操作的Lazy特效。在具体算子交给集群的Executor计算之前首先会通过SparkFramework（DAGshceduler）进行算子的优化（基于本地性的pipeline）
ShuffleDependency
NarrowDependency
作业：RDD彻底解密写博客
ＤＴ大数据梦工厂联系方式：
新浪微博：www.weibo.com/ilovepains/
微信公众号：DT_Spark
博客：http://.blog.sina.com.cn/ilovepains
TEL:18610086859
Email:[email protected]