Skip to Content

ステップ3:データカタログとETL処理 - AWS Glue

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

このステップでは、ステップ2でS3に保存したデータの構造を自動的に理解し、分析しやすい形に変換するためのAWS Glueを設定します。具体的には、Glue Crawlerを使用してデータのスキーマを自動検出し、Glue Data Catalogに登録します。

データ分析パイプラインにとって、AWS Glueは「データの翻訳者兼整理係」のような役割を果たします。様々な言語で書かれた書類(データ)を読み取り、統一された形式に翻訳し、整理してカタログに登録するようなものです。これにより、後でAthenaを使ってSQLクエリでデータを分析する際に、データの構造を理解しやすくなり、効率的にクエリを実行できるようになります。

このステップで学ぶこと

  • AWS Glueの概念とData Catalogの理解
  • Glue Crawlerによるデータスキーマの自動検出
  • データベースとテーブルの作成方法
  • パーティションの自動認識と管理

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

ステップ3で作成するリソースは、データ分析パイプラインのデータカタログ機能を構築するものです。それぞれのリソースがデータ分析パイプラインにどのように関わるのか、なぜ必要なのか、メリットとデメリットを説明します。

AWS Glue Data Catalogとデータ分析パイプラインの関わり

AWS Glue Data Catalogは、S3に保存されたデータの構造(スキーマ)を管理するメタデータリポジトリです。

なぜ必要なのか?

S3に保存されたデータファイル(JSON、CSVなど)を見ただけでは、そのデータがどのような構造になっているか、どの列があるか、どのようなデータ型かを知ることはできません。データ分析ツール(Athenaなど)がデータを読み取るには、データの構造を理解する必要があります。例えるなら、図書館の目録カードのようなもので、どのデータがどこにあるか、どのような構造になっているかを記録する必要があります。

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

  • SQL分析の実現:データの構造を理解することで、Athenaなどの分析ツールがSQLクエリを実行できるようになります(例:SELECT user_id, COUNT(*) FROM events WHERE event_type = 'purchase'のようなクエリが実行可能)
  • データ探索の容易さ:データの構造を事前に確認できるため、どのような分析が可能かを把握できます
  • スキーマの一元管理:複数の分析ツールが同じスキーマ定義を参照できるため、データの整合性が保たれます
  • 自動スキーマ検出:Glue Crawlerにより、データの構造を自動的に検出してカタログに登録できるため、手動でスキーマを定義する必要がありません

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

  • SQL分析の困難:データの構造が分からないため、SQLクエリを書くことができません(例:どの列があるか、どのようなデータ型かを手動で確認する必要がある)
  • データ探索の困難:データファイルを直接開いて構造を確認する必要があり、時間がかかります(例:1TBのデータファイルを開いて構造を確認するのは非現実的)
  • スキーマ管理の複雑さ:各分析ツールで個別にスキーマを定義する必要があり、スキーマの不整合が発生する可能性があります
  • 手動スキーマ定義の負担:データの構造が変更されるたびに、手動でスキーマを更新する必要があり、運用負担が大きくなります
Tip

【解説】メタデータとは何か?

メタデータは「データに関するデータ」、つまりデータそのものではなく、データの情報を表すものです。例えるなら、図書館の本(データ)に対して、目録カード(メタデータ)が存在するようなものです。

メタデータの具体例:

  • データの場所:S3バケットのパス(例:s3://data-analysis-lake/year=2024/month=01/day=15/
  • データの構造:テーブル名、列名、データ型(例:user_idは文字列型、timestampは日時型)
  • データの形式:JSON、CSV、Parquetなどのファイル形式
  • パーティション情報:どのようなパーティション構造になっているか(例:year=2024/month=01/day=15

なぜメタデータが必要なのか?

S3に保存されたデータファイル(JSON、CSVなど)を見ただけでは、そのデータがどのような構造になっているか、どの列があるか、どのようなデータ型かを知ることはできません。メタデータを管理することで、Athenaなどの分析ツールが「このデータにはuser_idという列があり、文字列型だ」ということを理解し、SQLクエリを実行できるようになります。

例えるなら、本の内容(データ)を読む前に、目録カード(メタデータ)を見ることで「この本は小説で、300ページあり、著者は○○さんだ」という情報を素早く把握できるようなものです。メタデータがあることで、必要なデータを効率的に見つけ、分析することができます。

Glue Crawlerとデータ分析パイプラインの関わり

Glue Crawlerは、S3に保存されたデータを自動的にスキャンし、データの構造を検出してData Catalogに登録するツールです。

なぜ必要なのか?

S3に保存されたデータの構造を手動で確認し、スキーマを定義するのは時間がかかり、エラーが発生しやすい作業です。Crawlerにより、データの構造を自動的に検出してカタログに登録できるため、手動作業を削減できます。例えるなら、図書館の司書が新しい本を読み、その内容を目録カードに記録するようなものです。

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

  • 自動スキーマ検出:データの形式(JSON、CSV、Parquetなど)を自動的に認識し、スキーマを推測してテーブル定義を作成できます(例:JSONファイルをスキャンすると、各フィールドの型を自動的に検出)
  • パーティションの自動認識:パーティショニング構造(year=2024/month=01/day=15/)を自動的に認識し、パーティション情報をカタログに登録できます
  • スキーマ更新の自動化:データの構造が変更された場合、Crawlerを再実行することで、スキーマを自動的に更新できます
  • 運用の効率化:手動でスキーマを定義する必要がなく、運用負担を削減できます(例:100個のテーブルを手動で定義する場合、数日かかるが、Crawlerを使用すると数時間で完了)

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

  • 手動スキーマ定義の負担:データの構造を手動で確認し、スキーマを定義する必要があり、時間がかかります(例:1つのテーブルを定義するのに30分かかる場合、100個のテーブルで50時間かかる)
  • エラーの発生:手動でスキーマを定義するため、データ型の誤りや列名の誤りが発生する可能性があります
  • パーティション管理の困難:パーティション情報を手動で管理する必要があり、パーティションが追加されるたびに手動で更新する必要があります
  • スキーマ更新の遅延:データの構造が変更された場合、手動でスキーマを更新する必要があり、更新が遅れる可能性があります

Glue Databaseとデータ分析パイプラインの関わり

Glue Databaseは、関連するテーブルをグループ化するコンテナです。

なぜ必要なのか?

データ分析において、複数のテーブルを管理する必要があります。Databaseにより、関連するテーブルをグループ化することで、データの整理と管理が容易になります。例えるなら、図書館の書架のようなもので、関連する本(テーブル)を同じ場所にまとめて保管します。

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

  • データの整理:関連するテーブルを同じDatabaseにまとめることで、データの整理と管理が容易になります
  • アクセス制御:Database単位でアクセス制御を設定できるため、セキュリティ管理が容易になります
  • クエリの簡潔化:Database名を指定することで、テーブル名を簡潔に記述できます(例:data_analysis_db.eventsのように記述可能)

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

  • データ管理の困難:テーブルが散在し、どのテーブルが関連しているかを把握するのが困難になります
  • アクセス制御の複雑さ:テーブル単位でアクセス制御を設定する必要があり、管理が複雑になります

実際の手順

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

1. Glue Databaseの作成

Glue Databaseは、関連するテーブルをグループ化するコンテナです。まず、データ分析パイプライン用のデータベースを作成します。

Note

AWSでの役割

メタデータ管理サービスです。

特徴:

  • データの構造(スキーマ)を自動検出
  • 複数のデータソースからのメタデータを一元管理
  • Athena、EMR、Redshiftなどと統合
  • サーバーレスでスケーラブル

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

  1. AWSマネジメントコンソールにログインします
  2. 検索バーに「Glue」と入力し、AWS Glueを選択します
  3. 左側のナビゲーションペインから「Databases」を選択します
  4. 「Add database」ボタンをクリックします

1-2. データベースの作成

  1. Database nameに「data_analysis_db」と入力します
  2. Descriptionに「データ分析パイプライン用のデータベース」と入力します(オプション)
  3. 「Create database」ボタンをクリックします
Tip

【解説】データベース名の命名規則

Glue Database名には、小文字、数字、アンダースコア(_)のみを使用できます。大文字やハイフン(-)は使用できないため、注意が必要です。

データベース名は、プロジェクトや用途を表す名前にすることをおすすめします。例えば、「data_analysis_db」「analytics_db」「data_lake_db」などです。

2. Glue Crawlerの作成

Glue Crawlerは、S3に保存されたデータを自動的にスキャンし、データの構造を検出してData Catalogに登録するツールです。

2-1. Crawlerの作成開始

  1. 左側のナビゲーションペインから「Crawlers」を選択します
  2. 「Create crawler」ボタンをクリックします

2-2. Crawlerの基本設定

  1. Crawler nameに「data-analysis-crawler」と入力します
  2. Descriptionに「S3データレイクをスキャンしてData Catalogに登録するCrawler」と入力します(オプション)
  3. 「Next」ボタンをクリックします

2-3. データソースの設定

  1. Data sourceで「S3」を選択します
  2. Include pathに、ステップ2で作成したS3バケットのパスを入力します(例:s3://data-analysis-lake-あなたのアカウントID/
Tip

【解説】Include pathの設定

Include pathには、CrawlerがスキャンするS3のパスを指定します。パーティショニング構造を使用している場合、ルートパスを指定することで、すべてのパーティションを自動的に認識します。

例:

  • すべてのデータをスキャン:s3://bucket-name/
  • 特定の年のデータのみスキャン:s3://bucket-name/year=2024/
  • 特定の月のデータのみスキャン:s3://bucket-name/year=2024/month=01/

学習用途では、ルートパスを指定してすべてのデータをスキャンすることをおすすめします。

  1. 「Add a data source」ボタンをクリックします
  2. 「Next」ボタンをクリックします

2-4. IAMロールの設定

  1. IAM roleで「Create new IAM role」を選択します
  2. IAM role nameに「GlueCrawlerRole」と入力します
  3. 「Next」ボタンをクリックします
Tip

【解説】IAMロールの権限

Glue Crawlerは、S3のデータを読み取るために適切な権限が必要です。新しいIAMロールを作成する場合、Glueは自動的に必要な権限を付与します。

作成されるIAMロールには、以下の権限が含まれます:

  • S3バケットへの読み取り権限
  • Glue Data Catalogへの書き込み権限
  • CloudWatch Logsへの書き込み権限(ログ出力用)

本番環境では、最小権限の原則に従って、必要な権限のみを付与するカスタムIAMロールを作成することをおすすめします。

2-5. 出力の設定

  1. Target databaseで、ステップ2-1で作成した「data_analysis_db」を選択します
  2. Table name prefixは空欄のままにします(オプション:テーブル名にプレフィックスを付ける場合に使用)
Tip

【解説】テーブル名の自動生成

Crawlerは、S3のパス構造に基づいてテーブル名を自動生成します。パーティショニング構造を使用している場合、Crawlerは1つのテーブルと複数のパーティションを作成します。

テーブル名のプレフィックスを指定すると、すべてのテーブル名の前にプレフィックスが付加されます。例えば、プレフィックスに「analytics_」を指定すると、テーブル名が「analytics_table1」のようになります。

学習用途では、プレフィックスを指定しないことをおすすめします。本番環境では、プロジェクト名や環境名をプレフィックスとして使用することで、テーブルを整理できます。

  1. 「Next」ボタンをクリックします

2-6. Crawlerの確認と作成

  1. 設定内容を確認します
  2. 「Create crawler」ボタンをクリックします

3. Crawlerの実行

作成したCrawlerを実行して、S3のデータをスキャンし、Data Catalogにテーブルを登録します。

3-1. Crawlerの実行

  1. 「Crawlers」ページで、作成した「data-analysis-crawler」を選択します
  2. 「Run crawler」ボタンをクリックします
  3. Crawlerのステータスが「Running」から「Ready」に変わるまで待ちます(通常、数分かかります)
Tip

【解説】Crawlerの実行時間

Crawlerの実行時間は、スキャンするデータの量とファイル数によって異なります。少量のデータ(数MB)の場合は、数秒から1分程度で完了する可能性があります。大量のデータ(数GB以上)の場合は、数分から数十分かかる可能性があります。

Crawlerが何をしているから時間がかかるのか?

Crawlerは、データの構造(スキーマ)を検出するために、以下の処理を行います:

  1. S3バケット内のファイルをスキャン:指定したパス配下のすべてのファイルを探します
  2. 各ファイルのサンプルを読み取り:各ファイルの一部を読み取って、データの形式(JSON、CSV、Parquetなど)を判断します
  3. データ構造を推測:読み取ったサンプルから、列名やデータ型(文字列、数値、日時など)を推測します
  4. パーティション情報を認識:フォルダ構造(year=2024/month=01/day=15/など)からパーティション情報を抽出します
  5. Data Catalogに登録:検出した情報をメタデータとしてData Catalogに保存します

これらの処理をすべてのファイルに対して行うため、ファイル数が多い場合や、ファイルサイズが大きい場合は、実行時間が長くなる可能性があります。例えるなら、図書館の司書が新しい本を1冊ずつ読み、目録カードに記録していくようなもので、本の数が多ければ多いほど、時間がかかります。

3-2. Crawlerの実行結果の確認

  1. Crawlerのステータスが「Ready」になったら、Crawlerの詳細ページを開きます
  2. 「Runs」タブで、最新の実行結果を確認します
  3. 「Tables added」や「Partitions added」の数を確認します

4. テーブルの確認

Crawlerの実行が完了したら、Data Catalogに登録されたテーブルを確認します。

4-1. テーブル一覧の確認

  1. 左側のナビゲーションペインから「Tables」を選択します
  2. データベース「data_analysis_db」を選択します
  3. 作成されたテーブルを確認します

4-2. テーブルスキーマの確認

  1. テーブル名をクリックして、テーブルの詳細を確認します
  2. 「Schema」タブで、テーブルのスキーマ(列の定義)を確認します
  3. 「Partitions」タブで、パーティション情報を確認します
Tip

【解説】テーブルスキーマの自動検出

Crawlerは、データファイルのサンプルを読み取って、データの構造を自動的に検出します。JSON形式のデータの場合、Crawlerは各フィールドの型(string、int、doubleなど)を推測してスキーマを作成します。

スキーマが正しく検出されない場合や、スキーマを修正したい場合は、テーブルのスキーマを手動で編集することができます。ただし、学習用途では、Crawlerが自動検出したスキーマで十分です。

パーティショニング構造を使用している場合、Crawlerは自動的にパーティションキー(year、month、dayなど)を認識し、パーティション情報をData Catalogに登録します。

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

このステップでは、データ分析パイプラインのデータカタログ機能を構築しました。具体的には、AWS Glueを使用して、S3に保存されたデータの構造を自動的に検出し、Data Catalogに登録しました。これにより、後でAthenaを使ってSQLクエリでデータを分析する際に、データの構造を理解しやすくなり、効率的にクエリを実行できるようになりました。

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

この構成により、データ分析パイプラインは、S3に保存されたデータの構造を自動的に理解できるようになりました。Glue Crawlerがデータをスキャンし、スキーマを検出してData Catalogに登録することで、Athenaがデータを効率的に読み取り、分析することができます。これは、図書館の司書が新しい本を読み、その内容を目録カードに記録するようなものです。また、パーティショニング構造を自動的に認識することで、必要なデータだけを効率的に読み取ることができ、分析の速度が向上し、コストも削減できます。

技術比較まとめ表

技術領域AWSオンプレミス
メタデータ管理AWS Glue Data Catalog
サーバーレス、自動スキーマ検出、複数データソース統合
自前でメタデータサーバーを構築・運用
スキーマ管理が複雑
スキーマ検出Glue Crawlerによる自動検出
複数のデータ形式に対応
手動でスキーマを定義
データ形式ごとに異なるツールが必要
パーティション管理自動的なパーティション認識
パーティション情報の自動更新
手動でパーティションを管理
パーティション情報の更新が複雑

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

1. メタデータ管理の方法

  • AWS:サーバーレスで自動管理。スキーマの検出と更新が自動化。Glue Data Catalogがメタデータを一元管理
  • オンプレミス:自前でメタデータサーバーを構築・運用する必要がある。スキーマの管理が複雑で、複数のデータソースとの統合が困難

2. スキーマ検出の自動化

  • AWS:Crawlerが自動的にデータをスキャンし、スキーマを検出
  • オンプレミス:手動でスキーマを定義。データ形式ごとに異なるツールが必要

3. パーティション管理

  • AWS:パーティショニング構造を自動的に認識。パーティション情報の更新が自動化
  • オンプレミス:手動でパーティションを管理。パーティション情報の更新が複雑

4. データソースの統合

  • AWS:S3、RDS、DynamoDBなど、複数のデータソースを統合
  • オンプレミス:データソースごとに異なるツールが必要。統合が困難

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

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

  • Glue Database「data_analysis_db」が作成されている
  • Glue Crawler「data-analysis-crawler」が作成されている
  • CrawlerのデータソースがS3バケット「data-analysis-lake-(あなたのアカウントID)」に設定されている
  • Crawlerが正常に実行され、ステータスが「Ready」になっている
  • Data Catalogにテーブルが作成されている
  • テーブルのスキーマ(列の定義)が正しく検出されている
  • (パーティショニングを使用している場合)パーティション情報が正しく認識されている

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

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

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

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

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

  • メタデータの流れの理解: Glue CrawlerがS3のデータをスキャンし、Data Catalogにメタデータを登録する流れを視覚的に把握できる
  • リソース間の関係性: S3、Glue、Data Catalogがどのように連携しているかを理解できる
  • システム全体の把握: パイプライン全体の構造を一目で理解できる

構成図の書き方

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

  1. AWS Glue: 図の中央に配置。S3とData Catalogの間に配置
  2. Glue Data Catalog: Glueの近くに配置。メタデータが保存される場所として表現
  3. Glue Crawler: Glueの一部として表現。S3からData Catalogへの矢印を描く

💡 ヒント: 構成図では、データの流れとメタデータの流れを区別して表現すると理解しやすくなります。データの流れは実線、メタデータの流れは点線で表現することをおすすめします。

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

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

Q. なぜGlue Crawlerが必要なのでしょうか?S3に直接データを保存しているのに、なぜメタデータを別途管理する必要があるのでしょうか?

Q. なぜパーティショニング構造を自動的に認識するのでしょうか?パーティショニングにより、どのような効果が得られますか?

Q. なぜGlue Data Catalogは複数のデータソース(S3、RDS、DynamoDBなど)を統合できるのでしょうか?統合することで、どのようなメリットが得られますか?

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

Last updated on