Spark调优之Tuning Spark(Part 2)

概述

翻译Spark官方调优指南Tuning Spark剩余部分Other Considerations。

Level of Parallelism

并行度不够，会导致集群的资源利用的不充分，并行程度由task数决定，task数和最后一个transformation的Partition数一致，因此，调整并行度就是调整Partition数。

创建RDD时可以指定Partition数量，默认由spark.default.parallelism参数决定(YARN模式下为所有executor的core数总和)，能够触发Shuffle的transformation可以通过参数的方式修改Partition数，推荐每个core运行2-3 task，更多内容请参考我的博客Spark RDD之Partition，Spark调优之Cloudera博客(Part 2)中关于Parallelism部分的介绍。

Memory Usage of Reduce Tasks

OOM是Spark开发中最常见的问题，Spark中也有溢写机制，内存不足时写磁盘，导致OOM的原因可以分为以下 两方面

• 非Spark原因导致，可以概括为JVM内存模型中某个部分内存不足导致OOM(常见如Perm区)，这一类问题是所有运行在JVM之上的程序都会遇到的，更详细的内容请参考深入理解Java虚拟机：OutOfMemory实战。
• Spark运行机制导致，由于Spark溢写机制的存在，仅仅是内存放不下数据并不会导致OOM，典型的场景是，当Shuffle中涉及到group、aggregation操作，需要把对应数据全部加载到内存，如果此时内存大小不足会触发OOM。

针对OOM问题，解决的思路如下

• 如果使用的资源管理器是YARN，通过Web UI查看日志确定内存使用情况，根据日志做出对应调整，参考yarn oom问题一例的思路。
• 通过日志没有思路的话，需要输出OOM时的堆栈信息，spark-submit提交任务时增加如下参数

  --conf "spark.executor.extraJavaOptions= -XX:+HeapDumpOnOutOfMemoryError" 
  

  使用eclipse插件Memory Analyzer (MAT)分析。
• 此外，增加Partition数是最简单，也是优先考虑尝试的方式。

Broadcasting Large Variables

如果transformation中使用了较大的对象(大于20KB)，Broadcast功能能够降低最终生成task的大小，因为每个task内部不再保存这个变量，而是通过driver直接发送给executor，参考Advantage of Broadcast Variables
，当Partition较多时，效果越发明显。

Data Locality

就近执行对Spark性能有较大影响，计算跟着数据走，两者在一个JVM或节点上是最快的，否则需要网络传输数据，有以下几个级别

PROCESS_LOCAL 数据和task在一个JVM，最好的情况，通常是Local模式下 NODE_LOCAL 数据和task在一个节点，比PROCESS_LOCAL差一些 NO_PREF 从任何地方访问数据速度相同，没有locality偏好 RACK_LOCAL 数据和task在相同机架不同节点 ANY 数据和task在不同机架

通过Spark Web UI查看Data Locality，如下

Spark根据就近执行原则选择较近的节点执行task，但较近的节点CPU可能处于忙碌状态，暂时无法执行task，此时Spark等待一段时间(由spark.locality参数确定，默认3s)，等待结束后依然如此，task发送到其他executor执行。

参考：
深入理解Java虚拟机：OutOfMemory实战
Tuning Spark
yarn oom问题一例
Advantage of Broadcast Variables