Spark-SQL 多维度聚合优化

1.问题描述

    问题描述
上线一个SQL任务,发现其本身输入表都不打,基本都在百万级别以内,但是能够耗时几个小时,故进行优化

2.优化思路

2.1 并行度

根据运行指标发现,各个stage运行时间,应该是某个stage下的task发生倾斜
进一步跟踪stage,发现 task读写数据不是很大,只有几百KB,只要shuffle时才比较大
,因此判断并行度无益于作业优化
    stage 362

2.2 shuffle ,聚合

shuflle

分析各个job的数据,发现也不是很大,无需改变shuffle时每个分区的数据处理大小【spark.sql.adaptive.shuffle.targetPostShuffleInputSize】
聚合
    数据膨胀
进一步查看耗时较久的stage,发现数据突然增大,由之前的百万级别突然增加到3亿多,貌似发现了问题所在,进一步分析对应的task集合,发现每个数据的
    数据join后发生膨胀 Task耗时,数据增加了大概190倍

2.3 优化思路

由此发现,数据进行shuffle发生数据膨胀【Expand】,查看spark的官网发现,spark- SQL对于数据的多维度聚合进行数据复制操作,对于不同聚合操作,复制多份全量数据,导致数据急剧增加,导致处理速度缓慢;因此有两种思路,

第一种是从业务上出发,分拆聚合指标和分组维度后进行join,得到原来的指标;
第二种减少每个分区的处理数据,增加并行度,减少分区数据处理量,但会导致大量小文件,SQL任务运行完毕后需要进行小文件合并操作
    优化选择,减少分区数据处理量
spark.sql.files.maxPartitionBytes: The maximum number of bytes to pack into a single partition when reading files.
默认值为128MB,同hdfs.block.size ,可以进行减小值,进行调整
    调整后运行结果,运行在48min结束,基本保证业务使用

3 参考来源

    https://spark.apache.org/docs/latest/sql-ref-syntax-qry-select-groupby.html https://blog..net/weixin_32688333/article/details/112290306
经验分享 程序员 微信小程序 职场和发展