一、宽依赖和窄依赖
1、窄依赖
窄依赖(Narrow Dependency)：指父RDD的每个分区只被子RDD的一个分区所使用，例如map、filter等这些算子
一个RDD，对它的父RDD只有简单的一对一的关系，也就是说，RDD的每个partition仅仅依赖于父RDD中的一个partition，父RDD和子RDD的partition之间的对应关系，是一对一的。
2、
宽依赖(Shuffle Dependency)：父RDD的每个分区都可能被子RDD的多个分区使用，例如groupByKey、reduceByKey，sortBykey等算子，这些算子其实都会产生shuffle操作
也就是说，每一个父RDD的partition中的数据都可能会传输一部分到下一个RDD的每个partition中。此时就会出现，父RDD和子RDD的partition之间，具有错综复杂的关系，那么，这种情况就叫做两个RDD之间是宽依赖，同时，他们之间会发生shuffle操作。
3、案例分析
下面来看图具体分析一个案例
以单词计数案例来分析
最左侧是linesRDD，这个表示我们通过textFile读取文件中的数据之后获取的RDD
接着是我们使用flatMap算子，对每一行数据按照空格切开，然后可以获取到第二个RDD，这个RDD中包含的是切开的每一个单词
在这里这两个RDD就属于一个窄依赖，因为父RDD的每个分区只被子RDD的一个分区所使用，也就是说他们的分区是一对一的，这样就不需要经过shuffle了。
接着是使用map算子，将每一个单词转换成(单词,1)这种形式，
此时这两个RDD也是一个窄依赖的关系，父RDD的分区和子RDD的分区也是一对一的
最后我们会调用reduceByKey算子，此时会对相同key的数据进行分组，分到一个分区里面，并且进行聚合操作，此时父RDD的每个分区都可能被子RDD的多个分区使用，那这两个RDD就属于宽依赖了。
这就是宽窄依赖的区别，那我们在这区分宽窄依赖有什么意义吗？
不要着急，往下面看
（1）Stage
spark job是根据action算子触发的,遇到action算子就会起一个job
Spark Job会被划分为多个Stage，每一个Stage是由一组并行的Task组成的
注意：stage的划分依据就是看是否产生了shuflle(即宽依赖),遇到一个shuffle操作就划分为前后两个stage
stage是由一组并行的task组成，stage会将一批task用TaskSet来封装，提交给TaskScheduler进行分配，最后发送到Executor执行
下面来看一张图来具体分析一下
注意：Stage的划分规则：从后往前，遇到宽依赖就划分Stage
为什么是从后往前呢？因为RDD之间是有血缘关系的，后面的RDD依赖前面的RDD，也就是说后面的RDD要等前面的RDD执行完,才会执行。
所以从后往前遇到宽依赖就划分为两个stage，shuffle前一个,shuffle后一个。如果整个过程没有产生shuffle那就只会有一个stage
看这个图
RDD G 往前推，到RDD B的时候，是窄依赖，所以不切分Stage，再往前到RDD A，此时产生了宽依赖，所以RDD A属于一个Stage、RDD B 和 G属于一个Stage
再看下面，RDD G到RDD F，产生了宽依赖，所以RDD F属于一个Stage，因为RDD F和 RDD C、D、E这几个RDD没有产生宽依赖，都是窄依赖，所以他们属于一个Stage。
所以这个图中,RDD A 单独一个stage1,RDD C、D、E、F被划分在stage2中,
最后RDD B和RDD G划分在了stage3 里面.
注意：Stage划分是从后往前划分，但是stage执行时从前往后的，这就是为什么后面先切割的stage为什么编号是3.
二、Spark Job的三种提交模式
1、standalone模式
基于Spark自己的standalone集群。
指定–master spark://bigdata01:7077
2、是基于YARN的client模式
指定–master yarn --deploy-mode client
这种方式主要用于测试，查看日志方便一些，部分日志会直接打印到控制台上面，因为driver进程运行在本地客户端，就是提交Spark任务的那个客户端机器，driver负责调度job，会与yarn集群产生大量的通信，一般情况下Spark客户端机器和Hadoop集群的机器是无法内网通信，只能通过外网，这样在大量通信的情况下会影响通信效率，并且当我们执行一些action操作的时候数据也会返回给driver端，driver端机器的配置一般都不高，可能会导致内存溢出等问题。
3、是基于YARN的cluster模式【推荐】
指定–master yarn --deploy-mode cluster
这种方式driver进程运行在集群中的某一台机器上，这样集群内部节点之间通信是可以通过内网通信的，并且集群内的机器的配置也会比普通的客户端机器配置高，所以就不存在yarn-client模式的一些问题了，只不过这个时候查看日志只能到集群上面看了，这倒没什么影响。
接下来看一下这个图，加深一下理解
左边是standalone模式，现在我们使用的提交方式，driver进程是在客户端机器中的，其实针对standalone模式而言，这个Driver进程也是可以运行在集群中的
来看一下官网文档，standalone模式也是支持的，通过指定deploy-mode 为cluster即可
中间的值yarn client模式，由于是on yarn模式，所以里面是yarn集群的进程，此时driver进程就在提交spark任务的客户端机器上了
最右边这个是yarn cluster模式，driver进程就会在集群中的某一个节点上面。
