问题描述
上线一个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.htmlhttps://blog.csdn.net/weixin_32688333/article/details/112290306
