Spark资源模型

Spark作业运行图：
1. 使用spark-submit提交一个spark应用，这个应用/作业会启动一个对应的driver进程，这个driver会根据提交模式的不同，可能在本地启动（client），也可能在集群中某个工作节点（cluster）上启动。
driver服务进程启动，会根据我们设置的参数，占用一定量的cpu和内存。
2. driver启动完成后做的第一件事是像集群的资源管理器去申请资源。
standalone（master）
YARN（ResourceManager）
申请应用所需要的资源，其实这儿所指的资源就是executor服务进程

      1.5版本以前，executor启动以后占用一定的内存，这部分内存主要分为三块：
      第一块：就是用来缓存数据（60 % ）
      第二块：就是让task通过shuffle过程去拉取上一个stage的task的输出后，进行聚合等操作时使用。（20%）
      第三块：task执行我们编写的代码的时候使用（20%）

3. 资源管理器会根据我们为spark作业设置的资源参数，在各个工作节点上启动一定数量的executor进程。每个executor进程都占有一定数量的cpu和内存。
4. driver在申请到资源以后，开始调度和运行我们提交的代码。driver会把我们提交的任务划分为多个stage，每个stage都执行一部分的代码片段，并为每个stage都创建一批task。将这写task分配到各个executor进程中去执行。也就是task就是我们的最小计算单元。
5. 一个stage内所有的task都执行完毕后，会在各个节点本地的磁盘文件中写入计算的中间结果。 driver会调动运行下一个stage，下一个stage的task的输入就是上一个stage的task的输出。就是如此循环往复的运行，直到代码停止为止。
6. 若在代码内执行了持久化操作（cache,persist）的时候，会根据持久化的级别的不同，每个task计算出来的数据也会保存到executor进程的内存或者是所在的磁盘文件中。

Spark内存模型：

Spark在一个Executor中的内存分为三块，一块是execution内存，一块是storage内存，一块是other内存。
• execution内存是执行内存，文档中说join，aggregate都在这部分内存中执行，shuffle的数据也会先缓存在这个内存中，满了再写入磁盘，能够减少IO。其实map过程也是在这个内存中执行的。（0.25）
• storage内存是存储broadcast，cache，persist数据的地方。（0.5）
• other内存是程序执行时预留给自己的内存。(执行代码的时候使用)（0.25）

execution和storage是Spark Executor中内存的大户，other占用内存相对少很多，这里就不说了。在spark-1.6.0以前的版本，execution和storage的内存分配是固定的，使用的参数配置分别是spark.shuffle.memoryFraction（execution内存占Executor总内存大小，default 0.2）和spark.storage.memoryFraction（storage内存占Executor内存大小，default 0.6），因为是1.6.0以前这两块内存是互相隔离的，这就导致了Executor的内存利用率不高，而且需要根据Application的具体情况，使用者自己来调节这两个参数才能优化Spark的内存使用。在spark-1.6.0以上的版本，execution内存和storage内存可以相互借用，提高了内存的Spark中内存的使用率，同时也减少了OOM的情况。

1.5版本

1.6版本

在Spark-1.6.0后加入了堆外内存，进一步优化了Spark的内存使用，堆外内存使用JVM堆以外的内存，不会被gc回收，可以减少频繁的full gc，所以在Spark程序中，会长时间逗留再Spark程序中的大内存对象可以使用堆外内存存储。使用堆外内存有两种方式，一种是在rdd调用persist的时候传入参数StorageLevel.OFF_HEAP，这种使用方式需要配合Tachyon一起使用。另外一种是使用Spark自带的spark.memory.offHeap.enabled 配置为true进行使用，但是这种方式在1.6.0的版本还不支持使用，只是多了这个参数，在以后的版本中会开放。

OOM的问题通常出现在execution这块内存中，因为storage这块内存在存放数据满了之后，会直接丢弃内存中旧的数据，对性能有影响但是不会有OOM的问题。