Spark性能优化调优根据Spark UI进行调优记录

SPARK-SQL优化三剑客：1内存2并发3CPU

1、内存： spark的dirver和executor内存及对应spark作业参数

涉及内存调优就三个参数：spark.driver.memory ，-executor-memory 和 spark.yarn.executor.memoryOverhead

2、并发：提高有shuffle（join, group by 等等数据混洗的场景）及对应业务逻辑SQL参数

涉及并发优化就1个参数：spark.sql.shuffle.partitions

3、CPU：spark的executor的CPU核数和对应spark作业参数（不建议改）

涉及内存调优就1个参数：-executor-cores

案例

1、发生GC，GC时间过长

为了提高运行速度，盲目的将-executor-cores的数量调大，增加CPU核数，但是executor memory的大小不变，每个core的内存也就变小，导致内存不够产生GC，可以也将executor memory也调大些，或者将executor-cores数量调小

2、临时视图或者串行跑任务，任务速度调优

很多时候我们的SQL中会出现许多的临时视图的情况

create temporary view a as
select xxx;
create temporary view b as
select xxx;
insert overwrite table x as 
select
xxx
from
a join weidu 
union all
b join weidu
group by xxx;

如果数据量比较小，那么这样操作是没什么问题的，如果数据量比较大，那么就会因为a视图计算完之后，存储在内存中，到b视图计算的时候有可能会因为内存不够导致shuffle溢写，速度就会下降许多。
我们可以利用任务调度器来进行操作。将这个任务拆分成三个任务（a|b----x），a和b并行跑，结束跑x的任务。这样的话可以提高整体的效率，相当于利用空间换时间。

因为在做一些调优，这个花费的时间比较长，join也是不可去避免的，只能去进行一个拆分并行计算的方法。

3、关联的时候将大表放到左边，小表放到右边

这个是小表join大表，join的时候用的是sort，这种可以进行优化的，这个花费了1.6m

我们看一下大表join小表

大表join小表用的是BroadcastHashJoin（广播join）。这个花费了1m，提高的速度还是不少的。
1、第一个的话就是普通的Join，将B表shuffle到A表关联所在的位置进行join，B表本来就很大，再去进行shuffle是一个很耗时的过程，而且也可以看到WholeStageCodegen 达到了5个，流程也变长了。
2、广播join，将右边的小表缓存到内存中，避免shuffle的情况，所以WholeStageCodegen 只有2个，中间的shuffle过程避免了，速度也会大大提升。

4、Spark，lateral view explode。任务优化问题

lateral view explode炸开。

源数据：a ,我们的日志层的数据，比如曝光日志

关联数据：b ，只有在B表的用户才是我们的，对曝光日志进行过滤。inner join.

A方式

select
	xxx
from
( a,b on a.mid=b