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