spark梳理 | 易学教程

大数据组件，离线用过hadoop，实时用过spark。

Hadoop现在比较稳定了，面试主要就是问Spark。

包括我工作这么多年，都没搞清过底层到底是怎么运行的，但是有些东西懂的人一说就通了，优化起来也会有思路。

我下面给spark梳理一下。做个基本概要，方便面试。

一、spark运行原理：

1.提交spark任务，构建spark application运行环境，启动sparkContext。

2.sparkContext向资源管理器（可以使Standalone，Mesos，Yarn）申请运行Executor资源，并启动StandaloneExecutorbackend（后台监控程序）。

注：

a.每个节点可以起一个或多个Executor。

3.Executor向SparkContext申请Task。

注：

a.每个Executor由若干core组成，每个Executor的每个core一次只能执行一个Task。

b.每个Task执行的结果就是生产了目标RDD的一个partition。

c.这里的core是虚拟机的core而不是机器的物理CPU核，可以理解为就是Executor的一个工作线程。

d.Task被执行并发度（并发度不等于task数量）=Executor数目*每个Executor核数（=core总个数）

e.partition数目在map阶段保持不变，在Reduce阶段，RDD的聚合会触发Shuffle操作，聚合后的RDD的partition数目跟具体操作有关，例如repartition操作会聚合成指定分区数，还有一些算子是可配置的。

f.RDD在计算的时候，每个分区都会起一个task，所以rdd的分区数目决定了总的task数目。

g.申请的计算节点（Executor）数目和计算节点的核数，决定了统一时刻可以并行执行的task。比如：rdd有100个分区（partition），那么计算的时候就会生成100个task，你的资源配置为10个计算节点，每个2个核，同时可以并行的task数量就是20，计算这个rdd就需要5个轮次。如果资源不变，你的RDD只有2个分区，那么同一时刻只有2个task运行，其余18个核空转，造成资源浪费。这就是在spark调优中，增大RDD分区数目，增大任务并行度的原因

4.sparkContext将应用程序分发给Executor。

5.sparkContext构建成DAG图，将DAG图分解成Stage、将Taskset发送给TaskScheduler，最后由TaskScheduler将Task发送给Executor运行。

6.Task在Executor上运行，运行完释放所有资源

常用术语：

Application：Application都是指用户编写的Spark应用程序，其中包括一个Driver功能的代码和分布在集群中多个节点上运行的Executor代码。

Driver：Spark中的Driver即运行上述Application的main函数并创建SparkContext，创建SparkContext的目的是为了准备Spark应用程序的运行环境，在Spark中有SparkContext负责与ClusterManager通信，进行资源申请、任务的分配和监控等，当Executor部分运行完毕后，Driver同事负责将SparkContext关闭，通常用SparkContext代表Driver。

Executor：某个Application运行在worker节点上的一个进程，该进程负责运行某些Task，并且负责将数据存到内存或磁盘上，每个Application都有各自独立的一批Executor，在Spark on Yarn模式下，其进程名称为CoarseGrainedExecutorBackend。一个CoarseGrainedExecutor Backend有且仅有一个Executor对象，负责将Task包装成taskRunner，并从线程池中抽取一个空闲线程运行Task，这个每一个CoarseGrainedExecutor Backend能并行运行Task的数量取决于分配给他的cpu核数。

ClusterManager：指的是在集群上获取资源的外部服务。目前有三种类型

1.Standalone：spark原生的资源管理，由Master负责资源的分配

2.Apache Mesos:与Hadoop MR兼容性良好的一种资源调度框架

3.Hadoop Yarn：主要是指Yarn中的ResourceManager

Worker：集群中任何可以运行Application代码的节点，在Standalone模式中指的是通过slave文件配置的Worker节点，在Spark on Yarn模式下就是NodeManager节点。

Task：被送到某个Executor上的工作单元，但HadoopMR中的MapTask和Reduce Task概念一样，是运行Application的基本单位，多个Task组成一个Stage，而Task的调度和管理等是由TaskScheduler负责。一般来说，一个 rdd 有多少个 partition，就会有多少个 task，因为每一个 task 只是处理一个 partition 上的数据。

Job：包含多个Task组成的并行计算，往往由Spark Action触发生成，一个Application中往往会产生多个Job。我的理解就是，多个task组成taskset也就是stage，1个或多个纵向的stage组成job。

stage:stage是一个job的组成单位，就是说，一个job会被切分成1个或1个以上的stage，然后各个stage会按照执行顺序依次执行。

Shuffle Write: 为下一个依赖的stage提供输入数据，shuffle过程中通过网络传输的数据字节数/记录条数。应该尽量减少shuffle的数据量及其操作次数，这是spark任务优化的一条基本原则。

工作期间发现很多同学不怎么会看web ui图，包括我

下面给个代码，分析一下web ui

可以看到，整个逻辑实际上就用了 sparkContext 的一个函数，rdd 的 3 个 transformation 和 1 个 action。

现在让我们从 WEB UI 上来看看，当我们运行这段代码的时候，后台都发生了什么。可以看到，执行这段代码的时候，spark 通过分析，优化代码，知道这段代码需要一个 job 来完成，所以 web ui 上只有一个 job。值得深究的是，这个 job 由两个 stage 完成，这两个 state 一共有 66 个 task。

从上面这张web ui图我们可以看到，这个job一共有2个stage，66个task，相当于每个 stage 的数据都有 33 个 partition [注意：这里是平均下来的哦，并不都是每个 stage 有 33 个 task，有时候也会有一个 stage 多，另外一个 stage 少的情况，就看你有没有在不同的 stage 进行 repartition 类似的操作了。]

stage是以shuffle为边界的，也就是说，某个action导致了shuffle，就会划分出两个stage

再次回顾上面那张图：这下应该就明了了，关于两个 stage 的情况：

第一个stage，即截图中stage id为0的stage，其执行了sc。wholeTextFiles().map().flatMap().map().reduceByKey()这几个步骤，因为这是一个Shuffle操作，所以后面会有Shuffle Read和Shuffle Write。具体来说，就是在stage0这个stage中，发生了一个Shuffle操作，这个操作读入22.5MB的数据，生成41.7KB的数据，并把生成的数据写在了硬盘上。

第二个stage，即截图中stage id为1的stage，其执行了collect()这个操作，因为这是一个action操作，并且它上一步不是一个Shuffle操作，且没有后续操作，所以这里collect()操作被独立成一个stage了。这里它把上一个shuffle写下来的数据读取进来，然后一起返回到driver端，所以这里可以看到他的Shuffle Read这里刚好读取了上一个stage写下的数据。

Storage
storage页面能看出application当前使用的缓存情况，可以看到有哪些RDD被缓存了，以及占用的内存资源。如果job在执行时持久化（persist）/缓存（cache）了一个RDD，那么RDD的信息可以在这个选项卡中查看。

Storage Detail
点击某个RDD即可查看该RDD缓存的详细信息，包括缓存在哪个Executor中，使用的block情况，RDD上分区（partitions）的信息以及存储RDD的主机的地址。

Environment选项卡提供有关Spark应用程序（或SparkContext）中使用的各种属性和环境变量的信息。用户可以通过这个选项卡得到非常有用的各种Spark属性信息，而不用去翻找属性配置文件。

Executors选项卡提供了关于内存、CPU核和其他被Executors使用的资源的信息。这些信息在Executor级别和汇总级别都可以获取到。一方面通过它可以看出来每个excutor是否发生了数据倾斜，另一方面可以具体分析目前的应用是否产生了大量的shuffle，是否可以通过数据的本地性或者减小数据的传输来减少shuffle的数据量。

Summary: 该application运行过程中使用Executor的统计信息。

Executors: 每个Excutor的详细信息（包含driver），可以点击查看某个Executor中任务运行的详细日志。