已恢复的S3 Deep Archive对象无法被Redshift Spectrum识别的问题咨询

问题背景 #

我有一个基于Glue元数据、存储在S3上的Redshift Spectrum外部表，为降低成本将部分分区数据迁移至S3 Deep Archive存储类。当需要查询某一分区时，我发起了S3 ObjectRestore操作，等待12小时后S3控制台显示数据已恢复，且确认：

• Glue分区存在且配置正确
• 该分区在Redshift的svv_external_partitions中可见
• 手动下载对应S3路径的文件可正常读取内容

但Redshift查询该分区时返回0行，Athena查询也得到相同结果。怀疑Redshift Spectrum仍将已恢复的对象识别为Deep Archive类而忽略，但未在官方文档找到相关说明，需确认这是否为预期行为，以及如何解决。

原因分析 #

1. 元数据缓存未同步：S3控制台显示恢复完成，但Glue或Redshift Spectrum的元数据缓存未更新对象存储类状态，导致查询引擎误判对象仍处于不可访问的Deep Archive状态。
2. 恢复参数导致的访问延迟：若恢复时使用批量恢复（Bulk Tier），可能存在实际可访问性延迟，临时副本的路径未被外部表正确识别。
3. 分区过滤条件不匹配：查询语句中的分区过滤条件与Glue存储的分区值（如大小写、格式）不一致，导致无数据返回。

解决方案 #

1. 刷新元数据并同步Redshift Spectrum #

• Glue端刷新：在Glue控制台对目标表执行「刷新表」操作，或用AWS CLI更新分区：

  aws glue batch-update-partition --database-name <你的数据库名> --table-name <你的表名> --partition-updates '[{"Values": ["<分区值>"], "PartitionInput": {"Values": ["<分区值>"], "StorageDescriptor": {"Location": "<S3分区路径>"}}}]'
  

• Redshift端重载分区：执行SQL强制Spectrum重新加载分区元数据：

  ALTER TABLE spectrum.<你的外部表名> RELOAD PARTITION (partition_col='<分区值>');
  

2. 验证S3对象实际状态 #

用AWS CLI检查对象的存储类和恢复状态，确认是否真的处于可访问状态：

aws s3api head-object --bucket <你的桶名> --key <对象键>

查看返回结果中的StorageClass（应为STANDARD或指定的临时存储类）和Restore字段（需显示恢复完成信息）。

3. 重新发起标准层恢复 #

若之前使用批量恢复，重新发起恢复时指定Standard Tier，确保对象快速恢复至可访问状态：

aws s3api restore-object --bucket <你的桶名> --key <对象键> --restore-request '{"Days": 7, "GlacierJobParameters": {"Tier": "Standard"}}'

4. 检查查询过滤条件 #

确认查询语句中的分区过滤条件与Glue中存储的分区值完全匹配（包括大小写、格式），避免因条件错误导致无数据返回。

结论 #

这种情况不是预期行为，正常恢复后S3对象应能被Redshift Spectrum和Athena正常访问。多数场景下是元数据缓存未更新导致，刷新元数据后即可解决。

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