Spark内核架构解密(DT大数据梦工厂)

Posted 2020-06-13

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Spark内核架构解密(DT大数据梦工厂)相关的知识，希望对你有一定的参考价值。

只有知道内核架构的基础上，才知道为什么要这样写程序？

手工绘图来解密Spark内核架构

通过案例来验证Spark内核架构

Spark架构思考

==========Spark Runtime的几个概念============

下载下来运行，基本都是standalone模式，如果掌握了standalone，则yarn和mesos，以后不做特别说明，一律是standalone模式

application=driver+executor，executor是具体处理数据分片，里面是线程池并发的处理数据分片

Drvier(代码部分就是SparkConf+SparkContext)：运行程序的时候，具有main方法，并且创建了SparkContext这样的一个环境对象，是整个程序运行调度的核心，它不是资源调度。有高层调度，底层调度。运行对象的时候，会向Master注册当前的程序。Master会分配资源，会有一系列的job，产生stage，交给task scheduler，发给executor，运行之后把结果返回给Drvier，然后关闭SparkContext。

executor：运行在Worker所在的节点，为当前应用程序开启的进程里面的对象，通过线程池并发执行和线程复用。分布在各个集群上的代码，但是要运行的话，这个代码得发过去。一个Worker一般只开辟一个executor，当然也可以配置多个。具体多少excutor，在优化的时候再讲解。

下面的代码是Drvier，里面有DAG

val conf = new SparkConf()//创建SparkConf对象
conf.setAppName("My First Spark App!")//设置应用程序的名称，在程序运行的监控界面可以看到名称
conf.setMaster("local")//此时程序在本地运行，不需要安装Spark集群

val sc = new SparkContext(conf)//通过创建SparkContext对象，通过传入SparkConf实例来定制Spark运行的具体参数和配置信息

然后是产生RDD，就是executor具体执行的代码，就是下面的代码

val lines = sc.textFile("F:/安装文件/操作系统/spark-1.6.0-bin-hadoop2.6/README.md", 1)

==========Spark Cluster的几个概念============

Cluster Manager：集群中获取资源的外部服务，Spark Application的运行不依赖于Cluster Manager。Spark应用程序注册给Cluster Manager，比如Master注册成功，Cluster Manager已经给Master分配好资源。此时运行程序根本不需要Cluster Manager。这是粗粒度的运行方式。

Master的机器配置要很好。

Woker：可以具体运行操作代码的节点。Woker本身不会运行程序的代码，它是管理当前node的内存CPU等资源的使用状况的，它会接受Master分配计算资源(executor，在新的进程中分配 )指令，通过executor runner启动新进程，进行里面有excutor，Worker是工头，Cluster Manager是项目经理，Worker下面有好多人干活的。

Worker会不会在发心跳的时候向Master汇报当前机器的内存和CPU信息？

不会！Worker向Master发心跳只有WorkerID。

如果不发，Master怎么知道它的资源呢？

应用程序注册成功，Master分配资源的时候就知道了

Job：就是包括了一些列Task的并行计算。一般需要Action触发。Action不会产生RDD。Action前面有RDD，是transfoemation，是lazy级别的。

Spark快不是因为基于内存。最基本是调度，然后是容错，才是精髓，还有其它好多内容。

窄依赖，除了一对一，range级别的，固定个数，不会随着规模的大小而变化，比如原来3个，就算加到100台，还是3个MapPartitionRDD。

Stage内部计算逻辑完全一样，只是计算的数据不同罢了。这就是分布式并行计算，是大数据的基本精髓点。

一个Partition是不是固定128M？不是，因为最后的一条数据跨两个Block。

一个application里面可以有多个jobs，一般一个action操作对应一个job。其它情况比如checkpoint也会导致job。

==========Spark内核架构解密绘图============

~~~1、Driver~~~

专门提交Spark程序的机器（Driver，它的核心是SparkContext），这台机器一定和Spark Cluster在同样的网络环境中，且其配置和普通的Worker一致。因为会不停的交互，所以网络在一起。该机器可能会有其它企业级的J2EE程序等。这个机器有appication、各种依赖的外部资源（例如.so、file等等）。在此基础上，使用spark-submit来运行，可以配置各种运行时的参数，比如memory、cores等等。实际生产环境下不会手工spark-submit来运行，一般会写脚本，用crontab自动化配置和提交程序。提交Spark程序的机器，必须要安装Spark，只不过是这里安装的Spark不属于集群！！！Driver单列的时候一般不做HA，但是Master形式的时候，用--supervise模式，它会自动启动Driver。

（Spark程序的运行有两种模式，client模式和cluster模式，默认建议使用client模式，因为可以看到很多日志信息，但是实际运用，Cluster）

之前写程序提交给Master，因为现在只有3台机器，所以，一般Driver和Worker是分开的。

~~~2、SparkContext~~~

最重要做三件事情：创建DAGScheduler、TaskScheduler、SchedulerBackend

在实例化的的过程Register当前的程序给Master，Master接受注册，如果没有问题，Master会为当前程序分配AppID并分配计算资源

~~~3、SparkCluster~~~

Master接受当前用户提交的作业，给Worker为当前程序的资源，每个Worker所在节点默认为当前程序分配一个Executor，在Executor中通过线程池并发执行

slaves老师机器配置的Worker1、2、3、4就是这个意思

我的配置的是Master、Woker1、2，因为我的电脑配置低

Master分配多少资源来源：1、spark-env.sh和spark-defaults.sh设置的参数；2、submit提供的参数；3、程序中SparkConf提供的参数

Worker通过一个Proxy为ExecutorRunner的对象实例远程启动ExecutorBackend

ExecutorBackend里面有Executor的线程池ThreadPool

实际在工作的时候会通过TaskRunner来封装Task

TaskRunner是一个runner的接口，然后从ThreadPool中获取一条线程执行Task，执行完后，线程被回收复用

上面就是分配资源的部分，然后通过Action来触发Job，这个时候DAGScheduler登场了

~~~4、Job~~~

一般情况下当通过Action触发Job时，SparkContext会通过DAGScheduler来把Job中的RDD构成的DAG划分成不同的Stage，每个Stage内部是一系列内部逻辑完全相同，但是处理数据不同的Tasks构成了TaskSet

~~~5、TaskScheduler ~~~

TaskScheduler和SchedulerBacked具体Task运行（遵循数据本地性）

~~~5、Task类型~~~

最后Stage的Task称为ResultTask，产生Job结果

其它前面的Stage的Task都是ShuffleMapTask为下一阶段的Stage做数据准备，相当于MapReduce的Mapper，知识是更精致和高效的实现

整个Spark运行的精髓就是DAGScheduler把Job划分成不同的Stage，提交TaskSet给TaskScheduler，进而提交给Executor进行（符合数据本地行），每个Task会计算RDD中的一个Partition，基于该Partition来具体执行我们定义的一系列同一个Stage内部的函数，以此类推，直到整个程序运行完成！