Spark存储原理 (核心篇三)

存储分析
Shuffle分析
序列化和压缩
共享变量
实例

https://www.cnblogs.com/tgzhu/p/5822370.html

Spark 作为一个以擅长内存计算为优势的计算引擎，内存管理方案是其非常重要的模块； Spark的内存可以大体归为两类：execution和storage，前者包括shuffles、joins、sorts和aggregations所需内存，后者包括cache和节点间数据传输所需内存；在Spark 1.5和之前版本里，两者是静态配置的，不支持借用，spark1.6 对内存管理模块进行了优化，通过内存空间的融合，消除以上限制，提供更好的性能。官方网站只是要求内存在8GB之上即可（Impala推荐要求机器配置在128GB），但spark job运行效率主要取决于：数据量大小，内存消耗，内核数（确定并发运行的task数量）

目录：

基础知识
spark1.5- 内存管理
spark1.6 内存管理

基本知识：

on-heap memory：Java中分配的非空对象都是由Java虚拟机的垃圾收集器管理的，也称为堆内内存。虚拟机会定期对垃圾内存进行回收，在某些特定的时间点，它会进行一次彻底的回收（full gc）。彻底回收时，垃圾收集器会对所有分配的堆内内存进行完整的扫描，这意味着一个重要的事实——这样一次垃圾收集对Java应用造成的影响，跟堆的大小是成正比的。过大的堆会影响Java应用的性能
off-heap memory：堆外内存意味着把内存对象分配在Java虚拟机的堆以外的内存，这些内存直接受操作系统管理（而不是虚拟机）。这样做的结果就是能保持一个较小的堆，以减少垃圾收集对应用的影响
LRU Cache（Least Recently Used）：LRU可以说是一种算法，也可以算是一种原则，用来判断如何从Cache中清除对象，而LRU就是“近期最少使用”原则，当Cache溢出时，最近最少使用的对象将被从Cache中清除
spark 源码： https://github.com/apache/spark/releases
scale ide for Intellij : http://plugins.jetbrains.com/plugin/?id=1347

Spark1.5- 内存管理：

1.6 版本引入了新的内存管理方案，配置参数： spark.memory.useLegacyMode 默认 false 表示使用新方案，true 表示使用旧方案， SparkEnv.scala 源码如下图：
在staticMemoryManager.scala 类中查看构造类及内存获取定义

通过代码推断，若设置了 spark.testing.memory 则以该配置的值作为 systemMaxMemory，否则使用 JVM 最大内存作为 systemMaxMemory。
spark.testing.memory 仅用于测试，一般不设置，所以这里我们认为 systemMaxMemory 的值就是 executor 的最大可用内存
Execution：用于缓存shuffle、join、sort和aggregation的临时数据，通过spark.shuffle.memoryFraction配置
spark.shuffle.memoryFraction：shuffle 期间占 executor 运行时内存的百分比，用小数表示。在任何时候，用于 shuffle 的内存总 size 不得超过这个限制，超出部分会 spill 到磁盘。如果经常 spill，考虑调大参数值
spark.shuffle.safetyFraction：为防止 OOM，不能把 systemMaxMemory * spark.shuffle.memoryFraction 全用了，需要有个安全百分比
最终用于 execution 的内存量为：executor 最大可用内存* spark.shuffle.memoryFraction*spark.shuffle.safetyFraction，默认为 executor 最大可用内存 * 0.16
execution内存被分配给JVM里的多个task线程。
task间的execution内存分配是动态的，如果没有其他tasks存在，Spark允许一个task占用所有可用execution内存

storage内存分配分析过程与 Execution 一致，由上面的代码得出，用于storage 的内存量为: executor 最大可用内存 * spark.storage.memoryFraction * spark.storage.safetyFraction，默认为 executor 最大可用内存 * 0.54
在 storage 中，有一部分内存是给 unroll 使用的，unroll 即反序列化 block，该部分占比由 spark.storage.unrollFraction 控制，默认为0.2

通过代码分析，storage 和 execution 总共使用了 80% 的内存，剩余 20% 内存被系统保留了，用来存储运行中产生的对象,该类型内存不可控.

小结：

这种内存管理方式的缺陷，即 execution 和 storage 内存表态分配，即使在一方内存不够用而另一方内存空闲的情况下也不能共享，造成内存浪费，为解决这一问题，spark1.6 启用新的内存管理方案UnifiedMemoryManager
staticMemoryManager- jvm 堆内存分配图如下

Spark1.6 内存管理：

从spark1.6开始，引入了新的内存管理方式-----统一内存管理(UnifiedMemoryManager)，在统一内存管理下，spark一个executor中的jvm heap内存被划分成如下图:
Reserved Memory,这一部分的内存是我们无法使用的部分，spark内部保留内存，会存储一些spark的内部对象等内容。
spark1.6默认的Reserved Memory大小是300MB。这部分大小是不允许我们使用者改变的。简单点说就是我们在为executor申请内存后，有300MB是我们无法使用的。并且如果我们申请的executor的大小小于1.5 * Reserved Memory 即 < 450MB，spark会报错:
User Memory：用户在程序中创建的对象存储等一系列非spark管理的内存开销都占用这一部分内存
Spark Memory：该部分大小为 (JVM Heap Size - Reserved Memory) * spark.memory.fraction,其中的spark.memory.fraction可以是我们配置的(默认0.75)，如下图：
如果spark.memory.fraction配小了，我们的spark task在执行时产生数据时，包括我们在做cache时就很可能出现经常因为这部分内存不足的情况而产生spill到disk的情况，影响效率。采用官方推荐默认配置
Spark Memory这一块有被分成了两个部分，Execution Memory 和 Storage Memory,这通过spark.memory.storageFraction来配置两块各占的大小(默认0.5，一边一半)，如图：
Storage Memory主要用来存储我们cache的数据和临时空间序列化时unroll的数据，以及broadcast变量cache级别存储的内容
Execution Memory则是spark Task执行时使用的内存(比如shuffle时排序就需要大量的内存)
为了提高内存利用率，spark针对Storage Memory 和 Execution Memory有如下策略:

1. 一方空闲，一方内存不足情况下，内存不足一方可以向空闲一方借用内存
2. 只有Execution Memory可以强制拿回Storage Memory在Execution Memory空闲时，借用的Execution Memory的部分内存（如果因强制取回，而Storage Memory数据丢失，重新计算即可）
3. 如果Storage Memory只能等待Execution Memory主动释放占用的Storage Memory空闲时的内存。(这里不强制取回，因为如果task执行，数据丢失就会导致task 失败)

https://www.cnblogs.com/liuliliuli2017/p/6809094.html

Spark核心概念之Shuffle

以reduceByKey为例解释shuffle过程。

在没有task的文件分片合并下的shuffle过程如下：（spark.shuffle.consolidateFiles=false）

fetch 来的数据存放到哪里？

刚 fetch 来的 FileSegment 存放在 softBuffer 缓冲区，经过处理后的数据放在内存 + 磁盘上。这里我们主要讨论处理后的数据，可以灵活设置这些数据是“只用内存”还是“内存＋磁盘”。如果spark.shuffle.spill = false就只用内存。由于不要求数据有序，shuffle write 的任务很简单：将数据 partition 好，并持久化。之所以要持久化，一方面是要减少内存存储空间压力，另一方面也是为了 fault-tolerance。

shuffle之所以需要把中间结果放到磁盘文件中，是因为虽然上一批task结束了，下一批task还需要使用内存。如果全部放在内存中，内存会不够。另外一方面为了容错，防止任务挂掉。

存在问题如下：

产生的 FileSegment 过多。每个 ShuffleMapTask 产生 R（reducer 个数）个 FileSegment，M 个 ShuffleMapTask 就会产生 M * R 个文件。一般 Spark job 的 M 和 R 都很大，因此磁盘上会存在大量的数据文件。
缓冲区占用内存空间大。每个 ShuffleMapTask 需要开 R 个 bucket，M 个 ShuffleMapTask 就会产生 MR 个 bucket。虽然一个 ShuffleMapTask 结束后，对应的缓冲区可以被回收，但一个 worker node 上同时存在的 bucket 个数可以达到 cores R 个（一般 worker 同时可以运行 cores 个 ShuffleMapTask），占用的内存空间也就达到了cores× R × 32 KB。对于 8 核 1000 个 reducer 来说，占用内存就是 256MB。

为了解决上述问题，我们可以使用文件合并的功能。

在进行task的文件分片合并下的shuffle过程如下：（spark.shuffle.consolidateFiles=true）

可以明显看出，在一个 core 上连续执行的 ShuffleMapTasks 可以共用一个输出文件 ShuffleFile。先执行完的 ShuffleMapTask 形成 ShuffleBlock i，后执行的 ShuffleMapTask 可以将输出数据直接追加到 ShuffleBlock i 后面，形成 ShuffleBlock i'，每个 ShuffleBlock 被称为 FileSegment。下一个 stage 的 reducer 只需要 fetch 整个 ShuffleFile 就行了。这样，每个 worker 持有的文件数降为 cores× R。FileConsolidation 功能可以通过spark.shuffle.consolidateFiles=true来开启。

Spark核心概念之Cache

val rdd1 = ... // 读取hdfs数据，加载成RDD
rdd1.cache

val rdd2 = rdd1.map(...)
val rdd3 = rdd1.filter(...)

rdd2.take(10).foreach(println)
rdd3.take(10).foreach(println)

rdd1.unpersist

cache和unpersisit两个操作比较特殊，他们既不是action也不是transformation。cache会将标记需要缓存的rdd，真正缓存是在第一次被相关action调用后才缓存；unpersisit是抹掉该标记，并且立刻释放内存。只有action执行时，rdd1才会开始创建并进行后续的rdd变换计算。

cache其实也是调用的persist持久化函数，只是选择的持久化级别为MEMORY_ONLY。

persist支持的RDD持久化级别如下：