[解決済み] MSCK REPAIR TABLEは裏で何をしているのか、なぜこんなに遅いのか？

質問内容

私は、以下のことを知っています。 MSCK REPAIR TABLE は、外部テーブルの現在のパーティションでメタストアを更新します。

そのために必要なのは ls テーブルのルートフォルダで（テーブルが1つのカラムでパーティショニングされている場合）、そのすべてのパーティションを取得するために、明らかに < 1s 操作を行います。

しかし、実際には、この操作には 非常に長い を実行する時間（あるいは AWS Athenaで実行した場合、タイムアウトが発生します。 ).

そこで質問なのですが MSCK REPAIR TABLE の裏側で実際に行われていること、そしてその理由とは？

MSCK REPAIR TABLEはどのようにパーティションを見つけるのですか？

一応、追加データ。

<サブ データはすべてS3上にあり、EMR（Hive）またはAthena（Presto）で実行すると遅くなります。テーブルには〜450のパーティションがあり、各パーティションには平均90ファイル、パーティション全体で3ギガバイト、ファイルはApacheパーケットフォーマットです。

解決方法は？

ディレクトリ構造を読み込んでパーティションを作成し、ハイブのメタストアを更新するという意味では、その通りです。実は最近、このコマンドはメタストアから存在しないパーティションを削除するように改良されました。この例では、パーティション・キーが1レベルしかないため、非常に単純です。複数のパーティション・キー（実際には2～3個のパーティション・キーが一般的です）を持つテーブルを考えてみましょう。 msck repair は、テーブルディレクトリの下にあるすべてのサブディレクトリをフルツリー探索し、ファイル名を解析し、ファイル名が有効であることを確認し、パーティションがメタストアに既に存在するかどうかをチェックし、メタストアに存在しないパーティションだけを追加しなければならないでしょう。ファイルシステムの各リストは、HDFSの場合はネームノードへのRPC、S3やADLSの場合はウェブサービス呼び出しとなり、かなりの時間がかかることに注意してください。さらに、パーティションがすでにメタストアに存在するかどうかを判断するために、メタストアが知っているテーブルのすべてのパーティションをリストアップする必要があります。これらの手順はいずれも、大規模なテーブルに対するコマンドにかかる時間を増加させる可能性があります。msck repair tableの性能は最近のHive 2.3.0でかなり改善されました（詳細はHIVE-15879を参照してください）。をチューニングするとよいでしょう。 hive.metastore.fshandler.threads と hive.metastore.batch.retrieve.max を使用して、コマンドの性能を向上させました。