Amazon Web Services ブログ

AWS Glue Studio ビジュアル ETL ジョブで AWS Glue DataBrew レシピを使用する

AWS Glue Studio は AWS Glue DataBrew と統合されました。 AWS Glue Studio は、AWS Glue で抽出、変換、ロード (ETL) ジョブを簡単に作成、実行、監視できるようにするグラフィカルインターフェイスです。 DataBrew は、コードを書かずにデータをクレンジングおよび正規化できる可視的なデータプレパレーションツールです。DataBrewで提供されている 200 を超える変換ステップを、AWS Glue Studio ビジュアルジョブで使用できるようになりました。

DataBrew において、レシピは、直感的なビジュアルインターフェイスで対話的に作成できる一連のデータ変換ステップです。このブログでは、DataBrew でレシピを作成し、それを AWS Glue Studio ビジュアル ETL ジョブの一部として適用する方法を説明します。

既存の DataBrew ユーザーもこの統合の恩恵を受けることができます。高度なジョブ設定と最新の AWS Glue エンジンバージョンを使用できることに加えて、AWS Glue Studio が提供している他のすべてのコンポーネントを使用して、より大規模なビジュアルワークフローの一部としてレシピを実行できるようになります。

この統合により、両方のツールの既存ユーザーに明確なメリットがもたらされます。

  • AWS Glue Studio では、全体的な ETL ダイアグラムをエンドツーエンドで一元的に表示できます。
  • DataBrew コンソール上で、値・統計・分布を確認しながらレシピをインタラクティブに定義し、テストおよびバージョン管理された処理ロジックを AWS Glue Studio ビジュアル ジョブで再利用できます。
  • AWS Glue ETL ジョブで複数の DataBrew レシピを統合でき、AWS Glue ワークフローを使用して複数のジョブを統合できます。
  • DataBrew レシピでは、増分データ処理のためのブックマーク、自動再試行、自動スケール、小さなファイルのグループ化などの AWS Glue ジョブ機能を使用して効率化を図ることができるようになります。

ソリューション概要

今回のユースケース例では、このブログ用に作成された医療請求データセットをクレンジングすることが要件となります。サンプルデータには、データプレパレーションにおける DataBrew の機能を実践するために意図的にいくつかのデータ品質の問題を組み込んでいます。次に、別のデータソースから取得した医療事業者に関する関連情報を追加して、請求データをデータカタログに取り込みます。 (そうすることでアナリストが可視化できるようになります)。

このソリューションは、請求データと医療事業者データの 2 つの CSV ファイルを読み取る AWS Glue Studio ビジュアルジョブで構成されます。このジョブは、データの品質問題に対処するために、請求データにレシピを適用させて、医療事業者データから必要な列を選択した上で、両方のデータセットを結合して、最後に結果を Amazon Simple Storage Service (Amazon S3) に保存して、データカタログ上にテーブルを作成します。出力データは、Amazon Athena などの他のツールで使用できます。

DataBrew レシピの作成

まず、サンプルデータとして、請求データをデータストアに登録します。そうすることで、実際のデータを使用してインタラクティブエディターでレシピを作成できるようになり、変換を定義する際にその結果をレビューできるようになります。

  1. 次のリンクから請求データの CSV ファイルをダウンロードします: alabama_claims_data_Jun2023.csv 。
  2. DataBrew コンソールのナビゲーション ペインで [データセット] を選択し、[新しいデータセットの接続] を選択します。
  3. [ファイルをアップロード] オプションを選択します。
  4. [データセット名] に Alabama Claims と入力します。
  5. [アップロードするファイルを選択します] で、ローカル PC にダウンロードしたファイルを選択します。

  1. [S3 送信先を入力] で、使用しているAWSアカウントとリージョンにあるバケット名を入力または参照します。
  2. 残りのオプションはデフォルトのままにし (CSV はカンマとヘッダーで区切られます)、データセットの作成を完了します。
  3. ナビゲーションペインで [プロジェクト] を選択し、[プロジェクトの作成] を選択します。
  4. プロジェクト名として、ClaimsCleanup と入力します。
  5. [レシピの詳細] の [アタッチされたレシピ] で、[新しいレシピを作成] を選択し、名前を ClaimsCleanup-recipe とし、Alabama Claims データセットを選択します。

  1. DataBrew に適切な既存の IAM ロールを選択するか、新しい IAM ロールを作成します。これで、プロジェクトの作成は完了です。

以上で、構成可能なデータのサブセットを使用してセッションが作成されます。セッションの初期化が完了すると、一部のセルに無効な値または欠落した値が含まれていることがわかります。

Diagnosis Code、Claim Amount、および Claim Date の列の値が欠落しており、データの一部の値には余分な文字が含まれています。Diagnosis Code の値には「code 」(スペースが含まれる) という接頭辞が付く場合があり、Procedure Code の値には、末尾に一重引用符が付いています。Claim Amount の値は一部の計算に使用される可能性があるため、数値型に変換し、Claim Date は Data 型に変換する必要があります。

対処すべきデータ品質の問題を特定したので、各問題をどのように対処するかを決定する必要があります。 レシピステップを追加するには、列のコンテキストメニュー、上部のツールバー、またはレシピの概要からなど、複数の方法があります。最後の方法を使用すると、指定されたステップタイプを検索して、このブログで作成したレシピを複製できます。

今回のユースケースでは Claim Amount は不可欠な値であるため、欠損のある行を削除することにします。

  1. [欠損した値を削除] のステップを追加します。
  2. ソース列で、[Claim Amount] を選択します。
  3. デフォルトのアクション [欠落した値がある行を削除する]のままにし、[適用] を選択して保存します。

ステップの適用を反映してビューが更新され、 Claim Amount が欠損している行はなくなりました。

Diagnosis Code は空でもよいですが、 Claim Date には合理的に推測された値が必要です。データ内の行は時系列で並べ替えられるため、プレビューの前の行の有効な値を使用して、欠落している日付を代入できます。毎日請求が発生していると仮定すると、最大の問題は、その日の最初の請求データの日付が欠落している場合に、プレビューの日付が割り当てられてしまうことです。今回は説明のために、潜在的なエラーは許容できると考えてみましょう。

まず、列を string 型から date 型に変換します。

  1. [型の変更] のステップを追加します。
  2. ソース列として [Claim Date] を選択し、型として[date] を選択し、[適用] を選択します。

  1. 次に、欠落した日付を代入するために、[欠落した値を埋める/帰属] ステップを追加します。
  2. ソース列に [Claim Date]、アクションとして [最後の有効な値で埋める] を選択します。
  3. [変更のプレビュー] を選択して検証し、[適用] を選択してステップを保存します。

下記の画像のように、ここまででレシピには 3 つのステップが存在しているはずです。

  1. 次に、[引用符の削除] ステップを追加します。
  2. ソース列に [Procedure Code]、削除する値に [先頭と末尾の引用符] を選択します。
  3. プレビューにてステップが反映されていることを確認し、新しいステップとして適用します。

  1. [特殊文字を削除] のステップを追加します。
  2. ソース列に [Claim Amount] 選択し、[カスタム特殊文字] の [カスタム特殊文字を入力] に $ を入力します。

  1. [型を変更] ステップを追加し、ソース列 [Claim Amount] 、タイプを [double] とします。

  1. 最後のステップとして、余分な “code ” プレフィックスを削除するために、[値またはパターンの置き換え] ステップを追加します。
  2. ソース列で [Diagnosis Code] を選択し、[カスタム値を入力] に code と入力します (末尾にスペースを入れます)。

サンプルで特定したすべてのデータ品質の問題に対処したので、プロジェクトをレシピとして公開します。

  1. レシピペインで [発行] を選択し、オプションでバージョンの説明を入力してレシピの発行を完了します。

発行するたびに、異なるバージョンのレシピが作成され、使用するレシピのバージョンを選択できるようになります。

AWS Glue Studio でビジュアル ETL ジョブを作成

次に、レシピを使用するジョブを作成します。次の手順を実行します。

  1. AWS Glue Studio コンソールのナビゲーションペインで [Visual ETL] を選択します。
  2. [Visual with a blank canvas] を選択し、ビジュアル ジョブを作成します。
  3. ジョブの上部の “Untitled job” を任意の名前に置き換えます。
  4. [Job Details] タブで、ジョブが使用するロールを指定します。
    これは、Amazon S3 および AWS Glue データカタログへのアクセス許可を持つ、AWS Glue に適した AWS Identity and Access Management (IAM) ロールである必要があります。先ほど DataBrew で使用したロールはジョブの実行には使用できないため、ここでは [IAM ロール] ドロップダウン メニューにはリストされないことに注意してください。

DataBrew ジョブとは違い、AWS Glue Studio では、ワーカー サイズ、自動スケーリング、柔軟な実行などのパフォーマンスとコストの設定を選択できるほか、最新の AWS Glue 4.0 ランタイムを使用することで大幅なパフォーマンスの改善を受けることができることに注目してください。このジョブでは、デフォルトの設定を使用できますが、節約のためにワーカーの数を減らします。この例では、2 Wokers で十分です。

  1. [Visual] タブで、S3 ソースを追加し、Providers という名前を付けます。
  2. S3 URL には、s3://awsglue-datasets/examples/medicare/Medicare_Hospital_Provider.csv と入力します。

  1. データフォーマットとして [CSV] を選択し、[Infer schema] を選択します。 これで、ファイルヘッダーを使用してスキーマが [Output schema] タブにリストされます。

このユースケースでは、providers データセット内のすべての列を必要としないため、残りは削除できます。

  1. Providers ノードを選択した状態で、Transforms で [Drop Fields] を追加します (Node parents を選択しなかった場合は、Node parents を手動で割り当てます)。
  2. Provider Zip Code 以降のフィールドをすべて選択します。

その後、この Providers データを、Alabama 州の 請求データと結合します。ただし、2 番目のデータセットには州の情報がありません。Providers データから、必要なデータをフィルタリングすることで結合を最適化できます。

  1. [Drop Fields] の子としてTransforms から[Filter] 追加します。
  2. Alabama providers と名前を付け、Provider State が AL と一致するという条件を追加します。

  1. 2番目のソース (新しい S3 ソース) を追加し、Alabama claims という名前を付けます。
  2. S3 URL を入力するには、別のブラウザ タブで DataBrew を開き、ナビゲーションペインで [データセット] を選択し、表に表示されている Alabama claims の場所をコピーします (http リンクではなく、s3:// で始まるテキストをコピーします)。次に、ビジュアルジョブに戻り、S3 URL 欄に貼り付けます。正しい場合は、[Output schema] タブにデータフィールドがリストされていることがわかります。
  3. CSV 形式を選択し、他のソースの場合と同様に [infer schema] します。
  4. このソースの子として、ノードの追加メニューで recipe と検索し、[Data Preparation Recipe] を選択します。

  1. 新しいノードのプロパティで、Claim cleanup Recipe という名前を付け、先ほど発行したレシピとバージョンを選択します。
  2. ここでレシピの手順を確認し、必要に応じて DataBrew へのリンクを使用して変更を加えることができます。

  1. 結合ノードを追加し、Alabama providers と Claim cleanup recipes の両方を親として選択します。
  2. 両方のソースの provider ID を結合条件として追加します。
  3. 最後のステップとして、S3 ノードをターゲットとして追加します (検索時に表示される最初のノードはソースであることに注意してください。ターゲットとして表示されるものを必ず選択してください)。
  4. ノード設定では、デフォルト形式の JSON のままにし、ジョブの IAM ロールが書き込み権限を持つ S3 URL を入力します。

さらに、データ出力をカタログ内のテーブルとして利用できるようにします。

  1. [データ カタログの更新オプション] セクションで、上から 2 番目のオプション [データ カタログにテーブルを作成し、その後の実行でスキーマを更新し、新しいパーティションを追加する] を選択し、テーブルを作成する権限があるデータベースを選択します。
  2. 名前を alabama_claims とし、partition key として Claim Date を選択します (これは説明のためであり、今回のような小さなテーブルでは、後でデータを追加しない場合、実際にはパーティションを必要としません)。

  1. ジョブを保存してジョブを実行します。
  2. [Run] タブでは、ジョブ ID リンクを使用してプロセスを追跡し、詳細なジョブメトリクスを確認できます。

ジョブが完了するまでに数分かかります。

  1. ジョブが完了したら、Athena コンソールに移動します。
  2. 選択したデータベースでテーブル alabama_claims を検索し、コンテキスト メニューを使用して [テーブルのプレビュー] を選択します。これにより、テーブルに対して単純な SELECT * SQL ステートメントが実行されます。

ジョブの結果から、データが DataBrew レシピによってクレンジングされ、AWS Glue Studio の結合処理によって強化されたことがわかります。

Apache Spark は、AWS Glue Studio で作成されたジョブを実行するエンジンです。生成されるイベント ログ上で Spark UI を使用すると、ジョブの計画と実行に関するインサイトを表示でき、ジョブのパフォーマンスと潜在的なパフォーマンスのボトルネックを理解するのに役立ちます。たとえば、大規模なデータセットに対するこのジョブの場合、これを使用して、結合処理を実行する前にプロバイダーの状態を明示的にフィルタリングすることの影響を比較したり、自動バランス変換を追加して並列処理を改善することでメリットが得られるかどうかを確認できます。

デフォルトでは、ジョブは Apache Spark イベント ログを s3://aws-glue-assets-<アカウント ID>-<リージョン名>/sparkHistoryLogs/ のパスに保存します。ジョブを表示するには、いずれかの方法を使用して History server をインストールする必要があります。

後片付け

このソリューションが不要になった際は、Amazon S3 に格納された生成ファイル、ジョブによって作成されたテーブル、DataBrew レシピ、および AWS Glue ジョブを削除してください。

まとめ

このブログでは、AWS DataBrew のインタラクティブエディターを使用してレシピを作成し、発行されたレシピを AWS Glue Studio ビジュアル ETL ジョブの一部として使用する方法を説明しました。データプレパテレーションを実施して、AWS Glue Catalog のテーブルにデータを取り込む際に必要な一般的なタスクの例をいくつか含めました。

この例ではビジュアルジョブで 1 つのレシピを使用しましたが、ETL プロセス内で複数のレシピを使用したり、複数のジョブで同じレシピを再利用することも可能です。

これらの AWS Glue ソリューションを使用すると、コードを記述することなく、構築と運用が簡単な高度な ETL パイプラインを効果的に作成できます。両方のツールを組み合わせたソリューションをすぐに開始できます。

この記事は、Sr. Software Dev Engineer の Mikhail Smirnov とSr. Big Data Architect の Gonzalo Herreros が執筆しています。日本語訳はソリューションアーキテクトの三宅が翻訳しました。原文はこちらです。

執筆者について

Mikhail Smirnov is a Sr. Software Dev Engineer on the AWS Glue team and part of the AWS Glue DataBrew development team. Outside of work, his interests include learning to play guitar and traveling with his family.

 

Gonzalo Herreros is a Sr. Big Data Architect on the AWS Glue team. Based on Dublin, Ireland, he helps customers succeed with big data solutions based on AWS Glue. On his spare time, he enjoys board games and cycling.