AWS Athena分区投影：yyyymmdd用日期型还是整型？

核心结论 #

直接把分区投影定义为date类型并指定格式yyyymmdd就行，别用int类型。

具体原因 #

• 彻底解决无效分区的性能浪费：如果用int类型做分区投影，查询20100101到20110101这个范围时，Athena会生成所有在这个整型区间里的数值——比如20102060这种根本不存在的日期值，然后挨个去S3上检查有没有对应的路径。哪怕这些路径不存在，这个检查过程也会耗时间拖慢查询。换成date类型后，Athena会严格按yyyymmdd格式生成有效的日期值，只会对应实际存在的365天路径，不会做无用功。
• 日期操作更顺手：Athena和Glue对date类型的分区支持更原生，后续查日期范围、按天/月聚合数据时，不用额外把整型转成日期，写SQL更简单，也没转换的性能损耗。
• 投影配置更精准：date类型的投影可以直接设起止日期、按天间隔，完全匹配你的分区结构，不会生成多余的无效值。

关于int类型的坑 #

要是非要用int类型，Athena/Glue不会自动把整型识别成日期，也不会忽略那些无效的日期数值。它会把所有在查询范围内的整型值都当成可能的分区路径去校验，这会触发大量没必要的S3请求，直接拉低查询性能，正好踩中AWS文档说的“分区投影间隙影响性能”的问题。

示例建表语句 #

给你一个适配你S3结构的建表示例：

CREATE EXTERNAL TABLE table_x (
  deviceid string,
  -- 这里填你的其他表字段
)
PARTITIONED BY (date date)
ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION 's3://bucket/deviceid/table_x/'
TBLPROPERTIES (
  'projection.enabled' = 'true',
  'projection.date.type' = 'date',
  'projection.date.range' = '20100101,20231231', -- 根据你的实际数据时间范围调整
  'projection.date.format' = 'yyyyMMdd',
  'projection.date.interval' = '1',
  'projection.date.interval.unit' = 'DAYS',
  'storage.location.template' = 's3://bucket/deviceid/table_x/${date}/'
);

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