ステップ4：データ分析クエリの実行 - Amazon Athena

今回のステップの概要とデータ分析パイプラインとの関連について

このステップでは、ステップ3でGlue Data Catalogに登録したデータを、Amazon Athenaを使用してSQLクエリで分析します。具体的には、標準的なSQLクエリを使って、データの集計、フィルタリング、結合などの分析処理を実行します。

データ分析パイプラインにとって、Amazon Athenaは「データを調査する賢い調査員」のような役割を果たします。巨大な図書館（S3）の中から必要な情報を素早く見つけ出し、質問（SQLクエリ）に答えてくれるようなものです。サーバーを用意する必要がなく、必要な時だけ働いてくれます。また、SQLという標準的な言語を使うため、データベースの知識があれば、すぐに使い始めることができます。

このステップで学ぶこと

Amazon Athenaの概念と使用方法
SQLクエリによるデータ分析の実行方法
パーティショニングを活用した効率的なクエリの書き方
クエリ結果の確認方法
コスト最適化のテクニック

リソースの関わりと構成説明

ステップ4で使用するリソースは、データ分析パイプラインのデータ分析機能を実現するものです。それぞれのリソースがデータ分析パイプラインにどのように関わるのか、なぜ必要なのか、メリットとデメリットを説明します。

Amazon Athenaとデータ分析パイプラインの関わり

Amazon Athenaは、S3に保存されたデータをSQLクエリで分析するサーバーレスなクエリサービスです。

なぜ必要なのか？

データ分析において、S3に保存された大量のデータを分析する必要があります。しかし、従来のデータベースでは、大量のデータを扱うことが困難です。Athenaにより、サーバーを構築・運用することなく、標準SQLを使ってS3のデータを直接分析できます。例えるなら、図書館の調査員のようなもので、必要な情報を素早く見つけ出し、質問に答えてくれます。

このリソースがあることで得られるメリット：

サーバーレス運用：サーバーを構築・運用する必要がなく、必要な時だけ使用できます（例：サーバーの構築・運用に数週間かかるが、Athenaは数分で使用開始可能）
標準SQLの使用：データベースの知識があれば、すぐに使い始めることができます（例：PostgreSQLやMySQLのSQL知識をそのまま活用可能）
スケーラビリティ：データ量が増加しても、自動的にスケーリングされるため、対応が容易です（例：1TBのデータも1PBのデータも同じように分析可能）
コスト効率：使用量に応じた従量課金のため、使用しない時はコストがかかりません（例：月に数回しかクエリを実行しない場合、従来のデータベースサーバー（月額数万円）と比較して大幅にコスト削減）
複数のデータ形式に対応：JSON、CSV、Parquet、ORCなどの形式に対応しているため、データ形式を変換する必要がありません

このリソースがない場合の問題点：

サーバー構築・運用の負担：自前でクエリエンジン（Apache HiveやPrestoなど）を構築・運用する必要があり、数週間から数ヶ月かかります
固定コストの発生：サーバーを24時間365日稼働させる必要があり、使用しない時でもコストがかかります（例：月額10万円のサーバーを維持する必要がある）
スケーリングの困難：データ量が増加した場合、サーバーを手動でスケールアップする必要があり、対応が遅れます
パフォーマンスチューニングの複雑さ：クエリのパフォーマンスを最適化するには、専門知識が必要で、時間がかかります
データ形式の制約：特定のデータ形式にしか対応していない場合、データ形式を変換する必要があり、時間とコストがかかります

SQLクエリとデータ分析パイプラインの関わり

SQLクエリは、データを分析するための標準的な言語です。SELECT、WHERE、GROUP BY、JOINなどのSQL構文を使って、データの集計、フィルタリング、結合などの分析処理を実行できます。

なぜ必要なのか？

データ分析において、データの集計、フィルタリング、結合などの処理が必要です。SQLは、これらの処理を標準的な構文で記述できるため、データ分析の効率が向上します。例えるなら、図書館の調査員に「2024年1月のアクセスログを集計して」と依頼するようなものです。

このリソースがあることで得られるメリット：

標準的な構文：SQLは標準的な構文のため、学習コストが低く、多くのエンジニアが使用できます
柔軟な分析：SELECT、WHERE、GROUP BY、JOINなどの構文を組み合わせることで、様々な分析が可能です（例：日別のイベント数を集計、カテゴリ別の売上を集計、ユーザー別の行動分析など）
再利用性：一度作成したSQLクエリは、他のデータセットでも再利用できます
可読性：SQLクエリは読みやすく、他のエンジニアが理解しやすいです

このリソースがない場合の問題点：

分析の困難：プログラミング言語（Python、Javaなど）でデータ分析を行う必要があり、コードが複雑になります（例：SQLで1行で書ける集計処理が、Pythonで数十行のコードになる）
学習コストの増大：各プログラミング言語のデータ分析ライブラリを学習する必要があり、時間がかかります
コードの保守性の低下：複雑なコードは保守が困難で、エラーが発生しやすくなります
分析の非効率：同じ分析を繰り返す場合、毎回コードを書く必要があり、時間がかかります

パーティショニングとクエリパフォーマンスの関わり

パーティショニングを活用することで、必要なデータだけを効率的に読み取ることができ、クエリの実行時間とコストを削減できます。

なぜ必要なのか？

データ分析において、全データを読み取る必要はなく、特定の期間やカテゴリのデータだけを分析することが多いです。パーティショニングにより、必要なデータだけを効率的に読み取ることができます。例えるなら、図書館で必要な分野の本だけを探すのと同じで、全館を検索する必要がなく、効率的に情報を見つけられます。

このリソースがあることで得られるメリット：

クエリパフォーマンスの向上：必要なデータだけを読み取るため、クエリの実行時間が大幅に短縮されます（例：全データを読み取る場合10分かかるクエリが、パーティションフィルタを使用すると1分で完了）
コストの削減：読み取るデータ量が減るため、Athenaのスキャンコストが削減されます（例：1TBのデータから100GBだけを読み取る場合、コストが90%削減。1TBスキャンで約5ドルかかるが、100GBスキャンで約0.5ドルで済む）
リソースの効率化：不要なデータを読み取らないため、ネットワーク帯域やCPUリソースが効率的に使用されます

このリソースがない場合の問題点：

クエリの遅延：全データをスキャンする必要があるため、クエリの実行時間が長くなります（例：1年間のデータを分析する場合、数時間かかる可能性がある）
コストの増大：全データをスキャンするため、Athenaのスキャンコストが高くなります（例：1TBのデータを毎回スキャンする場合、1回のクエリで約5ドルかかるが、パーティションフィルタを使用すると約0.5ドルで済む）
リソースの浪費：不要なデータも読み取るため、ネットワーク帯域やCPUリソースが無駄に消費されます
分析の制約：データ量が増加すると、クエリの実行時間が長くなり、実用的な分析ができなくなります

実際の手順

実際の手順では、たくさんの設定値を入力することになります。本文中に設定値が指定されていない場合は、デフォルト値のまま作業を進めてください。

1. Athenaの基本設定

AthenaでS3のデータを分析するための基本設定を行います。

Note

AWSでの役割

サーバーレスなインタラクティブクエリサービスです。

特徴：

サーバーの構築・運用が不要
標準SQL（ANSI SQL）を使用
使用量に応じた従量課金（スキャンしたデータ量に応じて課金）
Glue Data Catalogと統合
複数のデータ形式に対応（JSON、CSV、Parquet、ORCなど）

オンプレミスでの対応

オンプレミス環境では「Apache HiveやPresto」が対応します。

自前でクエリエンジンを構築・運用する必要がある
クラスター管理やパフォーマンスチューニングが複雑
スケーリングが困難

1-1. Athenaコンソールへのアクセス

AWSマネジメントコンソールにログインします
検索バーに「Athena」と入力し、Amazon Athenaを選択します
「Athena コンソールでデータをクエリする」のチェックを選択し、クエリエディタを起動します

1-2. クエリ結果の保存場所の設定

「クエリ設定」タブを選択します
Query result locationで「Browse S3」をクリックします
ステップ2で作成したS3バケット「data-analysis-lake-（あなたのアカウントID）」を選択します
フォルダパスに「/athena-query-results/」と追記します
「Save」ボタンをクリックします

Tip

【解説】クエリ結果の保存場所

Athenaは、クエリの実行結果をS3に保存します。クエリ結果の保存場所を事前に設定しておく必要があります。クエリ結果は、後で確認したり、他のツールで可視化したりするために使用できます。

クエリ結果の保存場所は、プロジェクトごとに分けて管理することをおすすめします。例えば、「athena-query-results/」というフォルダを作成し、その中にクエリ結果を保存します。

クエリ結果は、自動的に削除されないため、定期的にクリーンアップするか、ライフサイクルポリシーを設定して自動削除することをおすすめします。

2. データベースとテーブルの選択

Athenaでクエリを実行する前に、分析対象のデータベースとテーブルを選択します。

2-1. データベースの選択

「エディタ」タブへ移動し、データの部分でステップ3で作成した「data_analysis_db」を選択します
データベースを選択すると、そのデータベースに含まれるテーブルが表示されます

2-2. テーブルの確認

テーブル一覧から、ステップ3でCrawlerが作成したテーブルを確認します
テーブル名をクリックすると、テーブルのスキーマ（列の定義）が表示されます

Tip

【解説】テーブルスキーマの確認

テーブルのスキーマを確認することで、どのような列が利用可能か、各列のデータ型は何かを理解できます。これにより、適切なSQLクエリを書くことができます。

スキーマには、以下の情報が含まれます：

列名：データの属性名（例：user_id、event_type、timestamp）
データ型：列のデータ型（例：string、int、double、timestamp）
パーティション情報：パーティションキー（例：year、month、day）

クエリを書く前に、必ずテーブルのスキーマを確認することをおすすめします。

3. SQLクエリの実行

標準的なSQLクエリを使って、データを分析します。

3-1. 基本的なSELECTクエリ

クエリエディタに以下のSQLクエリを入力します：


SELECT *
FROM data_analysis_db.テーブル名
LIMIT 10;

Tip

【解説】LIMIT句の使用

LIMIT句を使用することで、クエリ結果の行数を制限できます。データの確認やテストを行う際は、LIMIT句を使用して、少量のデータだけを取得することをおすすめします。これにより、クエリの実行時間とコストを削減できます。

大量のデータを取得する場合は、LIMIT句を外すか、大きな値を指定します。ただし、クエリ結果が大きすぎる場合は、エラーが発生する可能性があるため、注意が必要です。

「Run」ボタンをクリックします
クエリの実行が完了するまで待ちます（通常、数秒から数分かかります）
「Results」タブで、クエリ結果を確認します

Warning

実行時の注意点：エラーが発生した場合

クエリ実行時に「HIVE_CURSOR_ERROR: Failed to read file」というエラーが表示される場合があります。この場合、以下の点を確認してください：

S3バケットにファイルが存在するか：S3コンソールで指定されたパスにファイルがあるか確認します
パーティションフィルタが正しいか：WHERE句でyear = '2024' AND month = '01' AND day = '15'のように、パーティションキーを正しく指定しているか確認します
Glue Crawlerを再実行：テーブル定義が古い場合は、ステップ3でGlue Crawlerを再実行してテーブル定義を更新します
S3へのアクセス権限：Athenaの実行ロールにS3バケットへの読み取り権限（s3:GetObject）があるか確認します

3-2. データの集計クエリ

データを集計して、統計情報を取得します。

クエリエディタに以下のSQLクエリを入力します：


SELECT
    event_type,
    COUNT(*) as event_count
FROM data_analysis_db.テーブル名
GROUP BY event_type
ORDER BY event_count DESC;

このクエリは、イベントタイプごとのイベント数を集計し、多い順に並べ替えます。

「Run」ボタンをクリックします
クエリ結果を確認します

Tip

【解説】GROUP BY句の使用

GROUP BY句を使用することで、データをグループ化して集計できます。例えば、イベントタイプごと、日付ごと、ユーザーごとなど、様々な属性でグループ化して集計できます。

GROUP BY句と一緒に、COUNT、SUM、AVG、MAX、MINなどの集計関数を使用することで、統計情報を取得できます。これにより、データの傾向やパターンを把握できます。

3-3. パーティションフィルタの使用

パーティションフィルタを使用して、必要なデータだけを効率的に読み取ります。

クエリエディタに以下のSQLクエリを入力します：


SELECT
    user_id,
    event_type,
    timestamp
FROM data_analysis_db.テーブル名
WHERE year = '2024'
  AND month = '01'
  AND day = '15'
LIMIT 100;

このクエリは、2024年1月15日のデータだけを取得します。

Tip

【解説】パーティションフィルタの重要性

パーティションフィルタを使用することで、必要なデータだけを効率的に読み取ることができ、クエリの実行時間とコストを大幅に削減できます。

パーティションフィルタを使用しない場合、Athenaはすべてのパーティションをスキャンするため、大量のデータを読み取ることになり、クエリの実行時間が長くなり、コストも高くなります。

パーティションフィルタを使用する場合、WHERE句でパーティションキー（year、month、dayなど）を指定します。これにより、指定したパーティションだけをスキャンするため、クエリの実行時間とコストを削減できます。

「Run」ボタンをクリックします
クエリ結果を確認します

3-4. 日付範囲でのフィルタリング

日付範囲を指定して、特定の期間のデータを分析します。

クエリエディタに以下のSQLクエリを入力します：


SELECT
    DATE(timestamp) as date,
    COUNT(*) as daily_count
FROM data_analysis_db.テーブル名
WHERE year = '2024'
  AND month = '01'
GROUP BY DATE(timestamp)
ORDER BY date;

このクエリは、2024年1月の日別のイベント数を集計します。

「Run」ボタンをクリックします
クエリ結果を確認します

4. クエリ結果の確認

クエリ実行後、結果は自動的にS3に保存されます。また、CSVファイルとしてダウンロードすることもできます。

4-1. S3バケットでのクエリ結果の確認

S3コンソールで、ステップ2で作成したS3バケット「data-analysis-lake-（あなたのアカウントID）」を開きます
「athena-query-results/」フォルダを確認します（ステップ1-2で設定したクエリ結果の保存場所）
クエリ実行ごとにフォルダが作成され、その中にクエリ結果が保存されていることを確認します

4-2. CSVファイルのダウンロード

クエリ結果は、Athenaの「Results」タブからCSVファイルとしてダウンロードできます。結果が100MB以下の場合、直接ダウンロードできます。結果が大きい場合は、S3バケットから直接ダウンロードしてください。

このステップで何をしたのか

このステップでは、データ分析パイプラインのデータ分析機能を実現しました。具体的には、Amazon Athenaを使用して、Glue Data Catalogに登録されたデータをSQLクエリで分析しました。また、パーティションフィルタを活用して、効率的にクエリを実行する方法も学びました。

データ分析パイプラインでどのような影響があるのか

この構成により、データ分析パイプラインは、S3に保存されたデータをSQLクエリで分析できるようになりました。標準的なSQL構文を使うため、データベースの知識があれば、すぐに使い始めることができます。また、パーティションフィルタを活用することで、必要なデータだけを効率的に読み取ることができ、クエリの実行時間とコストを削減できます。これは、図書館の調査員が必要な情報を素早く見つけ出し、質問に答えてくれるようなものです。

技術比較まとめ表

技術領域	AWS	オンプレミス
データ分析	Amazon Athena サーバーレス、標準SQL、使用量に応じた従量課金	Apache Hive/Presto 自前でクエリエンジンを構築・運用、固定コスト
クエリ言語	標準SQL（ANSI SQL）データベースの知識があればすぐに使用可能	SQL（HiveQL、Presto SQLなど）ツールごとに異なるSQL方言
コスト構造	スキャンしたデータ量に応じた従量課金使用しない時はコストがかからない	固定コスト（サーバー、ストレージ）使用しない時でもコストがかかる

学習において重要な技術的違い

1. サーバーレスとセルフマネージドの違い

AWS：サーバーの構築・運用が不要。必要な時だけ使用し、使用量に応じて課金
オンプレミス：自前でクエリエンジンを構築・運用。固定コストが発生

2. コスト構造

AWS：スキャンしたデータ量に応じた従量課金。使用しない時はコストがかからない
オンプレミス：固定コスト（サーバー、ストレージ）。使用しない時でもコストがかかる

3. スケーラビリティ

AWS：自動的にスケーリング。データ量が増加しても対応可能
オンプレミス：手動でスケーリング。データ量が増加すると対応が困難

4. パフォーマンス最適化

AWS：パーティションフィルタ、データ形式の最適化（Parquet、ORC）により、パフォーマンスとコストを最適化
オンプレミス：手動でパフォーマンスチューニング。最適化が複雑

実践チェック：画面キャプチャで証明しよう

下記のチェック項目について、実際にAWSマネジメントコンソールで設定ができていることを確認し、各項目ごとに該当画面のスクリーンショットを撮影して提出してください。

Athenaのクエリ結果の保存場所がS3バケット「data-analysis-lake-（あなたのアカウントID）/athena-query-results/」に設定されている
データベース「data_analysis_db」が選択されている
基本的なSELECTクエリが正常に実行され、データが表示されている
データの集計クエリ（GROUP BY）が正常に実行され、集計結果が表示されている
パーティションフィルタを使用したクエリが正常に実行されている
S3バケットの「athena-query-results/」フォルダにクエリ結果が保存されていることを確認している

提出方法： 各項目ごとにスクリーンショットを撮影し、まとめて提出してください。ファイル名やコメントで「どの項目か」が分かるようにしてください。

構成図による理解度チェック

このステップで使用したリソースを、データ分析パイプラインの構成図に追加しましょう。

なぜ構成図を更新するのか？

構成図を更新することで、データ分析パイプラインの全体像を視覚的に理解できるようになります。また、各リソースの関係性やデータの流れを明確にすることで、システムの動作を深く理解することができます。

クエリの流れの理解: AthenaがGlue Data Catalogを参照し、S3からデータを読み取って分析する流れを視覚的に把握できる
リソース間の関係性: Athena、Glue Data Catalog、S3がどのように連携しているかを理解できる
システム全体の把握: パイプライン全体の構造を一目で理解できる

構成図の書き方

ステップ3で作成した構成図をベースに、以下のリソースを追加してみましょう。

Amazon Athena: 図の右側（分析側）に配置。データを分析する場所として表現
クエリの流れ: AthenaからGlue Data Catalogへの矢印（メタデータ参照）、Glue Data CatalogからS3への矢印（データ読み取り）を描く
クエリ結果: AthenaからS3への矢印（クエリ結果の保存）を描く

💡 ヒント: 構成図では、データの流れ、メタデータの流れ、クエリの流れを区別して表現すると理解しやすくなります。また、各リソースの役割を短い説明文で補足すると、より分かりやすくなります。

理解度チェック：なぜ？を考えてみよう

AWSの各リソースや設計には、必ず”理由”や”目的”があります。下記の「なぜ？」という問いに自分なりの言葉で答えてみましょう。仕組みや設計意図を自分で説明できることが、真の理解につながります。ぜひ、単なる暗記ではなく「なぜそうなっているのか？」を意識して考えてみてください。

Q. なぜAthenaはサーバーレスなのでしょうか？サーバーレスにすることで、どのようなメリットが得られますか？

Q. なぜパーティションフィルタを使用することが重要なのでしょうか？パーティションフィルタを使用しない場合、どのような問題が発生しますか？

Q. なぜAthenaはスキャンしたデータ量に応じて課金されるのでしょうか？この課金モデルにより、どのような効果が得られますか？

今回のステップで利用したAWSサービス名一覧

Amazon Athena：サーバーレスなインタラクティブクエリサービス
AWS Glue Data Catalog：メタデータリポジトリ（ステップ3で作成）