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