Spark调优之Cloudera博客(Part 2)

概述

Cloudera关于Spark调优方面的第二篇博客How-to: Tune Your Apache Spark Jobs (Part 2)，主要关注resource tuning(资源使用)、parallelism(并行度)、data representation(数据格式)这三方面。

Tuning Resource Allocation

如何合理使用现有的资源，尽可能的最大化利用，是这小节的重点。

集群资源管理器主要有YARN、 Mesos、Spark Standalone，下面的介绍基于YARN，关于YARN的介绍及为什么选择YARN，参考Apache Spark Resource Management and YARN App Models，此外，不同的集群资源管理器，指定资源的参数有差别。

参数设置

这里的Resource是指core和memory，通过spark-submit参数、spark-defaults.conf配置文件或环境变量设置，否则使用默认值，参数的优先级也是上述顺序，主要参数如下

spark-submit参数 spark-defaults.conf 环境变量 默认值 含义 - -driver-memory spark.driver.memory SPARK_DRIVER_MEMORY 1G Memory for driver - -driver-cores spark.driver.cores - 1 Number of cores used by the driver, only in cluster mode - -executor-memory spark.executor.memory SPARK_EXECUTOR_MEMORY 1G Memory per executor - -executor-cores spark.executor.cores SPARK_EXECUTOR_CORES 1 Number of cores per executor - -num-executors spark.executor.instances - 2 Number of executors to launch

Spark已实现动态调整Executor数量，即dynamic allocation，参考Dynamic Resource Allocation。

向YARN申请资源

YARN中两个参数控制core和memory资源，如下

yarn.nodemanager.resource.memory-mb container可以使用的最大内存 yarn.nodemanager.resource.cpu-vcores container可以使用的最多core

core的申请简单，memory的申请复杂一些，复杂的原因主要有两方面，如下

• spark.executor.memory/- -executor-memory参数设置了Executor(JVM)的内存，但是JVM运行时会用到堆外内存，使用spark.yarn.executor.memoryOverhead参数设置，默认大小为max(0.1 * executorMemory, 384)。YARN管理下的Executor内存模型如下
  
• YARN内存最小限制和规整

yarn.scheduler.minimum-allocation-mb 单个任务可申请的最少物理内存量，默认是1024（MB），如果一个任务申请的物理内存量少于该值，则该对应的值改为这个数 yarn.scheduler.increment-allocation-mb 内存规整化单位，默认是1024（MB），这意味着，如果一个Container请求资源是1.5GB，则将被调度器规整化为ceiling(1.5 GB / 1GB) * 1G=2GB

小结

上面介绍了资源的配置及申请，接下来关注涉及到性能的几个方面

• ApplicationMaster，YARN启动的一个进程，用于申请及管理containers，从整体考虑集群资源时，ApplicationMaster也要考虑在内。yarn-client模式下默认1G、1core，yarn-cluster 模式下，ApplicationMaster运行driver，可以通过- -driver-memory、- -driver-cores参数调整memory和core资源。
• 单个Executor内存设置过大，可能导致严重的gc延迟，甚至hang住，64G是一个经验性的上限值。
• HDFS client的并发性较差，涉及到HDFS读取写入的操作，每个Executor上的task数不易超过5，即- -executor-cores小于等于5。
• tiny executor(如1core、1G)失去了一个JVM中运行多个任务的优势，同时，广播变量也需要被copy更多份。

举个例子

假设有6个节点运行NodeManager，配置为16core、64G 内存，每个节点预留给OS 1core、1G内存，剩余15core、63G，则我们首先想到的配置如下

   --num-executors 6 --executor-cores 15 --executor-memory 63G

但根据小结中的总结，下面的配置可能更好

   --num-executors 17 --executor-cores 5 --executor-memory 19G

这个链接Apache Spark: The number of cores vs. the number of executors描述的情况和上面例子相似。

Tuning Parallelism

Partition数量是调优Spark程序重要的参数，我的博客Spark RDD之Partition介绍了相关内容。

task数等于DAG中最后一个RDD的Partition数，最后一个RDD的Partition数等于其父RDD的Partition数，以下三个transformation例外，coalesce(repartition)、union 、cartesian

coalesce(repartition) 增大或减小Partition数 union 子RDD Partition的数量等于父RDD Partition的和 cartesian 子RDD Partition的数量等于父RDD Partition的积

对于创建RDD的transformation的Partition数，需要根据数据源具体分析，可以参考Spark RDD之Partition。

task数过少，集群资源(core)利用不充分，也可能导致部分节点内存压力过大，对于task数，或者说Partition数的调整，主要从以下两方面着手

• 使用coalesce(repartition)，或者能够触发Shuffle的transformation中以参数的形式指定，如reduceByKey(_ + _，X）指定Partition数为X。
• 从数据源考虑，如hdfs的block数，以及通过数据源创建RDD时指定，如sc.parallelize(List(“a c”), 2)。

其中，上面提到的reduceByKey(_ + _，X)这种方式，X的值如何确定？

• 最简单直接的方式，得到其父RDD的Partition数，每次1.5倍递增，直至性能没有提升。
• 更科学的计算方式，如下
  

总之，过多的Partition数总是比过少要好(too many partitions is usually better than too few partitions)。

Slimming Down Your Data Structures

Spark内存中处理的数据通常是Java对象，持久化到硬盘的是序列化数据，Tungsten项目的出现，使得Spark内存中也能够操作序列化数据，极大的减少了内存使用。

spark.serializer参数配置序列化器，默认是JavaSerializer，KryoSerializer是更好的选择，效率高。

Java对象通常要占用比其存储的实际数据大很多的空间，这导致Spark能够cache的数据变少(MEMORY storage level)，Spark tuning guide提供了一些措施对其进行瘦身。

臃肿的序列化对象会增加网络磁盘IO，也会导致Spark能够cache的数据变少(MEMORY_SERstorage level)，解决办法是，使用SparkConf#registerKryoClasses API注册自定义class。

Data Formats

外部存储，如HDFS，考虑使用Avro、Parquet、 Thrift、 Protobuf等格式，而不是text，Parquet + LZO或Parquet + snappy是不错的组合，具体根据自身环境和数据的测试情况决定。

JSON格式是不推荐的，需要消耗CPU一遍又一遍的解析。

参考：
How-to: Tune Your Apache Spark Jobs (Part 2)
Apache Spark Resource Management and YARN App Models
Hadoop YARN中内存和CPU两种资源的调度和隔离
Hadoop YARN配置参数剖析(4)—Fair Scheduler相关参数