Spark2.1.0模型设计与基本架构（下）

阅读提示：读者若是对Spark的背景知识不是很了解的话，建议首先阅读《SPARK2.1.0模型设计与基本架构（上）》一文。

Spark模型设计

1. Spark编程模型

正如Hadoop在介绍MapReduce编程模型时选择word count的例子，而且使用图形来讲明同样，笔者对于Spark编程模型也选择用图形展示。

Spark 应用程序从编写到提交、执行、输出的整个过程如图5所示。

 

图5   代码执行过程

图5中描述了Spark编程模型的关键环节的步骤以下。

1）用户使用SparkContext提供的API（经常使用的有textFile、sequenceFile、runJob、stop等）编写Driver application程序。此外，SparkSession、DataFrame、SQLContext、HiveContext及StreamingContext都对SparkContext进行了封装，并提供了DataFrame、SQL、Hive及流式计算相关的API。

2）使用SparkContext提交的用户应用程序，首先会经过RpcEnv向集群管理器（Cluster Manager）注册应用（Application）而且告知集群管理器须要的资源数量。集群管理器根据Application的需求，给Application分配Executor资源，并在Worker上启动CoarseGrainedExecutorBackend进程（CoarseGrainedExecutorBackend进程内部将建立Executor）。Executor所在的CoarseGrainedExecutorBackend进程在启动的过程当中将经过RpcEnv直接向Driver注册Executor的资源信息，TaskScheduler将保存已经分配给应用的Executor资源的地址、大小等相关信息。而后，SparkContext根据各类转换API，构建RDD之间的血缘关系（lineage）和DAG，RDD构成的DAG将最终提交给DAGScheduler。DAGScheduler给提交的DAG建立Job并根据RDD的依赖性质将DAG划分为不一样的Stage。DAGScheduler根据Stage内RDD的Partition数量建立多个Task并批量提交给TaskScheduler。TaskScheduler对批量的Task按照FIFO或FAIR调度算法进行调度，而后给Task分配Executor资源，最后将Task发送给Executor由Executor执行。此外，SparkContext还会在RDD转换开始以前使用BlockManager和BroadcastManager将任务的Hadoop配置进行广播。

3）集群管理器（Cluster Manager）会根据应用的需求，给应用分配资源，即将具体任务分配到不一样Worker节点上的多个Executor来处理任务的运行。Standalone、YARN、Mesos、EC2等均可以做为Spark的集群管理器。

4）Task在运行的过程当中须要对一些数据（例如中间结果、检查点等）进行持久化，Spark支持选择HDFS 、Amazon S三、Alluxio（原名叫Tachyon）等做为存储。

2.RDD计算模型

RDD能够看作是对各类数据计算模型的统一抽象，Spark的计算过程主要是RDD的迭代计算过程，如图6所示。RDD的迭代计算过程很是相似于管道。分区数量取决于Partition数量的设定，每一个分区的数据只会在一个Task中计算。全部分区能够在多个机器节点的Executor上并行执行。

 

图6   RDD计算模型

图6只是简单的从分区的角度将RDD的计算看做是管道，若是从RDD的血缘关系、Stage划分的角度来看，由RDD构成的DAG通过DAGScheduler调度后，将变成图7所示的样子。

 

图7  DAGScheduler对由RDD构成的DAG进行调度

图7中共展现了A、B、C、D、E、F、G一共7个RDD。每一个RDD中的小方块表明一个分区，将会有一个Task处理此分区的数据。RDD A通过groupByKey转换后获得RDD B。RDD C通过map转换后获得RDD D。RDD D和RDD E通过union转换后获得RDD F。RDD B和RDD F通过join转换后获得RDD G。从图中能够看到map和union生成的RDD与其上游RDD之间的依赖是NarrowDependency，而groupByKey和join生成的RDD与其上游的RDD之间的依赖是ShuffleDependency。因为DAGScheduler按照ShuffleDependency做为Stage的划分的依据，所以A被划入了ShuffleMapStage 1；C、D、E、F被划入了ShuffleMapStage 2；B和G被划入了ResultStage 3。

Spark基本架构

从集群部署的角度来看，Spark集群由集群管理器（Cluster Manager）、工做节点（Worker）、执行器（Executor）、驱动器（Driver）、应用程序（Application）等部分组成，它们之间的总体关系如图8所示。

 

图8   Spark基本架构图

下面结合图8对这些组成部分以及它们之间的关系进行介绍。

（1）Cluster Manager

Spark的集群管理器，主要负责对整个集群资源的分配与管理。Cluster Manager在Yarn部署模式下为ResourceManager；在Mesos部署模式下为Mesos master；在Standalone部署模式下为Master。Cluster Manager分配的资源属于一级分配，它将各个Worker上的内存、CPU等资源分配给Application，可是并不负责对Executor的资源分配。Standalone部署模式下的Master会直接给Application分配内存、CPU以及Executor等资源。目前，Standalone、YARN、Mesos、EC2等均可以做为Spark的集群管理器。

注意：这里提到了部署模式中的Standalone、Yarn、Mesos等模式，读者暂时知道这些内容便可，本书将在第9章对它们详细介绍。

（2）Worker

Spark的工做节点。在Yarn部署模式下实际由NodeManager替代。Worker节点主要负责如下工做：将本身的内存、CPU等资源经过注册机制告知Cluster Manager；建立Executor；将资源和任务进一步分配给Executor；同步资源信息、Executor状态信息给Cluster Manager等。在Standalone部署模式下，Master将Worker上的内存、CPU以及Executor等资源分配给Application后，将命令Worker启动CoarseGrainedExecutorBackend进程（此进程会建立Executor实例）。

（3）Executor

执行计算任务的一线组件。主要负责任务的执行以及与Worker、Driver的信息同步。

（4）Driver

Application的驱动程序，Application经过Driver与Cluster Manager、Executor进行通讯。Driver能够运行在Application中，也能够由Application提交给Cluster Manager并由Cluster Manager安排Worker运行。

（4）Application

用户使用Spark提供的API编写的应用程序，Application经过Spark API将进行RDD的转换和DAG的构建，并经过Driver将Application注册到Cluster Manager。Cluster Manager将会根据Application的资源需求，经过一级分配将Executor、内存、CPU等资源分配给Application。Driver经过二级分配将Executor等资源分配给每个任务，Application最后经过Driver告诉Executor运行任务。

小结

每项技术的诞生都会由某种社会需求所驱动，Spark正是在实时计算的大量需求下诞生的。Spark借助其优秀的处理能力，可用性高，丰富的数据源支持等特色，在当前大数据领域变得火热，参与的开发者也愈来愈多。Spark通过几年的迭代发展，现在已经提供了丰富的功能。笔者相信，Spark在将来必将产生更耀眼的火花。

 

关于《Spark内核设计的艺术 架构设计与实现》

通过近一年的准备，基于Spark2.1.0版本的《Spark内核设计的艺术 架构设计与实现》一书现已出版发行，图书如图：

​

 

纸质版售卖连接以下：

京东：https://item.jd.com/12302500.html