大手保険会社が1日あたり500GBのクレームデータをAmazon S3にCSV形式で年/月/日のディレクトリ構造で保存し、Amazon Athenaでアドホック分析を実行しています。 現在の課題： ・クエリの平均実行時間が60〜120秒 ・月次Athenaコストが約900万円（スキャンデータ量課金） ・各アナリストチームが同一の標準レポートクエリを1日に複数回実行 ・Glueデータカタログに300以上のテーブルが存在し、各テーブルに平均100以上のパーティション 制約：分析ツールはAthenaから変更できず、既存のSQLクエリパターンも修正不可 クエリコストと実行時間を最も効果的に削減する施策を2つ選択してください。
CSVからApache Parquetへの変換（選択肢A）は、Athenaコストと実行時間の削減に最大のインパクトをもたらします。Parquetは列指向フォーマットのためSELECT句で指定した列のみをスキャンし、Snappy圧縮によりCSV比で85〜93%のデータ量削減が実現します。スキャンデータ量がそのままAthenaの料金に直結するため月次コストを大幅に圧縮できます。Glue列統計情報の収集はAthenaクエリプランナーが最適な実行計画を選択するために有効です。SQLクエリの変更は一切不要のためツール・クエリ変更不可の制約にも抵触しません。 Query Result ReuseとPartition最適化（選択肢B）は、同一クエリの再実行時に前回スキャン結果を最大24時間再利用します。各チームが同一レポートを複数回実行する本シナリオでは2回目以降のAthenaスキャンコストが完全に発生しません。300テーブル×100パーティション規模ではPartition IndexingによりGlueカタログへのパーティション一覧取得コールが大幅に削減され、Partition Projectionは日付パーティションのメタデータアクセス自体を廃止します。 選択肢CのAmazon Redshift Serverlessへの移行は分析ツールをAthenaから変更することになり制約に直接違反します。 選択肢DのCloudFront + Lambda@EdgeによるAthena APIキャッシュはAthenaの非同期クエリモデルと整合せず、QuickSightへの移行も分析ツール変更禁止の制約に反します。 選択肢EのS3 Intelligent-TieringはS3ストレージ料金を最適化しますが、AthenaはスキャンバイトのみをS3ストレージ料金とは独立して課金するため効果がなく、Glue DataBrewもAthenaのスキャン量を直接削減する機能はありません。