AWS Athena查询字符串列MAX为何远快于AWS Glue？

一、Athena的极速原理 #

Athena（基于Presto引擎）能秒级返回MAX(datestring)，核心是直接利用Parquet文件的内置元数据统计：

• Parquet格式会在文件的footer部分存储每列的min/max等统计信息，你的场景中每日一个Parquet文件，每个文件的datestring最大值基本就是当日日期；
• Athena执行查询时，不需要扫描任何文件的实际数据，仅需遍历所有S3上Parquet文件的footer元数据，收集每个文件的datestring最大值，再取全局最大值即可；
• 作为Serverless服务，Athena无需启动集群、分配资源的额外开销，直接针对这类元数据查询做了深度优化。

二、Spark/Glue DynamicFrame慢的原因 #

你用Glue + Spark的方式耗时20分钟，本质是Spark默认不会自动依赖Parquet的元数据统计来优化聚合查询：

• Spark默认会启动Task扫描每个Parquet文件的内容（即使是计算max），即便开启了向量化读取等优化，仍需读取文件的部分或全部数据，再做局部聚合后全局汇总，5000亿行的规模下，这个过程必然耗时；
• 即便使用createDynamicFrame.fromCatalog，Glue Catalog仅提供表结构和文件路径信息，Spark并不会自动利用Parquet文件的footer统计，除非你手动开启相关优化并确保表统计信息已更新；
• 另外，Glue作业启动集群、分配worker的初始化开销，也会进一步拉长整体耗时。

三、让Glue/Spark达到近似Athena速度的优化方案 #

如果必须用Glue Pipeline实现，可通过以下配置让Spark利用元数据统计：

1. 更新Glue Catalog表的统计信息
   执行ANALYZE TABLE your_table_name COMPUTE STATISTICS（可通过Athena或Glue作业运行），确保Spark能获取到列级的统计数据。
2. 开启Spark的元数据优化配置
   在Glue作业的Spark配置中添加以下参数：

   --conf spark.sql.parquet.filterPushdown=true
   --conf spark.sql.statistics.fallBackToHdfs=true
   --conf spark.sql.parquet.metadataCacheTTL=3600s
   --conf spark.sql.statistics.histogram.enabled=true
   

   这些配置会让Spark优先读取Parquet文件的元数据统计，避免全量扫描。
3. 验证查询计划
   运行df.select(max("datestring")).explain()查看执行计划，如果计划中出现MetadataOnly扫描，说明已经成功利用元数据；若还是FileScan，则需要检查统计信息是否更新、配置是否生效。

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