对于小型数据集，AWS Athena MSCK REPAIR TABLE 花费的时间太长

Posted 2023-02-16

【中文标题】对于小型数据集，AWS Athena MSCK REPAIR TABLE 花费的时间太长

【英文标题】：AWS Athena MSCK REPAIR TABLE takes too long for a small dataset

【发布时间】：2017-12-19 20:15:24

【问题描述】：

我在使用 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 上，如果这个问题仍然存在，我不会这样做

有人知道为什么要花很长时间吗？

提前致谢

【参考方案1】：

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/… 的新链接。

【参考方案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 个文件是合适的。

一些参考资料： 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

【参考方案3】：

使用Athena Projection自动管理分区。