AWS Athena MSCK REPAIR TABLE tablename命令

Question

我们期望该命令有多少个分区

MSCK REPAIR TABLE tablename;

失败了吗？

我有一个系统，当前有超过27k的分区，并且为Athena表更改了架构，我们删除了该表，重新创建了该表，并说了新的列结尾，然后运行

MSCK REPAIR TABLE tablename;

我们对执行此命令没有任何运气，因此每次让它运行5个小时之后，我们都会感到运气不佳。没有添加单个分区。想知道是否有人知道我们可能遇到的分区限制信息，但是找不到任何地方的文档。

Answer 1

MSCK REPAIR TABLE是效率极低的命令。我真的希望文档不会鼓励人们使用它。

该怎么做取决于您情况所特有的许多事情。

在一般情况下，我建议编写一个脚本，该脚本执行S3列表并构造具有其位置的分区列表，并使用Glue API BatchCreatePartition将分区添加到表中。

当您的S3位置包含很多文件时，就像听起来的那样，我要么使用S3 Inventory来避免列出所有内容，要么使用分隔符为/的对象列出，以便我只能列出存储桶的目录/分区结构部分，并跳过列出所有文件的操作。如果避免列出所有内容，则可以相当快地列出27K分区。

Glue的BatchCreatePartitions有点烦人，因为您必须为每个分区指定所有列，serde和所有内容，但是它比运行ALTER TABLE … ADD PARTION …并等待查询执行完成要快-而且比MSCK REPAIR TABLE …还要快。

在将新分区添加到现有表时，出于绝大部分相同的原因，也不要使用MSCK REPAIR TABLE。几乎总是在将新分区添加到表中时知道新分区的位置，并且ALTER TABLE … ADD PARTION …或Glue的BatchCreatePartitions可以直接使用，而无需编写脚本。

如果添加新数据的过程与添加新分区的过程是分开的，则建议您将S3通知设置到SQS队列并定期读取消息，汇总新文件的位置并构造新分区的列表从那开始。