AWS Glue作业自动扩缩容不执行缩容操作的问题咨询

• 作业阶段特性限制：Glue的自动扩缩容逻辑在作业不同阶段有差异。比如读取数据源（尤其是分区表、大文件）或写入数据时，哪怕监控显示所需执行器远低于活跃数，系统也可能维持当前worker数量——这类阶段需要稳定资源避免数据读写碎片化或失败，比如动态分区写入时，Glue会保留worker完成后续分区提交操作。

• 扩缩容冷却机制：Glue自动扩缩容有冷却周期（实际场景通常5-15分钟，官方未明确公开时长）。要是所需执行器刚降到活跃数以下，系统得等冷却期结束才会缩容，防止频繁扩缩容引发资源波动。

• Worker类型限制：如果用的是G.1X/G.2X这类带本地磁盘的worker，Glue会优先保留已分配的worker——本地磁盘可能缓存了作业中间数据，缩容会导致缓存丢失，反而拖慢后续作业性能，所以系统会尽量维持worker数量直到作业接近收尾。

• 隐性配置影响：部分作业配置会干扰扩缩容逻辑，比如启用--job-bookmark-option后，Glue需要保留worker同步书签状态，避免状态丢失；如果作业里有自定义Spark广播变量、累加器，也可能让系统不会轻易缩容。

• 监控指标偏差：监控视图里的“所需最大执行器数量”是Spark调度器的预估值，可能存在延迟；或者作业后台的日志收集、状态同步等任务还在占用资源，导致系统判断当前worker数量仍有保留必要。

内容的提问来源于stack exchange，提问作者Slava Shpitalny