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.youkuaiyun.com/weixin_32688333/article/details/112290306