最近在做一些Spark SQL任务优化的工作，学习了极客时间吴磊老师的课程之后，针对AQE的特性做了一些调研实践，本文介绍一下应用自动分区合并特性优化任务的过程。
原理过程：
AQE（Adaptive Query Execution），自适应查询执行，是在Spark 3.0推出的任务运行策略和规则，一种动态优化机制，在运行时，每当 Shuffle Write 阶段执行完毕，AQE 都会结合这个阶段的统计信息，基于既定的规则动态地调整、修正尚未执行的逻辑计划和物理计划，来完成对原始查询语句的运行时优化。也就是说AQE起作用的时间是Shuffle Write执行完生成中间文件后，Reduce阶段执行时。
以本文要介绍的自动分区合并特性来说，在Shuffle Write阶段生成了很多磁盘文件，包括每个task生成的数据data文件和索引index文件，下一阶段当每个Reduce Task去磁盘文件所在的机器拉取数据时，每个文件数据量比较少，启用自动分区合并就可以将部分较小的分区提前合到一起，避免单个分区过小，任务过多。
当然，这里需要指定目标尺寸多大，多小的分区需要合并，涉及到两个参数：
第一个参数 spark.sql.adaptive.advisoryPartitionSizeInBytes 来直接指定目标尺寸。第二个参数用于限制 Reduce 阶段在合并之后的并行度，避免因为合并导致并行度过低，造成 CPU 资源利用不充分。举个例子。假设，Shuffle 过后数据大小为 20GB，minPartitionNum 设置为 200，反推过来，每个分区的尺寸就是 20GB / 200 = 100MB。再假设，advisoryPartitionSizeInBytes 设置为 200MB，最终的目标分区尺寸就是取（100MB，200MB）之间的最小值，也就是 100MB。因此并不是指定了 advisoryPartitionSizeInBytes 是多少，Spark 就设置多少，还要考虑 minPartitionNum 的设置。
具体的过程是：Spark SQL 事先并不去判断哪些分区是不是足够小，而是按照分区的编号依次进行扫描，当扫描过的数据体量超过了“目标尺寸”时，就进行一次合并。
以上图中为例，当任务扫描0 1 2三个分区时发现分区数据量超过设定的尺寸之后会进行一次合并形成新的分区0，当接下来扫描到3 4 分区时发现两个分区数据量超过目标尺寸大小时在进行一次合并形成新的分区1，后续以此类推。
实践实例：
资源使用：Spark版本3.1.2， 来源数据253.8GB，
spark.dynamicAllocation.maxExecutors=200，spark.sql.shuffle.partitions=1800，spark.num.output.files=1500，driver-memory=6G，executor-memory=6G，executor-cores=3。
3.1.2版本默认开启自动分区合并特性，现将其关闭看任务运行情况：
这里可以看到任务运行时间比较长的是stage 3，运行时间3.4分钟，Shuffle write阶段生成的中间文件大小是261.0 GiB，现任务并行度最大是600，261*1024/600=445，现在将目标尺寸设置为200MB，那么应该设置spark.sql.adaptive.advisoryPartitionSizeInBytes=200MB，spark.sql.adaptive.coalescePartitions.minPartitionNum=600，
spark.sql.adaptive.coalescePartitions.enabled=true。
200 < 445 ，所以Spark任务在执行过程中选择的目标分区应该是200MB。
然后观察任务运行情况：
stage 3的运行时间变长了，接下来调整spark.sql.adaptive.coalescePartitions.minPartitionNum=20，观察任务运行情况：
可以看到stage 3运行时间与不启用自动分区合并一致，没有看到该参数起到很明显的作用。
不知道有没有大佬知道这个参数具体怎么用，求告知，谢谢！
