データレイクの列指向変換とパーティション設計
全国配送を手がける物流企業が、配送実績を 1 日あたり約 4,000 万行の CSV ファイルとして Amazon S3 に蓄積しています。分析チームは Amazon Athena で「特定期間・特定営業所の配送遅延件数」といったアドホック集計を実行していますが、クエリが数分かかるうえスキャン量に応じた料金が想定を大きく超えています。分析対象になるのは全カラムのうち数個だけで、ほぼすべてのクエリが配送日で絞り込まれます。最も効果的な改善策はどれですか。
解説を読む（正解: A）
Amazon Athena は S3 上のデータをスキャンしたバイト数に応じて課金されるため、性能とコストの両方がデータフォーマットとレイアウトに直結します。Apache Parquet のような列指向フォーマットは、クエリが参照するカラムのブロックだけを読み出すため、数十カラムのうち数個しか使わないワークロードではスキャン量を大幅に削減できます。さらに配送日でパーティションを切っておけば、パーティションプルーニングによって対象期間外のオブジェクトは読み込まれません。AWS Glue の ETL ジョブはこの CSV から Parquet への変換とパーティション書き出しをサーバーレスで実行でき、Glue Data Catalog にスキーマを登録すれば Athena がそのまま参照できます。したがって A が最適です。B の gzip は転送量こそ減りますが行指向のままで不要カラムも読み込まれ、かつ gzip は分割不能なため並列処理が効かず性能が悪化することもあります。C の EMR 常時起動はクラスター費用が継続的に発生し、CSV のままではスキャン量の問題も解決しません。D の Redshift への全面移行はアドホック分析のために専用クラスターを維持することになり、データレイク上での柔軟な分析という要件に対して過剰かつ高コストです。
ストリーミング取り込みと Parquet 変換の構成
全国配送網を持つ物流企業が、配送トラック 8,000 台の車載端末から 1 分間隔で位置情報と冷蔵コンテナの温度データを送信しています。データは数分程度の遅延であれば許容されるため、ニアリアルタイムで Amazon S3 のデータレイクに蓄積し、翌日以降に Amazon Athena で分析したい。スキャン量に応じた分析コストを抑えるため、取り込み時に JSON から Apache Parquet 形式へ変換する必要があります。運用管理の負荷を最小限に抑えつつこの要件を満たす構成はどれか。
解説を読む（正解: A）
ストリーミングデータを S3 のデータレイクへ継続的に取り込む場合、送信されてくる小さなレコードをバッファリングしてまとまったファイルにまとめ、分析に適した列指向フォーマットへ変換する処理が必要になります。この一連の処理をマネージドで提供するのが Amazon Data Firehose です。A が正解で、Firehose は配信ストリームにデータを送るだけでバッファサイズやバッファ間隔に応じて自動的にレコードをまとめ、AWS Glue Data Catalog に登録されたテーブルスキーマを参照するレコード形式変換機能によって JSON を Apache Parquet や ORC へ変換したうえで S3 に配信します。シャード管理もサーバー管理も不要で、数分の遅延を許容するニアリアルタイム要件と運用負荷最小化の両方に合致します。B は実現自体は可能ですが、コンシューマーアプリケーションのデプロイ、シャード数の調整、チェックポイント管理、障害時の再処理を自前で運用する必要があり、要件である運用負荷の最小化に反します。C はバッチ処理であるためニアリアルタイム性が失われるうえ、端末が直接 PUT した膨大な小さいオブジェクトが S3 に残り、EMR クラスターのライフサイクル管理という追加運用も発生します。D の SQS と Lambda の組み合わせでは、Parquet は複数レコードをまとめた列指向ファイルであるため 1 メッセージごとに書き出すと極端に小さいファイルが大量発生して Athena の性能が劣化し、バッファリングと集約のロジックをすべて自作する必要があります。
データレイクのクエリ性能とスキャン量の最適化
全国展開する小売チェーンの分析基盤では、POS ログを 1 日あたり約 3 TB、gzip 圧縮した CSV ファイルとして Amazon S3 の単一プレフィックス配下に蓄積しています。アナリストは Amazon Athena で分析していますが、1 クエリに数十分かかり、スキャンしたデータ量に応じた課金も膨らんでいます。実際のクエリの大半は「特定の日付範囲」の「特定の店舗」について「売上金額など数列だけ」を集計するものです。運用負荷を大きく増やさずにクエリ性能とコストを改善する対策を 2 つ選択してください。
複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: A、B）
Amazon Athena は S3 上のデータを直接スキャンして課金する仕組みのため、性能とコストはどちらも「読まずに済むデータをどれだけ増やせるか」で決まります。これを実現する二本柱が、列指向フォーマットへの変換とパーティショニングです。A の Apache Parquet は列単位でデータを格納し列ごとに圧縮するため、数列だけを集計するクエリでは不要な列を物理的に読み飛ばせ、統計情報による述語プッシュダウンも効きます。B のパーティショニングは、日付や地域を S3 のプレフィックス階層に埋め込んで Glue Data Catalog に登録することで、WHERE 句で指定された日付範囲や店舗地域に該当するプレフィックスだけを読む「パーティションプルーニング」を可能にします。この 2 つを併用すると、スキャン量が桁違いに減り、実行時間と課金の両方が改善します。C のクエリ結果の再利用は、まったく同じ SQL を繰り返す場合にのみ効く限定的な最適化であり、日付や店舗を変えながら探索するアナリストの利用形態では大半のクエリが対象外となるため、根本改善にはなりません。D の S3 Standard-IA への変更は保管コストのみに作用し、Athena のスキャン量課金やクエリ時間は変わらないうえ、頻繁なアクセスでは取り出しリクエスト料金がかさむ可能性があります。E はファイルを結合しても列指向でもパーティション化でもないためスキャン量は減らず、S3 Transfer Acceleration はインターネット経由のアップロード高速化機能であって、AWS 内部からのクエリ性能とは無関係です。