あるデータエンジニアリングチームは、Amazon S3 に格納された10TBのウェブアクセスログデータをAmazon Athenaでクエリしています。現在のデータは非圧縮CSV形式で保存されており、パーティショニングは実施されていません。クエリの実行時間は平均45分かかり、コストも高騰しています。チームは以下の状況を把握しています。 ・ほとんどのクエリは date カラムと region カラムでフィルタリングしている ・全カラムのうち一部しか参照しないクエリが大半を占める ・月次レポートのバッチクエリとアドホッククエリが混在している クエリパフォーマンスの向上とコスト削減に最も直接的に効果がある対策を2つ選択してください。
Apache Parquetはカラム型ストレージ形式であり、クエリで参照するカラムのみを読み込みます。全カラムの一部しか使わないクエリが多い環境では、行形式のCSVに比べてスキャン量を大幅に削減できます。SNAPPY圧縮と組み合わせることでデータサイズも縮小され、Athenaの課金対象であるスキャンデータ量（1TBあたり課金）を直接削減できます。 dateおよびregionカラムによるパーティショニングを実装すると、WHERE句の条件に合致しないパーティションは完全にスキップされます。ほとんどのクエリがこれらのカラムでフィルタリングしているため、スキャン量削減の効果は非常に大きくなります。 選択肢Cのクエリ結果キャッシュは同一クエリの再実行コストを削減しますが、新規クエリやパラメータが異なるクエリには効果がなく、根本的な改善にはなりません。 選択肢DのRedshiftへの移行は大規模な設計変更を伴い、アドホッククエリにはAthenaの方が適している場合が多く、過剰な対策です。 選択肢EのワークグループはSLA管理・コスト配賦・クエリ制限に有効ですが、スキャン量の削減やクエリ速度の向上には直接寄与しません。