MaxCompute Spark 资源使用优化祥解

885 阅读8分钟

简介: 本文主要讲解MaxCompute Spark资源调优,目的在于在保证Spark任务正常运行的前提下,指导用户更好地对Spark作业资源使用进行优化,极大化利用资源,降低成本。

本文作者:吴数傑 阿里云智能 开发工程师

1. 概述

本文主要讲解MaxCompute Spark资源调优,目的在于在保证Spark任务正常运行的前提下,指导用户更好地对Spark作业资源使用进行优化,极大化利用资源,降低成本。

2. Sensor

  • Sensor提供了一种可视化的方式监控运行中的Spark进程,每个worker(Executor)及master(Driver)都具有各自的状态监控图,可以通过Logview中找到入口,如下图所示:

  • 打开Sensor之后,可以看到下图提供了Driver/Executor在其生命周期内的CPU和内存的使用情况:

  • cpu_plan/mem_plan(蓝线)代表了用户申请的CPU和内存计划量

  • 用户可以直观地从cpu_usage图中看出任务运行中的CPU利用率

  • mem_usage代表了任务运行中的内存使用,是mem_rss和page cache两项之和,详见下文

  • Memory Metrics

  • mem_rss 代表了进程所占用了常驻内存,这部分内存也就是Spark任务运行所使用的实际内存,通常需要用户关注,如果该内存超过用户申请的内存量,就可能会发生OOM,导致Driver/Executor进程终止。此外,该曲线也可以用于指导用户进行内存优化,如果实际使用量远远小于用户申请量,则可以减少内存申请,极大化利用资源,降低成本。

  • mem_cache(page_cache)用于将磁盘中的数据缓存到内存中,从而减少磁盘I/O操作,通常由系统进行管理,如果物理机内存充足,那么mem_cache可能会使用很多,用户可以不必关心该内存的分配和回收。

3. 资源参数调优

(1)Executor Cores

相关参数:spark.executor.cores

  • 每个Executor的核数,即每个Executor中的可同时运行的task数目
  • Spark任务的最大并行度是num-executors * executor-cores
  • Spark任务执行的时候,一个CPU core同一时间最多只能执行一个Task。如果CPU core数量比较充足,通常来说,可以比较快速和高效地执行完这些Task。同时也要注意,每个Executor的内存是多个Task共享的,如果单个Executor核数太多,内存过少,那么也很可能发生OOM。

(2)Executor Num

相关参数:spark.executor.instances

  • 该参数用于设置Spark作业总共要用多少个Executor进程来执行
  • 通常用户可以根据任务复杂度来决定到底需要申请多少个Executor

此外,需要注意,如果出现Executor磁盘空间不足,或者部分Executor OOM的问题,可以通过减少单个Executor的cores数,增加Executor的instances数量来保证任务总体并行度不变,同时降低任务失败的风险。

(3)Executor Memory

相关参数:spark.executor.memory

  • 该参数用于设置每个Executor进程的内存。Executor内存的大小,很多时候直接决定了Spark作业的性能,而且JVM OOM在Executor中更为常见。

相关参数2:spark.executor.memoryOverhead

  • 设置申请Executor的堆外内存,主要用于JVM自身,字符串, NIO Buffer等开销,注意memoryOverhead 这部分内存并不是用来进行计算的,用户代码及spark都无法直接操作。
  • 如果不设置该值,那么默认为spark.executor.memory * 0.10,最小为384 MB

Executor 内存不足的表现形式:

  • 在Executor的日志(Logview->某个Worker->StdErr)中出现Cannot allocate memory

  • 在任务结束的Logview result的第一行中出现:The job has been killed by "OOM Killer", please check your job's memory usage.
  • 在Sensor中发现内存使用率非常高
  • 在Executor的日志中出现java.lang.OutOfMemoryError: Java heap space
  • 在Executor的日志中出现GC overhead limit exceeded
  • Spark UI中发现频繁的GC信息
  • 可能出现OOM的间接表现形式:部分Executor出现No route to host: workerd********* / Could not find CoarseGrainedScheduler等错误

可能原因及解决方案:

  • 限制executor 并行度,将cores 调小:多个同时运行的 Task 会共享一个Executor 的内存,使得单个 Task 可使用的内存减少,调小并行度能缓解内存压力增加单个Executor内存
  • 增加分区数量,减少每个executor负载
  • 考虑数据倾斜问题,因为数据倾斜导致某个 task 内存不足,其它 task 内存足够
  • 如果出现了上文所述的Cannot allocate memory或The job has been killed by "OOM Killer", please check your job's memory usage,这种情况通常是由于系统内存不足,可以适当增加一些堆外内存来缓解内存压力,通常设置spark.executor.memoryOverhead为1g/2g就足够了

(4)Driver Cores

相关参数spark.driver.cores

  • 通常Driver Cores不需要太大,但是如果任务较为复杂(如Stage及Task数量过多)或者Executor数量过多(Driver需要与每个Executor通信并保持心跳),在Sensor中看到Cpu利用率非常高,那么可能需要适当调大Driver Cores

另外要注意,在Yarn-Cluster模式运行Spark任务,不能直接在代码中设置Driver的资源配置(core/memory),因为在JVM启动时就需要该参数,因此需要通过--driver-memory命令行选项或在spark-defaults.conf文件/Dataworks配置项中进行设置。

(5)Driver Memory

相关参数1:spark.driver.memory

  • 设置申请Driver的堆内内存,与executor类似

相关参数2:spark.driver.maxResultSize

  • 代表每个Spark的action(例如collect)的结果总大小的限制,默认为1g。如果总大小超过此限制,作业将被中止,如果该值较高可能会导致Driver发生OOM,因此用户需要根据作业实际情况设置适当值。

相关参数3:spark.driver.memoryOverhead

  • 设置申请Driver的堆外内存,与executor类似

  • Driver的内存通常不需要太大,如果Driver出现内存不足,通常是由于Driver收集了过多的数据,如果需要使用collect算子将RDD的数据全部拉取到Driver上进行处理,那么必须确保Driver的内存足够大。

表现形式:

  • Spark应用程序无响应或者直接停止
  • 在Driver的日志(Logview->Master->StdErr)中发现了Driver OutOfMemory的错误
  • Spark UI中发现频繁的GC信息
  • 在Sensor中发现内存使用率非常高
  • 在Driver的日志中出现Cannot allocate memory

可能原因及解决方案:

  • 代码可能使用了collect操作将过大的数据集收集到Driver节点
  • 在代码创建了过大的数组,或者加载过大的数据集到Driver进程汇总
  • SparkContext,DAGScheduler都是运行在Driver端的。对应rdd的Stage切分也是在Driver端运行,如果用户自己写的程序有过多的步骤,切分出过多的Stage,这部分信息消耗的是Driver的内存,这个时候就需要调大Driver的内存。有时候如果stage过多,Driver端甚至会有栈溢出

(6)本地磁盘空间

相关参数:spark.hadoop.odps.cupid.disk.driver.device_size:

  • 该参数代表为单个Driver或Executor申请的磁盘空间大小,默认值为20g,最大支持100g
  • Shuffle数据以及BlockManager溢出的数据均存储在磁盘上

磁盘空间不足的表现形式:

在Executor/Driver的日志中发现了No space left on device错误

解决方案:

最简单的方法是直接增加更多的磁盘空间,调大spark.hadoop.odps.cupid.disk.driver.device_size。

如果增加到100g之后依然出现该错误,可能是由于存在数据倾斜,shuffle或者cache过程中数据集中分布在某些block,也可能是单个Executor的shuffle数据量确实过大,可以尝试:

  • 对数据重分区,解决数据倾斜问题
  • 缩小单个Executor的任务并发spark.executor.cores
  • 缩小读表并发spark.hadoop.odps.input.split.size
  • 增加executor的数量spark.executor.instances

需要注意:

  • 同样由于在JVM启动前就需要挂载磁盘,因此该参数必须配置在spark-defaults.conf文件或者dataworks的配置项中,不能配置在用户代码中
  • 此外需要注意该参数的单位为g,不能省略g
  • 很多时候由于用户配置位置有误或者没有带单位g,导致参数实际并没有生效,任务运行依然失败

4. 总结

上文主要介绍了MaxCompute Spark在使用过程中可能遇到的资源不足的问题及相应的解决思路,为了能够最大化利用资源,首先建议按照1: 4的比例来申请单个worker资源,即1 core: 4 gb memory,如果出现OOM,那么需要查看日志及Sensor对问题进行初步定位,再进行相应的优化和资源调整。不建议单个Executor Cores 设置过多,通常单个Executor在2-8 core是相对安全的,如果超过8,那么建议增加instance数量。适当增加堆外内存(为系统预留一些内存资源)也是一个常用的调优方法,通常在实践中可以解决很多OOM的问题。最后,用户可以参考官方文档spark.apache.org/docs/2.4.5/…

原文链接

本文为阿里云原创内容,未经允许不得转载。