SparkSQL优化

优化说明

缓存数据到内存

Spark SQL可以通过调用spark.sqlContext.cacheTable("tableName") 或者dataFrame.cache()，将表用一种柱状格式（ an inmemory columnar format）缓存至内存中。然后Spark SQL在执行查询任务时，只需扫描必需的列，从而以减少扫描数据量、提高性能。通过缓存数据，Spark SQL还可以自动调节压缩，从而达到最小化内存使用率和降低GC压力的目的。调用sqlContext.uncacheTable("tableName")可将缓存的数据移出内存。

通过sc.broadcast(spark.table("表名"))，将表广播出去，进行表与表之间的join相关操作。

可通过两种配置方式开启缓存数据功能：

1)使用spark.sqlContext的setConf方法。

2)执行SQL命令 SET key=value。

表-2 优化方式

Property Name	Default	Meaning
spark.sql.inMemoryColumnarStorage.compressed	true	如果假如设置为true，SparkSql会根据统计信息自动的为每个列选择压缩方式进行压缩
spark.sql.inMemoryColumnarStorage.batchSize	10000	控制列缓存的批量大小。批次大有助于改善内存使用和压缩，但是缓存数据会有OOM的风险

参数调优

可以通过配置下表中的参数调节Spark SQL的性能。

表-3 参数调优

Property Name	Default	Meaning
spark.sql.files.maxPartitionBytes	134217728 (128 MB)	获取数据到分区中的最大字节数。
spark.sql.files.openCostInBytes	4194304 (4 MB)	该参数默认4M，表示小于4M的小文件会合并到一个分区中，用于减小小文件，防止太多单个小文件占一个分区情况。
spark.sql.broadcastTimeout	300	广播等待超时时间，单位秒。
spark.sql.autoBroadcastJoinThreshold	10485760 (10 MB)	最大广播表的大小。设置为-1可以禁止该功能。当前统计信息仅支持Hive Metastore表。
spark.sql.shuffle.partitions	200	设置shuffle分区数，默认200。

SQL炸裂函数

Explode：SparkSql中的列转行函数：专门针对array或map操作。

//使用explode方法必须导入下面的包：
import org.apache.spark.sql.functions._

object explode_Demo{def main(args: Array[String]): Unit = {//创建程序入口val spark: SparkSession = SparkSession.builder().appName("createDF").master("local[*]").getOrCreate()//调用sparkContextval sc: SparkContext = spark.sparkContext//设置控制台日志输出级别sc.setLogLevel("WARN")//导包import spark.implicits._//加载数据val positionDF = spark.read.json("E:\\资料\\position.json")//查看表结构positionDF.printSchema()//DSL方法处理val listData: DataFrame = positionDF.select(explode($"data.list")).toDF("position")//查看表结构listData.printSchema()//查看表数据listData.show(false)//查看workName并统计个数listData.select($"position.workName" as "positions").groupBy($"positions").count().orderBy($"count".desc).show()}
}//SQL风格操作/*positionDF.createOrReplaceTempView("t_position")val sql ="""|select position.workName as workNames,count(*) as counts|from(|select explode(data.list) as position|from t_position)|group by workNames|order by counts desc""".stripMarginspark.sql(sql).show()*/

SparkSQL运行架构

Spark SQL对SQL语句的处理和关系型数据库类似，即词法/语法解析、绑定、优化、执行。Spark SQL会先将SQL语句解析成一棵树，然后使用规则(Rule)对Tree进行绑定、优化等处理过程。Spark SQL由Core、Catalyst、Hive、Hive-ThriftServer四部分构成：

1)Core: 负责处理数据的输入和输出，如获取数据，查询结果输出成DataFrame等。

2)Catalyst: 负责处理整个查询过程，包括解析、绑定、优化等。

3)Hive: 负责对Hive数据进行处理。

4)Hive-ThriftServer: 主要用于对hive的访问。

DataFrame性能上比RDD要高，主要有两方面原因：

1)定制化内存管理：Rdd数据都放在堆内存，JAVA（JVM）内存，内存管理回收分配不是由spark管理，是由JAVA（GC）管理，有时候会出现资源不一致问题，spark不是直接的内存管理者。

2)DataFrame数据以二进制的方式存在于非堆内存，节省了大量空间之外，还摆脱了GC的限制。涉及到序列化和反序列化，如图-13。

图-13 GC占比关系图

优化的执行计划

查询计划通过Spark catalyst optimiser进行优化，例子如图-14。

图-14 案例图

SparkSQL针对案例优化如图-15所示：

图-15 优化流程

为了说明查询优化，我们来看图-15展示的人口数据分析的示例。图中构造了两个DataFrame，将它们join之后又做了一次filter操作。如果原封不动地执行这个执行计划，最终的执行效率是不高的。因为join是一个代价较大的操作，也可能会产生一个较大的数据集。如果我们能将filter下推到 join下方，先对DataFrame进行过滤，再join过滤后的较小的结果集，便可以有效缩短执行时间。而Spark SQL的查询优化器正是这样做的。简而言之，逻辑查询计划优化就是一个利用基于关系代数的等价变换，将高成本的操作替换为低成本操作的过程。

得到的优化执行计划在转换成物理执行计划的过程中，还可以根据具体的数据源的特性将过滤条件下推至数据源内。最右侧的物理执行计划中Filter之所以消失不见，就是因为溶入了用于执行最终的读取操作的表扫描节点内。

对于普通开发者而言，查询优化器的意义在于，即便是经验并不丰富的程序员写出的次优的查询，也可以被尽量转换为高效的形式予以执行。