背景

本文基于SPARK 3.3.0

HashAggregate的优化

该优化是FaceBook(Meta) 内部的优化，还有合并到spark社区。

该优化的主要是partialaggregate的部分：对于类似求count,sum,Avg的聚合操作，会存在现在mapper进行部分聚合的操作，之后在reduce端，再进行FinalAggregate操作。这看起来是没有问题的（能够很好的减少网络IO），但是我们知道对于聚合操作，我们会进行数据的spill的操作，如果在mapper阶段合并的数据很少，以至于抵消不了网络IO带来的消耗的话，这无疑会给任务带来损耗。

利用运行时的指标信息，能够达到比较好的加速效果。

ObjectHashAggregate的优化

对于ObjectHashAggreate的原理，可以参考深入理解SPARK SQL 中HashAggregateExec和ObjectHashAggregateExec以及UnsafeRow,该文可以比较清楚的解释ObjectHashAggregate和HashAggregate的区别：

ObjectHashAggregate能够弥补HashAggregate 不能支持collect_set等这种表达式，从而不会转变为SortAggregate

ObjectHashAggregate利用的是java Array对象(SpecificInternalRow)保存聚合的中间缓冲区,这对jvm gc是不太友好的

ObjectHashAggregate根据hashMap的size（默认是128），而不是输入的行数来进行spill，这会导致提前spill，内存利用率不高。

由于提前的spill,ObjectHashAggregate会对剩下的所有数据做额外的一次排序操作(如果没有spill，就不需要额外的sort操作),而HashAggregate则是会对每次需要spill的数据做排序

使用jvm heap的内存使用情况以及处理的行数来指导什么时候开始spill。

但是这种在数据倾斜的情况下，会增加OOM的风险。

SortAggregate优化

目前SortAggreaget的现状是：

每个任务在sort Aggreate前需要按照key进行排序

根据排序的结果，在相邻的行之间进行聚合操作

不同于Hash Aggregate：

不需要hashTable，也就不存在内存溢写和回退到sortAggregate

优化器更喜欢选择hashAggregate

没有codegen的实现.

目前在spark 3.3.0增加的功能：

如果数据是有序的话，会选择用sortAggragate替代HashAggregate

通过物理计划Rule ReplaceHashWithSortAgg 来做替换，当然通过spark.sql.execution.replaceHashWithSortAgg来开启（默认是关闭的），因为对于任何新特性，在release版本默认都是关闭的，在master分支才是开启的

支持sortAggretate（without keys）的codegen代码生成

其他

对于Aggregate更多的细节了解可以参考sparksql源码系列 | 一文搞懂with one count distinct 执行原理