AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

正解

A. 日付やキャンペーンIDなど、頻繁に絞り込み条件として使われるカラムでデータをパーティション分割する

日付やキャンペーン ID のようにWHERE 句で頻繁に絞り込むカラムをパーティションキーにすると、Athena は該当する S3 プレフィックスだけを読み、それ以外を丸ごとスキップする（パーティションプルーニング）。
広告クリックログのように日々積み上がるデータでは、対象期間だけを読む形になるためスキャン量が桁違いに減り、実行時間とコストが同時に改善する。
ログ系データの最初の最適化として必ず検討される定石。

B. データを行志向の CSV 形式のまま保持し、代わりにファイルをできるだけ大きな単一ファイルに統合する

CSV は行指向のため、クエリで数列しか使わなくても全列を読み込むことになり、スキャン量は減らない。
ファイルの統合自体は「小さすぎるファイルが大量にある（スモールファイル問題）」の対策として有効だが、できるだけ大きな単一ファイルに統合すると分散並列読み取りが効きにくくなり、むしろ実行時間が伸びかねない。
目安は数百 MB 程度のファイルに揃えることであり、「1本の巨大ファイル」は最適化ではない。

C. AWS Glue ジョブブックマークを有効化し、新規追加分のみを ETL 処理の対象にする

AWS Glue のジョブブックマークは、ETL ジョブが処理済みのデータを再処理しないようにする増分処理の仕組み。ETL 側の実行時間とコストには効くが、Athena がクエリ時に読むデータ量は 1 バイトも変わらない。
本問が求めているのは「クエリのパフォーマンスとコストの改善」であり、パイプライン側の効率化は要件に対する答えになっていない。
有用な機能ではあるが、論点がずれている典型的な誤答。

正解

D. データを列志向の Apache Parquet 形式に変換し、圧縮を適用する

Apache Parquet は列指向フォーマットで、クエリが参照する列だけを読み取れるため、SELECT する列が一部であればスキャン量が大幅に減る。
さらに Snappy / GZIP などの圧縮を適用すれば S3 上の実バイト数自体が小さくなり、スキャン量課金の Athena では料金がそのまま下がる。
列ごとの統計情報による述語プッシュダウンで不要な行グループも読み飛ばせるため、パーティション分割と並ぶ最重要の最適化。

E. S3 に新しいデータが追加されるたびに、AWS Glue Data Catalog のパーティションを手作業で追加登録する

新しいデータが追加されるたびに手作業でパーティションを追加登録するのは、運用負荷が高いうえにヒューマンエラーで登録漏れ（＝クエリ結果の欠落）を招く。
そもそもパーティションを登録すること自体はカタログの整備であって、スキャン量やファイル形式の最適化ではない。
自動化するなら AWS Glue クローラー、MSCK REPAIR TABLE、あるいはパーティション射影（Partition Projection）を使うのが定石で、手作業は選択肢にならない。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
スキャン対象データ量が膨らみコストが増大している	Athena はスキャンしたデータ量に対する課金。「読むバイト数を減らす」施策だけが直接効く →選択肢（A・D）は候補
日付やキャンペーンIDで頻繁に絞り込む	絞り込みカラムをパーティションキーにすると該当プレフィックスだけを読む（パーティションプルーニング） →選択肢（A）が正解
ファイル形式の見直しによる改善	列指向 Parquet ＋圧縮で、必要な列だけを圧縮された状態で読める →選択肢（D）が正解
CSV のまま巨大な単一ファイルへ統合する案	行指向は全列読み込みでスキャン量が減らず、単一巨大ファイルは並列読み取りも阻害する →選択肢（B）を消す
ETL 側の増分処理・カタログの手動運用	ジョブブックマークは ETL の再処理削減で、手動のパーティション登録は運用負荷。いずれもクエリのスキャン量には無関係 →選択肢（C・E）を消す

ひっかけポイント

• 「ファイルをできるだけ大きく統合する」は半分だけ正しいのが罠。小さすぎるファイルの解消は有効だが、CSV のままではスキャン量が減らず、単一の巨大ファイルは分散処理を妨げる
• AWS Glue ジョブブックマークはETL 側のコスト削減であって、Athena のクエリコストには効かない。「どこのコストを下げる話か」を必ず区別する
• パーティションの手作業登録は「パーティション」という正解キーワードを含むため選びたくなるが、要求されているのは設計改善であり、運用手順の追加ではない
• パーティションは細かくしすぎると小さなファイルとパーティションメタデータが激増して逆効果になる。粒度（例：日単位）の設計もセットで問われる

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「パーティションが数万個に増え、メタデータ取得がボトルネックになった」	パーティション射影（Partition Projection）が正解軸に浮上する。
「ETL の再処理コストを下げたい（クエリではなくパイプラインの話）」	今度は AWS Glue ジョブブックマークが正解になる。
「構造体や配列など複合データ型を多用している」	ORC がより幅広い複合型をサポートし、選定軸が変わる。
「行レベルの更新・削除やタイムトラベルが必要」	Apache Iceberg テーブル（S3 Tables 含む）が正解軸に。
「利用者が誤って全件スキャンするのを防ぎたい」	Athena ワークグループのデータ使用量制御（クエリごとのスキャン上限）が正解軸に。

関連サービスの解説

Amazon Athena
Amazon Simple Storage Service (Amazon S3)
AWS Glue