结构相近的Athena查询运行性能差异显著的原因咨询

核心性能差异原因 #

• Partition Projection分区下推逻辑失效
  你的表采用层级分区结构badge=%s/year=%s/month=%s/day=%s/hour=%s，且所有分区通过Partition Projection定义：
  查询2的日期筛选固定month值为10，所有分区筛选条件可以完全下推到存储层，执行计划走TableScan直接精准读取month=10下day=30、day=31的两个分区数据，S3路径遍历、数据读取的效率都极高。
  查询1的日期筛选跨month=10、month=11两个不同的父级分区，Partition Projection对跨父分区的OR条件识别能力不足，无法直接下推所有分区筛选条件，执行计划降级为ScanFilter模式，是性能下降的核心诱因。
• 开销倒挂导致扫描量小反而耗时更长
  查询2的所有过滤逻辑都下推到存储层，仅返回符合条件的216.86KB有效数据到计算节点，无额外过滤开销；查询1的ScanFilter模式需要先扫描远大于94.06KB的中间分区数据，再在计算节点过滤掉不符合条件的内容，中间的IO、CPU计算开销远高于直接读取有效数据的开销，最终出现扫描量更小但耗时更长的反常识结果。

优化方案 #

可以将查询1的筛选条件改写为元组IN的形式，帮助Partition Projection识别多分区匹配逻辑，触发分区条件下推：

SELECT * FROM "table" 
WHERE badge IN ('xyz', 'abc') 
    AND year = '2021'
    AND (month, day) IN (('11','1'), ('10','31'))
ORDER BY timestamp

改写后执行计划会回到TableScan模式，执行时长会回归正常区间。 #

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