深入分析Spark对MapReduce的底层技术优化

Spark对MapReduce做了大量的改进和优化，主要包括以下个方面：

1）磁盘I/O的读写优化：

• 中间结果缓存在内存中：随着实时大数据应用越来越多，Hadoop作为离线的高吞吐、低响应框架已不能满足这类需求。Hadoop MapReduce的map端将中间输出和结果存储在磁盘中，reduce端又需要从磁盘读写中间结果，从而造成磁盘I/O成为瓶颈。Spark则允许将map端的中间输出和结果缓存在内存中，从而使得reduce端在拉取中间结果时避免了大量的磁盘I/O。
• 应用程序上传的资源文件缓存在Driver本地文件服务的内存中：Hadoop YARN中的ApplicationMaster申请到Container后，具体任务需要利用NodeManager从HDFS的不同节点下载任务所需的资源（如Jar包），增加了磁盘I/O。Spark则将应用程序上传的资源文件缓存在Driver本地文件服务的内存中，当Executor执行任务时直接从Driver的内存中读取，从而节省了大量的磁盘I/O。

2）任务的并行处理优化：由于将中间结果写到磁盘与从磁盘读取中间结果属于不同的环节，Hadoop将它们简单地通过串行执行衔接起来。而Spark则把不同的环节抽象为Stage，允许多个Stage既可以串行执行，又可以并行执行。

3）任务调度中的资源过滤：当Stage中某个分区的Task执行失败后，会重新对此Stage调度，但在重新调度的时候会过滤已经执行成功的分区任务，所以不会造成重复计算和资源浪费。

4）Shuffle排序：Hadoop MapReduce在Shuffle之前会将中间结果按key的hash值和key值大小进行两层排序，确保分区内部的有序性。而Spark则可以根据不同场景选择在map端排序还是reduce端排序。

5）内存管理优化：Spark将内存分为堆上的存储内存、堆外的存储内存、堆上的执行内存、堆外的执行内存4个部分。Spark既提供了执行内存和存储内存之间固定边界的实现，又提供了执行内存和存储内存之间“软”边界的实现。Spark默认使用“软”边界的实现，执行内存或存储内存中的任意一方在资源不足时都可以借用另一方的内存，最大限度地提高资源的利用率，减少对资源的浪费。Spark由于对内存使用的偏好，内存资源的多寡和使用率就显得尤为重要，为此Spark的内存管理器提供的Tungsten实现了一种与操作系统的内存Page非常相似的数据结构，用于直接操作操作系统内存，节省了创建的Java对象在堆中占用的内存，使得Spark对内存的使用效率更加接近硬件。Spark会给每个Task分配一个配套的任务内存管理器，对Task粒度的内存进行管理。Task的内存可以被多个内部的消费者消费，任务内存管理器对每个消费者进行Task内存的分配与管理，因此Spark对内存有着更细粒度的管理。