Athena是否支持缓存基础查询中间结果以实现降本提效？

核心结论 #

• Athena 没有可直接配置的“公共子查询/视图中间结果自动缓存”能力，无法自动识别多个不同查询中复用的基础逻辑段、缓存中间结果供上层查询复用，仅靠配置无法实现你要的效果。
• 直接将基础逻辑存为视图对接QuickSight的方案无法降本提效：视图仅存储SQL逻辑，不存储实际计算结果，每次对视图发起不同聚合维度的查询时，Athena都会将视图逻辑嵌套进当前查询的执行计划，重新扫描全量100GB原始数据完成JSON解析、字段格式化步骤，不会复用之前的计算结果。

Athena原生缓存的实际限制 #

Athena自带两类缓存能力，均无法满足你的场景需求：

• 查询结果缓存：仅当提交的完整SQL文本、执行参数、工作组配置、访问权限完全一致，且缓存未超出配置的有效期（最长7天）时，才会直接返回上一次查询的S3结果文件。你要运行的20-30个查询聚合逻辑、筛选条件均有差异，SQL文本不相同，完全无法命中这类缓存。
• 查询结果重用功能：依然是整查询级别的复用，不支持公共逻辑片段的跨查询缓存，和视图搭配使用时不会自动提取公共基础逻辑做预计算。

推荐落地方案 #

你需要单独运行基础查询、将结果持久化存储后，再基于结果集运行后续查询，具体操作如下：

1. 将原有的100GB扫描量的基础逻辑，封装为CTAS语句或者INSERT OVERWRITE任务，把完成分区筛选、字段过滤、JSON解析、格式化后的200MB结果集，写入单独的一张列式存储（推荐Parquet格式）的基础结果表中，按你常用的查询时间维度做分区。
2. 数据更新可以根据你的业务时效要求选择：
   • 如果对数据新鲜度要求固定，可以配制定时调度任务，在原始表的新时间分区就绪后，增量计算对应分区的基础结果写入结果表，不用每次全量重算。
   • 如果需要懒加载触发，也可以通过工作组配置判断基础结果表对应分区是否存在，不存在时触发计算，存在时直接查询结果表。
3. QuickSight直接对接这张预计算好的基础结果表，不要对接基于原始表构建的视图。如果需要封装通用逻辑，可以基于这张200MB级别的结果表构建视图，后续所有聚合查询扫描的数据量仅为原方案的千分之二，查询耗时可从分钟级降至秒级，扫描成本对应下降99%以上。

注意：不要为了省事直接复用Athena单次查询输出的S3结果文件做后续查询，这类文件的存储格式、分区结构没有经过优化，且会被自动清理规则删除，手动维护成本极高。

内容的提问来源于stack exchange，提问作者T.G.