Spark计算引擎——概述

Spark的计算引擎主要包括执行内存和Shuffle两部分

1 执行内存

执行内存主要包括执行内存、任务内存管理器（TaskMemoryManager）、内存消费者（MemoryCosumer）等内容。执行内存包括在JVM堆上进行分配的执行内存池（ExecutionMemoryPool）和在操作系统的内存中进行分配的Tungsten。内存管理器将提供API对执行内存和Tungsten进行管理（包括申请内存、释放内存等）。因为同一节点上能够运行多次任务尝试，所以需要每一次任务尝试都有单独的任务内存管理器为其服务。任务尝试通过任务内存管理器与内存管理器交互，以申请任务尝试所需要的执行内存，并在任务尝试结束后释放使用的执行内存。一次任务尝试过程中会有多个组件需要使用执行内存，这些组件统称为内存消费者。内存消费者多种多样，有对map任务的中间输出数据在JVM堆上进行缓存、聚合、溢出、持久化等处理的ExternalSorter，也有在操作系统内存中进行缓存、溢出、持久化处理的ShuffleExternalSorter，还有将key/value对存储到连续的内存块中的RowBasedKeyValueBatch。消费者需要的执行内存都是向任务内存管理器所申请的。从执行内存的角度来看，计算引擎的整体架构如下图所示：

下面先来看看MapReduce计算框架的Shuffle过程：

在早期Spark版本中，Shuffle如下图所示：

步骤如下：

• 1）map任务会为每一个reduce任务创建一个bucket。假设有M个map任务，R个reduce任务，则map阶段一共会创建M * R个桶（bucket）
• 2）map任务会将产生的中间结果按照分区（partition）写入到不同的bucket中
• 3）reduce任务从本地或者远端的map任务所在的BlockManager获取相应的bucket作为输入。

Spark早期版本的Shuffle过程存在以下问题：

• 1）map任务的中间结果首先存入内存，然后才写入磁盘。这对于内存的开销很大，当一个节点上map任务的输出结果集很大时，很容易导致内存紧张，进而发生内存溢出
• 2）每个map任务都会输出R（reduce任务数量）个bucket。假设M等于1000，R也等于1000，那么共计生成100万个bucket，在bucket本身不大，但是Shuffle很频繁的情况下，磁盘I/O将成为性能瓶颈。

Hadoop MapReduce的Shuffle过程存在以下问题：

• 1）reduce任务获取到map任务的中间输出后，会对这些数据在磁盘上进行合并（merge）和排序（sort），虽然占用内存很小，但是却产生了更多的磁盘I/O
• 2）当数据量很小，但是map任务和reduce任务数目很多时，会产生很多网络I/O

为了解决以上MapReduce和早期spark的Shuffle过程中的性能问题，目前Spark已经对Shuffle做了多种性能优化，主要解决方法如下：

• 1）将map任务给每个partition的reduce任务输出的bucket合并到同一个文件中，这解决了bucket数量很多，但是数据本身的体积不大时，造成Shuffle频繁，磁盘I/O成为性能瓶颈的问题
• 2）map任务逐条输出计算结果，而不是一次性输出到内存，并使用AppendOnlyMap缓存及其聚合算法对中间结果进行聚合，这大大减小了中间结果所占的内存大小
• 3）对SizeTrackingAppendOnlyMap、SizeTrackingPairBuffer及Tungsten的Page进行溢出判断，当超出溢出限制的大小时，将数据写入磁盘，防止内存溢出
• 4）reduce任务将要拉取的Block按照BlockManager地址划分，然后将同一BlockManager地址中的Block累积为少量网络请求，减少网络I/O

经过以上优化，目前Spark实现的Shuffle的过程大致为：map任务在输出时会进行分区计算并生成数据文件和索引文件等步骤，可能还伴随有缓存、排序、聚合、溢出、合并等操作。reduce任务将map任务输出的Block划分为本地和远端的Block，对于远端的Block，需要使用ShuffleClient从远端节点下载，而对于 本地的BLock，只需要从本地的存储体系中读取即可。reduce任务读取到map任务输出的数据后，可能进行缓存 、排序、聚合、溢出、合并等操作，最终输出结果。