Athena含LIMIT 10查询正常，无LIMIT时超时问题求助

可能原因及对应解决方法 #

• 数据倾斜问题
  JOIN条件里的sid_hourly或license_id可能存在热点值（某个值对应的数据量异常大），加LIMIT时仅扫描小范围数据不会触发问题，全量扫描时热点值会导致单个计算节点负载过高超时。
  解决：

  1. 检查calender_dimension_hourly的sid_hourly、license_dimension的license_id数据分布，确认是否存在高频值。
  2. 若存在热点值，拆分查询：先处理非热点数据，单独处理热点数据后再合并结果。

• JOIN顺序不合理
  Athena查询优化器可能未选择最优JOIN顺序，多层LEFT JOIN先关联大表会生成超大中间结果集，拖慢计算速度。
  解决：

  1. 调整JOIN顺序，先关联小表（如license_dimension）与对应度量表，再关联calender_dimension_hourly。
  2. 用子查询提前过滤无效数据，减少中间结果规模。

• 表存储格式/分区缺失
  Glue Crawler生成的表若采用CSV等行式存储，或未按时间字段分区，全表扫描效率会极低。
  解决：

  1. 将表转换为Parquet/ORC列式存储格式，大幅提升查询性能。
  2. 检查calender_dimension_hourly是否按date或hour_of_day分区，查询时添加分区过滤条件减少扫描数据量。

• 查询资源与超时设置
  虽总数据量仅5GB，但JOIN后中间结果可能远超此规模，默认查询资源或超时时间不足以支撑。
  解决：

  1. 在Athena查询编辑器中将超时时间调至最大值（60分钟）。
  2. 若仍超时，联系AWS支持调整查询资源配额。

• 脏数据/NULL值过多
  表中大量NULL值或无效数据会导致JOIN时产生大量无效匹配，增加计算负载。
  解决：

  1. 检查hcm.sid_hourly、hqm.sid_hourly、license_id字段的NULL值占比，用子查询提前过滤无效数据。

优化后的SQL示例 #

SELECT
  date_parse(cdh.date, '%Y-%m-%d %H:%i:%s') "Hour"
  , cdh.hour_of_day "Hour of Day"
  , hcm.max_concurrent_usage "Concurrent Usage"
  , hqm.max_license_quantity "License Quantity"
  , lm.license_id
FROM
  db20221117.calender_dimension_hourly cdh
LEFT JOIN (
  SELECT sid_hourly, max_concurrent_usage, license_id
  FROM db20221117.hourly_concurrent_measure
  WHERE sid_hourly IS NOT NULL AND license_id IS NOT NULL
) hcm ON cdh.sid_hourly = hcm.sid_hourly
LEFT JOIN (
  SELECT sid_hourly, max_license_quantity, license_id
  FROM db20221117.hourly_quantity_measure
  WHERE sid_hourly IS NOT NULL AND license_id IS NOT NULL
) hqm ON cdh.sid_hourly = hqm.sid_hourly
LEFT JOIN db20221117.license_dimension lm 
  ON lm.license_id = hcm.license_id 
  AND lm.license_id = hqm.license_id

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