AWS Athena分区引发S3大量小文件及大数据集处理咨询

这个问题太典型了——用分区优化Athena查询和避免S3小文件爆炸确实是个两难的点，我来分享几个实战中常用的解决思路：

1. 写入阶段就控制文件大小，从源头避免小文件 #

与其事后处理小文件，不如从生成环节就掐断问题。如果你的数据是通过ETL工具（比如Spark、Flink或者AWS Glue）写入S3的，直接配置合并策略即可：

• 比如在Spark中设置spark.sql.files.maxRecordsPerFile（控制单文件记录数）或spark.sql.files.openCostInBytes（调整文件合并阈值），把输出文件大小稳定在100MB-1GB区间（这是适配S3和Athena的黄金大小）。
• 写完后再按分区键（比如日期、地区）组织目录结构，既满足分区要求，又不会产生大量零散小文件。

2. 用Athena分区投影（Partition Projection）替代物理分区目录 #

这是AWS近几年推出的实用功能，完美绕开了“必须建嵌套目录才能分区”的限制：

• 它不需要你在S3上创建实际的分区文件夹，也不用跑MSCK REPAIR TABLE同步分区。只需在创建Athena表时，通过TBLPROPERTIES配置分区规则（比如日期范围、枚举值），Athena会自动虚拟出这些分区。
• 举个日期分区的配置例子：

CREATE EXTERNAL TABLE my_large_dataset (
  id INT,
  content STRING
)
PARTITIONED BY (dt STRING)
LOCATION 's3://my-bucket/dataset-root/'
TBLPROPERTIES (
  'projection.enabled' = 'true',
  'projection.dt.type' = 'date',
  'projection.dt.range' = '2023-01-01,NOW',
  'projection.dt.format' = 'yyyy-MM-dd',
  'storage.location.template' = 's3://my-bucket/dataset-root/dt=${dt}'
);

• 你可以直接把大文件按规则放到对应路径（甚至不用分路径，只要表配置了投影规则，查询时指定分区键就能过滤数据），既享受到分区查询的扫描量优化，又不会有小文件的困扰。

3. 定期合并已存在的小文件 #

如果已经产生了大量小文件，可以用工具批量处理：

• AWS Glue Compact Jobs：Glue专门提供了合并小文件的作业，你只需指定目标S3路径和合并后的文件大小，它会自动扫描并合并同一分区下的小文件，同时更新Athena的分区信息。
• 自定义Lambda函数：如果需要更灵活的控制，可以写一个Lambda函数，定期扫描S3分区目录，把小文件下载合并后重新上传，再删除原小文件。注意要处理好并发和数据一致性（比如用S3版本控制或临时目录过渡）。

4. 切换到高效的列式存储格式 #

用Parquet、ORC这类列式存储格式替代CSV、JSON：

• 这类格式本身支持压缩和分块存储，相同数据量下文件数量会大幅减少，而且Athena查询时可以只扫描需要的列，性能提升非常明显。
• 大部分ETL工具都支持直接输出Parquet/ORC格式，写入时还能自动合并文件，一举两得。

最后补充：小文件的危害主要是增加S3请求成本和Athena查询的初始化时间，核心思路就是要么从源头避免，要么事后合并，要么用虚拟分区绕开物理目录的限制。

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