我知道MSCK REPAIR TABLE用外部表的当前分区更新元存储。
为此，您只需要在表的根文件夹上执行ls（假设表仅由一列进行分区），并获得其所有分区，显然是
但是实际上，该操作可能需要很长时间才能执行（甚至timeout if ran on AWS Athena）。
所以我的问题是MSCK REPAIR TABLE在幕后实际上是做什么的，为什么？
MSCK REPAIR TABLE如何找到分区？
与之相关的其他数据：
我们的数据全部在S3上，在EMR（Hive）或Athena（Presto）上运行时速度都很慢，表中有约450个分区，每个分区上平均有90个文件，一个分区总共3 GB，文件位于Apache拼花格式
最佳答案
在读取目录结构，从中创建分区然后更新配置单元元存储的意义上，您是对的。实际上，最近对该命令进行了改进，以从元存储中也删除不存在的分区。您给出的示例非常简单，因为它只有一层分区键。考虑具有多个分区键的表（在实践中通常使用2-3个分区键）。 msck repair将必须对表目录下的所有子目录进行全树遍历，分析文件名，确保文件名有效，检查分区在元存储中是否已存在，然后添加元存储中唯一不存在的分区。请注意，文件系统上的每个列表都是到名称节点的RPC（对于HDFS）或对于S3或ADLS的Web服务调用，这可能会增加大量时间。此外，为了弄清楚该分区是否已存在于metastore中，它需要对metastore知道的表的所有分区进行完整列出。这两个步骤都可能会增加在大型表上执行命令所花费的时间。最近，Hive 2.3.0改进了msck修复表的性能（有关更多详细信息，请参见HIVE-15879）。您可能需要调整hive.metastore.fshandler.threads和hive.metastore.batch.retrieve.max以提高命令的性能。
关于amazon-web-services - MSCK REPAIR TABLE在后台做了什么，为什么这么慢？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/53667639/