我在使用 amazon athena 时遇到问题，我有一个带有 4 个分区级别的小存储桶（36430 个对象，9.7 mb）（my-bucket/p1=ab/p2=cd/p3=ef/p4=gh/file .csv ）但是当我运行命令时
MSCK REPAIR TABLE db.table
耗时超过 25 分钟，我计划将 TB 量级的数据放在 Athena 上，如果这个问题仍然存在，我不会这样做
有人知道为什么要花很长时间吗？
提前致谢
【问题讨论】：
标签： amazon-web-services amazon-s3 hive amazon-athena
MSCK REPAIR TABLE 可能是一项代价高昂的操作，因为它需要扫描文件系统（S3 存储桶）中表的子树。多级分区可能会使其成本更高，因为它需要遍历额外的子目录。假设所有可能的分区值组合都出现在数据集中，这可能会变成组合爆炸。
如果您要向现有表添加新分区，那么您可能会发现为各个新分区运行ALTER TABLE ADD PARTITION 命令会更有效。这避免了扫描文件系统中表的整个子树的需要。它不如简单地运行MSCK REPAIR TABLE 方便，但有时优化是值得的。一个可行的策略通常是使用MSCK REPAIR TABLE 进行初始导入，然后在将新数据添加到表中时使用ALTER TABLE ADD PARTITION 进行持续维护。
如果直接使用ALTER TABLE ADD PARTITION来管理分区确实不可行，那么执行时间可能是不可避免的。减少分区的数量可能会减少执行时间，因为它不需要遍历文件系统中的许多目录。当然，那么分区不同，可能会影响查询执行时间，所以需要权衡。
【讨论】：
ALTER TABLE ADD PARTITION - docs.aws.amazon.com/athena/latest/ug/… 的新链接。
虽然标记的答案在技术上是正确的，但它并不能解决您的真正问题，即您的文件太多。
我有一个小桶（36430 个对象，9.7 mb），有 4 个级别 分区（my-bucket/p1=ab/p2=cd/p3=ef/p4=gh/file.csv）
对于这么小的表，36430 个文件在 S3 上造成了巨大的开销，4 级的分区是超级矫枉过正的。分区阻碍了查询性能，而不是优化它。 MSCK 很慢，因为它正在等待 S3 列表等。
如果 Athena 将整个 9.7MB 表放在一个文件中，则它读取整个表的速度比列出那个巨大的目录结构的速度要快。
我建议完全删除分区，或者如果您确实必须拥有它们，则删除 p2、p3 和 p4 级别。还可以考虑将其处理到另一个表中以将文件压缩成更大的文件。
有些人建议最佳文件大小在 64MB 和 4GB 之间，这与 S3 上的本机块大小有关。拥有多个文件是集群中工作人员的倍数也很有帮助，尽管 Athena 不知道这一点。您的数据小于该范围，因此最多 1 个或 8 个文件是合适的。
【讨论】：
使用Athena Projection自动管理分区。
【讨论】：