我对amazon athena有问题，我有一个小的bucket（36430个对象，9.7MB），有4个分区级别（my bucket/p1=ab/p2=cd/p3=ef/p4=gh/file.csv），但是当我运行命令时 MSCK REPAIR TABLE db.table 需要25分钟，我计划在雅典娜上公布结核病的严重程度，如果这个问题仍然存在，我不会这么做
有人知道为什么要花太长时间吗？
提前谢谢
我对amazon athena有问题，我有一个小的bucket（36430个对象，9.7MB），有4个分区级别（my bucket/p1=ab/p2=cd/p3=ef/p4=gh/file.csv），但是当我运行命令时 MSCK REPAIR TABLE db.table 需要25分钟，我计划在雅典娜上公布结核病的严重程度，如果这个问题仍然存在，我不会这么做
有人知道为什么要花太长时间吗？
提前谢谢
2条答案
按热度按时间y1aodyip1#
MSCK REPAIR TABLE这可能是一个代价高昂的操作，因为它需要扫描文件系统（s3 bucket）中表的子树。由于需要遍历额外的子目录，多个级别的分区可能会增加成本。假设分区值的所有潜在组合都出现在数据集中，这可能会变成组合爆炸。如果要向现有表中添加新分区，则可能会发现运行该表更高效
ALTER TABLE ADD PARTITION用于各个新分区的命令。这样就不需要扫描文件系统中表的整个子树。它不如简单地运行方便MSCK REPAIR TABLE，但有时优化是值得的。一个可行的策略是经常使用MSCK REPAIR TABLE用于初始导入，然后使用ALTER TABLE ADD PARTITION用于表中添加新数据时的日常维护。如果真的不可行的话
ALTER TABLE ADD PARTITION要直接管理分区，那么执行时间可能是不可避免的。减少分区的数量可能会减少执行时间，因为它不需要遍历文件系统中那么多的目录。当然，分区是不同的，这可能会影响查询执行时间，因此这是一种折衷。htrmnn0y2#
虽然标记的答案在技术上是正确的，但它并不能解决您的真正问题，即您有太多的文件。
我有一个小的bucket（36430个对象，9.7MB），有4层分区（my bucket/p1=ab/p2=cd/p3=ef/p4=gh/file.csv）
对于这样一个小的表，36430个文件在s3上产生了巨大的开销，并且4级分区是超级致命的。分区阻碍了查询性能，而不是优化它。msck的速度很慢，因为它正在等待s3的上市。
雅典娜将读取整个9.7mb的表，如果它是在一个文件的速度比它能够列出巨大的目录结构。
我建议完全删除分区，或者如果您真的必须删除它们，那么删除p2、p3和p4级别。还可以考虑将其处理到另一个表中，以便将文件压缩为更大的文件。
一些人建议最佳文件大小在64mb到4gb之间，这与s3上的本机块大小有关。拥有集群中多个worker的文件也很有帮助，尽管雅典娜对此一无所知。您的数据小于该范围，因此最多1个或8个文件是合适的。
一些参考资料：https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/#optimizefilesizes
https://www.upsolver.com/blog/small-file-problem-hdfs-s3