私はamazon athenaに問題があります。私は小さなバケット（36430個のオブジェクト、9.7メガバイト）に4レベルのパーティション（my-bucket/p1 = ab/p2 = CD/P3 = EF/P4 = GH/file.csvになり）が、私は、コマンドを実行するとAWS Athena MSCK REPAIR TABLEは小さなデータセットでは長すぎます
MSCK REPAIR TABLE db.table
は25分以上を取っている、と私はアテナにTBの大きさのデータを配置する計画を持っていますこの問題が残っていれば私はそれをしません
誰がなぜ時間がかかりすぎるのか分かりませんか？それは、ファイルシステム（S3バケット）にテーブルのサブツリーをスキャンする必要があるため、事前に
おかげ
MSCK REPAIR TABLEは、コストのかかる操作することができます。複数のレベルのパーティション化により、追加のサブディレクトリを横断する必要があるため、コストがかかる可能性があります。パーティション値のすべての潜在的な組み合わせがデータセット内に存在すると仮定すると、これはコンビナトリアル爆発に変わる可能性があります。
既存のテーブルに新しいパーティションを追加する場合は、新しいパーティションごとにALTER TABLE ADD PARTITIONコマンドを実行する方が効率的です。これにより、ファイルシステム内のテーブルのサブツリー全体をスキャンする必要がなくなります。単にMSCK REPAIR TABLEを実行するよりもあまり便利ではありませんが、最適化が必要な場合もあります。実行可能な戦略は、多くの場合、最初のインポートにMSCK REPAIR TABLEを使用し、新しいデータがテーブルに追加されると、継続的なメンテナンスにはALTER TABLE ADD PARTITIONを使用します。
ALTER TABLE ADD PARTITIONを直接使用してパーティションを直接管理できない場合は、実行時間が避けられない場合があります。パーティションの数を減らすと、ファイルシステム内の多くのディレクトリをトラバースする必要がないため、実行時間が短縮される可能性があります。もちろん、分割は異なります。これはクエリの実行時間に影響する可能性があるため、トレードオフです。