我在我的 Amazon Athena 表上运行了用于 AWS CloudTrail 日志的 SELECT 查询。但是,查询要么运行缓慢,没有返回结果,要么因超时错误而失败。
解决方法
根据用例执行以下故障排除步骤。
查询未返回任何结果
亚马逊 S3 位置路径不正确
查看 Amazon Simple Storage Service (Amazon S3) 表位置是否有您的 CloudTrail 日志。如果表中的输入 LOCATION 路径不正确,则 Athena 不会返回任何记录。
分区未加载到表中
如果您使用手动分区 CREATE TABLE 语句来创建表,请验证您是否已将分区加载到 Athena 表。如果您不向表中加载分区,则 Athena 查询不会返回结果。
使用 SHOW PARTITIONS 语句查看已加载到表中的分区。使用 ALTER TABLE ADD PARTITION 命令加载所需的分区,以便您的查询返回结果。
分区定义不正确
如果您使用手动分区 CREATE TABLE 语句来创建表,请检查时间戳属性范围。确保 projection.timestamp.range 属性与您的 Amazon S3 存储桶位置中的分区相匹配。
确保 SELECT 查询不会筛选超出您在 projection.timestamp.range 属性中设置的范围的值的数据。
存储类
Athena 不支持 S3 Glacier Flexible Retrieval 或 S3 Glacier Deep Archive 存储类的数据查询,对象将被忽略。
检查 CloudTrail 日志是否属于不支持的 S3 存储类。恢复要查询的 Amazon S3 存档对象。然后,查询恢复的 Amazon S3 对象。
查询需要很长时间才能运行或因超时错误而失败
非分区表
如果您使用 CloudTrail 控制台为 CloudTrail 日志创建 Athena 表,则会创建一个非分区表。
**SELECT ** 查询使用非分区表扫描 Amazon S3 存储桶中的所有日志文件。如果超过 DML 查询超时限制,则查询可能会运行缓慢或超时。
要优化查询性能,最佳做法是创建分区表。要缩短查询时间,请在 WHERE 子句中指定分区列,以便 Athena 仅扫描来自匹配分区的数据。
分区表查询不使用分区列来筛选数据
如果 SELECT 查询在 WHERE 子句中未使用分区列,则 Athena 会扫描来自 Amazon S3 存储桶的所有日志文件。
以下示例查询的分区投影 CloudTrail 表运行缓慢,因为它会扫描所有日志:
SELECT useridentity, sourceipaddress, eventtime
FROM cloudtrail_table
WHERE eventname = 'RunInstances'
AND eventtime >= '2023-10-30T00:00:00Z'
AND eventtime < '2023-10-30T00:04:00Z';
要缩短查询时间,请在 WHERE 子句中指定分区列,以便 Athena 仅扫描来自匹配分区的数据。
以下示例查询在分区列时间戳上有一个 WHERE 子句,该子句仅扫描来自 2023/10/30 分区的日志:
SELECT useridentity, sourceipaddress, eventtime
FROM cloudtrail_table
WHERE eventname = 'RunInstances'
AND eventtime >= '2023-10-30T00:00:00Z'
AND eventtime < '2023-10-30T00:04:00Z'
AND timestamp >= '2023/10/30'
AND timestamp < '2023/10/31'
有关详细信息,请参阅如何对使用 Athena 查询 CloudTrail 数据时的超时问题进行故障排除?
相关信息
如何在 Amazon Athena 中自动创建表以搜索 AWS CloudTrail 日志?
查询 AWS CloudTrail 日志