ある企業が、Amazon Athena を使って S3 上のログデータ（CSV 形式、毎日約 100GB 追加）に対してアドホッククエリを実行している。Athena の月次コストが予算を超えており、クエリあたりのスキャン量を削減してコストを最小化したい。データは日付でパーティション分割されており、ほとんどのクエリは特定の日付範囲のみを対象とする。コード変更を最小限にしてコストを削減する最も適切な改善策はどれか。
- A. Athena のクエリ実行ごとに S3 のデータを Redshift にロードして Redshift で実行する。
- B. CSV 形式のデータを Apache Parquet 形式に変換し、AWS Glue ETL ジョブで週次に変換する。Parquet は列指向・圧縮効率が高くスキャン量を大幅に削減できる。
- C. S3 バケットを Standard ストレージクラスから Standard-IA に移行し、ストレージコストを削減する。
- D. Athena の結果キャッシュ機能を有効化して同一クエリの繰り返し実行コストをゼロにする。
解答と解説を見る
正解: B
Athena はスキャンしたデータ量で課金される（1TB あたり約 5USD）。CSV から Parquet（列指向・圧縮）に変換することで、(1) 必要な列のみ読み取れる（列プルーニング）、(2) Snappy/gzip 圧縮でデータサイズが 1/5〜1/10 になる、という 2 つの効果でスキャン量が劇的に削減される。パーティション分割と Parquet の組み合わせでスキャン量を 90% 以上削減できるケースも多い。Glue ETL ジョブの実行コストを差し引いてもコスト削減効果が高い。選択肢AのRedshift へのロードはロード時間・コスト・Redshift クラスターの常時稼働コストが発生し、アドホッククエリのコスト削減には逆効果。選択肢Dの Athena 結果キャッシュは有効だが、アドホッククエリは毎回異なるため、同一クエリの繰り返し率が低い場合は効果が限定的。根本的なスキャン量削減にはならない。選択肢CのS3 Standard-IA への移行はストレージコストを削減するが、Athena のコスト（スキャン量課金）の削減には無関係。
📚 関連サービスの解説: AWS Glue