我遇到了amazon athena的问题，我有一个小桶（36430个对象，9.7 mb），有4级分区（my-bucket / p1 = ab / p2 = cd / p3 = ef / p4 = gh / file .csv）但是当我运行命令时
MSCK REPAIR TABLE db.table
花了25分钟，我计划在Athena上放置结核病的数据，如果这个问题仍然存在，我就不会这样做
有人知道为什么要花太长时间吗？
提前致谢
答案 0 :(得分：7)
MSCK REPAIR TABLE可能是一项代价高昂的操作，因为它需要在文件系统（S3存储桶）中扫描表的子树。多级分区可能会使其成本更高，因为它需要遍历其他子目录。假设分区值的所有潜在组合都出现在数据集中，这可能会变成组合爆炸。
如果要向现有表添加新分区，则可能会发现为各个新分区运行ALTER TABLE ADD PARTITION命令更有效。这样就无需在文件系统中扫描表的整个子树。它不如简单地运行MSCK REPAIR TABLE便利，但有时优化是值得的。一个可行的策略通常是使用MSCK REPAIR TABLE进行初始导入，然后在将新数据添加到表中时使用ALTER TABLE ADD PARTITION进行持续维护。
如果使用ALTER TABLE ADD PARTITION直接管理分区实际上是不可行的，那么执行时间可能是不可避免的。减少分区数可能会缩短执行时间，因为它不需要遍历文件系统中的多个目录。当然，分区是不同的，这可能会影响查询执行时间，所以这是一个权衡。
答案 1 :(得分：2)
虽然标记的答案在技术上是正确的，但不能解决您的实际问题，即文件太多。
我有一个小桶（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个文件是合适的。