AWSAthenaパーティションはすべてのパスをフェッチします
最近、パーティションの数が非常に多いときにAWSAthenaで問題が発生しました。
古いバージョンには、id = xのように1つのパーティションレベルしかないデータベースとテーブルがありました。 1つのテーブルを取りましょう。たとえば、ID（製品）ごとに支払いパラメーターを保存し、IDが十分にない場合です。その約1000-5000を想定します。ここで、「.. where id = 10」のようなwhere句でID番号を渡してそのテーブルをクエリしている間。クエリは実際にはかなり速く返されました。データを1日2回更新するとします。
最近、「../ id = x/dt = yyyy-mm-dd/..」のような別のパーティションレベルを追加することを検討しています。これは、1か月が経過するとパーティション番号が1日あたりxID回増加し、3000 IDがある場合、1か月あたり約3000x30 = 90000パーティションになることを意味します。したがって、パーティションの数が急速に増加します。
たとえば、3か月前のデータ（約27万パーティション）の場合、次のようなクエリが最大20秒程度で返されるようにします。
select count(*) from db.table where id = x and dt = 'yyyy-mm-dd'
これには1分ほどかかります。
実際のケース
Athenaは最初にすべてのパーティション（メタデータ）とs3パス（where句の使用に関係なく）をフェッチしてから、where条件で確認したいs3パスをフィルタリングします。最初の部分（パーティションによるすべてのs3パスのフェッチは、パーティションの数に比例して長く続きます）
パーティションが多いほど、クエリの実行速度は遅くなります。
直感的には、Athenaはwhere句に記載されているs3パスのみをフェッチすることを期待していました。つまり、これがパーティショニングの魔法の1つの方法になるということです。多分それはすべてのパスをフェッチします
- 誰かが回避策を知っていますか、それとも私たちはアテナを間違った方法で使用していますか？
- Athenaは少数のパーティションでのみ使用する必要がありますか？
編集
上記の説明を明確にするために、サポートメールから一部を追加します。
サポートから
...あなたはあなたの新しいシステムが膨大な数である360000を持っていると言いました。だからあなたがしているとき
select * from <partitioned table>、Athenaは最初にすべてのパーティションメタデータをダウンロードし、それらのパーティションにマップされたS3パスを検索しました。各パーティションのデータをフェッチするこのプロセスにより、クエリの実行時間が長くなります。 .。
更新
AWSフォーラムで開かれた問題。 awsフォーラムで提起されたリンクされた問題は ここ です。
ありがとう。
これは、データの量、ファイル形式、および話しているファイルの数を知らなければ、適切に答えることはできません。
TL; DR何千ものファイルを含むパーティションがあり、ボトルネックがそれらすべてをリストして読み取っていると思います。
時間の経過とともに増大するデータセットの場合、クエリパターンに応じて、日付または時刻でさえ、一時的なパーティション分割を行う必要があります。他のプロパティでパーティショニングを行う必要がある場合は、多くの要因に依存し、最終的にはパーティショニングしない方が良いことがよくあります。常にではありませんが、頻繁に。
適度なサイズ（〜100 MB）の寄木細工を使用すると、多くの場合、分割よりも効果的です。その理由は、パーティショニングにより、S3にリストする必要のあるプレフィックスの数と、読み取る必要のあるファイルの数が増えるためです。多くの場合、1つの100MB寄木細工ファイルは10個の10MBファイルよりも効率的です。
Athenaがクエリを実行すると、最初にGlueからパーティションが読み込まれます。 Glueはパーティションの制限付きフィルタリングをサポートします 、パーティションのリストを整理するのに少し役立ちます–したがって、私の知る限り、Athenaがallパーティションメタデータ。
パーティションがある場合、パーティションの場所にLIST操作を発行して、クエリに関係するファイルを収集します。つまり、Athenaはeveryパーティションの場所。クエリ用に選択されたパーティション内の場所のみ。これはまだ多数である可能性があり、これらのリスト操作は間違いなくボトルネックです。パーティションに1000を超えるファイルがある場合、それはS3のリスト操作のページサイズであり、複数のリクエストを順番に行う必要があるため、特に悪化します。
すべてのファイルがリストされると、Athenaは分割のリストを生成します。これは、ファイルのリストと等しい場合と等しくない場合があります。一部のファイル形式は分割可能であり、ファイルが十分に大きい場合は、分割されて並行して処理されます。
そのすべての作業が完了した後でのみ、実際のクエリ処理が開始されます。分割の総数とAthenaクラスターで使用可能な容量に応じて、クエリにリソースが割り当てられ、実行が開始されます。
データがParquet形式であり、パーティションごとに1つまたは少数のファイルがあった場合、質問のカウントクエリは1秒以内に実行されます。 Parquetのファイルには十分なメタデータがあるため、カウントクエリでデータを読み取る必要はなく、ファイルフッターだけを読み取ることができます。複数の手順が含まれるため、1秒未満でクエリを実行するのは困難ですが、単一のパーティションにヒットするクエリは迅速に実行されるはずです。
2分かかるので、パーティションごとに数千とまではいかなくても数百のファイルがあると思います。ボトルネックは、すべてのリストを実行してS3で操作を取得するのに時間がかかりすぎることです。