MSCK REPAIR TABLEは舞台裏で何をしますか？なぜそれがとても遅いのですか？
そんなこと知ってる MSCK REPAIR TABLEは、外部テーブルの現在のパーティションでメタストアを更新します。
これを行うには、テーブルのルートフォルダーでlsを実行するだけで（テーブルが1列だけでパーティション分割されている場合）、すべてのパーティションを取得します。明らかに<1秒の操作です。
ただし、実際には、操作の実行に非常に長い時間（または AWS Athenaで実行されている場合はタイムアウト ）もかかる場合があります。
だから私の質問は、MSCK REPAIR TABLE実際に舞台裏で行うのはなぜですか？
MSCK REPAIR TABLEはどのようにパーティションを見つけますか？
関連する場合の追加データ：
私たちのデータはすべてS3にあり、EMR（Hive）またはAthena（Presto）で実行すると速度が遅くなります。テーブルには〜450のパーティションがあり、すべてのパーティションには平均90ファイル、全体で3ギガバイトあり、ファイルはApache寄木細工のフォーマット
ディレクトリ構造を読み取り、そこからパーティションを作成し、Hiveメタストアを更新するという意味では、あなたは正しいです。実際、最近では、存在しないパーティションをメタストアからも削除するようにコマンドが改善されました。提供する例は、パーティションキーのレベルが1つしかないため、非常に単純です。複数のパーティションキーを持つテーブルを検討してください（実際には2〜3個のパーティションキーが一般的です）。 msck repairは、テーブルディレクトリの下のすべてのサブディレクトリのフルツリートラバーサルを実行し、ファイル名を解析し、ファイル名が有効であることを確認し、パーティションがメタストアにすでに存在するかどうかを確認してから、メタストアに存在しないパーティションのみ。ファイルシステムの各リストは、namenodeへのRPC（HDFSの場合）またはS3またはADLSの場合はWebサービス呼び出しであり、時間が大幅に増える可能性があることに注意してください。さらに、パーティションがメタストアにすでに存在するかどうかを判断するために、メタストアがテーブルについて知っているすべてのパーティションの完全なリストを作成する必要があります。これらの両方の手順により、大きなテーブルでのコマンドにかかる時間が長くなる可能性があります。 msck修復テーブルのパフォーマンスは、最近、Hive 2.3.0でかなり改善されました（詳細については、Hive-15879を参照してください）。調整したいかもしれませんHive.metastore.fshandler.threadsおよびHive.metastore.batch.retrieve.maxコマンドのパフォーマンスを改善します。