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

Question

我知道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 parquet 格式}

Answer 1

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