AWS ソリューションアーキテクト – アソシエイト学習サイト CP 学習サイトへ戻る

分析サービス（Athena / Glue / EMR / QuickSight 等）

AWS の分析サービスは、S3 に貯めたデータを「集める → 整える → 問い合わせる → 見せる」という流れの中で役割を分け合っています。SAA では、要件の言い回しから「どの段階の、どのサービスか」を選ぶ問題が出ます。特に Athena・Glue・EMR・Lake Formation・QuickSight（現在の名称は Amazon Quick の一部の Quick Sight）の使い分けが中心です。

ひとことで言うと: S3 をデータの置き場（データレイク）にして、変換は Glue、SQL での検索は Athena、大規模な分散処理は EMR、グラフ化は QuickSight、権限の管理は Lake Formation が受け持ちます。

たとえるなら、S3 は「倉庫」、Glue は「荷物を仕分けて棚札（カタログ）を付ける係」、Athena は「棚札を見て必要な箱だけ探す検索係」、QuickSight は「結果を報告書のグラフにする係」です。

このページで押さえる論点

データレイクと分析の流れ

データレイクとは、形式をそろえる前の生データも含めて、さまざまなデータを 1 か所にまとめて置いておく場所のことです。AWS では、安くて容量の上限を気にしなくてよい Amazon S3 をデータレイクにするのが基本です。データを置いたあと、必要に応じて形式を整え、分析サービスで読みます。

分析の流れは、次の 4 段階で考えると整理しやすくなります。試験の問題文も「どの段階の困りごとか」を読み取れば、答えのサービスが絞れます。

段階やること主なサービス
① 取り込みデータを S3 などに集める。一定間隔でまとめて送るか、絶え間なく流し込むか（ストリーミング）を決めるKinesis・Data Firehose（ストリーミング）、DataSync など（まとめて転送）
② 変換・カタログ化形式を変える（CSV → Parquet など）、不要なデータを除く、どこに何のデータがあるかの目録（カタログ）を作るAWS Glue（クローラー・データカタログ・ETL ジョブ）
③ 問い合わせ・処理SQL で検索する、大量データを分散処理するAmazon Athena、Amazon EMR、Amazon Redshift
④ 可視化結果をグラフやダッシュボードにして共有するAmazon QuickSight

この 4 段階をまたいで「誰がどのデータを見てよいか」を管理するのが AWS Lake Formation です。取り込みのうちストリーミング（Kinesis）や、データウェアハウス（Redshift）はそれぞれ別ページで詳しく扱います。

ETL は Extract（取り出す）・Transform（変換する）・Load（書き込む）の頭文字で、「データを取り出して形を整え、分析しやすい場所に入れ直す処理」のことです。

Amazon Athena: S3 のデータを SQL で検索

Athena は、S3 に置いたデータを標準 SQL でそのまま検索できるサーバーレスのサービスです。サーバーやデータベースを用意する必要がなく、データを別の場所に読み込む（ロードする）必要もありません。クエリを投げると、裏側で自動的に並列処理され、結果が数秒で返ります。

料金は、実行したクエリがスキャン（読み取り）したデータ量で決まります。サーバーを動かし続ける費用はかからないので、「たまにしか分析しない」「アドホック（その場限り）なクエリを実行したい」という要件に向きます。

スキャン量が料金に直結するため、次の工夫でコストと時間を減らせます。試験で「Athena のコストを下げたい」と問われたら、この 3 つが答えの候補です。

工夫なぜ安く・速くなるか
列指向形式（Apache Parquet・ORC）に変換必要な列だけを読めるので、使わない列をスキャンしない
圧縮するファイルが小さくなった分だけスキャン量が減る
パーティション分割（例: 年/月/日ごとのフォルダ）WHERE 句で絞った期間のフォルダだけを読むので、関係のないデータを読まない

列指向形式とは、データを「行ごと」ではなく「列ごと」にまとめて保存する形式です。CSV は行ごとに保存するので、1 列だけ欲しくても全部の列を読むことになります。CSV から Parquet への変換には、次の Glue の ETL ジョブを使うのが定番です。

Athena は、テーブルの定義（どの S3 の場所に、どんな列のデータがあるか）を AWS Glue データカタログから読みます。そのため、Glue と組み合わせて使うのが基本形です。

AWS Glue: カタログ化と ETL

AWS Glue は、分析や機械学習のためにデータを探し、整え、つなぎ合わせるサーバーレスのデータ統合サービスです。負荷に合わせて自動でスケールするので、ETL 用のサーバーを管理する必要はありません。主な部品は次のとおりです。

部品役割
データカタログデータの場所と構造（スキーマ）の目録。Athena・EMR・Redshift Spectrum・Lake Formation が共通で使う
クローラーS3 などのデータを自動で調べ、スキーマを推測してデータカタログにテーブルを登録する
ETL ジョブApache Spark（または Ray）でデータを変換する。CSV → Parquet の変換や、データの結合・クレンジング（汚れたデータの修正）に使う
ジョブのブックマーク処理済みのデータを記録し、次の実行では新しく増えた分だけを処理する（同じデータを二重に処理しない）
トリガー・ワークフロースケジュールやイベントでジョブを自動実行し、複数のクローラーとジョブをつなげる
Glue Studio・DataBrewGlue Studio は画面上で ETL の流れを組み立てる機能。DataBrew はコードを書かずにデータを整える（前処理する）サービス

試験では「毎日 S3 に届く CSV を、運用の手間をかけずに Parquet に変換して Athena で分析したい」のような要件がよく出ます。答えは「Glue のクローラーでカタログ化し、Glue の ETL ジョブで Parquet に変換」です。EC2 で変換スクリプトを動かす選択肢は、サーバーの管理が必要になるので「運用の手間」の点で劣ります。

Amazon EMR: ビッグデータ用のクラスター

Amazon EMR は、Apache Hadoop や Apache Spark などのビッグデータ用フレームワークを動かすマネージドなクラスターのサービスです。クラスターとは、複数のサーバー（ノード）をまとめて 1 つの大きな計算機として使う仕組みです。大量のデータを多数のノードに分けて並列に処理します。

Glue もサーバーレスで Spark を動かせますが、EMR はクラスターの構成（ノードの種類や台数、使うフレームワークとそのバージョン、細かな設定）を自分で決められる点が違います。「既存の Hadoop / Spark の処理をそのまま AWS へ移したい」「設定を細かく調整したい」なら EMR、「サーバーの管理をせずに ETL したい」なら Glue、と覚えます。

EMR のクラスターには 3 種類のノードがあります。スポットインスタンス（EC2 の空き容量を安く使えるが、途中で中断されることがある購入方法）をどこに使うかがよく問われます。

ノード役割HDFS にデータを保存するかスポットインスタンス
プライマリノードクラスター全体を管理し、ジョブの状態を追跡する管理用のサービスを動かす止まるとクラスター全体に影響するので向かない
コアノードデータの保存（HDFS）と計算の両方を行う保存する止まるとデータを失うおそれがあるので慎重に
タスクノード計算だけを行い、処理能力を足す保存しない向いている（止まってもジョブが失敗しないよう EMR が調整する）

HDFS（Hadoop 分散ファイルシステム）は、クラスターのノードのディスクにデータを分けて保存する仕組みです。「処理能力を安く一時的に増やしたい」という要件には、タスクノードをスポットインスタンスで追加するのが定番の答えです。

AWS Lake Formation: データレイクの保護

AWS Lake Formation は、データレイクを一元的に管理・保護し、共有するためのサービスです。メタデータ（データについての情報）は Glue データカタログに置き、その上で「誰がどのデータベース・テーブル・列・行を見てよいか」を Lake Formation で決めます。

IAM ポリシーや S3 のバケットポリシーでも S3 へのアクセスは制御できますが、制御できるのは基本的に「バケットやオブジェクト（ファイル）」の単位です。「テーブルの特定の列だけ隠したい」という要件は、Lake Formation を選びます。

Amazon QuickSight: ダッシュボードで可視化

Amazon QuickSight は、データをグラフやダッシュボードにして共有する BI（ビジネスインテリジェンス）サービスです。サーバーを用意する必要はありません。Athena・Redshift・RDS・S3 など多くのデータソースに接続できます。現在は、AI 機能をまとめた Amazon Quick の中の「Quick Sight」という名前になっており、SAA-C03 の試験ガイドにも「Amazon Quick」と書かれています。問題文に「QuickSight」と「Quick」のどちらが出ても、同じ可視化のサービスと考えて構いません。

SPICE（Super-fast, Parallel, In-memory Calculation Engine）は QuickSight のインメモリ（メモリ上で計算する）エンジンです。データを SPICE に取り込んでおくと、グラフを開くたびに元のデータソースへ問い合わせる必要がなく、表示が速くなります。取り込んだデータは何度使ってもデータソース側に追加の問い合わせ料金がかからないので、「Athena に何度も同じクエリが飛んでコストがかさむ」という問題の対策にもなります。

ダッシュボードは、自社のアプリや Web サイトに埋め込むこともできます。「経営層に売上のダッシュボードを見せたい」「データを可視化したい」という言い回しが出たら QuickSight を選びます。

要件からサービスを選ぶ

下のフローチャートで、要件から分析サービスを選ぶ練習をしてみましょう。

比較・選択フローチャート

質問に答えて分析サービスを選ぶ

やりたいことを思い浮かべて「はい / いいえ」で答えてください。答えた経路が上から順に表示されます。

    ※簡略化しています: 実際の構成では、Glue でカタログ化 → Athena で検索 → QuickSight で可視化、のように複数のサービスを組み合わせます。フローでは「いちばん中心になるサービス」を 1 つだけ示しています。ストリーミングの取り込み（Kinesis）は分岐に含めていません。

    サービスひとことでサーバー管理
    Amazon AthenaS3 のデータに SQL で問い合わせる不要（サーバーレス）
    AWS Glueカタログ化と ETL（形式変換）不要（サーバーレス）
    Amazon EMRHadoop / Spark のクラスターで大規模処理クラスター構成を自分で決める
    AWS Lake Formationデータレイクの権限を一元管理（列・行単位）不要
    Amazon QuickSightダッシュボードで可視化・共有不要
    Amazon Redshiftデータウェアハウス。大量データの複雑な集計を繰り返し実行別ページで扱う
    Amazon Kinesis・Data Firehoseストリーミングデータの取り込み別ページで扱う

    問題文のキーワード → 選ぶべき答え

    問題文の言い回し答えと理由
    「S3 のログをサーバーを管理せずに SQL で分析」「アドホックなクエリ」Amazon Athena。サーバーレスで S3 を直接検索する
    「Athena のクエリのコストを下げたい」「スキャン量を減らしたい」Parquet などの列指向形式・圧縮・パーティション分割
    「CSV を Parquet に変換」「運用負荷の少ない ETL」AWS Glue の ETL ジョブ。サーバーレスで Spark を動かす
    「S3 のデータのスキーマを自動で見つけてカタログ化」AWS Glue クローラー（データカタログに登録）
    「前回処理したデータを再処理しない」Glue のジョブのブックマーク
    「既存の Hadoop / Spark ジョブを移行」「クラスターの設定を細かく調整」Amazon EMR
    「EMR の処理能力を安く一時的に増やす」タスクノードをスポットインスタンスで追加。HDFS を持たないので中断されてもデータを失わない
    「データレイクの特定の列・行だけを見せたい」「分析サービス共通の権限管理」AWS Lake Formation
    「ダッシュボードで可視化」「経営層にグラフを共有」「BI」Amazon QuickSight（Amazon Quick）
    「ダッシュボードの表示を速くしたい」「同じクエリが何度も実行される」SPICE にデータを取り込む

    引っかけポイント

    まとめ: SAA 試験で押さえるポイント

    確認問題

    参考リンク

    AWS 公式ドキュメント（外部サイトが開きます）。