Athena表CSV与Parquet存储对比：除执行时间外的可查指标及Explain解读

一、除查询执行时间外的关键统计指标 #

• 数据扫描量（Data Scanned）：这是Athena的核心计费指标，Parquet作为列存格式只会扫描查询涉及的列，相比CSV全列扫描能大幅减少扫描量，直接关系到长期使用成本。
• 存储占用体积：Parquet自带默认Snappy压缩，相同数据量下存储大小通常只有CSV的1/5到1/10，能显著降低存储成本。
• 数据返回量（Data Returned）：聚合/关联后返回的结果数据量，反映数据处理后的传输效率，Parquet因提前过滤和聚合，返回量往往更小。
• 阶段执行明细：查看Athena查询详情里的Map/Reduce阶段耗时、任务并行数，Parquet的列存处理能让聚合操作更早执行，降低后续阶段的负载。
• 资源使用率（通过CloudWatch）：若开启CloudWatch监控，可查看查询对应的CPU、内存占用峰值，Parquet的列式解析和谓词下推能减少资源消耗。
• 缓存命中率：Athena的查询缓存对结构化数据更友好，Parquet的固定格式能提升缓存复用率，减少重复扫描的开销。

二、Athena Explain功能的关注重点 #

Athena的Explain基于Presto优化器，重点看以下几点来对比两种格式的执行效率：

• 谓词下推（Predicate Pushdown）：检查执行计划里是否把WHERE子句等过滤条件下推到了存储层。Parquet支持原生谓词下推，会在扫描数据时就过滤不符合条件的行/列；CSV通常需要全表扫描后再过滤，Explain里会显示Filter算子的位置（靠近数据源还是后续阶段）。
• 数据扫描范围：看是否是全表扫描，还是利用了分区/列裁剪。Parquet的列裁剪会明确显示只扫描查询涉及的列（比如Scan parquet_table (columns=[col1, col2], ...)），而CSV会扫描所有列。
• 聚合操作的执行时机：如果是聚合查询，看Aggregate算子是否紧跟在Scan之后。Parquet可以在扫描阶段就完成部分聚合（比如预计算分组统计），减少后续数据传输；CSV则可能需要先扫描全量数据再做聚合。
• 数据交换（Exchange）开销：关联或聚合时的shuffle数据量，Explain里的Exchange算子会显示数据传输规模，Parquet因数据更紧凑、过滤更彻底，shuffle量远小于CSV。
• 算子复杂度：对比两种格式执行计划中解析算子的开销，CSV会有专门的CsvParser算子，而Parquet的ParquetReader效率更高，执行计划更简洁。
• 统计信息利用：看优化器是否基于表的统计信息选择了最优关联策略（比如Broadcast Join vs Shuffle Join），Parquet的元数据包含更丰富的统计信息（比如列的基数、分布），能让优化器做出更高效的计划。

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