AWS Glue を使って、分析処理のためにデータを抽出、変換、ロードする方法 (パート 2)

企業が直面している大きな課題に、信頼性の高い抽出と変換、およびロード (ETL) プロセスをいかに確立し維持するかがあります。なぜならこれらは、データから値と正しい情報を取り出すのに重要だからです。従来の ETL ツールは使用するにも複雑で、実装、テスト、およびデプロイに数カ月かかることもあります。ETL ジョブを作成すると、データフォーマットとスキーマが頻繁に変更され、新しいデータソースを常に追加する必要があるため、それらを維持するのは骨が折れる作業となります。

一方で　AWS Glue は、データの発見、分類、クリーニング、充実化、および移行に関連する未分化の重労働の多くを自動化できるため、データ分析により時間を費やすことができます。AWS Glue はデータソースを自動的にクロールし、データフォーマットを識別して、適切なスキーマと変換を提案します。つまり、データフローを手作業でコーディングする必要がないのです。

AWS Glue は、分析用にデータセットを移行および変換する作業を簡素化するよう設計されています。普及している Apache Spark 実行フレームワーク上に構築したサーバーレスの完全管理型サービスです。

2 部構成となっている移行についてのブログシリーズのパート 2 では、AWS CloudFormation スタックの構築を行います。このスタックを使用して、AWS Glue が Amazon Aurora MySQL データベースとの間でデータを抽出、変換、そしてロードする方法を解説します。ソースとして Amazon Aurora MySQL を、そして AWS Glue のターゲットとして Amazon Simple Storage Service (Amazon S3) を使用します。Amazon Athena を使って簡単なクエリとレポートを行うために、Amazon S3 に集中型データレイクを構築する方法についても説明します。Amazon Redshift をデータウェアハウス戦略の構築のために、データターゲットとして使用することもできます。この記事では、AWS Glue を開始し、必要に応じてカスタマイズするためのフレームワークを説明します。

AWS Glue には、3 つのコアコンポーネントがあります。

データ カタログ – 中央メタデータリポジトリとして機能します。テーブルとデータベースは、AWS Glue データカタログ内にあるオブジェクトです。メタデータを含んでいますが、データストアのデータは含んでいません。
クローラ – Amazon S3、Amazon RDS、Amazon Redshift などのさまざまなデータソース (ソースまたはターゲット) からデータと関連メタデータを検出します。クローラは、自動的にデータカタログを作成し、新しいデータを取得したり、データが進化するのに応じて最新の状態に保ちます。
ETL ジョブ – データ処理を実行するために必要なビジネスロジック。ETL ジョブは、変換スクリプト、データソース、およびデータターゲットで構成されます。

さらに AWS Glue は、より広いデータ処理ワークフローの一部としてジョブを実行するために必要なスケジューリング、アラート、およびトリガー機能も用意されています。

仮想プライベートクラウド (VPC) や Amazon Aurora MySQL (このブログシリーズのパート 1 でデプロイ) などのリソースを利用する CloudFormation スクリプトを使用します。このスクリプトでは、AWS Glue の特徴および機能を紹介しています。このブログでデプロイする CloudFormation スタックは、AWS Glue で ETL を実行するために必要な 4 つのコアコンポーネントを作成します。

HRDATA データベースという Amazon Aurora MySQL データベースへの AWS Glue データベース接続
HRDATA データベースをクロールできる AWS Glue クローラ
クローラ結果を格納するためのデータカタログ内にある AWS Glue データベース
2 つのテーブルをマージし新しいテーブルを作成することで、データを変換する AWS Glue ジョブ

AWS Glue ジョブを使用すると、複雑なデータ変換も記述することができます。このブログポストの目的に合わせ、今回はシンプルな変換を用います。このシンプルな変換は、データをソースから取り出し、外部でそのデータを変換し、分析処理のために格納することで、ビジネスに関する情報を得るという、よくあるシナリオを示しています。AWS Glue が Amazon S3 にロードした変換データは、Amazon Athena を用いてクエリできるデータレイクを構築するためのソースになります。

Amazon Athena は、標準 SQL を使用して Amazon S3 のデータを簡単に分析できるインタラクティブなクエリサービスです。Amazon Athena はサーバーレスであるため、インフラストラクチャの管理は不要であり、実行したクエリにのみ課金されます。たいていのお客様は、クラスタの実行と管理に頭を悩ませることなく、簡単にデータを照会したいだけなので、Amazon Athena はお役に立つはずです。

次の図は、AWS Glue コンポーネントとエクササイズのアーキテクチャを示しています。

前提条件

この AWS Glue エクササイズを開始するには、以下の手順に従ってください。

このブログシリーズのパート 1 の手順を、まず完了します。
このスクリプトは、米国西部 –2 (オレゴン) または米国東部 –2 (オハイオ) リージョンでのみ動作します。パート 1 と同じ AWS リージョンを必ず使用してください。
パート 1 でデプロイした CloudFormation スタックから、次のコンポーネントを再利用します。
- Amazon Aurora MySQL 互換の HRDATA データベース
- このデータベースに関連付けられている VPC、セキュリティグループ、およびサブネット
- Amazon S3 の VPC エンドポイント
CloudFormation スクリプトは、AWS Glue IAM ロールを作成します。これは、AWS Glue が Amazon RDS や Amazon S3 などの必要なリソースにアクセスするには必須のロールです。
このスクリプトは、ウォークスルー用の AWS Glue 接続、データベース、クローラ、およびジョブも作成します。
AWS Glue ジョブのスクリプトは Amazon S3 に保存されます。

スタックを起動する

注 : スタックによってデプロイされたリソースの一部では、使用を終了しない限り、料金が発生します。

CloudFormation テンプレートのデプロイメントを開始するには、これらのステップを実行します。

[Launch Stack] ボタンを選択します。これによって、テンプレートのある AWS アカウントで、AWS CloudFormation サービスが自動的に開始されます。必要に応じて、サインインするプロンプトが表示されます。
パート 1 でスタックの作成に使用したのと同じ AWS Region (オハイオまたはオレゴン) に移動します。続行するには [次へ] を選択します。
このブログシリーズのパート 1 <link> でデプロイした CloudFormation スタックの名前を指定します。注 : MigrationStackName 入力パラメーターは、パート 1 でデプロイした CloudFormation テンプレートのスタック名である必要があります。CloudFormation は、この新しいスタックで使用する、前のスタックの出力から値を自動的に抽出します。
レビューページで、スタックを開始した結果として、CloudFormation が AWS Identity and Access Management (IAM) リソースを作成することを承認します。[作成] を選択します。
スタックの作成の進行状況を確認するには、[リフレッシュ] を選択し、次にスタックを選択して起動イベントを確認してください。
スタックの作成には数分かかります。スタックが正常に起動すると、ステータスが CREATE_IN_PROGRESSからCREATE_COMPLETE に変わります。[Output] セクションには、CloudFormation によってデプロイしたリソースに関する情報もあります。
AWS マネジメントコンソールで、AWS Glue に移動します。[データカタログ] 下の左側のナビゲーションペインで、[データベース] を選択します。Hrdb という新しいデータベースが CloudFormation スタックによって追加されていることが分かります。このデータベースには、データベース、テーブル、パーティション、カラム定義などの情報が格納されます。AWS Glue クローラを使用してデータカタログを追加します。これは後の手順で行います。
[データカタログ] 下の左側のナビゲーションペインで、[接続] を選択します。Rds-aurora-blog-conn という新しい RDS 接続が表示されます。この接続は CloudFormation によって作成されました。
rds-aurora-blog-conn を選択して、接続の詳細を確認してください。Amazon Aurora MySQL データベースの JDBC 文字列を、以下のように使用します。次に示すように、Aurora MySQL 設定から VPC ID、サブネット ID、およびセキュリティグループ ID を取得しました。
左のナビゲーションペインで [クローラ] を選択します。CloudFormation スタックによって新しいクローラが作成されたことが分かります。更新されたテーブルと追加されたテーブルの各列の値は、それぞれ 0 です。これは、クローラがまだデータソースをクロールしていないためです。
詳細を見るには、rds-aurora-blog-crawler を選択してください。rds-aurora-blog-conn 接続、AWS Glue データカタログ hrdb データベース、およびインクルードパスパラメータ (HRDATA/％ のもの) を使用して、HRDATA データベース内のすべてのスキーマをクロールします。クローラには、多くの一般的なソース形式の分類子が用意されています。クロールされたテーブルの先頭には、データカタログの glue_ が接頭辞として付いています。
リストから rds-aurora-blog-crawler を選択し、[クローラを実行] を選択してクローラを開始します。クローラが数分間実行されます。
完了したら、テーブルが更新され、AWS Glue データカタログに追加されていることが分かります。
左側のナビゲーションペインで、[データベース] を選択し、hrdbデータベースを選択します。このデータベースは CloudFormation スタックによって作成され、前の手順で実行したクローラは AWS Glue データカタログの中のこのデータベースにテーブルを追加しました。
左側のナビゲーションペインで、[ETL] セクションに移動し、[ジョブ] を選択します。CloudFormation スタックによって作成されたジョブが表示されます。
このジョブを選択すると、Amazon S3 バケットからの PySpark スクリプトの場所や ETL ジョブに関連付けられたスクリプトなどの詳細が表示されます。このジョブは、AWS Glue DynamicFrameを作成します。これは、glue_hrdata_employees および glue_hrdata_departments の 2 つの各テーブルに対して作られ、データカタログ内の hrdb データベースにあります。

次のスクリプトを使用して、2 つの DynamicFrames の DEPARTMENT_ID 値に JOIN 変換を行い、employees_department という 3 つ目の DynamicFrame を作成します。スクリプトは、生成された DynamicFrame を宛先 S3 バケットに書き込みます。注 : 次のスクリプトでは、ジョブの –DefaultArguments value を使用し、かつ sys.argv を使ってスクリプトにそれを抽出して、宛先 S3 バケットのパラメータを渡している方法が分かります。

"GlueJob": {
      "Type": "AWS::Glue::Job",
      "DependsOn": ["AWSGlueRole", "AWSGlueconnectionRDS", "S3Bucket"],
      "Properties": {
        "Role": {
          "Ref": "AWSGlueRole"
        },
        "Connections": {
          "Connections": [
            {
              "Ref": "AWSGlueconnectionRDS"
            }
          ]
        },
        "Description": "Job created with CloudFormation using existing script",
        "Command": {
          "Name": "glueetl",
          "ScriptLocation": {
            "Fn::If" : [
              "UseProdCondition",
              "s3://blog-scripts-glueetl/glueetl/blogetls3.py",
              "s3://blog-scripts-gluetl-west2/glueetl/blogetls3.py"
              ]}
        },
        "DefaultArguments": {

          "--job-bookmark-option": "job-bookmark-enable",
          "--destination": {"Ref": "S3Bucket"}
        },
        "ExecutionProperty": {
          "MaxConcurrentRuns": 2
        },
        "MaxRetries": 0,
        "Name": {
          "Fn::Join": [
            "-",
            [
              {
                "Ref": "AWS::StackName"
              },
              "blog-etljob"
            ]
          ]
        },
        "AllocatedCapacity": "10"
      }
    }
  }

[ジョブ] を選択し、[アクション] で [ジョブを実行] を選択します。必要に応じて、データ処理ユニット (DPU) などのアドバンスパラメータ、および最大同時実行性を変更できます。
パネル下部で、ジョブのステータスを確認します。ジョブの実行時間を示し、ログおよびエラーログの値 (Amazon CloudWatch にある) にアクセスできます。ジョブは、デフォルトの 10 DPU で、およそ数分間実行されます。
ジョブが完了すると、ステータスは RUNNING から SUCCEEDED に変わります。

Amazon Athena を使用して、Amazon S3 で結果のクエリを行う

次に、AWS Glue によって書かれたデータを Amazon S3 に入れ、Amazon Athena で SQL クエリを実行します。

コンソールで、Amazon Athena サービスに移動します。Amazon Athena が AWS Glue で作成した hrdb データベースを自動的に認識することが分かります。Amazon Athena は、AWS Glue と同じデータカタログを使用します。
Amazon Athena の左側のナビゲーションペインで、hrdb の下の [テーブルの作成] を選択し、次に [自動 (AWS Glue クローラ)] を選択します。
AWS Glue コンソールにリダイレクトされる旨の通知が表示されます。[続行]　を選択し、AWS Glue　コンソールに移動して新しいクローラを作成します。
AWS Glue コンソールで、クローラ名を入力し、[続行] を選択します。
Amazon S3 がデータストアの種類であることを確認し、フォルダアイコンを選択して宛先バケットを選択します。このバケットは、Amazon S3 に連結したDynamicFrame の結果を書き込むために、AWS Glue によって使用されるものでなければなりません。[次へ] を選択して、続行してください。
次のページでは、[いいえ] を選択し、それから [続行] を選択します。
[IAM の役割を選択する] セクションで、[既存の IAM の役割] を選択します。IAM ロールについては、AWS CloudFormation スタックによって AWS Glue サービス用にすでに作成されている IAM ロールを選択します。続行するには、[次へ] を選択してください。
[このクローラのスケジュールを作成する] セクションの、[オンデマンドで実行] で頻度を選択します。データが常に変化する Amazon　S3　の場合、定期的にクローラを実行すると、AWS Glue データカタログの変更を自動的に取得できます。続行するには、[次へ] を選択します。
クローラの出力セクションで、結果を格納する AWS Glue データカタログのデータベースとして、hrbd　を選択します。s3_ のような接頭辞を追加すると、Amazon S3　の固有のテーブルと AWS Glue カタログ内の他のテーブルを区別できます。[次へ] を選択して、続行してください。
設定を確認し、[終了] を選択してクローラを作成します。

クローラを作成したので、以下を実行できます。

AWS Glue クローラを実行して Amazon S3 をクロールし、新しいテーブルを hrdb データカタログデータベースに追加します。クローラは約 1 分間実行されます。
完了したら、新しいテーブルが AWS Glue カタログに追加されていること分かります。
Amazon Athena　コンソールに戻り、更新アイコンを選択します。クエリするために Athena の新しい Amazon S3 テーブルが表示されます。
クエリエディタを使用して、次のようなクエリを試してみましょう。必要に応じて、赤いイタリック体で強調表示されたテキストを Amazon Athena ナビゲーションペインのテーブル名に置き換えてください。
```
select * from s3_destinationbucketforhrdata;
select * from s3_destinationbucketforhrdata where department_name = 'Sales' and commission_pct >= 0.30;
```

この段階では、AWS Glue を使用して Amazon S3 にデータをクロール、変換、ロードすることに成功しました。Amazon Athena を使用して、結果に対してアドホック SQL クエリを実行しました。これは一般的なパターンですが、Amazon S3 でデータレイクを作成し、ETLを実行した後、Amazon Athena で SQL クエリを実行します。

クリーンアップ手順を実行する

このブログ記事では、CloudFormation スクリプトが、AWS Glue に固有の IAM サービスロールと、さらにデータカタログデータベース、接続、クローラ、およびジョブを作成しました。AWS Glue クローラとジョブ実行の一環として、エラスティックネットワークインタフェースも VPC に作成されました。プライベート IP アドレスを介して、Amazon RDS に接続します。ウォークスルーを完了したら、これらのリソースを削除して追加コストを防ぐことができます。

このブログシリーズのパート 2 で作成したリソースを削除するには、次の手順を実行します。

コンソールで、Amazon S3 に移動し、AWS Glue ジョブで使用された宛先バケットの内容を削除します。AWS CloudFormation が次の手順でアイテムを削除するには、Amazon S3 バケットを空にする必要があります。
コンソールで、AWS Glue クローラセクションに移動して、作成したクローラを選択および削除して、宛先 S3 バケットをクロールします。
コンソールで、CloudFormation に移動します。
このブログ投稿用に作成したスタックを選択し、[アクション] で [スタックの削除]　を選択します。警告メッセージが表示されます。続行するには、[Yes, Delete] を選択します。
削除処理には数分かかります。スタックが作成したすべてのリソースが削除されます。プロセス中、ステータスに DELETE_IN_PROGRESS と表示されます。削除が成功すると、スタックは CloudFormation リストから消えています。
コンソールで、Amazon EC2 に移動し、左側のナビゲーションペインで [ネットワークインターフェース]　を選択します。ネットワークインタフェースのリストから、以下の説明があるインタフェースのみを選択します。
```
Attached to Glue using role: arn:aws:iam::<accountid>:role/<stackname>-AWSGlueServiceRole 
```
[デタッチ] を選択します (使用中のステータスの場合)。警告が出るので、[Yes, Detach] を選択します。
ネットワークインタフェースがデタッチされたら、それらを再度選択し、[削除] を選択します。警告が出ます。続行するには、[Yes, Delete] を選択します。選択したインターフェイスが正常に削除されていることを確認します (リストから消えています)。
この時点で、このブログ投稿の一部としてデプロイしたすべてのリソースが正常に削除されています。移行ブログシリーズのパート 1 のクリーンアップ手順に従って、パート 1 で作成したリソースを削除します。

結論

このブログ記事では、コンソールでシンプルなウォークスルーを用いて、AWS Glue を使用する際に重要な点を紹介しました。これらの機能を使用すると、Amazon S3 でデータを理解、準備、およびロードして、Amazon Athena でクエリを実行できます。

AWS Glue を使えば、一貫性かつ信頼性の高い方法で、ETL タスクを自動化および管理できます。さらに、このブログで提供されている CloudFormation テンプレートを使用すると、ETL ワークフローをテストし自動化することが可能となります。

著者について

Sona Rajamani は AWS のソリューションアーキテクトです。 サンフランシスコのベイエリアに暮らしながら、AWS 上でアプリケーションを設計し最適化できるようお客様をサポートしています。仕事以外では、ハイキングや旅行が趣味です。

Ballu Singh は AWS のソリューションアーキテクトです。サンフランシスコのベイエリアに住んでおり、お客様が AWS でアプリケーションを設計し最適化するサポートを行っています。余暇には、彼は読書、家族との時間を楽しんでいます。

Amazon Web Services ブログ