spark基本概念（总结和理解）

最新推荐文章于 2024-05-16 19:26:23 发布

置顶懂什么

最新推荐文章于 2024-05-16 19:26:23 发布

阅读量615

点赞数

分类专栏： spark 文章标签： spark

spark 专栏收录该内容

14 篇文章 0 订阅

订阅专栏

基本概念和任务的执行流程

1、基本概念https://www.cnblogs.com/superhedantou/p/5699201.html

2、执行流程

https://blog.csdn.net/thomas0yang/article/details/50352261

这个针对yarn的，可惜图挂了https://www.jianshu.com/p/42fff40bfe31

补充一个这个https://wenku.baidu.com/view/c01a6a4ba55177232f60ddccda38376baf1fe005.html

ApplicationMaster

用户提交的每个应用程序均包含一个ApplicationMaster，它可以运行在ResourceManager以外的机器上。
负责与RM调度器协商以获取资源（用Container表示）。
将得到的任务进一步分配给内部的任务(资源的二次分配)。
与NM通信以启动/停止任务。
监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
当前YARN自带了两个ApplicationMaster实现，一个是用于演示AM编写方法的实例程序DistributedShell，它可以申请一定数目的Container以并行运行一个Shell命令或者Shell脚本；另一个是运行MapReduce应用程序的AM—MRAppMaster。
注：RM只负责监控AM，并在AM运行失败时候启动它。RM不负责AM内部任务的容错，任务的容错由AM完成。

client向RM提交应用程序，其中包括启动该应用的ApplicationMaster的必须信息，例如ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
ResourceManager启动一个container用于运行ApplicationMaster。
启动中的ApplicationMaster向ResourceManager注册自己，启动成功后与RM保持心跳。
ApplicationMaster向ResourceManager发送请求，申请相应数目的container。
ResourceManager返回ApplicationMaster的申请的containers信息。申请成功的container，由ApplicationMaster进行初始化。container的启动信息初始化后，AM与对应的NodeManager通信，要求NM启动container。AM与NM保持心跳，从而对NM上运行的任务进行监控和管理。
container运行期间，ApplicationMaster对container进行监控。container通过RPC协议向对应的AM汇报自己的进度和状态等信息。--client模式程序运行消息的来源，结合百度文库链接中的图看下
应用运行期间，client直接与AM通信获取应用的状态、进度更新等信息。
应用运行结束后，ApplicationMaster向ResourceManager注销自己，并允许属于它的container被收回。

一个spark的存储系统 http://www.sohu.com/a/132359011_470008 讲的挺好的值得一看

一、Spark 执行环境 SparkEnv

本章源地址：http://blog.csdn.net/dwb1015/article/details/52467490

红色字体为自己的考虑和相关注释，可能不对。这个博客讲的比较多了，和某本源码书的内容很相似

SparkEnv是Spark的执行环境对象，其中包括与众多Executor执行相关的对象。在local模式下Driver会创建Executor，local-cluster部署模式或者Standalone部署模式下Worker另起的CoarseGrainedExecutorBackend进程中也会创建Executor，所以SparkEnv存在于Driver或者CoarseGrainedExecutorBackend进程中。创建SparkEnv主要使用SparkEnv的createDriverEnv方法，有四个参数：conf、isLocal、listenerBus 以及在本地模式下driver运行executor需要的numberCores。

SparkEnv是Spark中比较重要的一部分，它构成了Spark赖以生存的环境，只有这个环境搭建好了，Spark才能正常运行。在Sparklocal运模式中，driver和executor在同个节点同个进程中，所以driver和executor可以本地交互调，但是在分布式的环境中，driver和executor往往运在不同的节点不同的进程中，driver就法监控executor的信息了，所以driver端创建了跳接收器.

  // 是否是本地模式
  def isLocal: Boolean = (master == "local" || master.startsWith("local["))
  // 采用监听器模式维护各类事件的处理
  // An asynchronous listener bus for Spark events
  private[spark] val listenerBus = new LiveListenerBus
  ...

  /**
   * 获取在本地模式下执行程序需要的cores个数，否则为0
   * The number of driver cores to use for execution in local mode, 0 otherwise.
   */
  private[spark] def numDriverCores(master: String): Int = {
    def convertToInt(threads: String): Int = {
      if (threads == "*") Runtime.getRuntime.availableProcessors() else threads.toInt
    }
    master match {
      case "local" => 1
      case SparkMasterRegex.LOCAL_N_REGEX(threads) => convertToInt(threads)
      case SparkMasterRegex.LOCAL_N_FAILURES_REGEX(threads, _) => convertToInt(threads)
      case _ => 0 // driver is not used for execution
    }
  }

  ...
  // This function allows components created by SparkEnv to be mocked in unit tests:
  private[spark] def createSparkEnv(
      conf: SparkConf,
      isLocal: Boolean,
      listenerBus: LiveListenerBus): SparkEnv = {
    SparkEnv.createDriverEnv(conf, isLocal, listenerBus, SparkContext.numDriverCores(master))
  }

SparkEnv的构造步骤如下：

1. 创建安全管理器SecurityManager；
2. 创建RpcEnv；

(Spark1.6推出的RpcEnv、RpcEndPoint、RpcEndpointRef为核心的新型架构下的RPC通信方式，在底层封装了Akka和Netty，为未来扩充更多的通信系统提供了可能。RpcEnv是RPC的环境，所有的RpcEndpoint都需要注册到RpcEnv实例对象中，管理着这些注册的RpcEndpoint的生命周期：
- 根据name或者uri注册RpcEndpoint；
- 管理各种消息的处理；
- 停止RpcEndpoint

RpcEnv的伴生对象的代码中可以看到RpcEnv支持两种Rpc模式：akka和netty，默认使用的是netty。 )

3. 创建基于Akka的分布式消息系统ActorSystem（注意：Spark 1.4.0之后已经废弃了）
4. 创建Map任务输出跟踪器MapOutputTracker；
5. 创建ShuffleManager；
6. 内存管理器MemoryManager；
7. 创建块传输服务NettyBlockTransferService；
8. 创建BlockManagerMaster；
9. 创建块管理器BlockManager；
10. 创建广播管理器BroadcastManager；
11. 创建缓存管理器CacheManager；
12. 创建测量系统MetricsSystem；
13. 创建OutputCommitCoordinator；
14. 创建SparkEnv

其中主要的关注点在于

分布式消息系统ActorSystem，不过在1.6中已经推出RpcEnv、RpcEndPoint、RpcEndpointRef为核心的新型架构下的RPC通信方式，需要简单学习。

Map任务输出跟踪器MapOutputTracker，ShuffleManager，内存管理器MemoryManager，BlockManagerMaster，块管理器BlockManager，广播管理器BroadcastManager，缓存管理器CacheManager将在下面的环节介绍。

二、MapOutputTracker

参考博客：http://blog.csdn.net/luofenghan/article/details/78591305 建议看一下

　　　mapOutputTracker用于跟踪map阶段任务的输出状态，此状态便于reduce阶段任务获取地址以及中间输出结果。每个map任务或者 reduce任务都会有唯一的标识。分别为mapId和reduceId.每个reduce任务的输入可能是多个map任务的输出，reduce会到各个map任务的所有节点上拉去Block，这一过程交shuffle，每批shuffle过程都有唯一的表示shuffleId。

这是我找到的比较好的一张图，可以看到*mater和*worker分别部署在driver和executor上，通过rpc信息交流。

MapOutputTracker是基于Master/Slave的架构，Master（Driver）负责存储当前Application上所有Shuffle的Map输出元数据信息，而Slave（Executor）可以通过rpc对Master上的Map输出状态信息进行查询。

需要注意的几点背景知识，这在理解上面的博客内容时很有帮助：

1）Stage有两种：

ShuffleMapStage
- 这种Stage是以Shuffle为输出边界
- 其输入边界可以是从外部获取数据，也可以是另一个ShuffleMapStage的输出
- 其输出可以是另一个Stage的开始
- ShuffleMapStage的最后Task就是ShuffleMapTask
- 在一个Job里可能有该类型的Stage，也可以能没有该类型Stage。
ResultStage
- 这种Stage是直接输出结果
- 其输入边界可以是从外部获取数据，也可以是另一个ShuffleMapStage的输出
- ResultStage的最后Task就是ResultTask
- 在一个Job里必定有该类型Stage。

一个Job含有一个或多个Stage，但至少含有一个ResultStage。

2）TimeStampedHashMap和MapStatus

主要是用来存放之前提到过的MapStatus对象，其中MapStatus包括shuffleID，块Id（即分区Id）以及压缩后的数据的大小，TimeStampedHashMap对象将存储在TimeStampedHashMap中的mapStatus更新，添加新的mapStatus，移除mapStatus，清空TimeStampedHashMap，获得相应mapStatus的时间戳等等

3）

MapOutTracker主要用来存放shuffle map stage的输出，因为主从节点的MapOutTracker实现机制不一样，所以它是一个抽象类，主要维护和记录map的状态，添加或移除shuffle，以及从节点从主节点上获取相应shuffle的状态

* MapOutputTracker是 SparkEnv初始化是初始化的重要组件之一是master-slave的结构
* 用来跟踪记录shuffleMapTask的输出位置（shuffleMapTask要写到哪里去），
* shuffleReader读取shuffle文件之前就是去请求MapOutputTrackerMaster 要自己处理的数据在哪里？
* MapOutputTracker给它返回一批 MapOutputTrackerWorker的列表（地址，port等信息）
* shuffleReader开始读取文件进行后期处理

总的来说 MapOutputTrackerMaster利用TimeStampedHashMap中的MapStatus记录shffuleid，记录跟踪shuffleMapTask的输出位置， shuffleReader读取shuffle文件之前就是去请求MapOutputTrackerMaster 处理的数据的位置。

三、RPC通信

Spark 1.6之前，spark的RPC是基于Akaa来实现的。Akka是一个基于scala语言的异步的消息框架。Spark1.6后，spark借鉴Akka的设计自己实现了一个基于Netty的rpc框架。

这篇博客https://www.cnblogs.com/superhedantou/p/7570692.html介绍的就很好了，不过要了解下面的概念比较好

Actor模型：http://blog.csdn.net/gulianchao/article/details/7249117

四、ShuffleManager

ShuffleManager发展概述

在Spark的源码中，负责shuffle过程的执行、计算和处理的组件主要就是ShuffleManager，也即shuffle管理器。而随着Spark的版本的发展，ShuffleManager也在不断迭代，变得越来越先进。

在Spark 1.2以前，默认的shuffle计算引擎是HashShuffleManager。该ShuffleManager而HashShuffleManager有着一个非常严重的弊端，就是会产生大量的中间磁盘文件，进而由大量的磁盘IO操作影响了性能。

因此在Spark 1.2以后的版本中，默认的ShuffleManager改成了SortShuffleManager。SortShuffleManager相较于HashShuffleManager来说，有了一定的改进。主要就在于，每个Task在进行shuffle操作时，虽然也会产生较多的临时磁盘文件，但是最后会将所有的临时文件合并（merge）成一个磁盘文件，因此每个Task就只有一个磁盘文件。在下一个stage的shuffle read task拉取自己的数据时，只要根据索引读取每个磁盘文件中的部分数据即可。

下面我们详细分析一下HashShuffleManager和SortShuffleManager的原理。

HashShuffleManager运行原理

未经优化的HashShuffleManager

下图说明了未经优化的HashShuffleManager的原理。这里我们先明确一个假设前提：每个Executor只有1个CPU core，也就是说，无论这个Executor上分配多少个task线程，同一时间都只能执行一个task线程。

我们先从shuffle write开始说起。shuffle write阶段，主要就是在一个stage结束计算之后，为了下一个stage可以执行shuffle类的算子（比如reduceByKey），而将每个task处理的数据按key进行“分类”。所谓“分类”，就是对相同的key执行hash算法，从而将相同key都写入同一个磁盘文件中，而每一个磁盘文件都只属于下游stage的一个task。在将数据写入磁盘之前，会先将数据写入内存缓冲中，当内存缓冲填满之后，才会溢写到磁盘文件中去。

（这里有点看不懂，按照这篇文章的意思，一共会有M * R个缓存文件，https://www.jianshu.com/p/9933fd9c60da中也是如此说的。即每个map task会存在R个文件。但是这里又说每个task处理的数据按key进行“分类”，所以每个task会存储key num个文件，这作何解释？）--从下面优化的hashshuffle的图中可以看到，每个task只生成一个文件，每个task处理的数据按key进行“分类”在何处体现？接着看了http://blog.csdn.net/ivysister/article/details/52347124 中的介绍：其次Mapper产生的结果会根据设置的partition算法填充到每个bucket中去。这里的partition算法是可以自定义的，当然默认的算法是根据key哈希到不同的bucket中去。所以R（reduce的数量其实就是key的数量），每个task生成R个文件，每个文件一个key。嗯嗯，解决的还是挺好的。

那么每个执行shuffle write的task，要为下一个stage创建多少个磁盘文件呢？很简单，下一个stage的task有多少个，当前stage的每个task就要创建多少份磁盘文件。比如下一个stage总共有100个task，那么当前stage的每个task都要创建100份磁盘文件。如果当前stage有50个task，总共有10个Executor，每个Executor执行5个Task，那么每个Executor上总共就要创建500个磁盘文件，所有Executor上会创建5000个磁盘文件。由此可见，未经优化的shuffle write操作所产生的磁盘文件的数量是极其惊人的。

接着我们来说说shuffle read。shuffle read，通常就是一个stage刚开始时要做的事情。此时该stage的每一个task就需要将上一个stage的计算结果中的所有相同key，从各个节点上通过网络都拉取到自己所在的节点上，然后进行key的聚合或连接等操作。由于shuffle write的过程中，task给下游stage的每个task都创建了一个磁盘文件，因此shuffle read的过程中，每个task只要从上游stage的所有task所在节点上，拉取属于自己的那一个磁盘文件即可。

shuffle read的拉取过程是一边拉取一边进行聚合的。每个shuffle read task都会有一个自己的buffer缓冲，每次都只能拉取与buffer缓冲相同大小的数据，然后通过内存中的一个Map进行聚合等操作。聚合完一批数据后，再拉取下一批数据，并放到buffer缓冲中进行聚合操作。以此类推，直到最后将所有数据到拉取完，并得到最终的结果。

优化后的HashShuffleManager

下图说明了优化后的HashShuffleManager的原理。这里说的优化，是指我们可以设置一个参数，spark.shuffle.consolidateFiles。该参数默认值为false，将其设置为true即可开启优化机制。通常来说，如果我们使用HashShuffleManager，那么都建议开启这个选项。

开启consolidate机制之后，在shuffle write过程中，task就不是为下游stage的每个task创建一个磁盘文件了。此时会出现shuffleFileGroup的概念，每个shuffleFileGroup会对应一批磁盘文件，磁盘文件的数量与下游stage的task数量是相同的。一个Executor上有多少个CPU core，就可以并行执行多少个task。而第一批并行执行的每个task都会创建一个shuffleFileGroup，并将数据写入对应的磁盘文件内。

当Executor的CPU core执行完一批task，接着执行下一批task时，下一批task就会复用之前已有的shuffleFileGroup，包括其中的磁盘文件。也就是说，此时task会将数据写入已有的磁盘文件中，而不会写入新的磁盘文件中。因此，consolidate机制允许不同的task复用同一批磁盘文件，这样就可以有效将多个task的磁盘文件进行一定程度上的合并，从而大幅度减少磁盘文件的数量，进而提升shuffle write的性能。

https://0x0fff.com/spark-architecture-shuffle/

假设第二个stage有100个task，第一个stage有50个task，总共还是有10个Executor，每个Executor执行5个task。那么原本使用未经优化的HashShuffleManager时，每个Executor会产生500个磁盘文件，所有Executor会产生5000个磁盘文件的。但是此时经过优化之后，每个Executor创建的磁盘文件的数量的计算公式为：CPU core的数量 * 下一个stage的task数量。也就是说，每个Executor此时只会创建100个磁盘文件，所有Executor只会创建1000个磁盘文件。

SortShuffleManager运行原理

SortShuffleManager的运行机制主要分成两种，一种是普通运行机制，另一种是bypass运行机制。当shuffle read task的数量小于等于spark.shuffle.sort.bypassMergeThreshold参数的值时（默认为200），就会启用bypass机制。

普通运行机制

下图说明了普通的SortShuffleManager的原理。在该模式下，数据会先写入一个内存数据结构中，此时根据不同的shuffle算子，可能选用不同的数据结构。如果是reduceByKey这种聚合类的shuffle算子，那么会选用Map数据结构，一边通过Map进行聚合，一边写入内存；如果是join这种普通的shuffle算子，那么会选用Array数据结构，直接写入内存。接着，每写一条数据进入内存数据结构之后，就会判断一下，是否达到了某个临界阈值。如果达到临界阈值的话，那么就会尝试将内存数据结构中的数据溢写到磁盘，然后清空内存数据结构。

在溢写到磁盘文件之前，会先根据key对内存数据结构中已有的数据进行排序。排序过后，会分批将数据写入磁盘文件。默认的batch数量是10000条，也就是说，排序好的数据，会以每批1万条数据的形式分批写入磁盘文件。写入磁盘文件是通过Java的BufferedOutputStream实现的。BufferedOutputStream是Java的缓冲输出流，首先会将数据缓冲在内存中，当内存缓冲满溢之后再一次写入磁盘文件中，这样可以减少磁盘IO次数，提升性能。

一个task将所有数据写入内存数据结构的过程中，会发生多次磁盘溢写操作，也就会产生多个临时文件。最后会将之前所有的临时磁盘文件都进行合并，这就是merge过程，此时会将之前所有临时磁盘文件中的数据读取出来，然后依次写入最终的磁盘文件之中。此外，由于一个task就只对应一个磁盘文件，也就意味着该task为下游stage的task准备的数据都在这一个文件中，因此还会单独写一份索引文件，其中标识了下游各个task的数据在文件中的start offset与end offset。

SortShuffleManager由于有一个磁盘文件merge的过程，因此大大减少了文件数量。比如第一个stage有50个task，总共有10个Executor，每个Executor执行5个task，而第二个stage有100个task。由于每个task最终只有一个磁盘文件，因此此时每个Executor上只有5个磁盘文件，所有Executor只有50个磁盘文件。

从上面的介绍中我们可以理解，每个task（即core）只会产生一个文件，这个文件中的数据按照key排序，即相同的key处在一起，经过处理，索引文件中存储的是一个key的起始位置和终止位置。

bypass运行机制

bypass和普通机制的索引文件的差别不是很清楚

下图说明了bypass SortShuffleManager的原理。bypass运行机制的触发条件如下：

shuffle map task数量小于spark.shuffle.sort.bypassMergeThreshold参数的值。
不是聚合类的shuffle算子（比如reduceByKey）。

此时task会为每个下游task都创建一个临时磁盘文件，并将数据按key进行hash然后根据key的hash值，将key写入对应的磁盘文件之中。当然，写入磁盘文件时也是先写入内存缓冲，缓冲写满之后再溢写到磁盘文件的。最后，同样会将所有临时磁盘文件都合并成一个磁盘文件，并创建一个单独的索引文件。

该过程的磁盘写机制其实跟未经优化的HashShuffleManager是一模一样的，因为都要创建数量惊人的磁盘文件，只是在最后会做一个磁盘文件的合并而已。因此少量的最终磁盘文件，也让该机制相对未经优化的HashShuffleManager来说，shuffle read的性能会更好。

而该机制与普通SortShuffleManager运行机制的不同在于：第一，磁盘写机制不同；第二，不会进行排序。也就是说，启用该机制的最大好处在于，shuffle write过程中，不需要进行数据的排序操作，也就节省掉了这部分的性能开销。

为什么可以省去排序？？触发条件？？写机制？

这个问题在网上确实没有找到答案，但是根据我的猜想可能是shuffle map task数量太少，也就意味着M的数量很少，总的文件数较少，排序对于性能的提升可能还赶不上排序的消耗。

shuffle相关参数调优

以下是Shffule过程中的一些主要参数，这里详细讲解了各个参数的功能、默认值以及基于实践经验给出的调优建议。

spark.shuffle.file.buffer

默认值：32k
参数说明：该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。将数据写到磁盘文件之前，会先写入buffer缓冲中，待缓冲写满之后，才会溢写到磁盘。
调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如64k），从而减少shuffle write过程中溢写磁盘文件的次数，也就可以减少磁盘IO次数，进而提升性能。在实践中发现，合理调节该参数，性能会有1%~5%的提升。

spark.reducer.maxSizeInFlight

默认值：48m
参数说明：该参数用于设置shuffle read task的buffer缓冲大小，而这个buffer缓冲决定了每次能够拉取多少数据。
调优建议：如果作业可用的内存资源较为充足的话，可以适当增加这个参数的大小（比如96m），从而减少拉取数据的次数，也就可以减少网络传输的次数，进而提升性能。在实践中发现，合理调节该参数，性能会有1%~5%的提升。

spark.shuffle.io.maxRetries

默认值：3
参数说明：shuffle read task从shuffle write task所在节点拉取属于自己的数据时，如果因为网络异常导致拉取失败，是会自动进行重试的。该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功，就可能会导致作业执行失败。
调优建议：对于那些包含了特别耗时的shuffle操作的作业，建议增加重试最大次数（比如60次），以避免由于JVM的full gc或者网络不稳定等因素导致的数据拉取失败。在实践中发现，对于针对超大数据量（数十亿~上百亿）的shuffle过程，调节该参数可以大幅度提升稳定性。

spark.shuffle.io.retryWait

默认值：5s
参数说明：具体解释同上，该参数代表了每次重试拉取数据的等待间隔，默认是5s。
调优建议：建议加大间隔时长（比如60s），以增加shuffle操作的稳定性。

spark.shuffle.memoryFraction

默认值：0.2
参数说明：该参数代表了Executor内存中，分配给shuffle read task进行聚合操作的内存比例，默认是20%。
调优建议：在资源参数调优中讲解过这个参数。如果内存充足，而且很少使用持久化操作，建议调高这个比例，给shuffle read的聚合操作更多内存，以避免由于内存不足导致聚合过程中频繁读写磁盘。在实践中发现，合理调节该参数可以将性能提升10%左右。

spark.shuffle.manager

默认值：sort
参数说明：该参数用于设置ShuffleManager的类型。Spark 1.5以后，有三个可选项：hash、sort和tungsten-sort。HashShuffleManager是Spark 1.2以前的默认选项，但是Spark 1.2以及之后的版本默认都是SortShuffleManager了。tungsten-sort与sort类似，但是使用了tungsten计划中的堆外内存管理机制，内存使用效率更高。
调优建议：由于SortShuffleManager默认会对数据进行排序，因此如果你的业务逻辑中需要该排序机制的话，则使用默认的SortShuffleManager就可以；而如果你的业务逻辑不需要对数据进行排序，那么建议参考后面的几个参数调优，通过bypass机制或优化的HashShuffleManager来避免排序操作，同时提供较好的磁盘读写性能。这里要注意的是，tungsten-sort要慎用，因为之前发现了一些相应的bug。

spark.shuffle.sort.bypassMergeThreshold

默认值：200
参数说明：当ShuffleManager为SortShuffleManager时，如果shuffle read task的数量小于这个阈值（默认是200），则shuffle write过程中不会进行排序操作，而是直接按照未经优化的HashShuffleManager的方式去写数据，但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件，并会创建单独的索引文件。
调优建议：当你使用SortShuffleManager时，如果的确不需要排序操作，那么建议将这个参数调大一些，大于shuffle read task的数量。那么此时就会自动启用bypass机制，map-side就不会进行排序了，减少了排序的性能开销。但是这种方式下，依然会产生大量的磁盘文件，因此shuffle write性能有待提高。

spark.shuffle.consolidateFiles

默认值：false
参数说明：如果使用HashShuffleManager，该参数有效。如果设置为true，那么就会开启consolidate机制，会大幅度合并shuffle write的输出文件，对于shuffle read task数量特别多的情况下，这种方法可以极大地减少磁盘IO开销，提升性能。
调优建议：如果的确不需要SortShuffleManager的排序机制，那么除了使用bypass机制，还可以尝试将spark.shffle.manager参数手动指定为hash，使用HashShuffleManager，同时开启consolidate机制。在实践中尝试过，发现其性能比开启了bypass机制的SortShuffleManager要高出10%~30%。

五、MemoryManager

5.1基本知识

https://www.cnblogs.com/dreamfly2016/p/5720526.html
我记得分配比例是0.6 0.4 而不是0.5。需要注意两种内存互相借用的条件是不一样的。storage在executor缺少内存时需要将自己的数据push到磁盘，而收回memory也只能是在executor不使用的情况下。反过来，在只有当Execution Memory空间有空余时，Storage Memory才可以向Execution Memory借用空间，也就是说Execution Memory只要不够用了就可以向Storage Memory挤占空间不管Storage Memory有没有空余，而Storage Memory只能当Execution Memory有空余时才要以借用不能抢占。

5.2 存储storage内存的步骤
MemoryStore是Spark缓存数据（使用storage memory）的入口，由BlockManager调用。MemoryStore有两类数据的保存形式：将序列化数据保存到storage内存中，和将非序列化数据保存到内存中。对于非序列化数据，由于可能传入的数据过大，为了避免内存溢出，需要先估算传入的非序列化数据大小，并申请unroll内存，如果发现非序列化数据可以放入内存则再实际将数据保存到内存中。Spark当前存在两种内存管理器（通过spark.memory.useLegacyMode指定，默认使用新的内存管理方法即UnifiedMemoryManager），内存管理器管理着StorageMemoryPool和ExecutionMemoryPool，负责向其申请和释放内存，每个JVM中只有一个内存管理器。流程如下：

对于保存序列化数据（putBytes），首先向StorageMemoryPool申请storage内存，如果内存不足则StorageMemoryPool会收回借用给execution并还没有被使用的内存。对于保存非序列化数据（putIterator），首先预估存入的数据大小，并向StorageMemoryPool申请unroll内存，如果内存充足，则释放unroll内存，并申请数据大小的storage内存
如果内存充足则将数据封装为MemoryEntry保存到MemoryStore的map中。此处为两种不同数据存储的步骤，需要注意。

(

这里是下面的rdd缓存的内容，具体的介绍了储存到storage的过程。

RDD 在缓存到存储内存之前，Partition 中的数据一般以迭代器（Iterator）的数据结构来访问，这是 Scala 语言中一种遍历数据集合的方法。通过 Iterator 可以获取分区中每一条序列化或者非序列化的数据项(Record)，这些 Record 的对象实例在逻辑上占用了 JVM 堆内内存的 other 部分的空间，同一 Partition 的不同 Record 的空间并不连续。

RDD 在缓存到存储内存之后，Partition 被转换成 Block，Record 在堆内或堆外存储内存中占用一块连续的空间。将Partition由不连续的存储空间转换为连续存储空间的过程，Spark称之为"展开"（Unroll）。Block 有序列化和非序列化两种存储格式，具体以哪种方式取决于该 RDD 的存储级别。非序列化的 Block 以一种 DeserializedMemoryEntry 的数据结构定义，用一个数组存储所有的对象实例，序列化的 Block 则以 SerializedMemoryEntry的数据结构定义，用字节缓冲区（ByteBuffer）来存储二进制数据。每个 Executor 的 Storage 模块用一个链式 Map 结构（LinkedHashMap）来管理堆内和堆外存储内存中所有的 Block 对象的实例[6]，对这个 LinkedHashMap 新增和删除间接记录了内存的申请和释放。

因为不能保证存储空间可以一次容纳 Iterator 中的所有数据，当前的计算任务在 Unroll 时要向 MemoryManager 申请足够的 Unroll 空间来临时占位，空间不足则 Unroll 失败，空间足够时可以继续进行。对于序列化的 Partition，其所需的 Unroll 空间可以直接累加计算，一次申请。而非序列化的 Partition 则要在遍历 Record 的过程中依次申请，即每读取一条 Record，采样估算其所需的 Unroll 空间并进行申请，空间不足时可以中断，释放已占用的 Unroll 空间。如果最终 Unroll 成功，当前 Partition 所占用的 Unroll 空间被转换为正常的缓存 RDD 的存储空间，如下图所示。)

5.3 存储executor内存的步骤
MemoryConsumer是Spark任务运行申请内存（使用execution memory）的入口，MemoryConsumer为抽象类，需要申请内存进行计算的类继承自MemoryConsumer。TaskMemoryManager是管理每个任务申请的execution内存的类，每一个executor对应一个TaskMemoryManager。任务运行可以使用堆内内存也可以使用堆外内存（根据配置文件参数spark.memory.offHeap.enabled指定）。流程如下
MemoryConsumer向TaskMemoryManager申请execution内存
TaskMemoryManager向ExecutionMemoryPool申请内存，如果execution内存不足，会借用storage内存，如果还不足会强制将storage中缓存的数据刷新到磁盘上释放内存
如果ExecutionMemoryPool返回的内存不足，则调用MemoryConsumer.spill方法，将MemoryConsumer占用的内存数据刷新到磁盘上释放内存
根据配置的内存模式，为MemoryConsumer分配堆内/堆外内存
分配的内存会被包装为MemoryBlock，每个MemoryBlock对应一个page
TaskMemoryManager中维护了任务的pageTable，任务可以通过page number查询到对应的MemoryBlock

包含部分堆内和堆外内存规划的内容，两种内存的管理写的也很好。

https://www.ibm.com/developerworks/cn/analytics/library/ba-cn-apache-spark-memory-management/index.html?ca=drs-&utm_source=tuicool&utm_medium=referral

5.4 存储内存管理

RDD持久化

弹性分布式数据集（RDD）作为 Spark 最根本的数据抽象，是只读的分区记录（Partition）的集合，只能基于在稳定物理存储中的数据集上创建，或者在其他已有的 RDD 上执行转换（Transformation）操作产生一个新的 RDD。转换后的 RDD 与原始的 RDD 之间产生的依赖关系，构成了血统（Lineage）。凭借血统，Spark 保证了每一个 RDD 都可以被重新恢复。但 RDD 的所有转换都是惰性的，即只有当一个返回结果给 Driver 的行动（Action）发生时，Spark 才会创建任务读取 RDD，然后真正触发转换的执行。
Task 在启动之初读取一个分区时，会先判断这个分区是否已经被持久化，如果没有则需要检查 Checkpoint 或按照血统重新计算。所以如果一个 RDD 上要执行多次行动，可以在第一次行动中使用 persist 或 cache 方法，在内存或磁盘中持久化或缓存这个 RDD，从而在后面的行动时提升计算速度。事实上，cache 方法是使用默认的 MEMORY_ONLY 的存储级别将 RDD 持久化到内存，故缓存是一种特殊的持久化。堆内和堆外存储内存的设计，便可以对缓存 RDD 时使用的内存做统一的规划和管理（存储内存的其他应用场景，如缓存 broadcast 数据，暂时不在本文的讨论范围之内）。

RDD 的持久化由 Spark 的 Storage 模块负责，实现了 RDD 与物理存储的解耦合。Storage 模块负责管理 Spark 在计算过程中产生的数据，将那些在内存或磁盘、在本地或远程存取数据的功能封装了起来。在具体实现时 Driver 端和 Executor 端的 Storage 模块构成了主从式的架构，即 Driver 端的 BlockManager 为 Master，Executor 端的 BlockManager 为 Slave。Storage 模块在逻辑上以 Block 为基本存储单位，RDD 的每个 Partition 经过处理后唯一对应一个 Block（BlockId 的格式为 rdd_RDD-ID_PARTITION-ID ）。Master 负责整个 Spark 应用程序的 Block 的元数据信息的管理和维护，而 Slave 需要将 Block 的更新等状态上报到 Master，同时接收 Master 的命令，例如新增或删除一个 RDD。

在对 RDD 持久化时，Spark 规定了 MEMORY_ONLY、MEMORY_AND_DISK 等 7 种不同的存储级别，而存储级别是以下 5 个变量的组合：

存储级别

class StorageLevel private(

private var _useDisk: Boolean, //磁盘

private var _useMemory: Boolean, //这里其实是指堆内内存

private var _useOffHeap: Boolean, //堆外内存

private var _deserialized: Boolean, //是否为非序列化

private var _replication: Int = 1 //副本个数

)

通过对数据结构的分析，可以看出存储级别从三个维度定义了 RDD 的 Partition（同时也就是 Block）的存储方式：

存储位置：磁盘／堆内内存／堆外内存。如 MEMORY_AND_DISK 是同时在磁盘和堆内内存上存储，实现了冗余备份。OFF_HEAP 则是只在堆外内存存储，目前选择堆外内存时不能同时存储到其他位置。
存储形式：Block 缓存到存储内存后，是否为非序列化的形式。如 MEMORY_ONLY 是非序列化方式存储，OFF_HEAP 是序列化方式存储。
副本数量：大于 1 时需要远程冗余备份到其他节点。如 DISK_ONLY_2 需要远程备份 1 个副本。

RDD 缓存的过程

淘汰和落盘

由于同一个 Executor 的所有的计算任务共享有限的存储内存空间，当有新的 Block 需要缓存但是剩余空间不足且无法动态占用时，就要对 LinkedHashMap 中的旧 Block 进行淘汰（Eviction），而被淘汰的 Block 如果其存储级别中同时包含存储到磁盘的要求，则要对其进行落盘（Drop），否则直接删除该 Block。

存储内存的淘汰规则为：

被淘汰的旧 Block 要与新 Block 的 MemoryMode 相同，即同属于堆外或堆内内存
新旧 Block 不能属于同一个 RDD，避免循环淘汰
旧 Block 所属 RDD 不能处于被读状态，避免引发一致性问题
遍历 LinkedHashMap 中 Block，按照最近最少使用（LRU）的顺序淘汰，直到满足新 Block 所需的空间。其中 LRU 是 LinkedHashMap 的特性。

落盘的流程则比较简单，如果其存储级别符合_useDisk 为 true 的条件，再根据其_deserialized 判断是否是非序列化的形式，若是则对其进行序列化，最后将数据存储到磁盘，在 Storage 模块中更新其信息。

5.5 执行内存管理

5.5.1 多任务间内存分配

Executor 内运行的任务同样共享执行内存，Spark 用一个 HashMap 结构保存了任务到内存耗费的映射。每个任务可占用的执行内存大小的范围为 1/2N ~ 1/N，其中 N 为当前 Executor 内正在运行的任务的个数。每个任务在启动之时，要向 MemoryManager 请求申请最少为 1/2N 的执行内存，如果不能被满足要求则该任务被阻塞，直到有其他任务释放了足够的执行内存，该任务才可以被唤醒。

5.5.2 Shuffle 的内存占用

执行内存主要用来存储任务在执行 Shuffle 时占用的内存，Shuffle 是按照一定规则对 RDD 数据重新分区的过程，我们来看 Shuffle 的 Write 和 Read 两阶段对执行内存的使用：

Shuffle Write

若在 map 端选择普通的排序方式，会采用 ExternalSorter 进行外排，在内存中存储数据时主要占用堆内执行空间。
若在 map 端选择 Tungsten 的排序方式，则采用 ShuffleExternalSorter 直接对以序列化形式存储的数据排序，在内存中存储数据时可以占用堆外或堆内执行空间，取决于用户是否开启了堆外内存以及堆外执行内存是否足够。

Shuffle Read

在对 reduce 端的数据进行聚合时，要将数据交给 Aggregator 处理，在内存中存储数据时占用堆内执行空间。
如果需要进行最终结果排序，则要将再次将数据交给 ExternalSorter 处理，占用堆内执行空间。

在 ExternalSorter 和 Aggregator 中，Spark 会使用一种叫 AppendOnlyMap 的哈希表在堆内执行内存中存储数据，但在 Shuffle 过程中所有数据并不能都保存到该哈希表中，当这个哈希表占用的内存会进行周期性地采样估算，当其大到一定程度，无法再从 MemoryManager 申请到新的执行内存时，Spark 就会将其全部内容存储到磁盘文件中，这个过程被称为溢存(Spill)，溢存到磁盘的文件最后会被归并(Merge)。

Shuffle Write 阶段中用到的 Tungsten 是 Databricks 公司提出的对 Spark 优化内存和 CPU 使用的计划，解决了一些 JVM 在性能上的限制和弊端。Spark 会根据 Shuffle 的情况来自动选择是否采用 Tungsten 排序。Tungsten 采用的页式内存管理机制建立在 MemoryManager 之上，即 Tungsten 对执行内存的使用进行了一步的抽象，这样在 Shuffle 过程中无需关心数据具体存储在堆内还是堆外。每个内存页用一个 MemoryBlock 来定义，并用 Object obj 和 long offset 这两个变量统一标识一个内存页在系统内存中的地址。堆内的 MemoryBlock 是以 long 型数组的形式分配的内存，其 obj 的值为是这个数组的对象引用，offset 是 long 型数组的在 JVM 中的初始偏移地址，两者配合使用可以定位这个数组在堆内的绝对地址；堆外的 MemoryBlock 是直接申请到的内存块，其 obj 为 null，offset 是这个内存块在系统内存中的 64 位绝对地址。Spark 用 MemoryBlock 巧妙地将堆内和堆外内存页统一抽象封装，并用页表(pageTable)管理每个 Task 申请到的内存页。（rdd在存储到storageMemory前存储在执行内存和堆外内存中，由Tungsten 采用的页式内存管理机制管理位置）

Tungsten 页式管理下的所有内存用 64 位的逻辑地址表示，由页号和页内偏移量组成：

页号：占 13 位，唯一标识一个内存页，Spark 在申请内存页之前要先申请空闲页号。
页内偏移量：占 51 位，是在使用内存页存储数据时，数据在页内的偏移地址。

有了统一的寻址方式，Spark 可以用 64 位逻辑地址的指针定位到堆内或堆外的内存，整个 Shuffle Write 排序的过程只需要对指针进行排序，并且无需反序列化，整个过程非常高效，对于内存访问效率和 CPU 使用效率带来了明显的提升[10]。

Spark 的存储内存和执行内存有着截然不同的管理方式：对于存储内存来说，Spark 用一个 LinkedHashMap 来集中管理所有的 Block，Block 由需要缓存的 RDD 的 Partition 转化而成；而对于执行内存，Spark 用 AppendOnlyMap 来存储 Shuffle 过程中的数据，在 Tungsten 排序中甚至抽象成为页式内存管理，开辟了全新的 JVM 内存管理机制。

5.5.3 Shuffle Write和Shuffle Read

上面的内容解决了shuffle内存是如何被管理的，接下来看一下sheffle write 和read的过程

http://blog.csdn.net/raintungli/article/details/70807376 比较好的介绍了write的过程，数据是如何在内存中保存(spill到磁盘)，如何最后落盘。写的很好，也很复杂。简而言之如下

使用AppendOnlyMap数据结构进行输入数据的合并计算
输入的数据是进行分区合并计算，分区的方式是由Partitioner决定的
当内存不够的时候，会进行相同区块下的数据整理排序，Spill到临时文件temp_shuffle_UUID
最后对所有的数据集合（AppendOnlyMap里的数据和多个Spill的临时文件）进行区块的数据合并
生成Shuffle_shuffleId_mapId_reduceId.data 分区的数据文件，Shuffle_shuffleId_mapId_reduceId.index记录分区的位置
每个分区分别迭代生成最小的Key，将k,v内容写到shufflewrite的文件Shuffle_shuffleId_mapId_reduceId.data中去，重复前面的行为直到所有的key被迭代结束

这里的shufflewrite过程非常类似取n个数组的最小值，再比较n个最小值中的最小值，取最小值保存

1、ShuffleMapTask的计算结果是如何被ResultTask获得的呢？

1）ShuffleMapTask将计算的状态（不是具体的计算数值）包装为MapStatus返回给DAGScheduler；
2）DAGScheduler将MapStatus保存到MapOutputTrackerMaster中；
3）ResultTask在调用ShuffledRDD时会利用BlockStoreShuffleFetcher中的fetch方法获取数据：

a. 首先要咨询MapOutputTrackerMaster所要获取数据的location；

b. 根据返回的结果调用BlockManager.getMultiple获取到真正的数据。

MapStatus的结构如上图所示，由blockmanager_id 和 byteSize构成，blockmanager_id表示计算的中间结果数据实际存储在哪个BlockManager，byteSize表示不同reduceid所要读取的数据的大小。

详细的源码分析见https://blog.csdn.net/yjh314/article/details/52574975，写的真的不错

六、BlockManager

https://www.jianshu.com/p/6b99128f3dd6

一些简单的基础概念，目前应该是够了

懂什么

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
spark基本概念（总结和理解）

基本概念和任务的执行流程1、基本概念https://www.cnblogs.com/superhedantou/p/5699201.html2、执行流程https://blog.csdn.net/thomas0yang/article/details/50352261这个针对yarn的，可惜图挂了https://www.jianshu.com/p/42fff40bfe31补充...
复制链接

扫一扫

专栏目录