spark 算子例子_Spark性能调优方法

公众号后台回复关键词：pyspark，获取本项目github地址。

Spark程序可以快如闪电⚡️，也可以慢如蜗牛?。

它的性能取决于用户使用它的方式。

一般来说，如果有可能，用户应当尽可能多地使用SparkSQL以取得更好的性能。

主要原因是SparkSQL是一种声明式编程风格，背后的计算引擎会自动做大量的性能优化工作。

基于RDD的Spark的性能调优属于坑非常深的领域，并且很容易踩到。

我们将介绍Spark调优原理，Spark任务监控，以及Spark调优案例。

本文参考了以下文章：

《Spark性能优化指南——基础篇》：https://tech.meituan.com/2016/04/29/spark-tuning-basic.html

《Spark性能优化指南——高级篇》：https://tech.meituan.com/2016/05/12/spark-tuning-pro.html

《spark-调节executor堆外内存》：https://www.cnblogs.com/colorchild/p/12175328.html

import findspark

#指定spark_home为刚才的解压路径,指定python路径
spark_home = "/Users/liangyun/ProgramFiles/spark-3.0.1-bin-hadoop3.2"
python_path = "/Users/liangyun/anaconda3/bin/python"
findspark.init(spark_home,python_path)

import pyspark 
from pyspark.sql import SparkSession

#SparkSQL的许多功能封装在SparkSession的方法接口中

spark = SparkSession.builder \
        .appName("test") \
        .config("master","local[4]") \
        .enableHiveSupport() \
        .getOrCreate()

sc = spark.sparkContext

一，Spark调优原理

可以用下面三个公式来近似估计spark任务的执行时间。

可以用下面二个公式来说明spark在executor上的内存分配。

如果程序执行太慢，调优的顺序一般如下：

1，首先调整任务并行度，并调整partition分区。

2，尝试定位可能的重复计算，并优化之。

3，尝试定位数据倾斜问题或者计算倾斜问题并优化之。

4，如果shuffle过程提示堆外内存不足，考虑调高堆外内存。

5，如果发生OOM或者GC耗时过长，考虑提高executor-memory或降低executor-core。

以下是对上述公式中涉及到的一些概念的初步解读。

• 任务计算总时间：假设由一台无限内存的同等CPU配置的单核机器执行该任务，所需要的运行时间。通过缓存避免重复计算，通过mapPartitions代替map以减少诸如连接数据库，预处理广播变量等重复过程，都是减少任务计算总时间的例子。

• shuffle总时间：任务因为reduceByKey，join，sortBy等shuffle类算子会触发shuffle操作产生的磁盘读写和网络传输的总时间。shuffle操作的目的是将分布在集群中多个节点上的同一个key的数据，拉取到同一个节点上，以便让一个节点对同一个key的所有数据进行统一处理。shuffle过程首先是前一个stage的一个shuffle write即写磁盘过程，中间是一个网络传输过程，然后是后一个stage的一个shuffle read即读磁盘过程。shuffle过程既包括磁盘读写，又包括网络传输，非常耗时。因此如有可能，应当避免使用shuffle类算子。例如用map+broadcast的方式代替join过程。退而求其次，也可以在shuffle之前对相同key的数据进行归并，减少shuffle读写和传输的数据量。此外，还可以应用一些较为高效的shuffle算子来代替低效的shuffle算子。例如用reduceByKey/aggregateByKey来代替groupByKey。最后，shuffle在进行网络传输的过程中会通过netty使用JVM堆外内存，spark任务中大规模数据的shuffle可能会导致堆外内存不足，导致任务挂掉，这时候需要在配置文件中调大堆外内存。

• GC垃圾回收总时间：当JVM中execution内存不足时，会启动GC垃圾回收过程。执行GC过程时候，用户线程会终止等待。因此如果execution内存不够充分，会触发较多的GC过程，消耗较多的时间。在spark2.0之后excution内存和storage内存是统一分配的，不必调整excution内存占比，可以提高executor-memory来降低这种可能。或者减少executor-cores来降低这种可能(这会导致任务并行度的降低)。

• 任务有效并行度：任务实际上平均被多少个core执行。它首先取决于可用的core数量。当partition分区数量少于可用的core数量时，只