Spark自适应查询执行（AQE）是否存在弊端？为何默认禁用？

虽然AQE能带来诸多性能优化收益，但确实存在一些场景下不适合启用它的理由，主要包括以下几点：

• 额外运行时开销：AQE需要在执行过程中实时收集中间数据的统计信息（如数据分布、分区大小），并基于这些信息动态调整执行计划。对于短查询、小数据集或者资源紧张的环境，这些额外的统计收集和计划调整开销可能抵消甚至超过AQE带来的性能提升，导致查询整体变慢。
• 执行计划的不确定性：相同的SQL语句在不同的数据分布下，AQE可能生成完全不同的执行路径。这种动态变化会增加查询性能稳定性排查的难度——当某次查询突然出现性能波动时，你很难快速界定是数据分布变化导致的，还是AQE的计划调整引发的问题，提升了调试成本。
• 兼容性问题：在部分旧版本Spark中，AQE与一些内置优化规则、自定义UDF或自定义分区策略存在兼容性冲突。例如，某些依赖固定分区数的自定义逻辑，在AQE自动合并/拆分分区后可能出现数据处理异常；部分复杂UDF的执行逻辑也可能在AQE的动态计划调整下出现不符合预期的结果。
• 资源调度不可控：AQE的动态调整（如拆分倾斜分区、合并小分区）会改变任务的数量和资源需求。在严格的资源配额环境（如固定资源队列的YARN/K8s集群）中，这种不可预测的资源请求可能引发调度延迟，甚至触发资源不足的报错，影响查询的可靠性。
• 历史兼容性与风险规避：早期Spark版本中AQE的稳定性不足，因此默认设置为禁用。尽管新版本中AQE已经成熟，但很多生产环境出于避免引入未知风险、保持与现有稳定查询的兼容性的考量，会选择继续禁用AQE，确保业务查询的稳定性。

内容的提问来源于stack exchange，提问作者Robin Zimmerman