如何找到Spark与Athena适配的最优文件大小？

问题背景 #

我有一个写入S3存储桶的Spark任务，该存储桶对应一张按source_system, execution_date, year_month_day分区的Athena表。原本每个Spark分区写入1GB单文件，后来通过maxRecordsPerFile配置改为每个文件500MB，每个分区生成2个文件，EMR运行时间节省了15分钟，但Athena查询的CPU耗时却显著增加。

测试查询与结果 #

执行同一查询：

select *
from dw.table
where source_system = 'SS1'
and year_month_day = '2022-09-14'
and product_vendor = 'PV1'
and execution_date = '2022-09-14'
and product_vendor_commission_amount is null
and order_confirmed_date is not null
and filter = 1
order by product_id 
limit 100;

• 调整前：执行时间6.79s；Explain analyze显示扫描数据355.04MB，CPU耗时13.38s
• 调整后：执行时间11.102s；Explain analyze显示扫描数据631.62MB，CPU耗时20.23s
• 输入行数相近，输出结果完全一致

疑问 #

1. 为何Athena查询耗时翻倍？
2. 后续需要注意哪些要点？
3. 是否存在适配Spark与Athena的最优文件大小平衡点？

问题分析与解答 #

1. 耗时翻倍的核心原因 #

• 文件元数据与IO开销累积：Athena处理每个文件都要单独执行元数据读取、S3连接建立、文件头解析操作。从1个文件拆成2个后，这些重复操作的开销会叠加，直接拉高CPU耗时和扫描数据量的统计值（这里的扫描数据量包含了额外的文件处理开销）。
• 谓词下推的重复计算：虽然查询过滤条件明确，但小文件会让Athena在每个文件中重复执行谓词判断逻辑。单文件时一次扫描就能完成的过滤，拆分后要在两个文件中分别执行，CPU的重复计算成本直接上升。
• S3批量读取效率下降：S3对大文件的批量读取更高效，小文件会增加HTTP请求次数，每个请求的连接握手、传输启动都会带来额外延迟，叠加后导致整体耗时上升。

2. 后续需要注意的要点 #

• 写入与查询的性能权衡：Spark的maxRecordsPerFile是为了提升写入并行度，但不能只看EMR的写入耗时，必须兼顾下游Athena的查询特性。
• 避免分区内小文件爆炸：如果分区本身数据量不大，强行拆分小文件只会徒增查询开销。要保证每个分区内的文件数量处于合理范围，避免出现数百个小文件的情况。
• 维护表统计信息：定期用ANALYZE TABLE更新Athena表的统计信息，让查询优化器能更准确判断文件扫描成本，减少不必要的全文件扫描。
• 配合合适的压缩格式：使用Snappy、GZIP等压缩格式，在不降低查询效率的前提下减少文件体积，同时保证单个压缩文件的大小处于合理区间，平衡写入和查询性能。

3. 最优文件大小平衡点 #

存在适配两者的最优区间，通常建议将文件大小控制在64MB-1GB之间，具体数值可根据场景调整：

• 对Athena来说，单个文件小于64MB会导致元数据和IO开销剧增；超过1GB则可能出现单文件处理瓶颈（比如内存不足、单线程延迟）。
• 对Spark来说，文件过小会增加写入时的任务调度开销；过大则可能导致单个Task写入时间过长，拖慢EMR整体运行时间。
• 建议测试不同文件大小（如256MB、512MB、768MB、1GB）的组合，对比EMR写入耗时和Athena查询耗时，找到两者性能的平衡点。比如当前500MB虽让EMR快了15分钟，但Athena耗时翻倍，可以尝试调整到768MB左右，兼顾双方性能。

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