MSCK REPAIR TABLE在后台做了什么，为什么它这么慢？

Question

我知道这会MSCK REPAIR TABLE使用外部表的当前分区更新元存储。

为此，您只需要ls在表的根文件夹上执行操作（假设表仅由一列进行分区），并获得其所有分区，显然是<1s操作。

但实际上，该操作可能需要很长时间才能执行（如果在AWS Athena上运行，甚至可能会超时）。

所以我的问题是，MSCK REPAIR TABLE幕后的实际工作是什么？为什么？

MSCK REPAIR TABLE如何找到分区？

---

与之相关的其他数据：

_{我们的数据全部在S3上，在EMR（Hive）或Athena（Presto）上运行时速度都很慢，表中有约450个分区，每个分区平均有90个文件，一个分区总共3 GB，文件位于Apache拼花格式}

Answer 1

在读取目录结构，从中创建分区然后更新配置单元元存储的意义上，您是对的。实际上，最近对该命令进行了改进，以从元存储中删除不存在的分区。您给出的示例非常简单，因为它只有一层分区键。考虑具有多个分区键的表（在实践中通常使用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提高指挥性能。