通过AWS Glue执行16条Athena查询时作业无日志失败问题排查

这种情况我之前在项目里碰到过类似的，结合Glue和Athena的运行机制，大概率是这几个方向的问题，你可以按优先级逐一排查：

1. Glue作业的资源或超时限制触发崩溃 #

Glue作业的默认资源配置和超时设置可能扛不住16条查询的连续执行：

• 超时时间不足：前14条查询已经消耗了不少时间，加上后两条的执行时间，可能超过了你设置的Glue作业超时阈值（默认是48小时，但很多用户会改短）。当作业超时被强制终止时，进程可能来不及生成错误日志就被kill了。
• Worker资源不足：如果用的是默认的Standard worker（比如G.025X），内存和CPU可能在执行到后期不够用，导致内存溢出崩溃，这种情况下日志也可能无法正常写入CloudWatch。

排查建议：

• 进入Glue作业的配置页面，把超时时间调大（比如先设为6小时），同时尝试升级worker类型到G.1X或G.2X，增加worker数量（比如从2个加到4个），再重新运行作业。

2. Athena查询在Glue中的等待逻辑有缺陷 #

如果你的Glue代码是用boto3调用Athena的start_query_execution，然后循环轮询查询状态，可能存在以下问题：

• 轮询的超时逻辑设置不合理：比如前14条查询已经消耗了大量的轮询等待时间，导致后续查询的轮询触发了代码里的自定义超时，但没有捕获这个异常并写入日志。
• 并发查询配额被占满：Athena有并发查询的配额限制（默认是20个），如果前14条查询中有部分长期运行（比如做大数据量的扫描），会占用并发名额，导致后两条查询排队等待，Glue作业一直等到自己超时。

排查建议：

• 在Glue代码里给后两条查询的执行逻辑加上try-except块，手动捕获所有异常并打印日志（比如用logger.error("查询执行失败: %s", str(e))）。
• 登录Athena控制台，查看“查询历史”，确认前14条查询是否都已经完成，有没有长期运行的查询占用并发配额。

3. Glue的日志配置异常导致日志丢失 #

你说前14条日志正常，后两条没有，可能是日志上传的环节出了问题：

• CloudWatch日志组权限不足：Glue作业的IAM角色可能没有足够的权限向CloudWatch写入日志，到后期作业状态异常时，日志无法上传。
• 作业崩溃时日志来不及写入：当作业因为内存溢出或被强制终止时，进程瞬间退出，缓存的日志还没来得及上传到CloudWatch。

排查建议：

• 检查Glue作业使用的IAM角色，确认是否有logs:CreateLogStream、logs:PutLogEvents等CloudWatch日志相关权限。
• 手动查看CloudWatch日志组里的所有日志流，有没有作业崩溃前的最后几条日志（可能被隐藏在分页里）。

4. 查询上下文或执行计划的差异 #

虽然单独在Athena里运行后两条查询正常，但在Glue上下文里可能存在环境差异：

• 数据库或表的上下文不同：Glue作业里可能默认切换了其他数据库，或者前14条查询修改了Athena的会话参数（比如set hive.exec.dynamic.partition.mode=nonstrict），导致后两条查询的执行计划变复杂，运行时间远超预期。
• 查询参数不一致：Glue代码里的查询可能和你手动在Athena里执行的有细微差别（比如表名大小写、分区过滤条件），导致执行效率下降。

排查建议：

• 把Glue代码里的后两条查询语句复制出来，和Athena里手动执行的版本逐行对比，确保完全一致。
• 在Glue代码里执行后两条查询前，添加重置会话参数的语句（比如SET SESSION reset_all=true;），消除前序查询的影响。

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