sparkrdd 并发 spark 并发参数

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.mid ) a 
lateral view explode x as xxx

Stage：先关联，产生shuffle数据，根据配置的partition划分区，然后再进行炸开。比如我们默认200个分区，那么之后进行操作的炸开也就只有200个文件去执行，数据量本身比较大，又按照分区的200去合并，会导致数据更大。

这个只是一个例子，200的分区是默认，一般是2000\4000

B方式

select
	xxx
from
(
select
	xxx
from a
lateral view explode x as xxx
) a join b

Stage：先去做炸开，然后去关联去重。炸开的时候是按照读取A表的文件数量，这个任务是按照5min跑一次文件比较多，在炸开的时候很快，炸开之后进行关联，然后按照shuffle partition的数量分区

5、多个开窗在一起，任务执行stage单个串行执行

SQL案例

select
        mid,
        row_number() over(partition by expose order by expose),
        row_number() over(partition by click order by click),
        row_number() over(partition by order order by order),
        row_number() over(partition by sale order by sale)
        from
    (
        select
            mid,
            sum(expose) expose,
            sum(click) click,
            sum(order) order,
            sum(sale) sale
        from
            (
                select
                    '1' mid,
                    1 expose,
                    2 click,
                    3 order,
                    4 sale
            ) a
        group by
            mid
    ) t

看一下spark UI

太长了。。。。。

开窗都是在一起，执行的时候先跑sale 再order -----最后expose，并不是并行运行，导致任务运行很慢。

优化一下SQL 并行执行

select
mid,
sum(expose_rn) as expose_rn,
sum(click_rn) as click_rn,
sum(order_rn) as order_rn,
sum(sale_rn) as sale_rn
from
(
    select
        mid,
        row_number() over(partition by expose order by expose) as expose_rn,
        0 as click_rn,
        0 as order_rn,
        0 as sale_rn
        from
    (
        select mid, sum(expose) expose from ( select '1' mid, 1 expose ) a group by mid
    ) t
    union all 
        select
        mid,
        0 as expose_rn,
        row_number() over(partition by click order by click) as click_rn,
        0 as order_rn,
        0 as sale_rn
        from
    (
        select mid, sum(click) click from ( select '1' mid, 1 click ) a group by mid
    ) t
    union all 
    select
        mid,
        0 as expose_rn,
        0 as click_rn,
        row_number() over(partition by order order by order) as order_rn,
        0 as sale_rn
        from
    (
        select mid, sum(order) order from ( select '1' mid, 1 order ) a group by mid
    ) t
    union all 
    select
        mid,
        0 as expose_rn,
        0 as click_rn,
        0 as order_rn,
        row_number() over(partition by sale order by sale) as sale_rn
        from
    (
        select mid, sum(sale) sale from ( select '1' mid, 1 sale ) a group by mid
    ) t
) a group by mid

Physical Plan 不太懂英文 叫物理执行图？？？

这样这几个开窗就是一起执行的，不用再一个个执行了。