Spark系列修炼---入门笔记25

---

核心内容：
1、Spark的体系结构详解
3、Spark Job的逻辑视图和物理视图解析

---

今天开始进入Spark的第二个小阶段了，坚持、坚持、在坚持！
OK，今天主要是学习Spark的体系结构，好的，先用一张图描绘一下Spark的主从式体系结构：

上面的这张图是我自己画的，我又从网上重新下载了一幅图：

从上面这两张图中可以看出，Spark的体系结构是一个主从式的结构，包括Driver、Master、Worker以及Executor。下面将这四个角色的作用进行依次介绍：
Master：
1>在Spark集群当中，Master是一个全局的资源管理器，负责整个系统的资源管理和分配。这里面所说的资源主要指内存、cpu、磁盘和网络。
2>接受客户端提交给的计算任务，并为客户端分配具体的计算资源。
这一点同我们的Yarn是一样的，用户的应用程序通过Spark的客户端提交给Master，首先向Master进行注册，注册中Master会给我们的应用程序Application分配一个ID。
注意：Spark（StandAlone模式下）中默认情况下是粗粒度的资源分配方式，所谓粗粒度的资源分配方式就是我们的作业在提交的时候，Spark就会为我们的作业分配具体的资源。后续作业运行的过程中，它都会复用这个程序在注册时获得的资源，除非我们的资源发生了异常，才会重新分配。
示例：

[root@hadoop11 ~]# spark-shell spark://hadoop11:7077

通过浏览器我们可以发现，尽管此时并没有触发什么Job，但是资源已经给我们分配好了：



也就是说在Spark当中，只要我们的作业一提交、一注册，系统就会立即为我们的作业分配计算资源。
Worker：Worker节点是每个从节点上面的资源和任务管理器，Worker主要负责当前节点上内存和Cpu等资源的使用情况：默认情况下每一个Worker会为我们当前的应用程序启动一个CoarseGrainedExecutorBackend进程，而每一个CoarseGrainedExecutorBackend进程里面都有一个Executor，且默认情况下CoarseGrainedExecutorBackend(Executor)会最大化的使用cores和内存。因此如果在同一套集群上面如果有多个计算框架的话，此时肯定需要资源管理器。
（注意：CoarseGrainedExecutorBackend是进程级别的，Executor是计算资源级别的………，CoarseGrainedExecutorBackend里面主要就是Executor。）
注意：CoarseGrainedExecutorBackend和Executor是一一对应的。
默认情况下一个节点就是一个worker process进程，一个worker process进程默认情况下只为当前应用程序分配一个Executor。（当然一个Worker上面是可以有多个Executor的，这个是可以配置的。）
Driver：Driver是负责具体作业调度的。Driver所在的进程叫做spark-submit,Driver的核心是main方法，main方法的核心是SparkContext。
Driver负责管理单个应用程序Application，即负责一个Application生命周期内的所有工作，并在任务task运行失败时重新为任务申请资源进而重新启动相应的任务。

Executor：Executor是具体做作业的，Executor会通过并发线程池（线程复用和并发执行的方式）来不断的执行我们的task。每个Executor一次能够并发的运行多少个task任务取决于当前Executors中拥有的cores的个数。
好的，上面依次介绍了Master、Worker、Driver、Executor的职能，现在概括一下用户的应用程序在Spark集群中的运行机制。
用户的应用程序在Spark集群中的运行机制以及Spark集群中各个角色的作用：
Spark集群启动之后，有一个全局的资源管理器Master，负责整个系统的资源管理和分配，并接受客户提交给的计算任务且为任务分配相应的计算资源，即任务在计算之前就已经为任务分配好资源了。每个工作节点Worker上面都有一个Worker守护进程来管理当前节点上面的计算资源，包括内存、Cpu、磁盘、网络等，并且Worker将通过心跳的机制向Master汇报Worker还能够正常工作。当用户向Master提交应用程序的时候，Master就会为我们当前提交的应用程序在每个Worker节点上面默认分配一个CoarseGrainedExecutorBackend进程，这个进程默认情况下如果不做内存和Cpu限制的话，默认情况下将会最大程度的使用当前节点上的内存和Cpu（这也是为什么很多人说Spark耗费内存的真正原因）。当我们的Driver实例化之后，Driver本身就会进行作业的调度即驱动我们CoarseGrainedExecutorBackend中的Executor中的线程来执行相应的任务task，此时任务就会并发的进行执行。
深度思考：Worker Process会不会管理计算资源呢？
Worker Process并不会管理计算资源，计算资源是一手被Master管理的，Master负责整个系统的资源管理和分配。Master告诉Worker该分配多少计算资源，worker就会分配多少计算资源。前面之所以说每个工作节点默认情况下都会启动一个Worker Process来管理当前节点的内存、cpu等计算资源，主要是从资源视角的角度来看待，因为从CoarseGrainedExecutorBackend的角度来看待的话，就是Worker节点来管理当前节点上的计算资源的。因为CoarseGrainedExecutorBackend是被Worker Process分配的。Worker Process并不会真正的管理资源Worker Process只不过是走一趟形式而已。综上，我们说Worker Process管理当前节点上的内存和cpu等计算资源，实质上是通过Master来管理每台机器上的计算资源的。

---

Spark Job的逻辑视图和物理视图解析：

Stage2是Stage3的Mapper任务，Stage3是Stage2的Reducer任务，Stage3是Stage4的Mapper任务，Stage4是Stage3的Reduer任务。
Spark是一个更加精致和更加高效的MapReduce思想的具体实现。在Spark当中，最后一个Stage里面的Task是ResultTasks类型的。前面所有的Stage中的Task类型都是ShuffleMapTask类型的。Stage里面的内容一定是在Executor里面执行的，而且Stage必须从前往后进行执行。每个Stage内部是窄依赖，Stage之间是宽依赖。Spark的一个应用程序中可以因为不同的Action产生众多的Job，每个Job至少有一个Stage。