为了解决 MapReduce的 频繁磁盘IO开销，序列化和反序列化的开销，
因为从磁盘读取数据转换为对象 需要反序列化， 在对象落磁盘时候 需要序列化。
spark通过抽象的RDD对象和DAG图，对数据读取流转进行优化， 最优方案实现流水线开发。
RDD逻辑上是一个数据集合，其数据是被分区后 分布式存储在各个机器上
即 每次生成的RDD是不能修改的，但是可以对老RDD进行转换 生成新RDD，来实现对RDD转换。
transformation： 只是记录转换的动作，并不会立马去执行， 具有懒惰性
action： 是行动动作，会立马触发 转换操作。
RDD支持粗粒度修改，只能一次对RDD全集进行转换
RDD 只能对全局数据进行修改，不能像 关系型数据库一样，精确的对某个特定的值进行修改
通过DAG 找到丢失的RDD的父类，来重新拉取/生成 已经丢失的RDD
把中间结果写入内存，减少磁盘io ，以及序列化和反序列化
DAG schedule 划分的主要依据是 各个RDD之间的依赖关系， 有两种依赖关系：宽依赖和窄依赖
如果是宽依赖 那就切分stage
如果是窄依赖 不切分
RDD之间是 宽依赖 或 窄依赖 主要看 两个RDD之间 有没有shuffle 即洗牌操作
如果从父RDD 到子RDD的时候 ，发生了 shuffle ，那么这两个 RDD就是 宽依赖， 那就会被DAG schedule 切分为两个 stage 阶段/作业
如果 父RDD 到子RDD的时候，没发生shuffle ，那么是窄依赖， 不会切分 stage
shuffle 中文意思是 洗牌，
那么对数据进行 打散重新分配，这个过程其实就是shuffle
如下图，文件中的数据， 传给了 3台 map节点，那么这3台蓝色的 map节点 处理完数据后， 要把数据传给 黄色的3台 reduce 节点，
关键点 就在这 3台蓝色的map节点是怎么 传给 黄色 3台reduce 节点的，
其实是 把map节点 所有数据进行 盘点洗牌，找到 （a, 1） 元素发给 reduce1节点，找到 （b, 1） 元素发给 reduce2节点.....
这个就是洗牌，对数据进行重新清洗，找到 特定元素 发给特定 节点。
shuffle 是需要大量的 节点之间的 网络IO开销的，并且shuffle一定会落磁盘。
有2种情况：
一个父RDD 对应多个 子RDD
因为如果 一个父RDD 对应多个 子RDD ，那么父RDD 会进行洗牌操作，找到特定的元素 发给特定的 某个子节点。
DAG schedule 根据RDD之间的宽窄依赖关系，划分stage ，其实是为了提高数据处理的效率，为了实现流水线优化。
简单点说 spark只能对 窄依赖进行优化， 宽依赖没法优化，所以要把宽窄依赖分开。
首先，在并行处理有2个基本的操作，fork 和 join ， fork 是分发 ，join是汇集
spark的流水线优化 其实就是对 不必要的join的 优化，减少不必要join，因为 join就可能有时间的等待
比如说，要实现把 北京一个学校的学生 送到厦门，根据宽窄依赖不同 可以有2种方案
如下图， 分别由班长带男生 和 组织委员带女生 ，分别乘坐飞机（并行处理），先飞往上海 集合后，再由班长带领男生 、组织委员带女生 ，从上海飞往厦门。
那么在这个过程中 由于要在上海集合， 所以班长带的男生 到达上海后 ，需要等待1小时的 女生，
然后，两班人马 从上海出发 到厦门后，又要 集合，所以 女生要等 男生1小时，
所以，全程用了 6小时。
在上边的例子中，班长带男生到上海后，等女生 1小时，其实是可以优化掉的， 班长可以直接从北京到厦门，组织委员也是
这个就是 DAG的流水线优化最基本原理
班长在带领 男生到上海后，需要带领 1班的学生去厦门， 而组织委员在带领女生到上海后，需要带领 2班学生去厦门
那么在 上海这个环节 就需要把同学重新分配，组织委员带领的1班女生要到 班长那边去 ，班长带的2班男生要到 组织委员那边去，
就有重新洗牌的操作了，就有shuffle，
而且班长提前到达 上海后，必须等组织委员和女生都到达以后 才能出发， 这也就是 宽依赖不能优化的原因。
宽依赖一定会落磁盘
如下图，A -> B 就是一个宽依赖， 所以A这部分 ，就切分为 一个stage
然后 C -> D -> F都是窄依赖 ， F -> G 是宽依赖 ，所以 C D F是一个stage
最后 G汇总又是一个stage
一共3个stage
