# AWS Glue での Spark ジョブの使用 AWS Glue for Spark の ETL ジョブについて説明します。 **Topics** + [AWS Glue ジョブでジョブパラメータを使用する](aws-glue-programming-etl-glue-arguments.md) + [AWS GlueSpark と PySpark のジョブ](spark_and_pyspark.md) + [AWS Glue ワーカータイプ](worker-types.md) + [AWS Glue でのストリーミング ETL ジョブ](add-job-streaming.md) + [AWS Lake Formation FindMatches によるレコードのマッチング](machine-learning.md) + [Apache Spark プログラムを AWS Glue に移行する](glue-author-migrate-apache-spark.md) # AWS Glue ジョブでジョブパラメータを使用する AWS Glue ジョブを作成するときは、`Role` や `WorkerType` などの標準フィールドを設定します。[`Argument`] フィールド (コンソールの **[ジョブパラメータ]**) で追加の設定情報を指定できます。これらのフィールドでは、AWS Glue ジョブに対して、このトピックに記載されている引数 (パラメータ) を指定できます。 AWS Glue Job API の詳細については、「[ジョブ](aws-glue-api-jobs-job.md)」を参照してください。 **注記** ジョブ引数の最大サイズの制限は 260KB です。検証チェックでは、引数のサイズが 260KB を超える場合にエラーが発生します。 ## ジョブのパラメータを設定する コンソールの **[Job details]** (ジョブの詳細) タブの **[Job Parameters]** (ジョブパラメータ) の見出しの下でジョブを設定できます。また、AWS CLI で、ジョブに `DefaultArguments` または `NonOverridableArguments` を設定するか、ジョブ実行に `Arguments` を設定することで、ジョブを設定できます。ジョブに設定された引数は、ジョブが実行されるたびに渡されますが、ジョブの実行に設定された引数は、その個々の実行に対してのみ渡されます。 次の例は、ジョブのパラメータを設定するために `--arguments` を使用してジョブを実行する構文です。 ``` $ aws glue start-job-run --job-name "CSV to CSV" --arguments='--scriptLocation="s3://my_glue/libraries/test_lib.py"' ``` ## ジョブのパラメータへのアクセス AWS Glue スクリプトを作成する際に、ジョブのパラメータ値にアクセスして作成したコードの動作を変更したい場合があります。そのためのヘルパーメソッドをライブラリに用意しています。これらのメソッドは、ジョブパラメータ値をオーバーライドするジョブ実行パラメータ値を解決します。複数の場所で設定されたパラメータを解決する場合、ジョブの `NonOverridableArguments` はジョブ実行の `Arguments` をオーバーライドしますが、ジョブの `DefaultArguments` はオーバーライドされます。 **Python では:** Python ジョブでは、`getResolvedParameters` という名前の関数を用意しています。詳細については、「[`getResolvedOptions` を使用して、パラメータにアクセスする](aws-glue-api-crawler-pyspark-extensions-get-resolved-options.md)」を参照してください。ジョブパラメータは `sys.argv` 変数から取得できます。 **Scala では:** Scala ジョブでは、`GlueArgParser` という名前のオブジェクトを用意しています。詳細については、「[AWS Glue Scala GlueArgParser API](glue-etl-scala-apis-glue-util-glueargparser.md)」を参照してください。ジョブパラメータは `sysArgs` 変数から取得できます。 ## ジョブパラメータリファレンス **AWS Glue は、ジョブおよびジョブ実行のスクリプト環境を設定するために使用できる次の引数名を認識します。** **`--additional-python-modules`** インストールする Python パッケージのセットを表すカンマ区切りのリスト。パッケージのインストールは、PyPI からでも、カスタムディストリビューションを提供することでも行えます。PyPI パッケージのエントリは、ターゲットパッケージの PyPI 名とバージョンを含む、`package==version` のような形式になります。カスタムディストリビューションエントリとは S3 のパスであり、ディストリビューションを指しています。 エントリは Python のバージョンマッチングを使用して、パッケージとバージョンの照合を行います。つまり、2 つの等号 (`==`) を使用する必要があります。バージョンマッチングには他の演算子もあります。詳細については「[PEP 440](https://peps.python.org/pep-0440/#version-matching)」を参照してください。 モジュールインストールオプションを `pip3` に渡すには、[--python-modules-installer-option](#python-modules-installer-option) パラメータを使用します。 **`--auto-scale-within-microbatch`** デフォルト値は True です。このパラメータは、ストリーミングデータを一連のマイクロバッチで処理する AWS Glue ストリーミングジョブにのみ使用でき、自動スケーリングを有効にする必要があります。この値を false に設定すると、完了したマイクロバッチのバッチ持続時間の指数平滑移動平均線を計算し、この値をウィンドウサイズと比較して、エグゼキューターの数をスケールアップするかスケールダウンするかを決定します。スケーリングはマイクロバッチが完了したときにのみ行われます。この値を true に設定すると、マイクロバッチの実行中に Spark タスクの数が 30 秒間変わらない場合や、現在のバッチ処理がウィンドウサイズを超えると、スケールアップします。エグゼキューターが 60 秒以上アイドル状態であったり、バッチ持続時間の指数平滑移動平均線が短い場合、エクゼキューターの数は減少します。 **`--class`** Scala スクリプトのエントリポイントとなる Scala クラス。これは、`--job-language` を `scala` に設定した場合にのみ適用されます。 **`--continuous-log-conversionPattern`** 連続ログ記録を有効にしたジョブのカスタム変換ログパターンを指定します。変換パターンは、ドライバーログとエグゼキューターログにのみ適用されます。この設定は、AWS Glue の進行状況バーには影響しません。 **`--continuous-log-logGroup`** 連続ログ記録が有効なジョブに対し、カスタム Amazon CloudWatch ロググループ名を指定します。 **`--continuous-log-logStreamPrefix`** 連続ログ記録が有効なジョブに対し、カスタム CloudWatch ログストリームのプレフィックスを指定します。 **`--customer-driver-env-vars` および `--customer-executor-env-vars` ** これらのパラメータは、各ワーカー (ドライバーまたはエグゼキューター) のオペレーティングシステムの環境変数をそれぞれ設定します。AWS Glue 上でプラットフォームやカスタムフレームワークを構築するときにこれらのパラメータを使用し、ユーザーが Glue 上にジョブを作成できるようします。これら 2 つのフラグを有効にすると、ジョブスクリプト自体に同じロジックを注入しなくても、ドライバーおよびエグゼキューターにそれぞれ異なる環境変数を設定できます。 **使用例** 次の内容は、これらのパラメータを使用する例を示します。 ``` "—customer-driver-env-vars", "CUSTOMER_KEY1=VAL1,CUSTOMER_KEY2=\"val2,val2 val2\"", "—customer-executor-env-vars", "CUSTOMER_KEY3=VAL3,KEY4=VAL4" ``` これらをジョブ実行の引数に設定することは、次のコマンドを実行することと同じです。 ドライバーに含まれるもの: + export CUSTOMER\$1KEY1=VAL1 + export CUSTOMER\$1KEY2="val2,val2 val2" エグゼキューターに含まれるもの: + export CUSTOMER\$1KEY3=VAL3 その後、ジョブスクリプト自体で `os.environ.get("CUSTOMER_KEY1")` または `System.getenv("CUSTOMER_KEY1")` を使用して環境変数を取得できます。 **強制構文** 環境変数を定義するとき、次の基準に従ってください。 + 各キーには、`CUSTOMER_ prefix` が必要です。 たとえば `"CUSTOMER_KEY3=VAL3,KEY4=VAL4"` の場合、`KEY4=VAL4` は無視されて設定されません。 + キーおよび値のペアは、それぞれ 1 つのカンマで区切る必要があります。 例: `"CUSTOMER_KEY3=VAL3,CUSTOMER_KEY4=VAL4"` + 「値」にスペースやカンマが含まれている場合、引用符で囲んで定義する必要があります。 例: `CUSTOMER_KEY2=\"val2,val2 val2\"` この構文は、bash 環境変数の設定基準を忠実に模倣しています。 **`--datalake-formats` ** AWS Glue 3.0 以降のバージョンでサポートされます。 使用するデータレイクフレームワークを指定します。AWSGlue は、指定したフレームワークに必要な JAR ファイルを `classpath` に追加します。詳細については、「[AWS Glue ETL ジョブでのデータレイクフレームワークの使用](aws-glue-programming-etl-datalake-native-frameworks.md)」を参照してください。 次の中から 1 つまたは複数の値をカンマで区切って指定できます。 + `hudi` + `delta` + `iceberg` 例えば、3 つのフレームワークすべてを指定するには、次の引数を渡します。 ``` '--datalake-formats': 'hudi,delta,iceberg' ``` **`--disable-proxy-v2`** サービスプロキシを無効にして、VPC を介してスクリプトから由来する Amazon S3、CloudWatch、AWS Glue への AWS サービス呼び出しを許可します。詳細については、「[すべての AWS コールを VPC を経由するように設定する](https://docs.aws.amazon.com/glue/latest/dg/connection-VPC-disable-proxy.html)」を参照してください。サービスプロキシを無効にするには、このパラメータの値を `true` に設定します。 **`--enable-auto-scaling`** 値を `true` に設定した場合、Auto Scaling およびワーカーごとの課金がオンになります。 **`--enable-continuous-cloudwatch-log`** AWS Glue ジョブのリアルタイムの連続ログ記録を有効にします。Apache Spark ジョブに関するリアルタイムのログは、CloudWatch で表示できます。 **`--enable-continuous-log-filter`** 連続ログ記録が有効であるジョブを作成または編集するときに、標準フィルタ (`true`) またはフィルタなし (`false`) を指定します。標準フィルタを選択すると、無用な Apache Spark ドライバー/エグゼキュータや Apache Hadoop YARN ハートビートのログメッセージは除外されます。フィルタなしを選択すると、すべてのログメッセージが表示されます。 **`--enable-glue-datacatalog`** AWS Glue データカタログの、Apache Spark Hive メタストアとしての使用を有効にします。この機能を有効にするには、値を `true` に設定します。 **`--enable-job-insights`** AWS Glue のジョブ実行インサイトによる追加のエラー分析のモニタリングを有効にします。詳細については、「[AWS Glue ジョブ実行インサイトでのモニタリング](monitor-job-insights.md)」を参照してください。デフォルトでは、値は `true` に設定されており、ジョブ実行インサイトは有効になっています。 このオプションは、AWS Glue バージョン 2.0 および 3.0 で利用できます。 **`--enable-lakeformation-fine-grained-access`** Glue AWS ジョブのきめ細かなアクセスコントロールを有効にします。詳細については、「[AWS Glue と AWS Lake Formation を併用したきめ細かなアクセスコントロール](security-lf-enable.md)」を参照してください。 **`--enable-metrics`** このジョブの実行のジョブプロファイリングに関するメトリクスの収集を有効にします。これらのメトリクスは、AWS Glue コンソールおよび Amazon CloudWatch コンソールから利用が可能です。このパラメータの値は関係ありません。この機能を有効にするには、このパラメータに任意の値を指定できますが、わかりやすくするために `true` が推奨されます。この機能を無効にするには、このパラメータをジョブ設定から削除します。 **`--enable-observability-metrics`** AWS Glue コンソールおよび Amazon CloudWatch コンソールの「ジョブ実行モニタリング」ページで、各ジョブ実行内で起こっている内容に関する情報を生成するため、一連のオブザーバビリティメトリクスを有効にします。この機能を有効にするには、パラメータの値を true に設定します。この機能を無効にするには、`false` に設定するか、ジョブ設定からこのパラメーターを削除します。 **`--enable-rename-algorithm-v2`** EMRFS 名前変更アルゴリズムのバージョンをバージョン 2 に設定します。Spark ジョブがパーティションの動的な上書きモードを使用している場合、パーティションが重複して作成される可能性があります。例えば、`s3://bucket/table/location/p1=1/p1=1` のような重複したパーティション作成されます。ここで、P1 は上書きされているパーティションです。名前変更アルゴリズムのバージョン 2 では、この問題が修正されています。 このオプションは、AWS Glue バージョン 1.0 でのみ使用できます。 **`--enable-s3-parquet-optimized-committer`** Parquet データを Amazon S3 に書き込むために、EMRFS S3 最適化コミッターを有効にします。AWS Glue ジョブの作成または更新時に、AWS Glue コンソールからパラメータ/値のペアを指定できます。値を **true** に設定すると、コミッターが有効になります。デフォルトでは、このフラグは AWS Glue 3.0 ではオン、AWS Glue 2.0 ではオフになっています。 詳細については、「[EMRFS S3 向けに最適化されたコミッターの使用](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-s3-optimized-committer.html)」を参照してください。 **`--enable-spark-ui`** `true` に設定すると、Spark UI を使用して AWS Glue ETL ジョブのモニタリングおよびデバッグを行う機能が有効になります。 **`--executor-cores`** 並列に実行できる Spark タスクの数。このオプションは、AWS Glue 3.0 以降でサポートされています。この値は、ワーカータイプの vCPU 数の 2 倍 (`G.1X` では 8、`G.2X` では 16、`G.4X` では 32、`G.8X` では 64、`G.12X` では 96、`G.16X` では 128、および `R.1X` では 8、`R.2X` では 16、`R.4X` では 32、`R.8X`では 64) を超えない値にする必要があります。タスクの並列処理が増えるとメモリやディスクに負荷がかかるだけでなく、ソースシステムとターゲットシステムがスロットリングされる (例えば、Amazon RDS での同時接続数が増える) ため、この構成を更新するときは注意が必要です。 **`--extra-files`** スクリプトを実行する前に、AWS Glue がドライバーノードのスクリプトの作業ディレクトリにコピーする構成ファイルなど、追加ファイルへの Amazon S3 パス。複数の値はコンマ (`,`) で区切られた完全なパスでなければなりません。値は個々のファイルまたはディレクトリの場所の場合があります。このオプションは Python Shell ジョブタイプではサポートされていません。 **`--extra-jars`** AWS Glue がドライバーおよびエグゼキュターにコピーする追加ファイルへの Amazon S3 パス。AWSGlue は、スクリプトを実行する前にこれらのファイルを Java クラスパスにも追加します。複数の値はコンマ (`,`) で区切られた完全なパスでなければなりません。拡張機能は `.jar` である必要はありません **`--extra-py-files`** スクリプトを実行する前に、AWS Glue がドライバーノードの Python パスに追加する追加の Python モジュールへの Amazon S3 パス。複数の値はコンマ (`,`) で区切られた完全なパスでなければなりません。ディレクトリパスではなく、個別のファイルのみがサポートされています。 **`--job-bookmark-option`** ジョブブックマークの動作を制御します。次のオプション値を設定できます。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/aws-glue-programming-etl-glue-arguments.html) 例えば、ジョブブックマークを有効にするには、以下の引数を渡します。 ``` '--job-bookmark-option': 'job-bookmark-enable' ``` **`--job-language`** スクリプトプログラミング言語。この値は `scala` または `python` のいずれかである必要があります。このパラメータが存在しない場合、デフォルトで `python` が使用されます。 **`--python-modules-installer-option`** [--additional-python-modules](#additional-python-modules) でモジュールをインストールする場合に、`pip3` に渡されるオプションを定義するプレーンテキストの文字列。コマンドラインの場合と同様に、スペースで区切り、先頭にダッシュを付けてオプションを指定します。使用方法の詳細については、「[pip を使用して追加の Python モジュールを AWS Glue 2.0 以降にインストールする](aws-glue-programming-python-libraries.md#addl-python-modules-support)」(Python モジュールのサポートの追加) を参照してください。 Python 3.9 を使用する場合、このオプションは AWS Glue ジョブではサポートされません。 **`--scriptLocation`** ETL スクリプトが (`s3://path/to/my/script.py` 形式で) 置かれている Amazon Simple Storage Service (Amazon S3) の場所。このパラメータは、`JobCommand` オブジェクトで設定されているスクリプトの場所を上書きします。 **`--spark-event-logs-path`** Amazon S3 パスを指定します。Spark UI モニタリング機能を使用する場合、AWS Glue は Spark イベントログを、30 秒ごとに、この Amazon S3 パスの (Spark UI イベントを保存するための一時ディレクトリとして使用可能な) バケットにフラッシュします。 **`--TempDir`** ジョブの一時ディレクトリとして使用できるバケットへの Amazon S3 のパスを指定します。 例えば、一時ディレクトリを設定するには、以下の引数を渡します。 ``` '--TempDir': 's3-path-to-directory' ``` バケットがリージョンに既に存在しない場合、AWS Glue はジョブに一時的なバケットを作成します。このバケットは、パブリックアクセスを許可する場合があります。Amazon S3 のバケットは、パブリックアクセスブロックを設定するように変更するか、そのリージョンのすべてのジョブが完了した後に削除するかのいずれかが可能です。 **`--use-postgres-driver`** この値を `true` に設定した場合、Amazon Redshift の JDBC ドライバーとの競合を避けるために、クラスパスにある Postgres JDBC ドライバーが優先されます。このオプションは、AWS Glue バージョン 2.0 以降でのみ使用可能です。 **`--user-jars-first`** この値を `true` に設定した場合、クラスパス内にあるお客様の追加 JAR ファイルが優先されます。このオプションは、AWS Glue バージョン 2.0 以降でのみ利用できます。 **`--conf`** Spark の設定パラメータを制御します。高度なユースケース向けです。 **`--encryption-type`** レガシーパラメータ。対応する動作は、セキュリティ設定を使用して設定する必要があります。セキュリティ設定の詳細については、「[AWS Glue​ によって書き込まれたデータの暗号化](encryption-security-configuration.md)」を参照してください。 AWS Glue は次の引数を内部的に使用するため、ユーザーは使用しません。 + `--debug` — AWS Glue 内部用。設定する必要はありません。 + `--mode` — AWS Glue 内部用。設定する必要はありません。 + `--JOB_NAME` — AWS Glue 内部用。設定する必要はありません。 + `--endpoint` — AWS Glue 内部用。設定する必要はありません。 ## AWS Glue は、サイト固有のカスタマイズを実行するための `sitecustomize` を使用した Python の `site` モジュールによる環境のブートストラップをサポートします。独自の初期化関数のブートストラップは高度なユースケースにのみ推奨され、AWS Glue 4.0 ではベストエフォートベースでサポートされています。 環境変数のプレフィックス `GLUE_CUSTOMER` は、お客様専用です。 # AWS GlueSpark と PySpark のジョブ AWS Glue は Spark および PySpark のジョブをサポートします。Spark ジョブは、AWS Glue によって管理される Apache Spark 環境で実行されます。データはバッチで処理されます。ストリーミング ETL ジョブは Spark ジョブに似ていますが、データストリームで ETL を実行する点が異なります。このタイプのジョブでは Apache Spark 構造化ストリーミングフレームワークが使用されます。一部の Spark ジョブ機能は、ストリーミング ETL ジョブでは使用できません。 以下のセクションでは、AWS GlueSpark と PySpark のジョブについて説明します。 **Topics** + [AWS Glue で Spark ジョブに関するジョブプロパティの構成](add-job.md) + [AWS Glueコンソールで Spark スクリプトの編集](edit-script-spark.md) + [仕事 (レガシー)](console-edit-script.md) + [ジョブのブックマークを使用した処理済みデータの追跡](monitor-continuations.md) + [Spark のシャッフルデータの保存](monitor-spark-shuffle-manager.md) + [モニタリングAWS GlueSpark ジョブ](monitor-spark.md) + [AWS Glue での Apache Spark の生成 AI トラブルシューティング](troubleshoot-spark.md) + [AWS Glue でマテリアライズドビューを使用する](materialized-views.md) # AWS Glue で Spark ジョブに関するジョブプロパティの構成 AWS Glue コンソールでジョブを定義するときに、AWS Glue ランタイム環境をコントロールするためのプロパティの値を指定します。 ## Spark ジョブのジョブプロパティの定義 次のリストは、Spark ジョブのプロパティについて説明しています。Python シェルジョブのプロパティについては、「[Python シェルジョブのジョブプロパティの定義](add-job-python.md#create-job-python-properties)」を参照してください。ストリーミング ETL ジョブのプロパティについては、「[ストリーミング ETL ジョブのジョブプロパティの定義](add-job-streaming.md#create-job-streaming-properties)」を参照してください。 プロパティは、AWS Glue コンソールの [**Add job**] (ジョブの追加) ウィザードに表示された順に一覧表示されます。 **名前** UTF-8 文字を 255 文字以内で入力します。 **説明** オプションとして最大 2,048 文字の説明を提示します。 **IAM ロール** ジョブ実行とデータストアへのアクセスに使用されるリソースの認可に使用する IAM ロールを指定します。AWS Glue でジョブを実行するためのアクセス権限の詳細については、[AWS Glue のアイデンティティとアクセスの管理](security-iam.md) を参照してください。 **タイプ** ETL ジョブの種類。これは、選択するデータソースの種類に基づいて自動的に設定されます。 + **[Spark]** は、`glueetl` のジョブコマンドで Apache Spark ETL スクリプトを実行します。 + **[Spark ストリーミング]** は、`gluestreaming` のジョブコマンドで Apache Spark ストリーミング ETL スクリプトを実行します。詳細については、「[AWS Glue でのストリーミング ETL ジョブ](add-job-streaming.md)」を参照してください。 + **[Python シェル]** は、`pythonshell` のジョブコマンドで Python スクリプトを実行します。詳細については、「[AWS Glue での Python シェルジョブに関するジョブプロパティの設定](add-job-python.md)」を参照してください。 **AWS Glue バージョン** AWS Glue のバージョンによって、ジョブで使用できる Apache Spark および Python のバージョンが次の表に指定されているように決まります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/add-job.html) **Language** ETL スクリプト内のコードでジョブのロジックを定義します。Python または Scala でスクリプトを記述できます。ジョブが実行するスクリプトを AWS Glue によって生成するのか、それとも自分で提供するのかを選択できます。Amazon Simple Storage Service (Amazon S3) でスクリプト名と場所を指定します。パスのスクリプトディレクトリと同じ名前のファイルが存在していないことを確認します。スクリプトの記述の詳細については、「[AWS Glue プログラミングガイド](edit-script.md)」を参照してください。 **ワーカータイプ** 以下のワーカータイプを使用できます。 AWS Glue ワーカーで利用可能なリソースは DPU 単位で測定されます。DPU は処理能力を相対的に測定するもので、4 個の vCPU のコンピューティング性能と 16 GB のメモリで構成されています。 + **G.025X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、84 GB のディスク (空き容量約 34 GB) を備えた 0.25 DPU (2 vCPU、4 GB メモリ) にマッピングされます。少量のストリーミングジョブには、このワーカータイプをお勧めします。このワーカータイプは、AWS Glue バージョン 3.0 以降のストリーミングジョブでのみ使用できます。 + **G.1X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、94 GB のディスク (空き容量約 44 GB) を備えた 1 DPU (4 vCPU、16 GB メモリ) にマッピングされます。データ変換、結合、クエリなどのワークロードには、ほとんどのジョブを実行するためのスケーラブルで費用対効果の高い方法として、このワーカータイプをお勧めします。 + **G.2X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、138 GB のディスク (空き容量約 78 GB) を備えた 2 DPU (8 vCPU、32 GB メモリ) にマッピングされます。データ変換、結合、クエリなどのワークロードには、ほとんどのジョブを実行するためのスケーラブルで費用対効果の高い方法として、このワーカータイプをお勧めします。 + **G.4X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、256 GB のディスク (空き容量約 230 GB) を備えた 4 DPU (16 vCPU、64 GB メモリ) にマッピングされます。ワークロードに含まれる変換、集約、結合、クエリへの要求が非常に厳しいジョブには、このワーカータイプをお勧めします。 + **G.8X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、512 GB のディスク (空き容量約 485 GB) を備えた 8 DPU (32 vCPU、128 GB メモリ) にマッピングされます。ワークロードに含まれる変換、集約、結合、クエリへの要求が非常に厳しいジョブには、このワーカータイプをお勧めします。 + **G.12X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、768 GB のディスク (空き容量約 741 GB) を備えた 12 DPU (48 vCPU、192 GB メモリ) にマッピングされます。このワーカータイプは、大量のコンピューティングキャパシティを必要とする極めて大規模なリソース集約型ワークロードを伴うジョブに推奨されます。 + **G.16X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、1,024 GB のディスク (空き容量約 996 GB) を備えた 16 DPU (64 vCPU、256 GB メモリ) にマッピングされます。このワーカータイプは、最大限のコンピューティングキャパシティを必要とする、最も大規模で最もリソース集約型のワークロードを伴うジョブに推奨されます。 + **R.1X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、メモリ最適化構成の 1 つの DPU にマッピングされます。このワーカータイプは、メモリ不足エラーが頻繁に発生する、または高いメモリ対CPU比を必要とするメモリ集約型ワークロードに推奨されます。 + **R.2X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、メモリ最適化構成の 2 つの DPU にマッピングされます。このワーカータイプは、メモリ不足エラーが頻繁に発生する、または高いメモリ対CPU比を必要とするメモリ集約型ワークロードに推奨されます。 + **R.4X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、メモリ最適化設定の 4 つの DPU にマッピングされます。このワーカータイプは、メモリ不足エラーが頻繁に発生する、または高いメモリ対CPU比を必要とする大規模なメモリ集約型ワークロードに推奨されます。 + **R.8X** – このタイプを選択する場合は、**[Number of workers]** (ワーカー数) の値も指定します。各ワーカーは、メモリ最適化設定の 8 つの DPU にマッピングされます。このワーカータイプは、メモリ不足エラーが頻繁に発生する、または高いメモリ対CPU比を必要とする極めて大規模なメモリ集約型ワークロードに推奨されます。 **ワーカータイプの仕様** 以下の表には、利用可能なすべての G ワーカータイプの仕様が詳しく説明されています。 **G ワーカータイプの仕様** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/add-job.html) **重要:** G.12X と G.16X のワーカータイプ、およびすべての R ワーカータイプ (R.1X～R.8X) では、起動レイテンシーが高くなります。 ETL ジョブの実行に使用された DPU の数に基づいて時間あたりの料金が請求されます。詳細については、[AWS Glue 料金表ページ](https://aws.amazon.com/glue/pricing/) を参照してください。 AWS Glue バージョン 1.0 以前のジョブでは、コンソールを使用してジョブを設定し、[**Worker type**] (ワーカータイプ) に [**Standard**] (標準) を指定する場合は、[**Maximum capacity**] (最大キャパシティー) が設定され、[**Number of workers**] (ワーカー数) は [**Maximum capacity**] (最大キャパシティー) から 1 を引いた値になります。AWS Command Line Interface (AWS CLI) または AWS SDK を使用する場合は、[**Max capacity**] (最大キャパシティー) パラメータを指定することも、[**Worker type**] (ワーカータイプ) と [**Number of workers**] (ワーカー数) の両方を指定することもできます。 AWS Glue バージョン 2.0 以降のジョブでは、**[最大キャパシティ]** の指定はできません。代わりに、[**Worker type**] (ワーカータイプ) と [**Number of workers**] (ワーカー数) を指定します。 **G.4X** と **G.8X** のワーカータイプは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (スペイン)、欧州 (ストックホルム)、南米 (サンパウロ) の AWS リージョンで、AWS Glue バージョン 3.0 以降の Spark ETL に対してのみ使用できます。 **G.12X**、**G.16X**、および **R.1X** から **R.8X** のワーカータイプは、米国東部 (バージニア北部)、米国西部 (オレゴン)、米国東部 (オハイオ)、欧州 (アイルランド)、欧州 (フランクフルト) の AWS リージョンで、AWS Glue バージョン 4.0 以降の Spark ETL ジョブに対してのみ使用できます。追加のリージョンは、今後のリリースでサポートされる予定です。 **リクエストしたワーカーの人数** ほとんどのワーカータイプで、ジョブの実行時に割り当てられるワーカーの数を指定する必要があります。 **ジョブのブックマーク** ジョブ実行時に AWS Glue が状態情報を処理する方法を指定します。以前に処理されたデータの記憶、状態情報の更新、または状態情報の無視を指定できます。詳細については、「[ジョブのブックマークを使用した処理済みデータの追跡](monitor-continuations.md)」を参照してください。 **ジョブ実行キューイング** サービスクォータが原因でジョブをすぐに実行できないとき、ジョブを後で実行するようにキューに入れるかどうかを指定します。 チェックすると、ジョブ実行キューイングがジョブ実行に対して有効になります。入力されていない場合、ジョブ実行はキューイングの対象になりません。 この設定がジョブ実行で設定された値と一致しない場合、ジョブ実行フィールドの値が使用されます。 **Flex 実行** AWS Studio や API を使用してジョブを設定する際、標準のジョブ実行クラスあるいは柔軟なジョブ実行クラスを指定することができます。ジョブには、さまざまな度合いの優先順位や時間的な制約を設定することができます。標準の実行クラスは、素早くジョブを起動する必要があり、専用のリソースが必要な時間的な制約のあるワークロードに最適です。 柔軟な実行クラスは、実稼働前のジョブ、テスト、1 回限りのデータの読み込みなど、緊急性のないジョブに適しています。柔軟なジョブの実行は、AWS Glue バージョン 3.0 以降と `G.1X` または `G.2X` ワーカータイプを使用するジョブでサポートされています。新しいワーカータイプ (`G.12X`、`G.16X`、および `R.1X` から `R.8X`) は、柔軟な実行をサポートしません。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/FnHCoTuDLXU/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/FnHCoTuDLXU) Flex ジョブの実行は、任意の時点で実行されているワーカーの数に基づいて課金されます。柔軟なジョブの実行では、ジョブ数を追加または削除することができます。`Max Capacity` \$1 `Execution Time` という単純な計算で課金されるのではなく、各ワーカーがジョブ実行中に実行された時間が含まれます。請求は (`Number of DPUs per worker` \$1 `time each worker ran`) の合計です。 詳細は、「AWS Studio のヘルプパネル」、または「[ジョブ](aws-glue-api-jobs-job.md)」や「[ジョブ実行](aws-glue-api-jobs-runs.md)」を参照してください。 **再試行回数** 失敗した場合に AWS Glue がジョブを自動的に再起動する回数を 0〜10 の間で指定します。タイムアウト制限に達したジョブは再起動されません。 **ジョブのタイムアウト** 最大の実行時間 (分) を設定します。最大値は 7 日 (10,080 分) です。それ以外の場合は、ジョブは例外をスローします。 値を空白のままにすると、タイムアウトはデフォルトで 2,880 分に設定されます。 タイムアウト値が 7 日を超える既存の AWS Glue ジョブは、デフォルトで 7 日に設定されます。たとえば、バッチジョブに 20 日間のタイムアウトを指定した場合、7 日目に停止します。 **ジョブタイムアウトのベストプラクティス** ジョブは実行時間に基づいて課金されます。予期しない課金を避けるには、ジョブの予想実行時間に適切なタイムアウト値を設定してください。 **詳細プロパティ** **スクリプトのファイル名** ジョブの一意のスクリプト名。**[タイトルがないジョブ]** という名前を付けられません。 **スクリプトパス** スクリプトの Amazon S3 ロケーション。パスは `s3://bucket/prefix/path/` の形式で指定する必要があります。末尾にスラッシュ (`/`) を付けてファイルは含めないでください。 **ジョブのメトリクス** このジョブの実行時に Amazon CloudWatch メトリクスの作成を有効または無効にします。プロファイリングデータを表示するには、このオプションを有効にする必要があります。メトリクスを有効にして表示する方法の詳細については、「[ジョブのモニタリングとデバッグ](monitor-profile-glue-job-cloudwatch-metrics.md)」を参照してください。 **ジョブのオブザーバビリティメトリクス** このジョブの実行時に追加のオブザーバビリティ CloudWatch メトリクスの作成を有効にします。詳細については、「[AWS Glue オブザーバビリティメトリクスを使用したモニタリング](monitor-observability.md)」を参照してください。 **連続ログ記録** Amazon CloudWatch への連続ログ記録を有効にします。このオプションが有効になっていない場合、ログはジョブの完了後にのみ使用できます。詳細については、[AWS Glue ジョブのログ記録](monitor-continuous-logging.md) を参照してください。 **Spark UI** このジョブをモニタリングするために Spark UI の使用を有効にします。詳細については、「[AWS Glue ジョブ用の Apache Spark ウェブ UI の有効化](monitor-spark-ui-jobs.md)」を参照してください。 **Spark UI ログパス** Spark UI が有効になっているときにログを書き込むパス。 **Spark UI のログ記録とモニタリングの設定** 以下のオプションのいずれかを選択してください: + スタンダード: AWS Glue ジョブの実行 ID をファイル名として使用してログを書き込みます。AWS Glue コンソールで Spark UI モニタリングを有効にします。 + レガシー: 「spark-application-\$1timestamp\$1」をファイル名として使用してログを書き込みます。Spark UI モニタリングをオンにしないでください。 + スタンダードとレガシー: スタンダードロケーションとレガシーロケーションの両方にログを書き込みます。AWS Glue コンソールで Spark UI モニタリングを有効にします。 **最大同時実行数** このジョブで許可される同時実行の最大数を設定します。デフォルトは 1 です。このしきい値に達すると、エラーが返されます。指定できる最大値は、サービスの制限によってコントロールされます。たとえば、新しいインスタンスの開始時に前回のジョブがまだ実行されている場合、同じジョブの 2 つのインスタンスが同時に実行されないようにエラーを戻すことができます。 **一時的なパス** AWS Glue がスクリプトを実行するときに一時的な中間結果が書き込まれる Amazon S3 の作業ディレクトリの場所を指定します。パスの一時ディレクトリと同じ名前のファイルが存在していないことを確認します。このディレクトリは、Amazon Redshift に対して AWS Glue が読み取りと書き込みをするときに使用します。また、特定の AWS Glue 変換で使用します。 AWS Glue では、リージョンにバケットが存在しない場合、ジョブの一時バケットが作成されます。このバケットは、パブリックアクセスを許可する場合があります。この Amazon S3 に置かれたバケットは、パブリックアクセスブロックを構成するために設定することができます。また、そのリージョンのすべてのジョブが完了した後に削除することが可能です。 **遅延通知のしきい値 (分)** 遅延通知を送信するまでのしきい値 (分単位) を設定します。`RUNNING`、`STARTING`、または `STOPPING` ジョブの実行が想定時間 (分単位) を超えると通知を送信するように、このしきい値を設定できます。 **セキュリティ設定** リストからセキュリティ設定を選択します。セキュリティ設定では、Amazon S3 ターゲットのデータの暗号化方法として、暗号化なし、AWS KMS で管理されたキー (SSE-KMS) を使用したサーバー側の暗号化、または Amazon S3 で管理された暗号化キー (SSE-S3) を使用したサーバー側の暗号化を指定します。 **サーバー側の暗号化** このオプションを選択すると、ETL ジョブが Amazon S3 に書き込むときに、データは SSE-S3 暗号化を使用して保管時に暗号化されます。Amazon S3 のデータターゲットと、Amazon S3 の一時ディレクトリに書き込まれるデータは、両方とも暗号化されています。このオプションはジョブパラメータとして渡されます。詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[Amazon S3 が管理する暗号化キーによるサーバー側の暗号化 (SSE-S3) を使用したデータの保護](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html)」を参照してください。 セキュリティ設定を指定している場合、このオプションは無視されます。 **Glue データカタログを Hive メタストアとして使用する** AWS Glue データカタログを Hive メタストアとして使用することを選択します。ジョブに使用される IAM ロールには、`glue:CreateDatabase` アクセス許可が必要です。「default」という名前のデータベースが存在しない場合はデータカタログに作成されます。 **Connections** VPC 設定を選択し、仮想プライベートクラウド (VPC) にある Amazon S3 データソースにアクセスします。AWS Glue でネットワーク接続を作成および管理できます。詳細については、「[データへの接続](glue-connections.md)」を参照してください。 **[ライブラリ]** **Python ライブラリパス、依存 JAR パス、参照されるファイルパス** これらのオプションはスクリプトで必要に応じて指定します。ジョブを定義するときに、これらのオプションのカンマ区切りの Amazon S3 パスを定義できます。ジョブ実行時にこれらのパスを上書きできます。詳細については、「[独自のカスタムスクリプトの提供](console-custom-created.md)」を参照してください。 **ジョブのパラメータ** スクリプトに名前付きパラメータとして渡される一連のキーと値のペア。これらは、スクリプトの実行時に使用されるデフォルト値ですが、トリガーまたはジョブの実行時に上書きできます。キー名の前に `--` を付ける必要があります (`--myKey` など)。AWS Command Line Interface を使用するときに、ジョブパラメータをマッピングとして渡します。 例については、「[AWS Glue の Python パラメータの受け渡しとアクセス](aws-glue-programming-python-calling.md#aws-glue-programming-python-calling-parameters)」で Python パラメータを参照してください。 **タグ** [**タグキー**] とオプションの [**タグ値**] を使用してジョブにタグを付けます。作成されたタグキーは読み取り専用になります。リソースを整理、識別しやすいように、いくつかのリソースでタグを使用します。詳細については、「[AWSAWS Glue のタグ](monitor-tags.md)」を参照してください。 ## Lake Formation 管理対象テーブルにアクセスするジョブの制約事項 AWS Lake Formation で管理されるテーブルに対して読み書きするジョブを作成する場合は、次の注意事項と制約事項に注意してください。 + 次の機能は、セルレベルフィルタを使用してテーブルにアクセスするジョブではサポートされません。 + [ジョブのブックマーク](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html)と[境界実行の実行](https://docs.aws.amazon.com/glue/latest/dg/bounded-execution.html) + [プッシュダウン述語](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-partitions.html#aws-glue-programming-etl-partitions-pushdowns) + [サーバーサイドのカタログパーティション述語](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-partitions.html#aws-glue-programming-etl-partitions-cat-predicates) + [UpdateCatalog を有効にする](https://docs.aws.amazon.com/glue/latest/dg/update-from-job.html) # AWS Glueコンソールで Spark スクリプトの編集 スクリプトには、ソースからデータを抽出して、変換し、ターゲットにロードするコードが含まれています。AWS Glue​ はジョブを開始するときにスクリプトを実行します。 AWS GluePython または Scala で ETL スクリプトを記述できます。Python スクリプトは、抽出、変換、ロード (ETL) ジョブのための PySpark Python ダイアレクトの拡張機能である言語を使用します。スクリプトには ETL 変換を処理する*拡張構造*が含まれます。自動でジョブのソースコードロジックを生成するときに、スクリプトが作成されます。このスクリプトを編集するか、または、独自のスクリプトを指定して ETL 作業を処理することができます。 AWS Glue のスクリプトの定義と編集の詳細については、「[AWS Glue プログラミングガイド](edit-script.md)」を参照してください。 ## その他のライブラリまたはファイル スクリプトに追加のライブラリやファイルが必要な場合は、次のように指定できます。 **Python ライブラリパス** スクリプトで必要とされる Python ライブラリへのカンマ区切りの Amazon Simple Storage Service (Amazon S3) パス。 純粋な Python ライブラリのみを使用できます。pandas Python データ解析ライブラリなど、C 拡張機能に依存するライブラリはまだサポートされていません。 **依存 JARS パス** スクリプトで必要とされる JAR ファイルへのカンマ区切りの Amazon S3 パスです。 現在、純粋な Java または Scala (2.11) ライブラリのみを使用できます。 **参照されるファイルパス** スクリプトに必要な追加のファイル (例えば、設定ファイル) への、カンマ区切りの Amazon S3 パス。 # 仕事 (レガシー) スクリプトには、抽出、変換、ロード (ETL) ワークを実行するコードが含まれます。独自のスクリプトを提供することもできますし、お客様のガイダンスで AWS Glue がスクリプトを生成することもできます。独自のスクリプトの作成については、「[独自のカスタムスクリプトの提供](console-custom-created.md)」を参照してください。 スクリプトは、AWS Glue コンソールで編集できます。スクリプトを編集する場合、ソース、ターゲット、および変換を追加することができます。 **スクリプトを編集するには** 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。その後 [**Jobs**] (ジョブ) タブを選択します。 1. リストでジョブを選択し、次に [**Action**] (アクション)、[**Edit script**] (スクリプトの編集) を選択してスクリプトエディタを開きます。 ジョブ詳細ページからスクリプトエディタにアクセスすることもできます。[**Script**] (スクリプト) タブを選択し、次に [**Edit script**] (スクリプトの編集) を選択します。 ## スクリプトエディタ AWS Glue スクリプトエディタを使用して、スクリプトのソース、ターゲット、変換を挿入、変更、および削除できます。スクリプトエディタにはスクリプトとダイアグラムの両方が表示され、データの流れを可視化しやすくなります。 スクリプトのダイアグラムを作成するには、[**ダイアグラムの生成**] を選択します。AWS Glue は **\$1＃** で始まるスクリプト内の注釈行を使用してダイアグラムをレンダリングします。ダイアグラムでスクリプトを正しく表すために、注釈のパラメータと Apache Spark コードのパラメータの同期を保つ必要があります。 スクリプトエディタを使用して、スクリプトのカーソルが置かれている任意の場所にコードテンプレートを追加することができます。エディタの上部で、次のオプションから選択します。 + ソーステーブルをスクリプトに追加するには、[**Source**] (ソース) を選択します。 + ターゲットテーブルをスクリプトに追加するには、[**Target**] (ターゲット) を選択します。 + ターゲット位置をスクリプトに追加するには、[**Target location**] (ターゲット位置) を選択します。 + 変換をスクリプトに追加するには、[**Transform**] (変換) を選択します。スクリプトで呼び出される関数については、「[PySpark で AWS Glue ETL スクリプトをプログラムする](aws-glue-programming-python.md)」を参照してください。 + スピゴット変換をスクリプトに追加するには、[**Spigot**] (スピゴット) を選択します。 挿入されたコードで、注釈および Apache Spark コード両方の `parameters` を変更します。たとえば、**スピゴット**変換を追加したら、`path` が `@args` 注釈行および `output` コード行の両方で置き換えられていることを検証します。 [**Logs**] (ログ) タブでは、実行されるジョブに関連するログが表示されます。最新の 1,000 行が表示されます。 [**Schema**] (スキーマ) タブでは、Data Catalog で使用可能な場合、選択されたソースとターゲットのスキーマが表示されます。 # ジョブのブックマークを使用した処理済みデータの追跡 AWS Glue ではジョブの実行による状態情報を保持することで、ETL ジョブの以前の実行中にすでに処理されたデータを追跡します。この継続状態の情報は*ジョブのブックマーク*と呼ばれています。ジョブのブックマークは、AWS Glue で状態情報を保持して、古いデータを再処理しないために役立ちます。ジョブのブックマークを使用すると、スケジュールされた間隔で再実行する際に新しいデータを処理できます。ジョブのブックマークは、ソース、変換、ターゲットなど、さまざまなジョブの要素で構成されています。例えば、ETL ジョブが Amazon S3 ファイルで新しいパーティションを読み込むとします。AWS Glue は、そのジョブにより正常に処理されたのはどのパーティションなのかを追跡し、処理の重複およびジョブのターゲットデータストアにデータが重複するのを防ぎます。 ジョブのブックマークは、JDBC データソース、Relationalize 変換、および一部の Amazon Simple Storage Service (Amazon S3) ソースに実装されています。次の表に、AWS Glue がジョブのブックマークに対してサポートする Amazon S3 ソース形式を示します。 | AWS Glue バージョン | Amazon S3 ソース形式 | | --- | --- | | バージョン 0.9 | JSON、CSV、Apache Avro、XML | | バージョン 1.0 以降 | JSON、CSV、Apache Avro、XML、Parquet、ORC | AWS Glue バージョンの詳細に関しては、「[Spark ジョブのジョブプロパティの定義](add-job.md#create-job)」を参照してください。 ジョブのブックマーク機能には、AWS Glue スクリプトからアクセスする際の追加機能があります。生成されたスクリプトを参照すると、この機能に関連する変換コンテキストが表示される場合があります。詳細については、「[ジョブのブックマークを使用する](programming-etl-connect-bookmarks.md)」を参照してください。 **Topics** + [AWS Glue でジョブのブックマークを使用する](#monitor-continuations-implement) + [ジョブブックマーク機能の運用に関する詳細](#monitor-continuations-script) ## AWS Glue でジョブのブックマークを使用する ジョブのブックマークオプションは、ジョブが開始したときにパラメータとして渡されます。AWS Glue コンソールでジョブのブックマークを設定するためのオプションを次の表に示します。 **** | ジョブのブックマーク | 説明 | | --- | --- | | 有効 | ジョブの実行後に状態を更新させて以前に処理されたデータを追跡します。ジョブのブックマークをサポートしているソースのあるジョブの場合、ジョブは処理されたデータを追跡し、ジョブが実行されると、最後のチェックポイント以降の新しいデータを処理します。 | | [無効] | ジョブのブックマークは使用されず、ジョブは常にデータセット全体を処理します。以前のジョブからの出力の管理は、ユーザーが行います。これがデフォルトです。 | | [Pause] (一時停止) | 最後のブックマークの状態は更新せずに、最後に正常に実行された後の増分データ、または次のサブオプションで識別される範囲内のデータを処理します。以前のジョブからの出力の管理は、ユーザーが行います。次の 2 つのサブオプションがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitor-continuations.html) このオプションが設定されている場合、ジョブのブックマークの状態は更新されません。 サブオプションはオプションですが、使用する場合、両方のサブオプションを提供する必要があります。 | コマンドラインでジョブに渡されるパラメータ、および特にジョブブックマークの詳細については、「[AWS Glue ジョブでジョブパラメータを使用する](aws-glue-programming-etl-glue-arguments.md)」を参照してください。 Amazon S3 入力ソースの場合、AWS Glue ジョブのブックマークではオブジェクトの最終更新日時を確認して、どのオブジェクトを再処理する必要があるのかを確認します。入力ソースデータが最後のジョブ実行以降に変更されている場合、ジョブを再度実行すると、ファイルが再度処理されます。 JDBC ソースでは、次のルールが適用されます。 + AWS Glue では、テーブルごとに 1 つ以上の列をブックマークキーとして使用して、新しいデータおよび処理済みのデータを決定します。ブックマークキーは、結合して単一の複合キーを形成します。 + AWS Glue はデフォルトでプライマリキーをブックマークキーとして使用します。ただし、プライマリキーが連続して (ギャップなく) 増減することが条件です。 + AWS Glue スクリプトでブックマークキーとして使用する列を指定できます。AWS Glue スクリプトでのジョブブックマーク使用の詳細については、「[ジョブのブックマークを使用する](programming-etl-connect-bookmarks.md)」を参照してください。 + AWS Glue は、ジョブブックマークキーとして名前の大文字と小文字を区別する列の使用をサポートしていません。 AWS Glue Spark ETL ジョブのジョブブックマークを以前のジョブ実行に巻き戻すことができます。ジョブのブックマークを以前のジョブ実行に巻き戻すことで、データのバックフィルシナリオをより適切にサポートできます。その結果、後続のジョブ実行ではブックマークされたジョブ実行からのデータだけが再処理されます。 同じジョブを使用してすべてのデータを再処理する場合は、ジョブのブックマークをリセットします。ジョブのブックマークの状態をリセットするには、AWS Glue コンソール、[ResetJobBookmark アクション (Python: reset\$1job\$1bookmark)](aws-glue-api-jobs-runs.md#aws-glue-api-jobs-runs-ResetJobBookmark) API オペレーション、または AWS CLI を使用します。例えば、AWS CLI を使用して以下のコマンドを入力します。 ``` aws glue reset-job-bookmark --job-name my-job-name ``` ブックマークを巻き戻したりリセットしたりしたとき、複数のターゲットが存在する可能性があり、ターゲットがジョブブックマークで追跡されないため、AWS Glue はターゲットファイルをクリーンアップしません。ジョブブックマークで追跡されるのは、ソースファイルだけです。ソースファイルの巻き戻しと再処理時に異なる出力ターゲットを作成して、出力内のデータが重複しないようにすることができます。 AWS Glue では、ジョブでジョブのブックマークを管理します。ジョブを削除すると、ジョブのブックマークは削除されます。 場合によっては、AWS Glue ジョブのブックマークを有効にしてあっても、以前の実行で処理したデータを ETL ジョブで再処理することがあります。このエラーの一般的な原因を解決する方法の詳細については、「[Glue の一般的なセットアップエラーのトラブルシューティング](glue-troubleshooting-errors.md)」を参照してください。 ## ジョブブックマーク機能の運用に関する詳細 このセクションでは、ジョブのブックマークを使用する運用の詳細を説明します。 ジョブのブックマークはジョブの状態を保存します。状態の各インスタンスは、ジョブ名とバージョン番号がキーになっています。スクリプトで呼び出された `job.init` では、その状態を取得し、常に最新バージョンを取得します。1 つの状態の中に複数の状態要素が存在します。要素は、スクリプト内のソース、変換、シンクインスタンスごとに固有です。これらの状態要素は、スクリプト内の対応する要素 (ソース、変換、またはシンク) にアタッチされている変換コンテキストによって識別されます。状態要素はユーザースクリプトから `job.commit` が呼び出されたときにアトミックに保存されます。スクリプトは引数からジョブのブックマークのジョブ名およびコントロールオプションを取得します。 ジョブのブックマーク内の状態要素は、ソース、変換、またはシンク固有のデータです。例えば、アップストリームジョブまたはプロセスによって継続的に書き込まれている Amazon S3 の場所から増分データを読み取るとします。この場合、スクリプトではそれまでに処理されている部分を判別する必要があります。Amazon S3 ソースのジョブのブックマーク実装では情報を保存するため、再度ジョブを実行するときに、保存された情報を使用して新しいオブジェクトのみをフィルターでき、次にジョブを実行するための状態を再計算できます。新しいファイルをフィルタリングするためにタイムスタンプが使用されます。 ジョブのブックマークは、状態要素に加えて、*実行番号*、*試行番号*、*バージョン番号* を持ちます。実行番号はジョブの実行を追跡し、試行番号はジョブ実行の試行回数を記録します。ジョブ実行番号は正常な実行ごとに増分される、一定間隔で増加する番号です。試行番号は各実行の試行回数を追跡し、失敗した試行後のに実行がある場合にのみ増分されます。バージョン番号は、一定間隔で増加し、ジョブのブックマークの更新を追跡します。 AWS Glue サービスデータベースでは、すべての変換のブックマーク状態がキーと値のペアとして一緒に格納されます。 ``` { "job_name" : ..., "run_id": ..., "run_number": .., "attempt_number": ... "states": { "transformation_ctx1" : { bookmark_state1 }, "transformation_ctx2" : { bookmark_state2 } } } ``` **ベストプラクティス** 以下は、ジョブブックマークを使用するためのベストプラクティスです。 + *ブックマークを有効にした状態でデータソースプロパティを変更しないでください*。例えば、Amazon S3 入力パス A を指している datasource0 があります。ジョブはブックマークを有効にして数ラウンド実行されているソースから読み出しています。`transformation_ctx` を変更せずに datasource0 の入力パスを Amazon S3 パス B に変更すると、AWS Glue ジョブは保存されている古いブックマークの状態を使用します。これによって、入力パス B のファイルは、見つからないか、スキップされます。AWS Glue は、これらのファイルが以前の実行で処理されたと仮定します。 + *パーティション管理を改善するために、ブックマーク付きのカタログテーブルを使用してください*。ブックマークは、データカタログのデータソースとオプションの両方に対して機能します。ただし、from オプションのアプローチでは、新しいパーティションを削除/追加するのは困難です。クローラーでカタログテーブルを使用すると、新しく追加された [パーティション](https://docs.aws.amazon.com/glue/latest/dg/tables-described.html#tables-partition)を追跡するための自動化が向上し、[プッシュダウン述語](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-partitions.html)を使用して特定のパーティションを柔軟に選択できるようになります。 + *大規模なデータセット向けの[AWS GlueAmazon S3 ファイルリスター](https://aws.amazon.com/premiumsupport/knowledge-center/glue-oom-java-heap-space-error/)の使用* ブックマークは、各入力パーティションの下のすべてのファイルをリストし、ファイリングを実行します。したがって、単一のパーティションの下にファイルが多すぎると、ブックマークがドライバ OOM で実行される可能性があります。AWS Glue Amazon S3 ファイルリスターを使用して、メモリ内のすべてのファイルを一度にリストしないようにします。 # Spark のシャッフルデータの保存 シャッフルは、データがパーティション間で再配置されるたびに行われる Spark ジョブの重要なステップです。これが必要なのは、`join`、` groupByKey`、`reduceByKey`、`repartition` などのさまざまな変換に、処理を完了するために他のパーティションからの情報が必要なためです。Spark は各パーティションから必要なデータを収集し、新しいパーティションに結合します。シャッフル中、データはディスクに書き込まれ、ネットワーク経由で転送されます。その結果、シャッフルオペレーションはローカルディスク容量に制約されます。Spark の `No space left on device` または ` MetadataFetchFailedException` エラーは、エグゼキュターに十分なディスク領域がなく、リカバリがない場合に発生します。 **注記** Amazon S3 での AWS Glue Spark シャッフルプラグインは、AWS Glue ETL ジョブについてのみサポートされています。 **ソリューション** AWS Glue では、Amazon S3 を使用して Spark シャッフルデータを保存できるようになりました。Amazon S3 は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。このソリューションで、Spark ジョブ用のコンピューティングとストレージが非集約化され、完全な伸縮自在性と低コストのシャッフルストレージが得られ、シャッフル負荷の高いワークロードが高い信頼性で実行できるようになります。 ![\[Spark workflow showing Map and Reduce stages using Amazon S3 for shuffle data storage.\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/gs-s3-shuffle-diagram.png) Amazon S3 を使用するための Cloud Shuffle Storage Plugin for Apache Spark を導入します。大きなシャッフルオペレーションのためにローカルディスク容量の制約を受けることがわかっている場合、Amazon S3 シャッフルを有効にすると、AWS Glue ジョブを失敗することなく高い信頼性で実行できます。小さなパーティションが多数ある場合や、Amazon S3 に書き込まれたファイルをシャッフルする場合、Amazon S3 へのシャッフルはローカルディスク (または EBS) よりもわずかに遅くなる場合があります。 ## クラウドシャッフルストレージプラグインを使用するための前提条件 AWS Glue ETL ジョブにクラウドシャッフルストレージプラグインを使用するには、以下が必要です。 + 途中のシャッフルデータやスピルしたデータを保存するための、ジョブが実行されているのと同じリージョンにある Amazon S3 バケット。シャッフルストレージの Amazon S3 プレフィックスは、`--conf spark.shuffle.glue.s3ShuffleBucket=s3://shuffle-bucket/prefix/` で次の例のように指定できます。 ``` --conf spark.shuffle.glue.s3ShuffleBucket=s3://glue-shuffle-123456789-us-east-1/glue-shuffle-data/ ``` + シャッフルマネージャーはジョブの終了後にファイルをクリーンアップしないため、プレフィックス (`glue-shuffle-data` など) に Amazon S3 ストレージライフサイクルポリシーを設定します。途中のシャッフルデータやスピルしたデータは、ジョブの終了後に削除する必要があります。ユーザーはプレフィックスに短いライフサイクルポリシーを設定できます。Amazon S3 ライフサイクルポリシーのセットアップ手順については、「Amazon Simple Storage Service ユーザーガイド」の「[バケットのライフサイクル設定の指定](https://docs.aws.amazon.com//AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)」を参照してください。 ## AWS コンソールからの AWS Glue Spark シャッフルマネージャーの使用 ジョブを設定するときに AWS Glue コンソールまたは AWS Glue Studio を使用して AWS Glue Spark シャッフルマネージャーをセットアップするには、**--write-shuffle-files-to-s3** ジョブパラメータを選択して、ジョブの Amazon S3 シャッフルを有効にします。 ![\[Job parameters interface showing --write-shuffle-files- parameter and option to add more.\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/gs-s3-shuffle.png) ## AWS Glue Spark シャッフルプラグインの使用 次のジョブパラメータで、AWS Glue シャッフルマネージャーが有効になり、チューニングされます。これらのパラメータはフラグなので、指定された値は考慮されません。 + `--write-shuffle-files-to-s3` – メインフラグです。Amazon S3 バケットを使用してシャッフルデータの書き込みと読み込みを行う AWS Glue Spark シャッフルマネージャーが有効になります。フラグを指定しない場合、シャッフルマネージャーは使用されません。 + `--write-shuffle-spills-to-s3` – (AWS Glue バージョン 2.0 でのみサポートされています)。オプションのフラグです。スピルファイルを Amazon S3 バケットにオフロードできます。これにより、Spark ジョブの耐障害性が強化されます。これは、大量のデータをディスクに退避させる大規模なワークロードにのみ必要です。フラグが指定されていない場合、中間スピルファイルは書き込まれません。 + ` --conf spark.shuffle.glue.s3ShuffleBucket=s3://` – 別のオプションのフラグです。シャッフルファイルを書き込む Amazon S3 バケットを指定します。デフォルトでは、`--TempDir`/shuffle data です。AWS Glue 3.0 以降では、`--conf spark.shuffle.glue.s3ShuffleBucket=s3://shuffle-bucket-1/prefix,s3://shuffle-bucket-2/prefix/` のようにバケットをカンマ区切りで指定することで、シャッフルファイルを複数のバケットに書き込むことができます。複数のバケットを使用するとパフォーマンスが向上します。 シャッフルデータの保存時の暗号化を有効にするには、セキュリティ構成設定を提供する必要があります。　 セキュリティの構成の詳細については、「[AWS Glue での暗号化のセットアップ](set-up-encryption.md)」を参照してください。AWS Glue は、Spark が提供する他のすべてのシャッフル関連の構成をサポートします。 **クラウドシャッフルストレージプラグインのソフトウェアバイナリ** また、Apache 2.0 ライセンスで Cloud Shuffle Storage Plugin for Apache Spark のソフトウェアバイナリをダウンロードして、任意の Spark 環境で実行することもできます。新しいプラグインは Amazon S3 をそのまま使えるようにサポートしており、[Google クラウドストレージや Microsoft Azure Blob ストレージ](https://github.com/aws-samples/aws-glue-samples/blob/master/docs/cloud-shuffle-plugin/README.md)などの他の形式のクラウドストレージを使用するように簡単に設定することもできます。詳細については、「[Cloud Shuffle Storage Plugin for Apache Spark](https://docs.aws.amazon.com/glue/latest/dg/cloud-shuffle-storage-plugin.html)」を参照してください。 **注意事項と制限事項** AWS Glue シャッフルマネージャーには次の注意事項や制限事項があります。 + AWS Glue シャッフルマネージャーは、ジョブの完了後に Amazon S3 バケットに保存されている (一時的な) シャッフルデータファイルを自動的に削除しません。データを確実に保護するには、Cloud Shuffle ストレージプラグインを有効にする前に、[クラウドシャッフルストレージプラグインを使用するための前提条件](#monitor-spark-shuffle-manager-prereqs) の手順に従ってください。 + データに偏りがある場合、この機能が使用できます。 # Cloud Shuffle Storage Plugin for Apache Spark Cloud Shuffle ストレージプラグインは [`ShuffleDataIO` API](https://github.com/apache/spark/blob/master/core/src/main/java/org/apache/spark/shuffle/api/ShuffleDataIO.java) と互換性のある Apache Spark プラグインで、シャッフルデータをクラウドストレージシステム (Amazon S3 など) に保存することを可能にします。この機能では、Spark アプリケーションにおいて `join`、`reduceByKey`、`groupByKey`、および `repartition` などの変換によってトリガーされることが多い、大規模なシャッフル操作用のローカルディスクストレージ容量を補充または置換できます。このため、サーバーレスデータ分析ジョブやパイプラインでの、一般的な障害やコスト対パフォーマンスの不整合を軽減するのに役立ちます。 **AWS Glue** AWS Glue バージョン 3.0 と 4.0 には、このプラグインが事前インストールされており、特別な手順なしで Amazon S3 でシャッフルが利用可能になります。Spark アプリケーションでこの機能を有効にする方法については、「[AWS Glue シャッフルマネージャーと Amazon S3](https://docs.aws.amazon.com/glue/latest/dg/monitor-spark-shuffle-manager.html) 」を参照してください。 **その他の Spark 環境** 他の Spark 環境では、このプラグインに以下の Spark 構成を設定する必要があります。 + `--conf spark.shuffle.sort.io.plugin.class=com.amazonaws.spark.shuffle.io.cloud.ChopperPlugin`: こSpark に対し、Shuffle IO 用としてこのプラグインを使用することを通知します。 + `--conf spark.shuffle.storage.path=s3://bucket-name/shuffle-file-dir`: シャッフルファイルが保存されるパスです。 **注記** このプラグインは、Spark コアクラスの 1 つを上書きします。そのため、プラグインの jar ファイルは、Spark jar に先行してロードする必要があります。プラグインを AWS Glue の外部で使用する場合は、オンプレミスの YARN 環境で `userClassPathFirst` を使用して、この処理を実行できます。 ## Spark アプリケーションへのプラグインのバンドル Spark アプリケーションをローカルで開発する際、Maven `pom.xml` にプラグインの依存関係を追加することで、Spark アプリケーションと Spark ディストリビューション (バージョン 3.1 以降) にプラグインをバンドルできます。このプラグインと Spark バージョンの詳細については、「[プラグインのバージョン](#cloud-shuffle-storage-plugin-versions)」を参照してください。 ``` ... aws-glue-etl-artifacts https://aws-glue-etl-artifacts.s3.amazonaws.com/release/ ... com.amazonaws chopper-plugin 3.1-amzn-LATEST ``` 別の方法として、以下のように AWS Glue Maven アーティファクトからバイナリを直接ダウンロードして、Spark アプリケーションにインクルードすることも可能です。 ``` #!/bin/bash sudo wget -v https://aws-glue-etl-artifacts.s3.amazonaws.com/release/com/amazonaws/chopper-plugin/3.1-amzn-LATEST/chopper-plugin-3.1-amzn-LATEST.jar -P /usr/lib/spark/jars/ ``` spark-submit の例 ``` spark-submit --deploy-mode cluster \ --conf spark.shuffle.storage.s3.path=s3:/// \ --conf spark.driver.extraClassPath= \ --conf spark.executor.extraClassPath= \ --class s3:/// \ ``` ## オプションの設定 これらは Amazon S3 シャッフルの動作を制御するための、オプションの設定値です。 + `spark.shuffle.storage.s3.enableServerSideEncryption`: ファイルのシャッフルおよびスピルのために、S3 SSE を有効化/無効化します。デフォルト値は `true` です。 + `spark.shuffle.storage.s3.serverSideEncryption.algorithm`: 使用される SSE アルゴリズム。デフォルト値は `AES256` です。 + `spark.shuffle.storage.s3.serverSideEncryption.kms.key`: aws:kms が有効になっている場合の KMS キーの ARN。 これらの構成に加え、ユースケースに応じて適切な暗号化が適用されるように `spark.hadoop.fs.s3.enableServerSideEncryption`、**その他の環境固有の構成**などの設定が必要になる場合があります。 ## プラグインのバージョン このプラグインは、AWS Glue のバージョンごとに関連付けられている Spark バージョンで、それぞれサポートされています。次の表に、AWS Glue のバージョン、Spark バージョン、およびプラグインのソフトウェアバイナリ用の Amazon S3 ロケーションと関連付けたプラグインバージョンを示します。 | AWS Glue バージョン | Spark バージョン | プラグインバージョン | Amazon S3 ロケーション | | --- | --- | --- | --- | | 3.0 | 3.1 | 3.1-amzn-LATEST | s3://aws-glue-etl-artifacts/release/com/amazonaws/chopper-plugin/3.1-amzn-0/chopper-plugin-3.1-amzn-LATEST.jar | | 4.0 | 3.3 | 3.3-amzn-LATEST | s3://aws-glue-etl-artifacts/release/com/amazonaws/chopper-plugin/3.3-amzn-0/chopper-plugin-3.3-amzn-LATEST.jar | ## ライセンス このプラグインのソフトウェアバイナリは、Apache-2.0 License の下でライセンスされています。 # モニタリングAWS GlueSpark ジョブ **Topics** + [AWS Glue Studio で使用可能な Spark メトリクス](#console-jobs-details-metrics-spark) + [Apache Spark ウェブ UI を使用したジョブのモニタリング](monitor-spark-ui.md) + [AWS Glue ジョブ実行インサイトでのモニタリング](monitor-job-insights.md) + [Amazon CloudWatch によるモニタリング](monitor-cloudwatch.md) + [ジョブのモニタリングとデバッグ](monitor-profile-glue-job-cloudwatch-metrics.md) ## AWS Glue Studio で使用可能な Spark メトリクス [**Metrics**] (メトリクス) タブには、ジョブが実行され実行とプロファイリングが有効になっているときに収集されるメトリクスが表示されます。以下のグラフが Spark ジョブに表示されます。 + ETL データ移動 + メモリプロファイル: ドライバーおよびエグゼキュター [**View additional metrics (追加のメトリクスの表示)**] を選択し、以下のグラフを表示します。 + ETL データ移動 + メモリプロファイル: ドライバーおよびエグゼキュター + エグゼキュター間のデータシャッフル + CPU 負荷: ドライバーおよびエグゼキュター + ジョブの実行: アクティブなエグゼキュター、完了したステージ、必要な最大エグゼキュター これらのグラフのデータは、ジョブでメトリクスの収集が有効になっている場合に CloudWatch メトリクスにプッシュされます。メトリクスを有効にしてグラフを解釈する方法の詳細については、「[ジョブのモニタリングとデバッグ](monitor-profile-glue-job-cloudwatch-metrics.md)」を参照してください。 **Example ETL データ移動グラフ** ETL データ移動グラフには、以下のメトリクスが表示されます。 + すべてのエグゼキュターにより Amazon S3 から読み取られたバイト数 – [`glue.ALL.s3.filesystem.read_bytes`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) + すべてのエグゼキュターにより Amazon S3 に書き込まれたバイト数 – [`glue.ALL.s3.filesystem.write_bytes`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) ![\[AWS Glue コンソールの [Metrics] (メトリクス) タブに表示された ETL データ変動のグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/job_detailed_etl.png) **Example メモリプロファイルグラフ** メモリプロファイルグラフには、以下のメトリクスが表示されます。 + このドライバーの JVM ヒープにより使用されるメモリの割合を、スケール 0～1 で、ドライバーごと、*executorId* により識別されるエグゼキュターごと、またはすべてのエグゼキュターごとに表示 – + [`glue.driver.jvm.heap.usage`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage) + [`glue.executorId.jvm.heap.usage`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.usage) + [`glue.ALL.jvm.heap.usage`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) ![\[AWS Glue コンソールの [Metrics] (メトリクス) タブに表示されたメモリプロファイルのグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/job_detailed_mem.png) **Example エグゼキュター間のデータシャッフルグラフ** エグゼキュター間でのデータシャッフルグラフには、以下のメトリクスが表示されます。 + すべてのエグゼキュター間でデータをシャッフルするためにそれらのエグゼキュターにより読み取られたバイト数 — [`glue.driver.aggregate.shuffleLocalBytesRead`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead) + すべてのエグゼキュター間でデータをシャッフルするためにそれらのエグゼキュターにより書き込まれたバイト数 — [`glue.driver.aggregate.shuffleBytesWritten`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten) ![\[AWS Glue コンソールの [Metrics] (メトリクス) タブに表示されたエグゼキュター間でのデータシャッフルのグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/job_detailed_data.png) **Example CPU ロードグラフ** CPU ロードグラフには、以下のメトリクスが表示されます。 + 使用された CPU システムロードの割合を、スケール 0～1 で、ドライバーごと、*executorId* により識別されるエグゼキュターごと、またはすべてのエグゼキュターごとに表示 – + [`glue.driver.system.cpuSystemLoad`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.system.cpuSystemLoad) + [`glue.executorId.system.cpuSystemLoad`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.system.cpuSystemLoad) + [`glue.ALL.system.cpuSystemLoad`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.system.cpuSystemLoad) ![\[AWS Glue コンソールの [Metrics] (メトリクス) タブに表示された CPU ロードのグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/job_detailed_cpu.png) **Example ジョブの実行グラフ** ジョブの実行グラフには、以下のメトリクスが表示されます。 + アクティブに実行されているエグゼキュターの数 — [`glue.driver.ExecutorAllocationManager.executors.numberAllExecutors`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors) + 完了したステージの数 — [`glue.aggregate.numCompletedStages`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages) + 必要なエグゼキュターの最大数 — [`glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors) ![\[AWS Glue コンソールの [Metrics] (メトリクス) タブに表示されたジョブの実行のグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/job_detailed_exec.png) # Apache Spark ウェブ UI を使用したジョブのモニタリング Apache Spark ウェブ UI を使用して、AWS Glue ジョブシステムで実行されている AWS Glue ETL ジョブと、 AWS Glue 開発エンドポイントで実行されている Spark アプリケーションをモニタリングおよびデバッグできます。Spark UI では、ジョブごとに以下の項目を確認できます。 + 各 Spark ステージのイベントタイムライン + ジョブの Directed Acyclic Graph (DAG) + SparkSQL クエリの物理プランと論理プラン + 各ジョブの基盤となる Spark 環境変数 Spark Web UI の使用の詳細については、Spark ドキュメントの「[Web UI](https://spark.apache.org/docs/3.3.0/web-ui.html)」を参照してください。Spark UI の結果を解釈してジョブのパフォーマンスを向上させる方法のガイダンスについては、「AWS 規範的ガイダンス」の「[Best practices for performance tuning AWS Glue for Apache Spark jobs](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/introduction.html)」を参照してください。 AWS Glue コンソールで Spark UI を表示できます。これは、AWS Glue ジョブが AWS Glue 3.0 以降のバージョンで実行され、新しいジョブのデフォルトである (レガシーではなく) 標準形式でログが生成される場合に使用できます。　 ログファイルが 0.5 GB を超える場合は、AWS Glue 4.0 以降のバージョンのジョブ実行のローリングログサポートを有効にして、ログのアーカイブ、分析、トラブルシューティングを簡素化できます。 Spark UI を有効にするには、AWS Glue コンソールまたは AWS Command Line Interface (AWS CLI) を使用します。Spark UI を有効にすると、AWS Glue ETL ジョブと、AWS Glue 開発エンドポイントの Spark アプリケーションの Spark イベントログを Amazon Simple Storage Service (Amazon S3) の指定した場所にバックアップできます。Amazon S3 にバックアップされたイベントログは、ジョブの実行中 (リアルタイム) でも、ジョブの完了後でも Spark UI で使用できます。ログが Amazon S3 に残っている間は、AWS Glue コンソールの Spark UI でログを表示できます。 ## アクセス許可 AWS Glue コンソールで Spark UI を使用するには、`UseGlueStudio` を使用するか、個々のサービス API をすべて追加できます。Spark UI を完全に使用するには、すべての API が必要です。ただし、ユーザーはきめ細かくアクセスするために、IAM 許可にサービス API を追加して SparkUI の機能にアクセスできます。 `RequestLogParsing` はログの解析を行うため、最も重要です。残りの API は、それぞれの解析済みデータを読み取るためのものです。たとえば、`GetStages` は Spark ジョブのすべてのステージに関するデータへのアクセスを提供します。 `UseGlueStudio` にマッピングされた Spark UI サービス API のリストは、以下のサンプルポリシーに記載されています。以下のポリシーは、Spark UI 機能のみを使用するためのアクセスを提供します。Amazon S3 や IAM などの許可をさらに追加するには、「[AWS Glue Studio のカスタム IAM ポリシーの作成](https://docs.aws.amazon.com/glue/latest/dg/getting-started-min-privs.html#getting-started-all-gs-privs.html)」を参照してください。 `UseGlueStudio` にマッピングされた Spark UI サービス API のリストは、以下のサンプルポリシーに記載されています。Spark UI サービス API を使用するとき、`glue:` という名前空間を使用してください。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowGlueStudioSparkUI", "Effect": "Allow", "Action": [ "glue:RequestLogParsing", "glue:GetLogParsingStatus", "glue:GetEnvironment", "glue:GetJobs", "glue:GetJob", "glue:GetStage", "glue:GetStages", "glue:GetStageFiles", "glue:BatchGetStageFiles", "glue:GetStageAttempt", "glue:GetStageAttemptTaskList", "glue:GetStageAttemptTaskSummary", "glue:GetExecutors", "glue:GetExecutorsThreads", "glue:GetStorage", "glue:GetStorageUnit", "glue:GetQueries", "glue:GetQuery" ], "Resource": [ "*" ] } ] } ``` ------ ## 制限事項 + AWS Glue コンソールの Spark UI は、レガシーログ形式であるため、2023 年 11 月 20 日よりも前に発生したジョブ実行には使用できません。　 + AWS Glue コンソールの Spark UI は、ストリーミング ジョブでデフォルトで生成されるログなど、AWS Glue 4.0 のローリング ログをサポートしています。生成されたすべてのロールされたログファイルの最大合計は 2 GB です。ロールログがサポートされていない AWS Glue ジョブの場合、SparkUI でサポートされるログイベントファイルの最大サイズは 0.5 GB です。 + サーバーレス Spark UI は、VPC のみがアクセスできる Amazon S3 バケットに保存されている Spark イベントログでは使用できません。 ## 例: Apache Spark Web UI この例では、Spark UI を使用してジョブのパフォーマンスを理解する方法を示します。　 スクリーンショットは、自己管理型の Spark 履歴サーバーが提供する Spark ウェブ UI を示しています。AWS Glue コンソールの Spark UI にも同様のビューが表示されます。　 Spark Web UI の使用の詳細については、Spark ドキュメントの「[Web UI](https://spark.apache.org/docs/3.3.0/web-ui.html)」を参照してください。 次の例に示す Spark アプリケーションでは、2 つのデータソースから読み取り、結合変換を実行し、それを Parquet 形式で Amazon S3 に書き込みます。　 ``` import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from pyspark.sql.functions import count, when, expr, col, sum, isnull from pyspark.sql.functions import countDistinct from awsglue.dynamicframe import DynamicFrame args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME']) df_persons = spark.read.json("s3://awsglue-datasets/examples/us-legislators/all/persons.json") df_memberships = spark.read.json("s3://awsglue-datasets/examples/us-legislators/all/memberships.json") df_joined = df_persons.join(df_memberships, df_persons.id == df_memberships.person_id, 'fullouter') df_joined.write.parquet("s3://aws-glue-demo-sparkui/output/") job.commit() ``` 次の DAG 可視化は、この Spark ジョブのさまざまなステージを示しています。 ![\[ジョブ 0 の 2 つの完了済みステージを示す Spark UI のスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/spark-ui1.png) 次に示すジョブのイベントタイムラインは、さまざまな Spark エグゼキュターの開始、実行、終了を示しています。 ![\[さまざまな Spark エグゼキュターの完了、失敗、アクティブの各ステージを示す Spark UI のスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/spark-ui2.png) 次の画面は、SparkSQL クエリプランの詳細を示しています。 + 解析された論理プラン + 分析された論理プラン + 最適化された論理プラン + 実行のための物理プラン ![\[SparkSQL クエリプラン: 解析された論理プラン、分析された論理プラン、最適化された論理プラン、および実行のための物理プラン。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/spark-ui3.png) **Topics** + [アクセス許可](#monitor-spark-ui-limitations-permissions) + [制限事項](#monitor-spark-ui-limitations) + [例: Apache Spark Web UI](#monitor-spark-ui-limitations-example) + [AWS Glue ジョブ用の Apache Spark ウェブ UI の有効化](monitor-spark-ui-jobs.md) + [Spark 履歴サーバーの起動](monitor-spark-ui-history.md) # AWS Glue ジョブ用の Apache Spark ウェブ UI の有効化 Apache Spark ウェブ UI を使用して、AWS Glue ジョブシステムで実行されている AWS Glue ETL ジョブをモニタリングおよびデバッグできます。Spark UI は、AWS Glue コンソールまたは AWS Command Line Interface (AWS CLI) を使用して設定できます。 30 秒ごとに、AWS Glue は指定した Amazon S3 パスに Spark イベントログをバックアップします。 **Topics** + [Spark UI の設定 (コンソール)](#monitor-spark-ui-jobs-console) + [Spark UI の設定 (AWS CLI)](#monitor-spark-ui-jobs-cli) + [Notebook を使用するセッション用の Spark UI の設定](#monitor-spark-ui-sessions) + [ローリングログを有効にする](#monitor-spark-ui-rolling-logs) ## Spark UI の設定 (コンソール) 以下のステップに従い、AWS マネジメントコンソールを使用して Spark UI を設定します。AWS Glue ジョブを作成する際、Spark UI はデフォルトで有効になります。　 **ジョブを作成または編集するときに Spark UI をオンにするには　** 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. ナビゲーションペインで **ジョブ**を選択します。 1. **[ジョブを追加]** を選択するか、または既存のジョブを選択します。 1. **[ジョブの詳細]** で、**[詳細プロパティ]** を開きます。 1. **[Spark UI]** タブで、**[Spark UI ログを Amazon S3 に書き込む]** を選択します。　 1. ジョブの Spark イベントログを保存するための Amazon S3 パスを指定します。ジョブでセキュリティ設定を使用する場合、暗号化は Spark UI ログファイルにも適用されることに注意してください。　 詳細については、「[AWS Glue​ によって書き込まれたデータの暗号化](encryption-security-configuration.md)」を参照してください。 1. **[Spark UI のログ記録とモニタリングの設定]** で、次のように操作します。 + AWS Glue コンソールで表示するログを生成している場合は、**[標準]** を選択します。 + Spark 履歴サーバーで表示するログを生成している場合は、**[レガシー]** を選択します。 + 両方を生成することを選択することもできます。 ## Spark UI の設定 (AWS CLI) Spark UI で表示するログを生成するには、AWS Glue コンソールで AWS CLI を使用して、次のジョブパラメータを AWS Glue ジョブに渡します。詳細については、「[AWS Glue ジョブでジョブパラメータを使用する](aws-glue-programming-etl-glue-arguments.md)」を参照してください。 ``` '--enable-spark-ui': 'true', '--spark-event-logs-path': 's3://s3-event-log-path' ``` ログをレガシーの場所に配布するには、`--enable-spark-ui-legacy-path` パラメータを `"true"` に設定します。両方の形式でログを生成したくない場合は、`--enable-spark-ui` パラメータを削除します。 ## Notebook を使用するセッション用の Spark UI の設定 **警告** AWS Glue インタラクティブセッションは現在、コンソールでの Spark UI をサポートしていません。Spark 履歴サーバーを設定します。 AWS Glue ノートブック を使用する場合は、セッションを開始する前に SparkUI の設定をセットアップします。そのためには、次のように `%%configure` セルマジックを使用します。 ``` %%configure { “--enable-spark-ui”: “true”, “--spark-event-logs-path”: “s3://path” } ``` ## ローリングログを有効にする AWS Glue ジョブの SparkUI とローリングログファイルを有効にすると、いくつかの利点があります。 + ローリングログイベントファイル – ローリングログイベントファイルを有効にすると、AWS Glue はジョブ実行の各ステップごとに個別のログファイルを生成し、特定のステージまたは変換に固有の問題の特定とトラブルシューティングを容易にします。 + ログ管理の向上 – ログファイルをローリングすると、ログファイルをより効率的に管理できます。1 つの大きなログファイルを持つ代わりに、ログはジョブ実行ステージに基づいて、より小さく管理しやすいファイルに分割されます。これにより、ログのアーカイブ、分析、トラブルシューティングを簡素化できます。 + 障害耐性の向上 – AWS Glue ジョブが失敗または中断された場合、ローリングログイベントは、最後に成功したステージに関する貴重な情報を提供するため、最初から開始するのではなく、その時点からジョブを再開しやすくなります。 + コストの最適化 – ローリングログファイルを有効にすることで、ログファイルに関連するストレージコストを削減できます。1 つの大きなログファイルを保存する代わりに、より小さく、管理しやすいログファイルを保存します。これは、特に長時間実行されるジョブや複雑なジョブの場合、費用対効果が高くなります。 新しい環境では、ユーザーは以下を通じてローリングログを明示的に有効にできます。 ``` '—conf': 'spark.eventLog.rolling.enabled=true' ``` or ``` '—conf': 'spark.eventLog.rolling.enabled=true —conf spark.eventLog.rolling.maxFileSize=128m' ``` ローリングログが有効な場合、`spark.eventLog.rolling.maxFileSize` はロールオーバーする前のイベントログファイルの最大サイズを指定します。このオプションパラメータが指定されていない場合のデフォルト値は 128 MB です。最小は 10 MB です。 生成されたすべてのロールされたログファイルの最大合計は 2 GB です。ローリングログがサポートされていない AWS Glue ジョブの場合、SparkUI でサポートされるログイベントファイルの最大サイズは 0.5 GB です。 追加の設定を渡すことで、ストリーミングジョブのローリングログをオフにすることができます。　 ログファイルが非常に大きいと、管理にコストがかかる場合があることに注意してください。　 ローリングログをオフにするには、次の設定を提供します。 ``` '--spark-ui-event-logs-path': 'true', '--conf': 'spark.eventLog.rolling.enabled=false' ``` # Spark 履歴サーバーの起動 Spark 履歴サーバーを使用して、独自のインフラストラクチャ上で Spark ログを視覚化できます。(レガシーではなく) 標準形式で生成されたログで、AWS Glue 4.0 以降のバージョンで AWS Glue ジョブが実行された場合、AWS Glue コンソールで同じ視覚化を確認することができます。詳細については、「[Apache Spark ウェブ UI を使用したジョブのモニタリング](monitor-spark-ui.md)」を参照してください。 EC2 インスタンスでサーバーをホストする AWS CloudFormation テンプレートを使用して Spark 履歴サーバーを起動するか、Docker を使用してローカルで起動できます。 **Topics** + [AWS CloudFormation を使用した Spark 履歴サーバーの起動と Spark UI の表示](#monitor-spark-ui-history-cfn) + [Docker を使用した Spark 履歴サーバーの起動と Spark UI の表示](#monitor-spark-ui-history-local) ## AWS CloudFormation を使用した Spark 履歴サーバーの起動と Spark UI の表示 AWS CloudFormation テンプレートを使用して Apache Spark 履歴サーバーを起動し、Spark ウェブ UI を表示できます。これらのテンプレートは、要件に応じて変更する必要があるサンプルです。 **CloudFormation を使用して Spark 履歴サーバーを起動し、Spark UI を表示するには** 1. 次の表に示す**起動スタック**ボタンの 1 つを選択します。これにより、CloudFormation コンソールでスタックが起動されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitor-spark-ui-history.html) 1. [**Specify template (テンプレートの指定)**] ページで、[**次へ**] を選択します。 1. [**Specify stack details (スタック詳細の指定)**] ページで、[**Stack name (スタック名)**] に入力します。**パラメータ**の下に追加情報を入力します。 1. **Spark UI の設定** 以下の情報を指定します。 + **IP アドレス範囲** – Spark UI の表示に使用できる IP アドレス範囲。特定の IP アドレス範囲からのアクセスを制限する場合は、カスタム値を使用する必要があります。 + **履歴サーバーポート** – Spark UI のポート。デフォルト値を使用できます。 + **イベントログディレクトリ** – AWS Glue ジョブまたは開発エンドポイントから保存された Spark イベントログの場所を選択します。イベントログのパススキームとして **s3a://** を使用する必要があります。 + **Spark パッケージの場所** – デフォルト値を使用できます。 + **キーストアパス** – HTTPS の SSL/TLS キーストアパス。カスタムキーストアファイルを使用する場合は、ここで S3 パス `s3://path_to_your_keystore_file` を指定できます。このパラメータを空のままにすると、自己署名証明書ベースのキーストアが生成されて使用されます。 + **キーストアパスワード** – HTTPS 用の SSL/TLS キーストアパスワードを入力します。 1. **EC2 インスタンスの設定** 以下の情報を指定します。 + **インスタンスタイプ** – Spark 履歴サーバーをホストする Amazon EC2 インスタンスのタイプ。このテンプレートによってアカウントで Amazon EC2 インスタンスが起動されるため、Amazon EC2 のコストがアカウントに別個に課金されます。 + **最新の AMI ID** – Spark 履歴サーバーインスタンスの Amazon Linux 2 の AMI ID。デフォルト値を使用できます。 + **VPC ID** – Spark 履歴サーバーインスタンスの Virtual Private Cloud (VPC) の ID。アカウントで利用可能な VPC のいずれかを使用できます。デフォルトの VPC と [デフォルトのネットワーク ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#default-network-acl) を使用することは推奨されません。詳細については、「*Amazon VPC ユーザーガイド*」の「[デフォルト VPC とデフォルトサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html)」および「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC)」を参照してください。 + **サブネット ID** – Spark 履歴サーバーインスタンスの ID。VPC 内の任意のサブネットを使用できます。クライアントからサブネットのネットワークにアクセスできる必要があります。インターネット経由でアクセスする場合は、ルートテーブルにインターネットゲートウェイがあるパブリックサブネットを使用する必要があります。 1. [**次へ**] を選択します。 1. [**Configure stack options**] ページで、CloudFormation がスタック内のリソースを作成、変更、または削除する方法を決定するために現在のユーザー認証情報を使用する場合は、[Next] をクリックします。**アクセス許可**セクションで、現在のユーザー権限の代わりに使用するロールを指定し、**[次へ]** を選択することもできます。 1. [**確認**] ページで、テンプレートを確認します。 [**I acknowledge that CloudFormation might create IAM resources**] (CloudFormation によって IAM リソースが作成される場合があることを承認します) を選択し、[**Create stack**] (スタックの作成) を選択します。 1. スタックが作成されるまで待ちます。 1. [**Outputs (出力)**] タブをクリックします。 1. パブリックサブネットを使用している場合は、 **SparkUiPublicUrl** の URL をコピーします。 1. プライベートサブネットを使用している場合は、 **SparkUiPrivateUrl** の URL をコピーします。 1. ウェブブラウザを開き、URL を貼り付けます。これにより、指定したポートで HTTPS を使用してサーバーにアクセスできます。ブラウザがサーバーの証明書を認識しない場合があります。この場合、保護を上書きして続行する必要があります。 ## Docker を使用した Spark 履歴サーバーの起動と Spark UI の表示 ローカルアクセスを希望する (Apache Spark 履歴サーバーの EC2 インスタンスを使用しない) 場合は、Docker を使用して Apache Spark 履歴サーバーを起動し、Spark UI をローカルに表示することもできます。この Dockerfile は、要件に応じて変更する必要があるサンプルです。 **前提条件** ラップトップに Docker をインストールする方法については、[Docker Engine community](https://docs.docker.com/install/) を参照してください。 **Docker を使用して Spark 履歴サーバーを起動し、Spark UI をローカルに表示するには** 1. GitHub からファイルをダウンロードします。 Dockerfileと`pom.xml` を [[ AWS Glueコードサンプル](https://github.com/aws-samples/aws-glue-samples/tree/master/utilities/Spark_UI/)]からダウンロードします。 1. アクセス AWS にユーザー認証情報を使用するか、フェデレーティッドユーザー認証情報を使用するかを決定します。 + 現在のユーザー認証情報を使用してアクセスを AWS にするには、` AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` で使用する値を `docker run` コマンドで取得します。詳細については、「IAM ユーザーガイド」の「[IAM ユーザーのアクセスキーの管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)」を参照してください。 + SAML 2.0 フェデレーティッドユーザーを使用して AWS にアクセスするには、` AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY`、` AWS_SESSION_TOKEN` で値を取得します。詳細については、「[一時的なセキュリティ認証情報のリクエスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)」を参照してください。 1. `docker run` コマンドで使用するイベントログディレクトリの場所を決定します。 1. ローカルディレクトリ内のファイルを使用して、名前 ` glue/sparkui` とタグ `latest` を指定して、Docker イメージを構築します。 ``` $ docker build -t glue/sparkui:latest . ``` 1. Docker コンテナを作成してスタートします。 次のコマンドでは、ステップ 2 および 3 で事前に取得した値を使用します。 1. ユーザー認証情報を使用して docker コンテナを作成するには、次のようなコマンドを使用します。 ``` docker run -itd -e SPARK_HISTORY_OPTS="$SPARK_HISTORY_OPTS -Dspark.history.fs.logDirectory=s3a://path_to_eventlog -Dspark.hadoop.fs.s3a.access.key=AWS_ACCESS_KEY_ID -Dspark.hadoop.fs.s3a.secret.key=AWS_SECRET_ACCESS_KEY" -p 18080:18080 glue/sparkui:latest "/opt/spark/bin/spark-class org.apache.spark.deploy.history.HistoryServer" ``` 1. 一時的な認証情報を使用して Docker コンテナを作成するには、` org.apache.hadoop.fs.s3a.TemporaryAWSCredentialsProvider` をプロバイダとして指定し、ステップ 2 で取得した認証情報値を指定します。詳細については、「[一時的な AWSCredentialsProvider でのセッション資格情報の使用](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html#Using_Session_Credentials_with_TemporaryAWSCredentialsProvider)の*Hadoop: Amazon Web Services との統合*」のドキュメント を参照してください。 ``` docker run -itd -e SPARK_HISTORY_OPTS="$SPARK_HISTORY_OPTS -Dspark.history.fs.logDirectory=s3a://path_to_eventlog -Dspark.hadoop.fs.s3a.access.key=AWS_ACCESS_KEY_ID -Dspark.hadoop.fs.s3a.secret.key=AWS_SECRET_ACCESS_KEY -Dspark.hadoop.fs.s3a.session.token=AWS_SESSION_TOKEN -Dspark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.TemporaryAWSCredentialsProvider" -p 18080:18080 glue/sparkui:latest "/opt/spark/bin/spark-class org.apache.spark.deploy.history.HistoryServer" ``` **注記** これらの設定パラメータは、[ Hadoop-AWS モジュール](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html)に由来します。場合によっては、ユースケースに基づいて特定の設定を追加する必要があります。たとえば、隔離されたリージョンのユーザーは、` spark.hadoop.fs.s3a.endpoint` を設定する必要があります。 1. ブラウザで `http://localhost:18080` を開き、Spark UI をローカルに表示します。 # AWS Glue ジョブ実行インサイトでのモニタリング AWS Glue ジョブ実行インサイトは、AWS Glue ジョブのデバッグとジョブの最適化を簡素化する AWS Glue の機能です。AWS Glue は、[Spark UI](https://docs.aws.amazon.com/glue/latest/dg/monitor-spark-ui.html)、および AWS Glue ジョブをモニタリングするための[CloudWatch Logs とメトリクス](https://docs.aws.amazon.com/glue/latest/dg/monitor-cloudwatch.html)を提供します。この機能を使用すると、AWS Glue ジョブの実行に関する情報を取得できます: + エラーが発生した AWS Glue ジョブスクリプトの行番号。 + ジョブの失敗の直前に Spark クエリプランで最後に実行された Spark アクション。 + 時系列ログストリームに表示される障害に関連する Spark 例外イベント。 + 根本原因の分析と、問題を解決するための推奨アクション（スクリプトのチューニングなど）。 + 根本原因に対処する推奨アクションを含む共通の Spark イベント（Spark アクションに関連するログメッセージ）。 これらのインサイトはすべて、AWS Glue ジョブの CloudWatch Logs 内の 2 つの新しいログストリームを使用して利用できます。 ## 要件 AWS Glue ジョブ実行インサイト機能は、AWS Glue バージョン 2.0 以降で利用できます。既存のジョブの[移行ガイド](https://docs.aws.amazon.com/glue/latest/dg/migrating-version-30.html)に従って、古い AWS Glue バージョンからアップグレードすることができます。 ## AWS Glue ETL ジョブのジョブ実行インサイトの有効化 ジョブ実行インサイトは、AWS Glue Studio または CLI によって有効にできます。 ### AWS Glue Studio AWS Glue Studio でジョブを作成する場合、[**ジョブの詳細**] タブでジョブ実行インサイトを有効または無効にすることができます。**[ジョブインサイトを生成する]** ボックスが選択されていることを確認します。 ![\[AWS Glue Studio でのジョブ実行インサイトの有効化。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-job-run-insights-1.png) ### コマンドライン CLI を使用してジョブを作成する場合は、単一の新しい[ジョブパラメータ](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-glue-arguments.html)でジョブの実行を開始できます: `--enable-job-insights = true`。 デフォルトでは、ジョブ実行インサイトログストリームは、[AWS Glue連続ログ記録](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuous-logging.html) (つまり `/aws-glue/jobs/logs-v2/`)で使用されるのと同じデフォルトロググループの下に作成されます。連続ログ記録に同じ引数のセットを使用して、カスタムロググループ名、ログフィルター、およびロググループ構成を設定できます。詳細については、「[AWS Glue ジョブの連続ログ記録の有効化](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuous-logging-enable.html)」を参照してください。 ## CloudWatch でのジョブ実行インサイトログストリームへのアクセス ジョブ実行インサイト機能を有効にすると、ジョブ実行が失敗したときに 2 つのログストリームが作成されることがあります。ジョブが正常に終了すると、いずれのストリームも生成されません。 1. *例外分析ログストリーム*:`-job-insights-rca-driver`。このストリームは、以下を提供します: + エラーが発生した AWS Glue ジョブスクリプトの行番号。 + Spark クエリプラン (DAG) で最後に実行された Spark アクション。 + Spark ドライバおよび例外に関連するエグゼキュータからの簡潔な時系列イベント。完全なエラーメッセージ、失敗した Spark タスク、およびそのエグゼキューター ID などの詳細を調べて、必要に応じてさらに詳細な調査を行うために、特定のエグゼキューターのログストリームに集中できます。 1. *ルールベースのインサイトストリーム*: + エラーの修正方法に関する根本原因の分析とレコメンデーション（特定のジョブパラメータを使用してパフォーマンスを最適化するなど）。 + 関連する Spark イベントは、根本原因の分析および推奨アクションの基礎として機能します。 **注記** 最初のストリームは、失敗したジョブ実行で例外の Spark イベントが使用できる場合にのみ存在し、2 番目のストリームは、失敗したジョブ実行に対して利用可能なインサイトがある場合にのみ存在します。例えば、ジョブが正常に終了した場合、どちらのストリームも生成されません。ジョブが失敗しても、失敗シナリオと一致するサービス定義のルールがない場合は、最初のストリームだけが生成されます。 AWS Glue Studio からジョブが作成された場合、上記のストリームへのリンクは、[ジョブ実行の詳細] タブ (ジョブ実行インサイト) の下で「簡潔で統合されたエラーログ」および「エラー分析とガイダンス」としても使用できます。 ![\[ログストリームへのリンクを含む [ジョブ実行の詳細] ページ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-job-run-insights-2.png) ## AWS Glue ジョブ実行インサイトの例 このセクションでは、ジョブ実行インサイト機能が、失敗したジョブの問題を解決するためにどのように役立つかの例を紹介します。この例では、ユーザーは AWS Glue ジョブで必要なモジュール (tensorflow) をインポートし、データに基づいて機械学習モデルを分析および構築するのを忘れていました。 ``` import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from pyspark.sql.types import * from pyspark.sql.functions import udf,col args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) data_set_1 = [1, 2, 3, 4] data_set_2 = [5, 6, 7, 8] scoresDf = spark.createDataFrame(data_set_1, IntegerType()) def data_multiplier_func(factor, data_vector): import tensorflow as tf with tf.compat.v1.Session() as sess: x1 = tf.constant(factor) x2 = tf.constant(data_vector) result = tf.multiply(x1, x2) return sess.run(result).tolist() data_multiplier_udf = udf(lambda x:data_multiplier_func(x, data_set_2), ArrayType(IntegerType(),False)) factoredDf = scoresDf.withColumn("final_value", data_multiplier_udf(col("value"))) print(factoredDf.collect()) ``` ジョブ実行インサイト機能がないと、ジョブが失敗すると、Spark によってスローされる次のメッセージのみが表示されます。 `An error occurred while calling o111.collectToPython. Traceback (most recent call last):` メッセージがあいまいなので、デバッグ体験が制限されます。この場合、この機能は 2 つの CloudWatch Logs ストリームに追加のインサイトを提供します。 1. `job-insights-rca-driver` ログストリーム: + *例外イベント*: このログストリームは、Spark ドライバおよびさまざまな分散ワーカーから収集された障害に関連する Spark 例外イベントを提供します。これらのイベントは、障害のあるコードが Spark タスク、エグゼキューター、および AWS Glue ワーカーに分散されたステージ全体で実行されるときに、例外の時系列の伝播を理解するのに役立ちます。 + *行番号*: このログストリームは、失敗の原因となった欠落している Python モジュールをインポートするための呼び出しを行った 21 行目を識別します。 また、スクリプトで最後に実行された行として、Spark アクション `collect()` の呼び出しである 24 行目も識別します。 ![\[job-insights-rca-driver ログストリーム。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-job-run-insights-3.png) 1. `job-insights-rule-driver` ログストリーム: + *根本原因とレコメンデーション*：スクリプトの障害の行番号と最後に実行された行番号に加えて、このログストリームには、根本原因の分析と、AWS Glue ドキュメントに従って、AWS Glue ジョブの追加の Python モジュールを使用するために必要なジョブパラメーターを設定するためのレコメンデーションが表示されます。 + *基本イベント*: このログストリームには、根本原因を推測してレコメンデーションを提供するために、サービス定義ルールで評価された Spark 例外イベントも表示されます。 ![\[job-insights-rule-driver ログストリーム。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-job-run-insights-4.png) # Amazon CloudWatch によるモニタリング Amazon CloudWatch を使用して AWS Glue をモニタリングすることで、AWS Glue から raw データを収集し、ほぼリアルタイムの読み取り可能なメトリクスに加工することができます。これらの統計は 2 週間記録されるため、履歴情報にアクセスしてウェブアプリケーションまたはサービスの動作をより的確に把握することができます。デフォルトでは、AWS Glue メトリクスデータは CloudWatch に自動的に送信されます。詳細については、*Amazon CloudWatch ユーザーガイド*の「[Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html)」、および「[AWS Glue のメトリクス](monitoring-awsglue-with-cloudwatch-metrics.md#awsglue-metrics)」を参照してください。 **継続的なログ記録** AWS Glue は、AWS Glue ジョブのリアルタイムの連続ログ記録もサポートします。ジョブの連続ログ記録が有効になっている場合は、AWS Glue コンソールまたは CloudWatch コンソールダッシュボードでリアルタイムのログを表示できます。詳細については、「[AWS Glue ジョブのログ記録](monitor-continuous-logging.md)」を参照してください。 **オブザーバビリティメトリクス** **[ジョブのオブザーバビリティメトリクス]** が有効になっている場合、ジョブの実行時に追加の Amazon CloudWatch メトリクスが生成されます。AWS Glue オブザーバビリティメトリクスを使用して、AWS Glue の内部で何が起こっているかに関するインサイトを生成し、問題の優先順位付けと分析を改善できます。 **Topics** + [Amazon CloudWatch メトリクスを使用した AWS Glue のモニタリング](monitoring-awsglue-with-cloudwatch-metrics.md) + [AWS Glue ジョブプロファイルでの Amazon CloudWatch アラームの設定](monitor-profile-glue-job-cloudwatch-alarms.md) + [AWS Glue ジョブのログ記録](monitor-continuous-logging.md) + [AWS Glue オブザーバビリティメトリクスを使用したモニタリング](monitor-observability.md) # Amazon CloudWatch メトリクスを使用した AWS Glue のモニタリング AWS Glue ジョブプロファイラーを使用して AWS Glue オペレーションをプロファイルおよびモニタリングできます。AWS Glue ジョブから raw データが収集され、ほぼリアルタイムの読み取り可能なメトリクスに加工されて、Amazon CloudWatch に保存されます。これらの統計は CloudWatch に保持されて集計されるため、履歴情報にアクセスしてアプリケーションの動作をより的確に把握できます。 **注記** ジョブメトリクスを有効にし、CloudWatch カスタムメトリクスが作成されると、追加料金が発生することがあります。詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。 ## AWS Glue メトリクスの概要 AWS Glue を操作するときに、CloudWatch にメトリクスが送信されます。これらのメトリクスは、AWS Glue コンソール (推奨される方法)、CloudWatch コンソールダッシュボード、または AWS Command Line Interface (AWS CLI) で表示できます。 **AWS Glue コンソールダッシュボードを使ってメトリクスを表示するには** ジョブのメトリクスの概要または詳細なグラフを表示したり、ジョブの実行の詳細なグラフを表示したりできます。 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. ナビゲーションペインで、**[ジョブ実行モニタリング]** を選択します。 1. **[Job の実行]** で **[アクション]** を選択して、現在実行中のジョブの停止、ジョブの表示、またはジョブのブックマークの巻き戻しを実行します。 1. ジョブを選択し、**[実行の詳細を表示する]** を選択すると、そのジョブ実行に関する追加情報が表示されます。 **CloudWatch コンソールダッシュボードを使用してメトリクスを表示するには** メトリクスはまずサービスの名前空間ごとにグループ化され、次に各名前空間内のさまざまなディメンションの組み合わせごとにグループ化されます。 1. CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。 1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。 1. [**Glue**] 名前空間を選択します。 **AWS CLI を使ってメトリクスを表示するには** + コマンドプロンプトで、次のコマンドを使用します。 ``` 1. aws cloudwatch list-metrics --namespace Glue ``` メトリクスは 30 秒ごとに AWS Glue から CloudWatch に報告され、CloudWatch メトリクスダッシュボードは 1 分ごとにそれらを表示するように設定されています。AWS Glue メトリクスは、以前に報告された値からデルタ値を表示します。必要に応じて、メトリクスのダッシュボードにより 30 秒の値が集計 (合計) され、直近 1 分間分の値を取得できます。 ### Spark ジョブの AWS Glue メトリクス動作 AWS Glue メトリクスは、スクリプトでの `GlueContext` の初期化時に有効になり、基本的には Apache Spark タスクの終了時にのみ更新されます。また、これまでに完了した Spark タスク全体の集計値を表します。 ただし、AWS Glue が CloudWatch に渡す Spark メトリクスは、一般的に報告された時点で現在の状態を表す絶対値です。それらは 30 秒ごとに AWS Glue から CloudWatch に報告され、一般的にメトリクスダッシュボードには直近 1 分間に受け取ったデータポイントの平均が表示されます。 すべての AWS Glue メトリクス名の前には、必ず次のいずれかの種類のプレフィックスが付きます。 + `glue.driver.` – 名前がこのプレフィックスで始まるメトリクスは、Spark ドライバーのすべてのエグゼキュターから集計された AWS Glue メトリクスか、Spark ドライバーに対応する Spark メトリクスを表します。 + `.`*executorId*`glue.` – *executorId* は、特定の Spark エグゼキュターの番号です。ログに表示されているエグゼキュータに対応します。 + `glue.ALL.` – 名前がこのプレフィックスで始まるメトリクスは、すべての Spark エグゼキュターからの値を集計します。 ## AWS Glue のメトリクス AWS Glue によって、プロファイルが作成され、次のメトリクスが 30 秒ごとに CloudWatch に送信され、AWS Glue メトリクスダッシュボードに 1 分に 1 回表示されます。 | メトリクス | 説明 | | --- | --- | | `glue.driver.aggregate.bytesRead` | すべてのエグゼキュターで実行され完了したすべての Spark タスクによるすべてのデータソースから読み取られたバイト数。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。 単位: バイト 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) このメトリクスは、`glue.ALL.s3.filesystem.read_bytes` メトリクスと同様に使用できます。ただし、このメトリクスは Spark タスクの最後に更新され、S3 以外のデータソースも取得するという点が異なります。 | | `glue.driver.aggregate.elapsedTime` | ETL の経過時間 (ミリ秒単位) (ジョブのブートストラップ時間は含まれません)。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。 単位: ミリ秒 ジョブの実行に平均どのくらいの時間がかかるかを調べるために利用できます。 データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.numCompletedStages` | ジョブの完了したステージの数 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。 単位: 数 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.numCompletedTasks` | ジョブで完了したタスクの数。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。 単位: 数 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.numFailedTasks` | 失敗したタスクの数。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。 単位: 数 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データを使用して、データ、クラスター、スクリプトの異常を示唆する可能性のある障害の増加に対するアラームを設定できます。 | | `glue.driver.aggregate.numKilledTasks` | 強制終了したタスクの数。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。 単位: 数 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.recordsRead` | すべてのエグゼキュターで実行され完了したすべての Spark タスクによるすべてのデータソースから読み取られたレコードの数。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。 単位: 数 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) このメトリクスは、`glue.ALL.s3.filesystem.read_bytes` メトリクスと同様に使用できますが、このメトリクスは Spark タスクの最後に更新される点が異なります。 | | `glue.driver.aggregate.shuffleBytesWritten` | 前のレポート以降にデータをシャッフルするためにそれらのエグゼキュターにより書き込まれたバイト数 (直前の 1 分間にこの目的のために書き込まれたバイト数として AWS Glue メトリクスダッシュボードにより集計)。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。 単位: バイト ジョブのデータシャッフル (大規模な結合、グループ化、再分割、合体) をモニタリングするために使用できます。 データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.shuffleLocalBytesRead` | 前のレポート以降にデータをシャッフルするためにそれらのエグゼキュターにより読み取られたバイト数 (直前の 1 分間にこの目的のために読み取られたバイト数として AWS Glue メトリクスダッシュボードにより集計)。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。 単位: バイト ジョブのデータシャッフル (大規模な結合、グループ化、再分割、合体) をモニタリングするために使用できます。 データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.BlockManager.disk.diskSpaceUsed_MB` | すべてのエグゼキュターで使用されたディスク領域のメガバイト数。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (ゲージ)。 有効な統計: Average これは Spark メトリクスで、絶対値としてレポートされます。 単位: メガバイト 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.ExecutorAllocationManager.executors.numberAllExecutors` | アクティブに実行されているジョブエグゼキュターの数。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (ゲージ)。 有効な統計: Average これは Spark メトリクスで、絶対値としてレポートされます。 単位: 数 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors` | 現在の負荷を満たすために必要な (アクティブに実行中および保留中の) ジョブエグゼキュターの最大数。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (ゲージ)。 有効な統計: Maximum。これは Spark メトリクスで、絶対値としてレポートされます。 単位: 数 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.jvm.heap.usage` `glue.`*executorId*`.jvm.heap.usage` `glue.ALL.jvm.heap.usage` | ドライバー、executorId により識別されるエグゼキュター、またはすべてのエグゼキュターに対する、このドライバー (スケール: 0～1) の JVM ヒープにより使用されるメモリの割合。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (ゲージ)。 有効な統計: Average これは Spark メトリクスで、絶対値としてレポートされます。 単位: パーセント 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.jvm.heap.used` `glue.`*executorId*`.jvm.heap.used` `glue.ALL.jvm.heap.used` | ドライバー、*executorId* によって特定されたエグゼキュター、またはすべてのエグゼキュターのために JVM ヒープが使用したメモリバイト数。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (ゲージ)。 有効な統計: Average これは Spark メトリクスで、絶対値としてレポートされます。 単位: バイト 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.s3.filesystem.read_bytes` `glue.`*executorId*`.s3.filesystem.read_bytes` `glue.ALL.s3.filesystem.read_bytes` | 前のレポート以降に、ドライバー、*executorId* によって特定されるエグゼキュター、またはすべてのエグゼキュターが Amazon S3 から読み取ったバイト数 (直前 1 分間に読み取ったバイト数として AWS Glue メトリクスダッシュボードに集計されます)。 有効なディメンション: `JobName`、`JobRunId`、および `Type` (ゲージ)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。AWS Glue メトリクスダッシュボードのカーブの下にある領域は、2 つの異なるジョブ実行によって読み取られたバイト数を視覚的に比較するために使用できます。 単位: バイト 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) 結果データは、次の目的で使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.s3.filesystem.write_bytes` `glue.`*executorId*`.s3.filesystem.write_bytes` `glue.ALL.s3.filesystem.write_bytes` | 前のレポート以降に、ドライバー、*executorId* によって特定されるエグゼキュター、またはすべてのエグゼキュターが Amazon S3 に書き込んだバイト数 (直前 1 分間に書き込んだバイト数として AWS Glue メトリクスダッシュボードに集計されます)。 有効なディメンション: `JobName`、`JobRunId`、および `Type` (ゲージ)。 有効な統計: SUM。このメトリクスは、最後に報告された値からのデルタ値であるため、AWS Glue メトリクスダッシュボードでは、集計に SUM 統計が使用されます。AWS Glue メトリクスダッシュボードのカーブの下にある領域は、2 つの異なるジョブ実行によって書き込まれたバイト数を視覚的に比較するために使用できます。 単位: バイト 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.streaming.numRecords` | マイクロバッチで受信されたレコードの数。このメトリクスは AWS Glue バージョン 2.0 以降の AWS Glue ストリーミングジョブにのみ使用できます。です。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: Sum, Maximum, Minimum, Average, Percentile 単位: 数 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.streaming.batchProcessingTimeInMs` | バッチの処理に要する時間 (ミリ秒単位)。このメトリクスは AWS Glue バージョン 2.0 以降の AWS Glue ストリーミングジョブにのみ使用できます。です。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (カウント)。 有効な統計: Sum, Maximum, Minimum, Average, Percentile 単位: 数 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.system.cpuSystemLoad` `glue.`*executorId*`.system.cpuSystemLoad` `glue.ALL.system.cpuSystemLoad` | ドライバー、*executorId* により識別されるエグゼキュター、またはすべてのエグゼキュターに対する使用された CPU システムロードの割合 (スケール: 0 ～ 1)。 有効なディメンション: `JobName` (AWS Glue Job の名前)、`JobRunId` (JobRun ID. または `ALL`)、`Type` (ゲージ)。 有効な統計: Average このメトリクスは絶対値としてレポートされます。 単位: パーセント 次のモニタリングに使用できます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) データの使用法をいくつか次に示します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | ## AWS Glue メトリクスのディメンション AWS Glue メトリクスは AWS Glue 名前空間を使用し、以下のディメンションのメトリクスを提供しています。 | ディメンション | 説明 | | --- | --- | | `JobName` | このディメンションで、特定の AWS Glue ジョブのすべてのジョブ実行のメトリクスがフィルタリングされます。 | | `JobRunId` | このディメンションで、JobRun ID によって特定の AWS Glue ジョブ実行のメトリクスがフィルタリングされるか、`ALL` となります。 | | `Type` | このディメンションで、`count` (集計した数) または `gauge` (ある時点での値) によってメトリクスがフィルタリングされます。 | 詳細については、「[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)」を参照してください。 # AWS Glue ジョブプロファイルでの Amazon CloudWatch アラームの設定 AWS Glue メトリクスは、Amazon CloudWatch でも利用できます。スケジュールされたジョブのどの AWS Glue メトリクスでもアラームを設定できます。 アラームを設定するいくつかの一般的なシナリオは次のとおりです。 + ジョブのメモリ不足 (OOM): メモリ使用率が AWS Glue ジョブのドライバーまたはエグゼキュターの通常平均を超えた場合にアラームを設定します。 + 散在したエグゼキュター: AWS Glue ジョブでエグゼキュターの数が長時間一定のしきい値を下回ったときにアラームを設定します。 + データバックログまたは再処理: CloudWatch の数式を使用して、ワークフローの個別のジョブから得られたメトリクスを比較します。その後、生成された式の値 (あるジョブにより書き込まれたバイトと後続のジョブにより読み込まれたバイトの割合など) でアラームをトリガーできます。 アラームの設定に関する詳細については、「*[Amazon CloudWatch Events ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/)*」の「[Create or Edit a CloudWatch Alarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)」を参照してください。 CloudWatch を使用したモニタリングとデバッグのシナリオについては、「[ジョブのモニタリングとデバッグ](monitor-profile-glue-job-cloudwatch-metrics.md)」を参照してください。 # AWS Glue ジョブのログ記録 AWS Glue 5.0 では、すべてのジョブにリアルタイムのログ記録機能があります。さらに、カスタム設定オプションを指定してログ記録の動作を調整できます。これらのオプションには、Amazon CloudWatch ロググループ名、Amazon CloudWatch ログストリームプレフィックス (AWS Glue ジョブ実行 ID とドライバー/エグゼキュター ID の前に付けられる)、ログメッセージのログ変換パターンの設定が含まれます。これらの設定により、異なる有効期限ポリシーを持つカスタム Amazon CloudWatch ロググループにログを集約できます。さらに、カスタムログストリームのプレフィックスおよび変換パターンを使用することで、ログをより効果的に分析できます。このレベルのカスタマイズによって、特定の要件に応じてログ管理と分析を最適化できます。 ## AWS Glue 5.0 でのログ記録動作 デフォルトでは、システムログ、Spark デーモンログ、ユーザー AWS Glue ロガーログは、Amazon CloudWatch の `/aws-glue/jobs/error` ロググループに書き込まれます。一方、ユーザー stdout (標準出力) ログと stderr (標準エラー) ログは、デフォルトで `/aws-glue/jobs/output` ロググループに書き込まれます。 ## カスタムログ記録 次のジョブ引数を使用すると、デフォルトのロググループとログストリームプレフィックスをカスタマイズできます。 + `--custom-logGroup-prefix`: `/aws-glue/jobs/error` および `/aws-glue/jobs/output` ロググループのカスタムプレフィックスを指定できます。カスタムプレフィックスを指定すれば、ロググループ名は次の形式になります。 + `/aws-glue/jobs/error` は `/error` になります。 + `/aws-glue/jobs/output ` は `/output` になります。 + `--custom-logStream-prefix`: ロググループ内のログストリーム名にカスタムプレフィックスを指定できます。カスタムプレフィックスを指定すれば、ログストリーム名は次の形式になります。 + `jobrunid-driver` は `-driver` になります。 + `jobrunid-executorNum` は `-executorNum` になります。 カスタムプレフィックスの検証ルールと制限は次のとおりです。 + ログストリーム名全体は、1～512 文字である必要があります。 + カスタムプレフィックス自体は 400 文字に制限されます。 + カスタムプレフィックスは正規表現パターン `[^:\$1]\$1` と一致する必要があります (使用できる特殊文字は '\$1'、'-'、'/' です)。 ## カスタムスクリプトロガーを使用したアプリケーション固有のメッセージのログ記録 AWS Glue ロガーを使用すると、ドライバーログストリームにリアルタイムで送信される、スクリプトのアプリケーション固有のメッセージを記録できます。 Python スクリプトの例を以下に示します。 ``` from awsglue.context import GlueContext from pyspark.context import SparkContext sc = SparkContext() glueContext = GlueContext(sc) logger = glueContext.get_logger() logger.info("info message") logger.warn("warn message") logger.error("error message") ``` Scala スクリプトの例を以下に示します。 ``` import com.amazonaws.services.glue.log.GlueLogger object GlueApp { def main(sysArgs: Array[String]) { val logger = new GlueLogger logger.info("info message") logger.warn("warn message") logger.error("error message") } } ``` ## 進行状況バーでのジョブ進行状況の表示 AWS Glue は、`JOB_RUN_ID-progress-bar` ログストリームでリアルタイムの進行状況バーを提供して AWS Glue ジョブ実行のステータスを確認します。現時点では、`glueContext` を初期化するジョブのみがサポートされています。`glueContext` を初期化せずに純粋な Spark ジョブを実行すると、AWS Glue 進行状況バーは表示されません。 進行状況バーでは、以下の進行状況が 5 秒ごとに更新されます。 ``` Stage Number (Stage Name): > (numCompletedTasks + numActiveTasks) / totalNumOfTasksInThisStage] ``` ## Amazon CloudWatch ログ記録によるセキュリティ設定 Amazon CloudWatch ログのセキュリティ設定を有効にすると、AWS Glue によってセキュリティ設定名が組み込まれた特定の命名パターンを持つロググループが作成されます。 ### セキュリティ設定を使用したロググループの命名 デフォルトのロググループおよびカスタムロググループは次のようになります。 + **デフォルトのエラーロググループ:** `/aws-glue/jobs/Security-Configuration-Name-role/glue-job-role/error` + **デフォルトの出力ロググループ:** `/aws-glue/jobs/Security-Configuration-Name-role/glue-job-role/output` + **カスタムエラーロググループ (AWS Glue 5.0):** `custom-log-group-prefix/Security-Configuration-Name-role/glue-job-role/error` + **カスタム出力ロググループ (AWS Glue 5.0):** `custom-log-group-prefix/Security-Configuration-Name-role/glue-job-role/output` ### 必須の IAM アクセス許可 Amazon CloudWatch Logs でセキュリティ設定を有効にする場合、`logs:AssociateKmsKey` 許可を IAM ロールのアクセス許可に追加する必要があります。そのアクセス許可が含まれていない場合、連続ログ記録は無効になります。 また、Amazon CloudWatch Logs 暗号化を設定するには、「Amazon Amazon CloudWatch Logs ユーザーガイド」の「[Encrypt Log Data in Amazon CloudWatch Logs Using AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)」を参照してください。 ### 追加情報 セキュリティ設定の作成の詳細については、「[AWS Glue コンソールでのセキュリティ設定の管理](https://docs.aws.amazon.com/glue/latest/dg/console-security-configurations.html)」を参照してください。 **Topics** + [AWS Glue 5.0 でのログ記録動作](#monitor-logging-behavior-glue-50) + [カスタムログ記録](#monitor-logging-custom) + [カスタムスクリプトロガーを使用したアプリケーション固有のメッセージのログ記録](#monitor-logging-script) + [進行状況バーでのジョブ進行状況の表示](#monitor-logging-progress) + [Amazon CloudWatch ログ記録によるセキュリティ設定](#monitor-security-config-logging) + [AWS Glue 4.0 以前のジョブの継続的なログ記録の有効化](monitor-continuous-logging-enable.md) + [AWS Glue ジョブのログの確認](monitor-continuous-logging-view.md) # AWS Glue 4.0 以前のジョブの継続的なログ記録の有効化 **注記** AWS Glue 4.0 以前のバージョンでは、継続的なログ記録の機能は利用可能でした。しかし、AWS Glue 5.0 の導入により、すべてのジョブでリアルタイムのログ記録機能を利用できるようになりました。AWS Glue 5.0 のログ記録機能と設定オプションの詳細については、「[AWS Glue ジョブのログ記録](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuous-logging.html)」を参照してください。 AWS Glue コンソールを使用するか、AWS Command Line Interface (AWS CLI) を通じて、連続ログ記録を有効にできます。 新しいジョブを作成するか、既存のジョブを編集または AWS CLI を介して有効にするときに、連続ログ記録を有効にできます。 また、Amazon CloudWatch ロググループ名、AWS Glue ジョブ実行 ID ドライバー/エグゼキュター ID の前の CloudWatch ログストリームプレフィックス、ログメッセージのログ変換パターンなどのカスタム設定オプションを指定することもできます。これらの設定は、異なる有効期限ポリシーを持つカスタム CloudWatch ロググループに集約ログを設定し、カスタムログストリームプレフィックスと変換パターンを使用してさらに分析するのに役立ちます。 **Topics** + [AWS マネジメントコンソール を使用する場合](#monitor-continuous-logging-enable-console) + [カスタムスクリプトロガーを使用したアプリケーション固有のメッセージのログ記録](#monitor-continuous-logging-script) + [進行状況バーでのジョブ進行状況の表示](#monitor-continuous-logging-progress) + [連続ログ記録によるセキュリティ設定。](#monitor-logging-encrypt-log-data) ## AWS マネジメントコンソール を使用する場合 次のステップに従ってコンソールを使用して、AWS Glue ジョブを作成または編集するときに連続ログ記録を有効にします。 **連続ログ記録を有効にして新しい AWS Glue ジョブを作成するには** 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. ナビゲーションペインで **[ETL ジョブ]** を選択します。 1. **[ビジュアル ETL]** を選択します。 1. **[Job 詳細]** タブで、**[詳細プロパティ]** セクションを展開します。 1. **[継続的なログ記録]** で **[CloudWatch でログの有効化]** を選択します。 **既存の AWS Glue ジョブに対して連続ログ記録を有効にするには** 1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) で AWS Glue コンソール を開きます。 1. ナビゲーションペインで [**Jobs**] (ジョブ) を選択します。 1. [**Jobs (ジョブ)**] リストから既存のジョブを選択します。 1. [**Action (アクション)**]、[**Edit job (ジョブの編集)**] の順に選択します。 1. **[Job 詳細]** タブで、**[詳細プロパティ]** セクションを展開します。 1. **[継続的なログ記録]** で **[CloudWatch でログの有効化]** を選択します。 ### AWS CLI の使用 連続ログ記録を有効にするには、 AWS Glue ジョブにジョブパラメータを渡します。他の AWS Glue ジョブパラメータに類似した次の特殊なジョブパラメータを渡します。詳細については、「[AWS Glue ジョブでジョブパラメータを使用する](aws-glue-programming-etl-glue-arguments.md)」を参照してください。 ``` '--enable-continuous-cloudwatch-log': 'true' ``` カスタム Amazon CloudWatch ロググループ名を指定できます。指定しない場合、デフォルトのロググループ名は、`/aws-glue/jobs/logs-v2` になります。 ``` '--continuous-log-logGroup': 'custom_log_group_name' ``` カスタム Amazon CloudWatch ログストリームプレフィックスを指定できます。指定しない場合、デフォルトのログストリームプレフィックスはジョブ実行 ID になります。 ``` '--continuous-log-logStreamPrefix': 'custom_log_stream_prefix' ``` カスタムの連続ロギング変換パターンを指定できます。指定しない場合、デフォルトの変換パターンは `%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n` になります。変換パターンは、ドライバーログとエグゼキューターログにのみ適用されます。AWS Glue の進行状況バーには影響しません。 ``` '--continuous-log-conversionPattern': 'custom_log_conversion_pattern' ``` ## カスタムスクリプトロガーを使用したアプリケーション固有のメッセージのログ記録 AWS Glue ロガーを使用すると、ドライバーログストリームにリアルタイムで送信される、スクリプトのアプリケーション固有のメッセージを記録できます。 Python スクリプトの例を以下に示します。 ``` from awsglue.context import GlueContext from pyspark.context import SparkContext sc = SparkContext() glueContext = GlueContext(sc) logger = glueContext.get_logger() logger.info("info message") logger.warn("warn message") logger.error("error message") ``` Scala スクリプトの例を以下に示します。 ``` import com.amazonaws.services.glue.log.GlueLogger object GlueApp { def main(sysArgs: Array[String]) { val logger = new GlueLogger logger.info("info message") logger.warn("warn message") logger.error("error message") } } ``` ## 進行状況バーでのジョブ進行状況の表示 AWS Glue は、`JOB_RUN_ID-progress-bar` ログストリームでリアルタイムの進行状況バーを提供して AWS Glue ジョブ実行のステータスを確認します。現時点では、`glueContext` を初期化するジョブのみがサポートされています。`glueContext` を初期化せずに純粋な Spark ジョブを実行すると、AWS Glue 進行状況バーは表示されません。 進行状況バーでは、以下の進行状況が 5 秒ごとに更新されます。 ``` Stage Number (Stage Name): > (numCompletedTasks + numActiveTasks) / totalNumOfTasksInThisStage] ``` ## 連続ログ記録によるセキュリティ設定。 CloudWatch ログのセキュリティ設定が有効になっている場合、AWS Glue では、連続ログに対して次のような名前のロググループが作成されます。 ``` - ``` デフォルトのロググループおよびカスタムロググループは次のようになります。 + デフォルトの連続ロググループは `/aws-glue/jobs/error-` となります。 + カスタム連続ロググループは `-` となります。 CloudWatch Logs でセキュリティ設定を有効にする場合、`logs:AssociateKmsKey` を IAM ロールのアクセス許可に追加する必要があります。そのアクセス許可が含まれていない場合、連続ログ記録は無効になります。また、CloudWatch Logs 暗号化を設定するには、「*Amazon CloudWatch Logs ユーザーガイド*」の「[AWS Key Management Service を使用して CloudWatch Logs のログデータを暗号化する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)」を参照してください。 セキュリティ設定作成の詳細については、「[AWS Glue コンソールでのセキュリティ設定の管理](console-security-configurations.md)」を参照してください。 **注記** ログを有効にし、追加の CloudWatch ログイベントが作成されると、追加料金が発生することがあります。詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。 # AWS Glue ジョブのログの確認 リアルタイムのログは、AWS Glue コンソールまたは Amazon CloudWatch コンソールを使用して表示できます。 **AWS Glue コンソールダッシュボードを使用してリアルタイムのログを表示するには** 1. AWS マネジメントコンソールにサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. ナビゲーションペインで **ジョブ**を選択します。 1. 既存のジョブを追加または開始します。[**アクション**]、[**ジョブの実行**] の順に選択します。 ジョブの実行を開始するときは、実行中のジョブに関する情報が含まれているページに移動します。 + [**ログ**] タブには、集約された古いアプリケーションログが表示されます。 + **[ログ]** タブには、`glueContext` が初期化されたジョブが実行されているときのリアルタイムの進行状況バーが表示されます。 + **[ログ]** タブには、**[ライバーログ]** も含まれています。このログには、リアルタイムの Apache Spark ドライバーログと、ジョブが実行中に AWS Glue アプリケーションを使用して記録されたスクリプトからのアプリケーションログがキャプチャされます。 1. 古いジョブでは、リアルタイムログを [**Job History**] (ジョブ履歴) ビューで [**Logs**] (ログ) を選択して表示することもできます。このアクションを実行すると、そのジョブ実行のすべての Spark ドライバー、エグゼキュター、および進捗状況バーのログストリームを表示する CloudWatch コンソールに移動します。 **CloudWatch コンソールダッシュボードを使用してリアルタイムのログを表示するには** 1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。 1. ナビゲーションペインで [**ログ**] を選択します。 1. **/aws-glue/jobs/error/** ロググループを選択します。 1. [**フィルタ**] ボックスに、ジョブ実行 ID を貼り付けます。 ドライバーログ、エグゼキュターログ、および進行状況バーを表示できます ([**標準フィルタ**] を使用している場合)。 # AWS Glue オブザーバビリティメトリクスを使用したモニタリング **注記** AWS Glue オブザーバビリティメトリクスは AWS Glue 4.0 以降のバージョンで使用できます。　 AWS Glue オブザーバビリティメトリクスを使用して、AWS Glue for Apache Spark ジョブの内部で何が起こっているかに関するインサイトを生成し、問題の優先順位付けと分析を改善できます。オブザーバビリティメトリクスは Amazon CloudWatch ダッシュボードを通じて視覚化され、エラーの根本原因分析の実行に役立てたり、パフォーマンスのボトルネックを診断したりするために使用できます。問題のデバッグにかかる時間を大幅に削減できるため、より迅速かつ効果的に問題を解決することに注力できます。 AWS Glue オブザーバビリティは、次の 4 つのグループに分類された Amazon CloudWatch メトリクスを提供します。 + **[信頼性] (エラークラス)** – 対処する特定の時間範囲における最も一般的な障害の理由を簡単に特定します。 + **[パフォーマンス] (歪み)** – パフォーマンスのボトルネックを特定し、チューニング手法を適用します。例えば、ジョブの歪みを理由としてパフォーマンスの低下が発生した場合、Spark Adaptive Query Execution を有効にして、歪み結合のしきい値を微調整することをお勧めします。 + **[スループット] (ソース/シンクあたりのスループット)** – データの読み取りと書き込みの傾向をモニタリングします。異常についての Amazon CloudWatch アラームを設定することもできます。 + **[リソースの使用率] (ワーカー、メモリ、ディスクの使用率)** – キャパシティの使用率が低いジョブを効率的に見つけます。これらのジョブについて AWS Glue 自動スケーリングを有効にすることをお勧めします。 ## AWS Glue オブザーバビリティメトリクスの開始方法 **注記** 新しいメトリクスは、AWS Glue Studio コンソールでデフォルトで有効化されています。 **AWS Glue Studio でオブザーバビリティメトリクスを設定するには:** 1. AWS Glue コンソールにログインし、コンソールメニューから **[ETL ジョブ]** を選択します。 1. **[自分のジョブ]** セクションで、ジョブ名をクリックしてジョブを選択します。 1. [**Job details**] (ジョブの詳細) タブを選択します。 1. 一番下までスクロールして、**[詳細プロパティ]** を選択し、**[ジョブのオブザーバビリティメトリクス]** を選択します。 ![\[このスクリーンショットは、[ジョブの詳細] タブの [詳細プロパティ] を示しています。[ジョブのオブザーバビリティメトリクス] オプションが強調表示されます。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/job-details-observability-metrics.png) **AWS CLI を使用して AWS Glue オブザーバビリティメトリクスを有効にするには** + 入力 JSON ファイル内の次の key-value を `--default-arguments` マップに追加します。 ``` --enable-observability-metrics, true ``` ## AWS Glue オブザーバビリティの使用 AWS Glue オブザーバビリティメトリクスは Amazon CloudWatch を通じて提供されるため、Amazon CloudWatch コンソール、AWS CLI、SDK、または API を使用してオブザーバビリティメトリクスデータポイントをクエリできます。AWS Glue オブザーバビリティメトリクスを使用する場合のユースケースの例については、「[Using Glue Observability for monitoring resource utilization to reduce cost](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics/)」を参照してください。 ### Amazon CloudWatch コンソールでの AWS Glue オブザーバビリティの使用 **Amazon CloudWatch コンソールでメトリクスをクエリおよび視覚化するには:** 1. Amazon CloudWatch コンソールを開き、**[すべてのメトリクス]** を選択します。 1. [カスタム名前空間] の下で、**AWS Glue** を選択します。 1. **[ジョブのオブザーバビリティメトリクス]、[ソースごとのオブザーバビリティメトリクス]、または [シンクごとのオブザーバビリティメトリクス]** を選択します。 1. 特定のメトリクス名、ジョブ名、ジョブ実行 ID を検索し、選択します。 1. **[グラフ化されたメトリクス]** タブで、任意の統計、期間、その他のオプションを設定します。 ![\[スクリーンショットは、Amazon CloudWatch コンソールとメトリクスのグラフを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/cloudwatch-console-metrics.png) **AWS CLI を使用してオブザーバビリティメトリクスをクエリするには:** 1. メトリクス定義 JSON ファイルを作成し、`your-Glue-job-name` と `your-Glue-job-run-id` を実際のものに置き換えます。 ``` $ cat multiplequeries.json [ { "Id": "avgWorkerUtil_0", "MetricStat": { "Metric": { "Namespace": "Glue", "MetricName": "glue.driver.workerUtilization", "Dimensions": [ { "Name": "JobName", "Value": "" }, { "Name": "JobRunId", "Value": "" }, { "Name": "Type", "Value": "gauge" }, { "Name": "ObservabilityGroup", "Value": "resource_utilization" } ] }, "Period": 1800, "Stat": "Minimum", "Unit": "None" } }, { "Id": "avgWorkerUtil_1", "MetricStat": { "Metric": { "Namespace": "Glue", "MetricName": "glue.driver.workerUtilization", "Dimensions": [ { "Name": "JobName", "Value": "" }, { "Name": "JobRunId", "Value": "" }, { "Name": "Type", "Value": "gauge" }, { "Name": "ObservabilityGroup", "Value": "resource_utilization" } ] }, "Period": 1800, "Stat": "Minimum", "Unit": "None" } } ] ``` 1. `get-metric-data` コマンドを実行します。 ``` $ aws cloudwatch get-metric-data --metric-data-queries file: //multiplequeries.json \ --start-time '2023-10-28T18: 20' \ --end-time '2023-10-28T19: 10' \ --region us-east-1 { "MetricDataResults": [ { "Id": "avgWorkerUtil_0", "Label": "", "Timestamps": [ "2023-10-28T18:20:00+00:00" ], "Values": [ 0.06718750000000001 ], "StatusCode": "Complete" }, { "Id": "avgWorkerUtil_1", "Label": "", "Timestamps": [ "2023-10-28T18:50:00+00:00" ], "Values": [ 0.5959183673469387 ], "StatusCode": "Complete" } ], "Messages": [] } ``` ## オブザーバビリティメトリクス AWS Glue オブザーバビリティは以下のメトリクスをプロファイリングし、30 秒ごとに Amazon CloudWatch に送信します。これらのメトリクスの一部は、AWS Glue Studio の「ジョブ実行モニタリング」ページで確認できます。 | メトリクス | 説明 | カテゴリ | | --- | --- | --- | | glue.driver.skewness.stage | メトリクスカテゴリ: job\$1performance スパークステージの実行歪度: このメトリクスは、特定のステージの最大タスク期間が、このステージのタスク期間の中央値と比較してどれだけ長いかを示す指標です。このメトリクスは、入力データの歪みや変換 (スキュー結合など) によって生じる可能性のある実行の歪みをキャプチャします。このメトリクスの値は [0, infinity] の範囲に入ります。ここで、0 は、ステージ内のすべてのタスクのうち、タスクの実行時間の最大値と中央値の比率が特定のステージ歪度係数未満であることを意味します。デフォルトのステージ歪度係数は `5`で、spark conf: spark.metrics.conf.driver.source.glue.jobPerformance.skewnessFactor で上書きされます ステージ歪度の値が 1 の場合、比率はステージ歪度係数の 2 倍になります。 ステージ歪度の値は、現在の歪度を反映して 30 秒ごとに更新されます。ステージ終了時の値は、最終ステージの歪度を反映しています。 このステージレベルのメトリクスは、ジョブレベルのメトリクス `glue.driver.skewness.job` を計算するために使用されます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (job\$1performance) 有効な統計: Average、Maximum、Minimum、Percentile 単位: 数 | job\$1performance | | glue.driver.skewness.job | メトリクスカテゴリ: job\$1performance ジョブの歪度は、すべてのステージの重み付き歪度の最大値です。ステージの歪度 (glue.driver.skewness.stage) は、ステージ期間で重み付けされます。これは、非常に歪んだステージが、実際には他のステージに比べて実行時間が非常に短い (したがって、その歪度はジョブパフォーマンス全体にとって重要ではなく、歪みの解消に努力する価値がない) というコーナーケースを回避するためです。 このメトリクスは各ステージの完了時に更新されるため、最後の値には実際の全体的なジョブの歪みが反映されます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (job\$1performance) 有効な統計: Average、Maximum、Minimum、Percentile 単位: 数 | job\$1performance | | glue.succeed.ALL | メトリクスカテゴリ: error 障害カテゴリの全体像を把握するための、正常なジョブ実行の総数 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (カウント)、ObservabilityGroup (エラー) 有効な統計: SUM 単位: 数 | エラー | | glue.error.ALL | メトリクスカテゴリ: error 障害カテゴリの全体像を把握するための、ジョブ実行エラーの総数 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (カウント)、ObservabilityGroup (エラー) 有効な統計: SUM 単位: 数 | エラー | | glue.error.[error category] | メトリクスカテゴリ: error これは実際には一連のメトリクスで、ジョブの実行が失敗した場合にのみ更新されます。エラー分類はトリアージとデバッグに役立ちます。ジョブ実行に失敗すると、失敗の原因となったエラーが分類され、対応するエラーカテゴリメトリクスが 1 に設定されます。これにより、時間の経過に伴う障害分析だけでなく、すべてのジョブエラー分析を実行して、最も一般的な障害カテゴリを特定して対処を開始できます。AWS Glue には、OUT\$1OF\$1MEMORY (ドライバとエグゼキュター)、PERMISSION、SYNTAX、THROTTLING など、28 のエラーカテゴリがあります。また、COMPILATION、LAUNCH、TIMEOUT といったエラーカテゴリもあります。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (カウント)、ObservabilityGroup (エラー) 有効な統計: SUM 単位: 数 | エラー | | glue.driver.workerUtilization | メトリクスカテゴリ: resource\$1utilization 割り当てられたワーカーのうち、実際に使用されているワーカーの割合。うまく機能しない場合は、自動スケーリングが役に立ちます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average、Maximum、Minimum、Percentile 単位: パーセント | resource\$1utilization | | glue.driver.memory.heap.[available \$1 used] | メトリクスカテゴリ: resource\$1utilization ジョブ実行中のドライバの使用可能/使用済みヒープメモリ。これは、特に時間の経過に伴うメモリ使用量の傾向を把握するのに役立ち、メモリ関連の障害をデバッグするだけでなく、潜在的な障害を回避するのにも役立ちます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: バイト | resource\$1utilization | | glue.driver.memory.heap.used.percentage | メトリクスカテゴリ: resource\$1utilization ジョブ実行中にドライバが (%) 使用したヒープメモリ。これは、特に時間の経過に伴うメモリ使用量の傾向を把握するのに役立ち、メモリ関連の障害をデバッグするだけでなく、潜在的な障害を回避するのにも役立ちます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: パーセント | resource\$1utilization | | glue.driver.memory.non-heap.[available \$1 used] | メトリクスカテゴリ: resource\$1utilization ジョブ実行中のドライバの使用可能/使用済み非ヒープメモリ。これは、特に時間の経過に伴うメモリ使用量の傾向を把握するのに役立ち、メモリ関連の障害をデバッグするだけでなく、潜在的な障害を回避するのにも役立ちます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: バイト | resource\$1utilization | | glue.driver.memory.non-heap.used.percentage | メトリクスカテゴリ: resource\$1utilization ジョブ実行中にドライバが (%) 使用した非ヒープメモリ。これは、特に時間の経過に伴うメモリ使用量の傾向を把握するのに役立ち、メモリ関連の障害をデバッグするだけでなく、潜在的な障害を回避するのにも役立ちます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: パーセント | resource\$1utilization | | glue.driver.memory.total.[available \$1 used] | メトリクスカテゴリ: resource\$1utilization ジョブ実行中のドライバの使用可能/使用済み合計メモリ。これは、特に時間の経過に伴うメモリ使用量の傾向を把握するのに役立ち、メモリ関連の障害をデバッグするだけでなく、潜在的な障害を回避するのにも役立ちます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: バイト | resource\$1utilization | | glue.driver.memory.total.used.percentage | メトリクスカテゴリ: resource\$1utilization ジョブ実行中にドライバが (%) 使用した合計メモリ。これは、特に時間の経過に伴うメモリ使用量の傾向を把握するのに役立ち、メモリ関連の障害をデバッグするだけでなく、潜在的な障害を回避するのにも役立ちます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: パーセント | resource\$1utilization | | glue.ALL.memory.heap.[available \$1 used] | メトリクスカテゴリ: resource\$1utilization エグゼキュターの使用可能/使用済みヒープメモリ。ALL はすべてのエグゼキュターを意味します。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: バイト | resource\$1utilization | | glue.ALL.memory.heap.used.percentage | メトリクスカテゴリ: resource\$1utilization エグゼキュターの (%) 使用済みヒープメモリ。ALL はすべてのエグゼキュターを意味します。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: パーセント | resource\$1utilization | | glue.ALL.memory.non-heap.[available \$1 used] | メトリクスカテゴリ: resource\$1utilization エグゼキュターの使用可能/使用済み非ヒープメモリ。ALL はすべてのエグゼキュターを意味します。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: バイト | resource\$1utilization | | glue.ALL.memory.non-heap.used.percentage | メトリクスカテゴリ: resource\$1utilization エグゼキュターの (%) 使用済み非ヒープメモリ。ALL はすべてのエグゼキュターを意味します。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: パーセント | resource\$1utilization | | glue.ALL.memory.total.[available \$1 used] | メトリクスカテゴリ: resource\$1utilization エグゼキュターの使用可能/使用済み合計メモリ。ALL はすべてのエグゼキュターを意味します。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: バイト | resource\$1utilization | | glue.ALL.memory.total.used.percentage | メトリクスカテゴリ: resource\$1utilization エグゼキュターの (%) 使用済み合計メモリ。ALL はすべてのエグゼキュターを意味します。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: パーセント | resource\$1utilization | | glue.driver.disk.[available\$1GB \$1 used\$1GB] | メトリクスカテゴリ: resource\$1utilization ジョブ実行中のドライバの使用可能/使用済みディスク容量。これは、特に時間の経過に伴うディスク使用量の傾向を把握するのに役立ち、潜在的な障害を回避できるだけでなく、ディスク容量不足に関連する障害をデバッグするのにも役立ちます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: ギガバイト | resource\$1utilization | | glue.driver.disk.used.percentage] | メトリクスカテゴリ: resource\$1utilization ジョブ実行中のドライバの使用可能/使用済みディスク容量。これは、特に時間の経過に伴うディスク使用量の傾向を把握するのに役立ち、潜在的な障害を回避できるだけでなく、ディスク容量不足に関連する障害をデバッグするのにも役立ちます。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: パーセント | resource\$1utilization | | glue.ALL.disk.[available\$1GB \$1 used\$1GB] | メトリクスカテゴリ: resource\$1utilization エグゼキュターの使用可能/使用済みディスク容量。ALL はすべてのエグゼキュターを意味します。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: ギガバイト | resource\$1utilization | | glue.ALL.disk.used.percentage | メトリクスカテゴリ: resource\$1utilization エグゼキュターの使用可能/使用済み/(%) 使用済みディスク容量。ALL はすべてのエグゼキュターを意味します。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization) 有効な統計: Average 単位: パーセント | resource\$1utilization | | glue.driver.bytesRead | メトリクスカテゴリ: throughput このジョブ実行で入力ソースごとに読み取られたバイト数、およびすべてのソースで読み取られたバイト数。これにより、データ量とその経時的な変化を把握でき、データの歪みなどの問題に対処しやすくなります。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization)、Source (ソースデータの場所) 有効な統計: Average 単位: バイト | スループット | | glue.driver.[recordsRead \$1 filesRead] | メトリクスカテゴリ: throughput このジョブ実行で入力ソースごとに読み取られたレコード/ファイルの数、およびすべてのソースで読み取られたレコード/ファイルの数。これにより、データ量とその経時的な変化を把握でき、データの歪みなどの問題に対処しやすくなります。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization)、Source (ソースデータの場所) 有効な統計: Average 単位: 数 | スループット | | glue.driver.partitionsRead | メトリクスカテゴリ: throughput このジョブ実行で Amazon S3 入力ソースごとに読み取られたパーティションの数、およびすべてのソースで読み取られたのパーティション数。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization)、Source (ソースデータの場所) 有効な統計: Average 単位: 数 | スループット | | glue.driver.bytesWrittten | メトリクスカテゴリ: throughput このジョブ実行で出力シンク 1 つあたりに書き込まれたバイト数、およびすべてのシンクで書き込まれたバイト数。これにより、データ量とその経時的変化を把握でき、処理の歪みなどの問題に対処しやすくなります。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization)、Sink (シンクデータの場所) 有効な統計: Average 単位: バイト | スループット | | glue.driver.[recordsWritten \$1 filesWritten] | メトリクスカテゴリ: throughput このジョブ実行で出力シンクごとに書き込まれるレコード/ファイルの数、およびすべてのシンクで書き込まれるレコード/ファイルの数。これにより、データ量とその経時的変化を把握でき、処理の歪みなどの問題に対処しやすくなります。 有効なディメンション: JobName (AWS Glue ジョブの名前)、JobRunId (JobRun ID. または ALL)、Type (ゲージ)、ObservabilityGroup (resource\$1utilization)、Sink (シンクデータの場所) 有効な統計: Average 単位: 数 | スループット | ## エラーカテゴリ | エラーカテゴリ | 説明 | | --- | --- | | COMPILATION\$1ERROR | Scala コードのコンパイル中に発生するエラー。 | | CONNECTION\$1ERROR | サービス/リモート、ホスト/データベースのサービスなどへの接続中に発生するエラー。 | | DISK\$1NO\$1SPACE\$1ERROR | ドライバ/エグゼキュターのディスクに空きがないと発生するエラー。 | | OUT\$1OF\$1MEMORY\$1ERROR | ドライバ/エグゼキュターのメモリに空きがないと発生するエラー。 | | IMPORT\$1ERROR | 依存関係をインポートすると発生するエラー。 | | INVALID\$1ARGUMENT\$1ERROR | 入力引数が無効または不正なときにエラーが発生します。 | | PERMISSION\$1ERROR | サービス、データなどに対する権限がないと発生するエラー。 | | RESOURCE\$1NOT\$1FOUND\$1ERROR | データ、位置情報などが存在しないと発生するエラー。 | | QUERY\$1ERROR | Spark SQL クエリの実行によって発生するエラー。 | | SYNTAX\$1ERROR | スクリプトに構文エラーがあると発生するエラー。 | | THROTTLING\$1ERROR | サービスの同時実行数の制限に達したり、サービスクォータの制限を超えたりすると発生するエラー。 | | DATA\$1LAKE\$1FRAMEWORK\$1ERROR | AWS Glue がネイティブでサポートするデータレイクフレームワーク (Hudi、Iceberg など) から発生するエラー。 | | UNSUPPORTED\$1OPERATION\$1ERROR | サポートされていない操作を行うと発生するエラー。 | | RESOURCES\$1ALREADY\$1EXISTS\$1ERROR | 作成または追加するリソースがすでに存在していると発生するエラー。 | | GLUE\$1INTERNAL\$1SERVICE\$1ERROR | AWS Glue の内部サービスに問題があると発生するエラー。 | | GLUE\$1OPERATION\$1TIMEOUT\$1ERROR | AWS Glue 操作がタイムアウトになると発生するエラー。 | | GLUE\$1VALIDATION\$1ERROR | AWS Glue ジョブに必要な値を検証できなかった場合に発生するエラー。 | | GLUE\$1JOB\$1BOOKMARK\$1VERSION\$1MISMATCH\$1ERROR | 同じソースバケットで同じジョブを実行し、同じ/異なる送信先に同時に書き込んだ場合 (同時実行数 >1) に発生するエラー。 | | LAUNCH\$1ERROR | AWS Glue ジョブの起動段階で発生するエラー。 | | DYNAMODB\$1ERROR | Amazon DynamoDB サービスから発生する一般的なエラー。 | | GLUE\$1ERROR | AWS Glue サービスから発生する一般的なエラー。 | | LAKEFORMATION\$1ERROR | AWS Lake Formation サービスから発生する一般的なエラー。 | | REDSHIFT\$1ERROR | Amazon Redshift サービスから発生する一般的なエラー。 | | S3\$1ERROR | Amazon S3 サービスから発生する一般的なエラー。 | | SYSTEM\$1EXIT\$1ERROR | 一般的なシステム終了エラー。 | | TIMEOUT\$1ERROR | 操作がタイムアウトしてジョブが失敗すると発生する一般的なエラー。 | | UNCLASSIFIED\$1SPARK\$1ERROR | Spark から発生する一般的なエラー。 | | UNCLASSIFIED\$1ERROR | デフォルトのエラーカテゴリ。 | ## 制限事項 **注記** メトリクスを公開するには、`glueContext` を初期化する必要があります。 ソースディメンションの値は、ソースタイプに応じて Amazon S3 パスまたはテーブル名のいずれかになります。さらに、ソースが JDBC でクエリオプションが使用されている場合、クエリ文字列はソースディメンションに設定されます。値が 500 文字を超える場合は、500 文字以内に切り捨てられます。値には次の制限があります。 + ASCII 以外の文字は削除されます。 + ソース名に ASCII 文字が含まれていない場合は、 に変換されます。 ### スループットメトリクスの制約事項と考慮事項 + DataFrame と DataFrame ベースの DynamicFrame (例:JDBC、Amazon S3 の parquet からの読み取り) はサポートされていますが、RDD ベースの DynamicFrame (Amazon S3 での csv、json の読み取りなど) はサポートされていません。技術的には、Spark UI に表示されるすべての読み取りと書き込みがサポートされています。 + データソースがカタログテーブルで、形式が JSON、CSV、テキスト、または Iceberg の場合、`recordsRead` メトリクスが出力されます。 + `glue.driver.throughput.recordsWritten`、`glue.driver.throughput.bytesWritten`、`glue.driver.throughput.filesWritten` メトリクスは JDBC テーブルと Iceberg テーブルでは使用できません。 + メトリクスは遅延する可能性があります。ジョブが約 1 分後に終了する場合、Amazon CloudWatch メトリクスにはスループットメトリクスがない可能性があります。 # ジョブのモニタリングとデバッグ AWS Glue ジョブに関するメトリクスを収集して AWS Glue および Amazon CloudWatch コンソールで可視化し、問題を特定して修正できます。AWS Glue ジョブのプロファイリングには、以下のステップが必要です。 1. メトリクスを有効にする: 1. ジョブ定義で [**Job metrics (ジョブメトリクス)**] オプションを有効にします。AWS Glue コンソールでプロファイリングを有効にするか、ジョブに対するパラメータとして有効にできます。詳細については、「[Spark ジョブのジョブプロパティの定義](add-job.md#create-job)」または「[AWS Glue ジョブでジョブパラメータを使用する](aws-glue-programming-etl-glue-arguments.md)」を参照してください。 1. ジョブ定義で **[AWS Glue オブザーバビリティメトリクス]** オプションを有効にします。AWS Glue コンソールでオブザーバビリティを有効にするか、ジョブに対するパラメータとして有効にできます。詳細については、「[AWS Glue オブザーバビリティメトリクスを使用したモニタリング](monitor-observability.md)」を参照してください。 1. ジョブスクリプトが `GlueContext` を初期化することを確認します。たとえば、次のスクリプトスニペットは `GlueContext` を初期化し、プロファイリングされたコードが配置されるスクリプト内の場所を示しています。この一般的な形式は、以下のデバッグシナリオで使用されます。 ``` import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job import time ## @params: [JOB_NAME] args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) ... ... code-to-profile ... ... job.commit() ``` 1. ジョブを実行します。 1. メトリクスを可視化する: 1. AWS Glue コンソールでジョブメトリクスを可視化し、ドライバまたはエグゼキュターの異常なメトリクスを識別します。 1. オブザーバビリティメトリクスは、「ジョブ実行モニタリング」ページ、「ジョブ実行詳細」ページ、または Amazon CloudWatch で確認できます。詳細については、「[AWS Glue オブザーバビリティメトリクスを使用したモニタリング](monitor-observability.md)」を参照してください。 1. 特定されたメトリクスを使用して根本原因を絞り込みます。 1. 必要に応じて、識別されたドライバーまたはジョブエグゼキュターのログストリームを使用して根本原因を確認します。 **AWS Glue オブザーバビリティメトリクスのユースケース** + [OOM 例外とジョブの異常のデバッグ](monitor-profile-debug-oom-abnormalities.md) + [要求の厳しいステージとストラグラータスクのデバッグ](monitor-profile-debug-straggler.md) + [複数のジョブの進行状況のモニタリング](monitor-debug-multiple.md) + [DPU の容量計画のモニタリング](monitor-debug-capacity.md) + [AWS Glue オブザーバビリティを使用してリソースの使用状況を監視し、コストを削減します。](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics) # OOM 例外とジョブの異常のデバッグ AWS Glue でメモリ不足 (OOM) 例外とジョブの異常をデバッグできます。以下のセクションでは、Apache Spark ドライバーや Spark エグゼキュターのメモリ不足例外をデバッグするためのシナリオについて説明します。 + [ドライバー OOM 例外のデバッグ](#monitor-profile-debug-oom-driver) + [エグゼキュター OOM 例外のデバッグ](#monitor-profile-debug-oom-executor) ## ドライバー OOM 例外のデバッグ このシナリオでは、Spark ジョブで多数の小さいファイルが Amazon Simple Storage Service (Amazon S3) から読み込まれます。ファイルが Apache Parquet 形式に変換された後、Amazon S3 に書き込まれます。Spark ドライバーのメモリが不足しています。入力 Amazon S3 データの複数の Amazon S3 パーティションに 100 万を超えるファイルがあります。 プロファイルされたコードは次のとおりです。 ``` data = spark.read.format("json").option("inferSchema", False).load("s3://input_path") data.write.format("parquet").save(output_path) ``` ### AWS Glue コンソールでプロファイルされたメトリクスを可視化する 以下のグラフでは、ドライバーとエグゼキュターのメモリ使用率がパーセントで示されています。この使用率は、直近の 1 分間に報告された値を平均した 1 つのデータポイントとしてプロットされます。ジョブのメモリプロファイルでは、[ドライバーメモリ](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage)が安全しきい値である使用率の 50% をすぐに超えることがわかります。一方、すべてのエグゼキュターにおける[平均メモリ使用率](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage)は、まだ 4% 未満です。これは、この Spark ジョブにおけるドライバー実行に異常があることを明確に示しています。 ![\[ドライバーおよびエグゼキュターのメモリ使用率の割合 (パーセント)。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-oom-memoryprofile.png) ジョブの実行はすぐに失敗し、AWS Glue コンソールの [**History**] (履歴) タブにエラー「Command Failed with Exit Code 1」が表示されます。このエラー文字列は、システムエラーのためにジョブが失敗したことを意味します。この場合はドライバーのメモリ不足です。 ![\[AWS Glue コンソールに表示されたエラーメッセージ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-oom-errorstring.png) コンソールの [**History**] (履歴) タブにある [**Error logs**] (エラーログ) リンクを選択し、CloudWatch Logs からのドライバー OOM に関する詳細情報を確認します。ジョブのエラーログで「**Error**」を検索し、それが本当にジョブの失敗の原因となった OOM 例外であることを確認します。 ``` # java.lang.OutOfMemoryError: Java heap space # -XX:OnOutOfMemoryError="kill -9 %p" # Executing /bin/sh -c "kill -9 12039"... ``` ジョブの [**履歴**] タブで、[**ログ**] を選択します。ジョブの開始時における CloudWatch Logs 内のドライバー実行の以下のトレースが表示されます。Spark ドライバーは、すべてのディレクトリのすべてのファイルのリストの取得を試み、`InMemoryFileIndex` を構築してファイルごとに 1 つのタスクを起動します。この結果、Spark ドライバーは、すべてのタスクを追跡するため、大量の状態をメモリに保持する必要が生じます。また、メモリ内インデックスの多数のファイルの完全なリストを取得するため、ドライバー OOM となります。 ### グループ化を使用した複数のファイルの処理を修正する * で*グループ化AWS Glue機能を使用して、複数のファイルの処理を修正できます。グループ化は、動的なフレームを使用しているときと、入力データセットに多数のファイル (50,000 超) があるときに自動的に有効になります。グループかにより、複数のファイルを 1 つのグループにまとめることができ、タスクは単一のファイルではなくグループ全体を処理できるようになります。その結果、Spark ドライバーがメモリに保存する状態がかなり少なくなり、追跡するタスクが減少します。データセットのグループ化を手動で有効にする方法の詳細については、「[大きなグループの入力ファイルの読み取り](grouping-input-files.md)」を参照してください。 AWS Glue ジョブのメモリプロファイルを確認するには、グループ化を有効にして次のコードをプロファイルします。 ``` df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json") datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink") ``` AWS Glue ジョブプロファイルでは、メモリプロファイルと ETL データ移動を監視できます。 ドライバーは、AWS Glue ジョブの持続期間全体にわたって、メモリ使用率のしきい値である 50% 未満で実行されます。エグゼキュターは、Amazon S3 からデータをストリーミングして処理し、Amazon S3 に書き出します。その結果、消費されるメモリは常に 5% 未満となります。 ![\[この問題が発生していたメモリプロファイルが修正されました。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-oom-memoryprofile-fixed.png) 以下のデータ移動プロファイルは、ジョブが進行するにつれてすべてのエグゼキュターにより直近 1 分間に[読み取り](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes)および[書き込み](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes)された Amazon S3 バイトの合計数を示しています。データはすべてのエグゼキュターでストリーミングされるため、どちらも同様のパターンに従っています。ジョブは、100 万ファイルすべての処理を 3 時間未満で完了します。 ![\[この問題が発生していたデータ移動プロファイルが修正されました。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-oom-etlmovement.png) ## エグゼキュター OOM 例外のデバッグ このシナリオでは、Apache Spark エグゼキュターで発生する可能性がある OOM 例外をデバッグする方法について説明します。次のコードでは、Spark MySQL リーダーを使用して、約 34 万行の大きなテーブルを Spark データフレームに読み取ります。次に、Parquet 形式で Amazon S3 に書き出します。接続プロパティを用意し、デフォルト Spark 設定を使用してテーブルを読み取ることができます。 ``` val connectionProperties = new Properties() connectionProperties.put("user", user) connectionProperties.put("password", password) connectionProperties.put("Driver", "com.mysql.jdbc.Driver") val sparkSession = glueContext.sparkSession val dfSpark = sparkSession.read.jdbc(url, tableName, connectionProperties) dfSpark.write.format("parquet").save(output_path) ``` ### AWS Glue コンソールでプロファイルされたメトリクスを可視化する メモリ使用量グラフの傾きが正で 50% を超えた場合、および次のメトリクスが出力される前にジョブが失敗した場合は、メモリ枯渇が原因の候補となります。以下のグラフは、実行してから 1 分以内に、すべてのエグゼキュターにおける[平均メモリ使用率](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage)がすぐに 50% を超えることを示しています。使用率は最大 92% に上昇し、エグゼキュターを実行するコンテナは Apache Hadoop YARN により停止されます。 ![\[すべてのエグゼキュターにおける平均メモリ使用率。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile.png) 次のグラフが示すよう、ジョブが失敗するまで常に[単一のエグゼキュター](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors)が実行されています。これは、新しいエグゼキュターが起動され、停止されたエグゼキュターが置き換えられるためです。JDBC データソースの読み取りは、列上のテーブルをパーティション化して複数の接続を開く必要があるため、デフォルトでは並列化されません。その結果、1 つのエグゼキュターだけがテーブル全体を順番に読み込みます。 ![\[ジョブの実行は、ジョブが失敗するまで単一のエグゼキュターが実行されることを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-oom-2-execution.png) 次のグラフが示すように、Spark はジョブが失敗するまでに 4 回新しいタスクを起動しようとします。3 つのエグゼキュターの[メモリプロファイル](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.used)を確認できます。各エグゼキュターはすべてのメモリをすぐに使い尽くします。4 番目のエグゼキュターのメモリが不足し、ジョブは失敗します。その結果、そのメトリクスはすぐに報告されません。 ![\[エグゼキュターのメモリプロファイル。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-oom-2-exec-memprofile.png) 次の図に示すように、AWS Glue コンソールのエラー文字列からは、ジョブが OOM 例外のために失敗したことを確認できます。 ![\[AWS Glue コンソールに表示されたエラーメッセージ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-oom-2-errorstring.png) **ジョブ出力ログ:** エグゼキュター OOM 例外の結果をさらに確認するには、CloudWatch Logs を参照します。「**Error**」を検索すると、メトリクスダッシュボードに示されているように、4 つのエグゼキュターがほぼ同じ時間枠で停止されています。メモリ制限を超えると、すべて YARN により終了されます。 エグゼキュター 1 ``` 18/06/13 16:54:29 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:54:29 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:54:29 ERROR YarnClusterScheduler: Lost executor 1 on ip-10-1-2-175.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:54:29 WARN TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, ip-10-1-2-175.ec2.internal, executor 1): ExecutorLostFailure (executor 1 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. ``` エグゼキュター 2 ``` 18/06/13 16:55:35 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:55:35 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:55:35 ERROR YarnClusterScheduler: Lost executor 2 on ip-10-1-2-16.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:55:35 WARN TaskSetManager: Lost task 0.1 in stage 0.0 (TID 1, ip-10-1-2-16.ec2.internal, executor 2): ExecutorLostFailure (executor 2 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. ``` エグゼキュター 3 ``` 18/06/13 16:56:37 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:56:37 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:56:37 ERROR YarnClusterScheduler: Lost executor 3 on ip-10-1-2-189.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:56:37 WARN TaskSetManager: Lost task 0.2 in stage 0.0 (TID 2, ip-10-1-2-189.ec2.internal, executor 3): ExecutorLostFailure (executor 3 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. ``` エグゼキュター 4 ``` 18/06/13 16:57:18 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:57:18 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:57:18 ERROR YarnClusterScheduler: Lost executor 4 on ip-10-1-2-96.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:57:18 WARN TaskSetManager: Lost task 0.3 in stage 0.0 (TID 3, ip-10-1-2-96.ec2.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. ``` ### AWS Glue 動的フレームを使用してフェッチサイズ設定を修正する Spark JDBC フェッチサイズのデフォルトの設定が 0 であるため、エグゼキュターは JDBC テーブルの読み取り中にメモリ不足になります。つまり、Spark は行を一度に 1 つずつストリーミングしますが、Spark エグゼキュター上の JDBC ドライバーがデータベースから 3400 万行をまとめてフェッチして、それらをキャッシュしようとします。Spark を使用すると、フェッチサイズパラメータを 0 以外のデフォルト値に設定することにより、このシナリオを回避できます。 代わりに AWS Glue 動的フレームを使用することで、この問題を解決することもできます。デフォルトでは、動的フレームは 1,000 行のフェッチサイズを使用します。これは通常十分な値です。このため、エグゼキュターが合計メモリの 7% 超を使用することはありません。AWS Glue ジョブは、エグゼキュターを 1 つだけ使用して 2 分未満で完了します。AWS Glue 動的フレームを使用することが推奨されるアプローチですが、Apache Spark の `fetchsize` プロパティを使用してフェッチサイズを設定することもできます。「[Spark SQL、DataFrames および Datasets ガイド](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html#jdbc-to-other-databases)」を参照してください。 ``` val (url, database, tableName) = { ("jdbc_url", "db_name", "table_name") } val source = glueContext.getSource(format, sourceJson) val df = source.getDynamicFrame glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink") ``` **プロファイルされた通常のメトリクス:** 以下の図に示すように、AWS Glue 動的フレームを持つ[エグゼキュターメモリ](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage)が安全しきい値を超えることはありません。データベースから行をストリーミングし、任意の時点で 1,000 行のみ JDBC ドライバーにキャッシュします。メモリ不足例外は発生しません。 ![\[安全しきい値を下回ったエグゼキュターメモリを示している AWS Glue コンソール。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile-fixed.png) # 要求の厳しいステージとストラグラータスクのデバッグ AWS Glue ジョブプロファイリングを使用して、抽出、変換、ロード (ETL) ジョブで要求の厳しいステージとストラグラータスクを特定できます。ストラグラータスクは、AWS Glue ジョブのステージに含まれる他のタスクよりかなり時間がかかります。その結果、ステージの完了まで時間がかかり、ジョブの合計実行時間も遅延します。 ## 小さい入力ファイルを大きい出力ファイルにまとめる ストラグラータスクは、さまざまなタスク間の処理が均等に分散していないときや、データスキューによって特定のタスクが処理するデータが多くなった場合に発生する可能性があります。 Apache Spark の一般的なパターンである次のコードをプロファイルし、多数の小さいファイルをいくつかの大きい出力ファイルにまとめることができます。この例では、入力データセットは 32 GB の JSON Gzip 圧縮ファイルです。出力データセットには、約 190 GB の圧縮されていない JSON ファイルが含まれています。 プロファイルされたコードは次のとおりです。 ``` datasource0 = spark.read.format("json").load("s3://input_path") df = datasource0.coalesce(1) df.write.format("json").save(output_path) ``` ### AWS Glue コンソールでプロファイルされたメトリクスを可視化する ジョブをプロファイルすると、4 つのメトリクスセットを調べることができます。 + ETL データ移動 + エグゼキュター間のデータシャッフル + ジョブの実行 + メモリプロファイル **ETL データ移動**: [**ETL Data Movement (ETL データ移動)**] プロファイルでは、バイトは、最初の 6 分間に完了する最初のステージのすべてのエグゼキュターにより比較的早く[読み取られます](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes)。ただし、ジョブの合計実行時間が約 1 時間の場合、ほとんどがデータの[書き込み](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes)で構成されます。 ![\[ETL データ移動プロファイルを示すグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-straggler-1.png) **エグゼキュター間のデータシャッフル:** [ジョブ実行](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead)メトリクスと[データシャッフル](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten)メトリクスが示しているように、シャッフル中の**読み取り**および**書き込み**のバイト数も、ステージ 2 が終了する前に急増しています。すべてのエグゼキュターからのデータシャッフルの後、読み取りと書き込みはエグゼキュター 3 番のみから続行されます。 ![\[エグゼキュター間でのデータシャッフルのメトリクス。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-straggler-2.png) **ジョブの実行:** 以下のグラフに示すように、他のすべてのエグゼキュターはアイドル状態であり、最終的に時間 10:09 までに破棄されます。この時点で、エグゼキュターの合計数はわずか 1 に減ります。これは、エグゼキュター 3 番が、実行時間が最も長いストラグラータスクで構成されているため、ジョブの実行時間の大部分を占めていることを明確に示しています。 ![\[アクティブなエグゼキュターの実行メトリクス。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-straggler-3.png) **メモリプロファイル:** 最初の 2 つのステージの後、[エグゼキュター 3 番](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used)のみがメモリをアクティブに消費してデータを処理します。残りのエグゼキュターはアイドル状態のままであるか、最初の 2 つのステージの完了後すぐに破棄されます。 ![\[最初の 2 つのステージの後のメモリプロファイルのメトリクス。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-straggler-4.png) ### グループ化を使用してストラグラーエグゼキュターを修正する ストラグラーエグゼキュターは、* で*グループ化AWS Glueを使用して回避できます。グループ化を使用してデータをすべてのエグゼキュター間に均等に分散し、クラスター内で利用可能なすべてのエグゼキュターを使用して大きいファイルにまとめます。詳細については、 を参照してください。[大きなグループの入力ファイルの読み取り](grouping-input-files.md) AWS Glue ジョブで ETL データ移動を確認するには、グループ化を有効にして次のコードをプロファイルします。 ``` df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json") datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "json", transformation_ctx = "datasink4") ``` **ETL データ移動:** データの書き込みは、ジョブの実行時間全体にわたって、データの読み取りと並行してストリーミングされるようになりました。その結果、ジョブは 8 分以内に終了します。以前よりもはるかに早いスピードです。 ![\[この問題が発生していた ETL データ移動が修正されました。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-straggler-5.png) **エグゼキュター間でのデータシャッフル:** グループ化機能を使用して読み取り中に入力ファイルがまとめられると、データの読み取り後、コストのかかるデータシャッフルが行われなくなります。 ![\[この問題が発生していたデータシャッフルメトリクスが修正されました。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-straggler-6.png) **ジョブの実行:** ジョブ実行メトリクスは、実行されてデータを処理しているアクティブなエグゼキュターの合計数がかなり安定していることを示しています。ジョブに単一のストラグラーはありません。すべてのエグゼキュターがアクティブで、ジョブが完了するまでは破棄されません。エグゼキュター間でデータの中間シャッフルは行われないため、ジョブにはステージが 1 つしかありません。 ![\[ジョブにストラグラーがないことを示しているジョブの実行ウィジェットのメトリクス。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-straggler-7.png) **メモリプロファイル:** このメトリクスは、すべてのエグゼキュター間の[アクティブなメモリ消費](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used)を示しています。これは、すべてのエグゼキュター間にアクティビティがあることを再確認するものです。データは並行してストリーミングおよび書き出されるため、すべてのエグゼキュターの合計メモリ使用量はほぼ均等で、すべてのエグゼキュター安全しきい値をかなり下回っています。 ![\[すべてのエグゼキュター間でアクティブなメモリ消費量を示すメモリプロファイルメトリクス。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-straggler-8.png) # 複数のジョブの進行状況のモニタリング 複数の AWS Glue ジョブをまとめてプロファイルし、それらの間のデータフローを監視できます。これは、一般的なワークフローパターンであり、個々のジョブの進行状況、データ処理バックログ、データの再処理、ジョブのブックマークのモニタリングが必要です。 **Topics** + [プロファイルされたコード](#monitor-debug-multiple-profile) + [AWS Glue コンソールでプロファイルされたメトリクスを可視化する](#monitor-debug-multiple-visualize) + [ファイルの処理を修正する](#monitor-debug-multiple-fix) ## プロファイルされたコード このワークフローには、入力ジョブと出力ジョブの 2 つがあります。入力ジョブは、定期的なトリガーを使用して 30 分ごとに実行するようにスケジュールされます。出力ジョブは、入力ジョブの実行が成功するたびに実行されるようにスケジュールされます。このようなスケジュールされたジョブは、ジョブトリガーを使用して制御されます。 ![\[入力および出力ジョブのスケジュールを制御するジョブトリガーが表示されたコンソールスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-multiple-1.png) **入力ジョブ**: このジョブは Amazon Simple Storage Service (Amazon S3) の場所からデータを読み取り、`ApplyMapping` を使用して変換し、Amazon S3 のステージング場所に書き込みます。次のコードは、入力ジョブのプロファイルされたコードです。 ``` datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": ["s3://input_path"], "useS3ListImplementation":True,"recurse":True}, format="json") applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec]) datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": staging_path, "compression": "gzip"}, format = "json") ``` **出力ジョブ**: このジョブは、Amazon S3 内のステージング場所から入力ジョブの出力を読み取り、もう一度変換して、ターゲットの場所に書き込みます。 ``` datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json") applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec]) datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "json") ``` ## AWS Glue コンソールでプロファイルされたメトリクスを可視化する 次のダッシュボードでは、入力ジョブから取得された Amazon S3 バイトの書き込みメトリクスを、出力ジョブの同じタイムラインにある Amazon S3 バイトの読み取りメトリクスに重ね合わせています。タイムラインには、入力および出力ジョブのさまざまなジョブの実行が表示されます。入力ジョブ (赤で表示) は、30 分ごとに開始されます。出力ジョブ (茶色で表示) は、入力ジョブの完了時に開始し、最大同時実行数は 1 です。 ![\[データの読み書きを示しているグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-multiple-4.png) この例では、[ジョブのブックマーク](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html)が有効になっていません。スクリプトコードでジョブのブックマークを有効にするために使用される変換コンテキストはありません。 **ジョブ履歴**: [**履歴**] タブに示されているように、入力および出力ジョブには、午後 12 時に始まる複数の実行があります。 AWS Glue コンソールで入力ジョブは次のようになります。 ![\[入力ジョブの [履歴] タブが表示されているコンソールスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-multiple-2.png) 以下のイメージに、出力ジョブを示します。 ![\[出力ジョブの [履歴] タブが表示されているコンソールスクリーンショット。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-multiple-3.png) **最初のジョブの実行**: 以下のデータバイトの読み書きグラフに示されているように、12:00 から 12:30 の間に行われた入力および出力ジョブの最初のジョブの実行は、曲線の下のほぼ同じ領域を示しています。これらの領域は、入力ジョブによって書き込まれた Amazon S3 バイトと、出力ジョブによって読み取られた Amazon S3 バイトを表しています。このデータは、書き込まれた Amazon S3 バイトの比率によっても確認されます (30 分間の累計 – 入力ジョブのジョブトリガー頻度)。午後 12 時に開始された入力ジョブの実行の比率のデータポイントも 1 です。 以下のグラフは、すべてのジョブの実行におけるデータフロー比率を示しています。 ![\[データフロー比率を示しているグラフ: 書き込みバイトと読み取りバイト。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-multiple-5.png) **2 回目のジョブの実行**: 2 回目のジョブの実行では、入力ジョブによって書き込まれるバイト数と比較して、出力ジョブにより読み取られるバイト数に明確な違いがあります。(出力ジョブの 2 つのジョブの実行にまたがる曲線の下の領域を比較するか、入力および出力ジョブの 2 回目の実行の領域を比較します)。読み取りバイトと書き込みバイトの比率は、12:30 から 13:00 までの 2 番目の 30 分スパンにおいて入力ジョブによって書き込まれるデータの約 2.5 倍のデータを出力ジョブが読み取ることを示しています。ジョブのブックマークが有効になっていなかったため、出力ジョブが入力上部による最初のジョブの実行の出力を再処理したことがその理由です。1 より大きい比率は、出力ジョブにより処理された追加のデータバックログがあることを示しています。 **3 回目のジョブの実行**: 入力ジョブは、書き込まれるバイト数の観点でほぼ一定です (赤色の曲線の下にある領域を参照)。ただし、入力ジョブの 3 回目の実行には、予想されるよりも時間がかかります (赤色の曲線が長く続いていることを確認)。その結果、出力ジョブの 3 回目のジョブの実行が遅れて開始します。3 回目のジョブの実行では、13:00 から 13:30 までの残りの 30 分においてステージング場所に蓄積されたデータのごく一部のみ処理されました。バイトフローの比率は、入力ジョブの 3 回目の実行により書き込まれたデータの 0.83 のみ処理されたことを示しています (13:00 の比率を参照)。 **入力ジョブと出力ジョブの重複**: 入力ジョブの 4 回目のジョブの実行は、スケジュールに従って 13:30 に開始されました。これは、出力ジョブの 3 回目のジョブの実行が終了する前です。これらの 2 つのジョブの実行は一部の重複しています。ただし、出力ジョブの 3 回目の実行では、13:17 前後に開始されたとき、Amazon S3 のステージング場所にリストされたファイルのみキャプチャされます。これは、入力ジョブの最初のジョブの実行から取得されたすべてのデータ出力で構成されています。13:30 時点での実際の比率は約 2.75 です。出力ジョブの 3 回目のジョブの実行では、13:30 から 14:00 に入力ジョブの 4 回目のジョブの実行により書き込まれたデータの約 2.75 倍のデータが処理されました。 これらのイメージが示すように、出力ジョブは、入力ジョブのそれ以前のすべてのジョブの実行から取得されたステージング場所からのデータを再処理します。その結果、出力ジョブの 4 番目のジョブの実行が最も長くなり、入力ジョブの 5 回目のジョブの実行全体と重複します。 ## ファイルの処理を修正する 出力ジョブが、出力ジョブの以前のジョブの実行で処理されていないファイルのみ処理するようにする必要があります。これを行うには、次のように、ジョブのブックマークを有効にし、ジョブ出力に変換コンテキストを設定します。 ``` datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json", transformation_ctx = "bookmark_ctx") ``` ジョブのブックマークが有効な場合、出力ジョブは、入力ジョブのそれまでのすべてのジョブの実行から取得されたステージング場所のデータを再処理しません。読み書きされたデータを示す以下のイメージでは、茶色の曲線の下にある領域はほぼ一定であり、赤色の曲線と似ています。 ![\[読み書きされたデータを赤色の線と茶色の線で示しているグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-multiple-6.png) 追加のデータが処理されないため、バイトフローの比率もほぼ 1 に維持されます。 ![\[データフロー比率を示しているグラフ: 書き込みバイトと読み取りバイト。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-multiple-7.png) 出力ジョブのジョブの実行が開始され、次の入力ジョブの実行がデータをさらにステージング場所に置き始める前にステージング場所のファイルをキャプチャします。これを続けている限り、それまでの入力ジョブの実行からキャプチャされたファイルのみ処理され、比率はほぼ 1 に維持されます。 ![\[データフロー比率を示しているグラフ: 書き込みバイトと読み取りバイト。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-multiple-7.png) 入力ジョブに予想以上に時間がかかるため、2 回の入力ジョブの実行から取得されたステージング場所のファイルが出力ジョブによってキャプチャされるとします。その出力ジョブの実行では、比率が 1 よりも大きくなります。ただし、出力ジョブのそれ以降のジョブの実行では、出力ジョブのそれまでのジョブの実行により既に処理されているファイルは処理されません。 # DPU の容量計画のモニタリング AWS Glue でジョブメトリクスを使用すると、AWS Glue ジョブをスケールアウトするために使用できるデータ処理単位 (DPU) の数を予測できます。 **注記** このページは AWS Glue バージョン 0.9 および 1.0 にのみ適用できます。AWS Glue 以降のバージョンには、容量計画時に追加の考慮事項を導入するコスト削減機能が含まれています。 **Topics** + [プロファイルされたコード](#monitor-debug-capacity-profile) + [AWS Glue コンソールでプロファイルされたメトリクスを可視化する](#monitor-debug-capacity-visualize) + [最適な DPU 容量を決定する](#monitor-debug-capacity-fix) ## プロファイルされたコード 次のスクリプトは、428 個の gzip で圧縮された JSON ファイルを含む Amazon Simple Storage Service (Amazon S3) パーティションを読み取ります。このスクリプトは、マッピングを適用してフィールド名を変更し、Apache Parquet 形式に変換して Amazon S3 に書き込みます。デフォルトに従って 10 個の DPU をプロビジョニングし、このジョブを実行します。 ``` datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [input_path], "useS3ListImplementation":True,"recurse":True}, format="json") applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [(map_spec]) datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet") ``` ## AWS Glue コンソールでプロファイルされたメトリクスを可視化する **ジョブの実行 1:** このジョブの実行では、プロビジョニングが不足している DPU がクラスターにあるかどうかを調べる方法を示します。AWS Glue でのジョブ実行機能は、[アクティブに実行されているエグゼキュターの合計数](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors)、[完了したステージの数](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages)、[必要なエグゼキュターの最大数](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors)を表示します。 必要なエグゼキュターの最大数は、実行中のタスクと保留中のタスクの合計数を加算し、エグゼキュターごとのタスクで除算することによって算出されます。この結果は、現在の負荷に対応するために必要なエグゼキュターの合計数の尺度となります。 一方、アクティブに実行されているエグゼキュターの数は、アクティブな Apache Spark タスクで実行されているエグゼキュターの数を測定します。ジョブが進行するにつれて、必要なエグゼキュターの最大数は変化し、保留中のタスクキューが減るため通常はジョブの終わりに向かって減少します。 次のグラフの横方向の赤色の線は、割り当てられたエグゼキュターの最大数を示しています。これは、ジョブに割り当てる DPU の数によって異なります。この場合、ジョブの実行に対して 10 個の DPU を割り当てます。1 つの DPU が管理用に予約されています。9 個の DPU はそれぞれ 2 つのエグゼキュターを実行し、1 つのエグゼキュターは Spark ドライバー用に予約されています。Spark ドライバーはプライマリアプリケーション内で実行されます。そのため、割り当てられるエグゼキュターの最大数は、2\$19 - 1 = 17 です。 ![\[アクティブなエグゼキュターと必要なエグゼキュターの最大数を示すジョブメトリクス。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-capacity-1.png) グラフが示すとおり、必要なエグゼキュターの最大数はジョブの開始時に 107 から始まりますが、アクティブなエグゼキュターの数は 17 のままです。これは、10 個の DPU を持つ割り当てられるエグゼキュターの最大数と同じです。必要なエグゼキュターの最大数と割り当てられるエグゼキュターの最大数の比率 (Spark ドライバーでは両方に 1 を加算) から、プロビジョニングが不足している係数が 108/18 = 6 倍であるとわかります。6 (プロビジョニング率未満) \$19 (現在の DPU 容量 -1) \$11 DPU = 55 個の DPU をプロビジョニングしてジョブをスケールアウトし、最大限の並列処理で実行することで処理時間を短縮することができます。 AWS Glue コンソールは、詳細なジョブメトリクスを、元の割り当てられるエグゼキュターの最大数を表す静的な線として表示します。コンソールは、メトリクスのジョブ定義からから割り当てられるエグゼキュターの最大数を計算します。対照的に、詳細なジョブ実行メトリクスについては、コンソールはジョブ実行設定から割り当てられるエグゼキュターの最大数、特にジョブ実行に割り当てられた DPU を計算します。個々のジョブ実行のメトリクスを表示するには、ジョブ実行を選択して、[**実行メトリクスの表示**] を選択します。 ![\[ETL データ移動を示すジョブメトリクス。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-capacity-2.png) [読み取り](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes)および[書き込み](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes)された Amazon S3 バイトを見ると、ジョブが Amazon S3 からのデータをストリーミングして並列に書き出すことに 6 分すべてを消費していることがわかります。割り当てられた DPU 上のすべてのコアは、Amazon S3 に対して読み取りと書き込みを行います。必要なエグゼキュターの最大数 107 は、入力 Amazon S3 パス内のファイル数 428 とも整合しています。各エグゼキュターは、4 つの Spark タスクを起動し、4 つの入力ファイルを処理します (gzip で圧縮された JSON)。 ## 最適な DPU 容量を決定する 前のジョブの実行の結果に基づいて、割り当てられる DPU の合計数を 55 に増やし、ジョブがどのように実行されるかを確認できます。ジョブは 3 分未満で完了します。以前に必要な時間の半分です。この場合、実行時間の短いジョブであるため、ジョブのスケールアウトは直線的ではありません。存続期間の長いタスクまたは多数のタスクを持つジョブ (必要なエグゼキュターの最大数が大きい) は、直線的に近い DPU スケールアウトのパフォーマンス向上から恩恵を受けます。 ![\[割り当てられる DPU の合計数の増加を示しているグラフ\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-capacity-3.png) 上の図に示すように、アクティブなエグゼキュターの合計数が最大割り当て数 107 個のエグゼキュターに到達します。同様に、必要なエグゼキュターの最大数が割り当てられるエグゼキュターの最大数を上回ることはありません。必要なエグゼキュターの最大数は、アクティブに実行されているタスクと保留中のタスクの数から計算されるため、アクティブなエグゼキュターの数よりも小さい可能性があります。これは、短期間部分的または完全にアイドル状態になり、まだ停止されていないエグゼキュターが存在する可能性があるためです。 ![\[最大割り当て数に到達しているアクティブなエグゼキュターの合計数を示しているグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-capacity-4.png) このジョブの実行では、Amazon S3 から並列で読み取りと書き込みをするために 6 倍のエグゼキュターが使用されます。その結果、このジョブの実行では、読み取りと書き込みの両方に使用される Amazon S3 帯域幅が多くなり、早く完了します。 ### 過度にプロビジョニングされた DPU を識別する 次に、100 個の DPU (99 \$1 2 = 198 個のエグゼキュター) でジョブをスケールアウトするとこれ以上スケールアウトしなくてよくなるかどうかを調べることができます。次のグラフが示すように、ジョブが完了するまでまだ 3 分かかります。同様に、ジョブは 107 個を超えてスケールアウトしないため (55 DPU 構成)、残りの 91 個のエグゼキュターは過剰にプロビジョニングされてまったく使用されません。必要なエグゼキュターの最大数からわかるように、これは DPU の数を増やしても必ずパフォーマンスが向上するわけではないことを示しています。 ![\[DPU の数を増やしてもジョブのパフォーマンスが必ずしも向上するわけではないことを示しているグラフ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/monitor-debug-capacity-5.png) ### 時間の差を比較する 次の表に示す 3 つのジョブが実行は、10 個の DPU、55 個の DPU、100 個の DPU のジョブの実行時間をまとめています。最初のジョブの実行をモニタリングすることで確立した推定値を使用して、ジョブの実行時間を向上させることができる DPU 容量を調べることができます。 | ジョブ ID | DPU の数 | 実行時間 | | --- | --- | --- | | jr\$1c894524c8ef5048a4d9..。 | 10 | 6 分。 | | jr\$11a466cf2575e7ffe6856..。 | 55 | 3 分。 | | jr\$134fa1ed4c6aa9ff0a814..。 | 100 | 3 分。 | # AWS Glue での Apache Spark の生成 AI トラブルシューティング AWS Glue の Apache Spark ジョブ用の生成 AI トラブルシューティングは、データエンジニアやサイエンティストが Spark アプリケーションの問題を簡単に診断および修正するのに役立つ新機能です。この機能は、機械学習と生成 AI テクノロジーを活用して Spark ジョブの問題を分析し、詳細な根本原因分析と、それらの問題を解決するための実用的な推奨事項を提供します。Apache Spark の生成 AI トラブルシューティングは、AWS Glue バージョン 4.0 以降で実行するジョブで使用できます。 | | | --- | | AI を活用したトラブルシューティングエージェントを使用して Apache Spark のトラブルシューティングを変革できます。AWS Glue、Amazon EMR on EC2、Amazon EMR Serverless、Amazon SageMaker AI のノートブックを始めとするすべての主要なデプロイモードがサポートされるようになりました。この強力なエージェントは、自然言語インタラクション、リアルタイムのワークロード分析、スマートコードの推奨事項を組み合わせてシームレスなエクスペリエンスを実現するので、複雑なデバッグプロセスが排除されます。実装の詳細については、「[What is Apache Spark Troubleshooting Agent for Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/spark-troubleshoot.html)」を参照してください。AWS Glue のトラブルシューティングの例については、「[Using the Troubleshooting Agent](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/spark-troubleshooting-using-troubleshooting-agent.html)」の 2 番目のデモを参照してください。 | ## Apache Spark の生成 AI トラブルシューティングの仕組み 失敗した Spark ジョブの場合、生成 AI のトラブルシューティングはジョブのメタデータと、ジョブのエラー署名に関連する正確なメトリクスとログを分析して根本原因分析を生成し、ジョブの障害に対処するのに役立つ特定のソリューションとベストプラクティスを推奨します。 ## ジョブ用の Apache Spark の生成 AI トラブルシューティングの設定 ### IAM 許可の設定 AWS Glue のジョブに対して Spark トラブルシューティングで使用される APIs にアクセス許可を付与するには、適切な IAM アクセス許可が必要です。次のカスタム AWS ポリシーを IAM アイデンティティ (ユーザー、ロール、グループなど) にアタッチすることで、許可を取得できます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:StartCompletion", "glue:GetCompletion" ], "Resource": [ "arn:aws:glue:*:*:completion/*", "arn:aws:glue:*:*:job/*" ] } ] } ``` ------ **注記** AWS Glue Studio コンソールを通じてこのエクスペリエンスを実現するための IAM ポリシーでは、`StartCompletion` と `GetCompletion` の 2 つの API が使用されます。 ### 権限の割り当て アクセスを提供するには、ユーザー、グループ、またはロールにアクセス許可を追加します。 + IAM Identity Center のユーザーおよびグループでは: 許可セットを作成します。「IAM Identity Center のユーザーガイド」の「[許可セットの作成](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtocreatepermissionset.html)」の手順に従ってください。 + アイデンティティプロバイダーを介して IAM で管理されているユーザーでは: ID フェデレーションのロールを作成します。詳細については、「IAM ユーザーガイド」の「[サードパーティー ID プロバイダー (フェデレーション) 用のロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html)」を参照してください。 + IAM ユーザーでは: 引き受けることができるロールを作成します。手順については、「IAM ユーザーガイド」の「[IAM ユーザー用ロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」を参照してください。 ## 失敗したジョブ実行からのトラブルシューティング分析の実行 AWS Glue コンソールの複数のパスからトラブルシューティング機能にアクセスできます。開始方法はこちら: ### オプション 1: ジョブリストページから 1. AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. ナビゲーションペインで、**[ETL ジョブ]** を選択します。 1. 失敗したジョブをジョブリストで見つけます。 1. ジョブの詳細セクションで**[実行]** タブを選択します。 1. 分析する失敗したジョブ実行をクリックします。 1. **[AI によるトラブルシューティング]** を選択して分析を開始します。 1. トラブルシューティング分析が完了したら、画面の下部にある **[トラブルシューティング分析]** タブで根本原因分析と推奨事項を表示できます。 ![\[GIF には、失敗した実行のエンドツーエンドの実装と、AI 機能の実行によるトラブルシューティングが表示されます。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/troubleshoot_spark_option_1_jobs_list.gif) ### オプション 2: [ジョブ実行モニタリング] ページの使用 1. **[ジョブ実行のモニタリング]** ページに移動します。 1. 失敗したジョブ実行を見つけます。 1. ドロップダウンメニューで **[アクション]** を選択します。 1. **[AI によるトラブルシューティング]** を選択します。 ![\[GIF には、失敗した実行のエンドツーエンドの実装と、AI 機能の実行によるトラブルシューティングが表示されます。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/troubleshoot_spark_option_2_job_monitoring.gif) ### オプション 3: [ジョブ実行の詳細] ページから 1. 失敗したジョブ実行の詳細ページに移動するには、**[実行]** タブから失敗した実行の **[詳細を表示]** をクリックするか、**[ジョブ実行のモニタリング]** ページからジョブ実行を選択します。 1. ジョブ実行の詳細ページで、**[トラブルシューティング分析]** タブを見つけます。 ## サポートされているトラブルシューティングカテゴリ このサービスは、データエンジニアとデベロッパーが Spark アプリケーションで頻繁に遭遇する問題の 3 つの主要なカテゴリに焦点を当てています。 + **リソースのセットアップとアクセスエラー:** AWS Glue で Spark アプリケーションを実行する場合、リソースのセットアップとアクセスエラーは、診断するのが最も一般的でありながら難しい問題の 1 つです。これらのエラーは、Spark アプリケーションが、AWS リソースとやり取りしようとしても、アクセス許可の問題、リソースの欠落、または設定の問題が発生した場合によく発生します。 + **Spark ドライバーとエグゼキュターのメモリの問題:** Apache Spark ジョブのメモリ関連のエラーは、診断と解決が複雑なものである場合があります。これらのエラーは、多くの場合、データ処理要件がドライバーノードまたはエグゼキューターノードで使用可能なメモリリソースを超えたときに発生します。 + **Spark ディスク容量の問題:** AWS Glue Spark ジョブのストレージ関連のエラーは、シャッフル操作、データスピル、または大規模なデータ変換の処理中に発生することがよくあります。これらのエラーは、ジョブがしばらく実行されるまで表示されない可能性があり、貴重なコンピューティング時間とリソースを浪費する可能性があります。 + **クエリ実行エラー:** Spark SQL および DataFrame オペレーションのクエリエラーは、エラーメッセージが根本原因を明確に指さない可能性があり、小さなデータセットで正常に機能するクエリが突然大規模に失敗する可能性があるため、トラブルシューティングが困難になる可能性があります。これらのエラーは、複雑な変換パイプラインの深い段階で発生すると、特定がさらに困難になります。実際の原因は、クエリロジック自体ではなく、前段階におけるデータ品質の問題に起因する場合があります。 **注記** 本番環境に提案された変更を実装する前に、提案された変更を徹底的に確認してください。このサービスは、パターンとベストプラクティスに基づいてレコメンデーションを提供しますが、特定のユースケースでは追加の考慮事項が必要になる場合があります。 ## サポート対象のリージョン Apache Spark の生成 AI トラブルシューティングは、次のリージョンで利用できます。 + **アフリカ**: ケープタウン (af-south-1) + **アジアパシフィック**: 香港 (ap-east-1)、東京 (ap-northeast-1)、ソウル (ap-northeast-2)、大阪 (ap-northeast-3)、ムンバイ (ap-south-1)、シンガポール (ap-southeast-1)、シドニー (ap-southeast-2)、ジャカルタ (ap-southeast-3) + **欧州**: フランクフルト (eu-central-1)、ストックホルム (eu-north-1)、ミラノ (eu-south-1)、アイルランド (eu-west-1)、ロンドン (eu-west-2)、パリ (eu-west-3) + **中東**: バーレーン (me-south-1)、UAE (me-central-1) + **北米**: カナダ (ca-central-1) + **南米**: サンパウロ (sa-east-1) + **米国**: バージニア北部 (us-east-1)、オハイオ (us-east-2)、北カリフォルニア (us-west-1)、オレゴン (us-west-2) # AWS Glue でマテリアライズドビューを使用する AWS Glue バージョン 5.1 以降では、AWS Glue Data Catalog での Apache Iceberg マテリアライズドビューの作成と管理がサポートされています。マテリアライズドビューは、SQL クエリの事前計算された結果を Apache Iceberg 形式で保存し、基盤となるソーステーブルが変更されると段階的に更新するマネージドテーブルです。マテリアライズドビューを使用して、データ変換パイプラインを簡素化し、複雑な分析ワークロードのクエリパフォーマンスを高速化できます。 AWS Glue で Spark を使用してマテリアライズドビューを作成すると、ビュー定義とメタデータが AWS Glue Data Catalog に保存されます。事前に計算された結果は、アカウント内の Amazon S3 Tables バケットまたは Amazon S3 汎用バケットに Apache Iceberg テーブルとして保存されます。AWS Glue Data Catalog は、ソーステーブルを自動的にモニタリングし、マネージドコンピューティングインフラストラクチャを使用してマテリアライズドビューを更新します。 **Topics** + [マテリアライズドビューと AWS Glue が連動する仕組み](#materialized-views-how-they-work) + [前提条件](#materialized-views-prerequisites) + [マテリアライズドビューを使用するように Spark を設定する](#materialized-views-configuring-spark) + [マテリアライズドビューの作成](#materialized-views-creating) + [マテリアライズドビューのクエリ](#materialized-views-querying) + [「マテリアライズドビューの更新」](#materialized-views-refreshing) + [マテリアライズドビューを管理する](#materialized-views-managing) + [マテリアライズドビューのアクセス許可](#materialized-views-permissions) + [マテリアライズドビューオペレーションをモニタリングする](#materialized-views-monitoring) + [例: ワークフローの完了](#materialized-views-complete-workflow) + [考慮事項と制限事項](#materialized-views-considerations-limitations) ## マテリアライズドビューと AWS Glue が連動する仕組み マテリアライズドビューは、Apache Spark の Iceberg サポートを介して AWS Glue ジョブと AWS Glue Studio ノートブックで AWS Glue と統合されます。AWS Glue Data Catalog を使用するように Spark セッションを設定すると、標準の SQL 構文を使用してマテリアライズドビューを作成できます。Spark オプティマイザは、パフォーマンスを向上させるときにマテリアライズドビューを使用するようにクエリを自動的に書き換えることができるため、アプリケーションコードを手動で変更する必要はありません。 AWS Glue Data Catalog は、次のようなマテリアライズドビューメンテナンスの運用面のすべての側面を処理します。 + Apache Iceberg のメタデータレイヤーを使用したソーステーブルの変更の検出 + マネージド Spark コンピューティングを使用した更新オペレーションのスケジュールと実行 + データの変更に基づいて完全更新と増分更新のどちらを実行するかを決定する + 事前に計算された結果をマルチエンジンアクセス用に Apache Iceberg 形式で保存する 通常のテーブルに使用するのと同じ Spark SQL インターフェイスを使用して、AWS Glue からマテリアライズドビューをクエリできます。事前に計算されたデータは、Amazon Athena や Amazon Redshift などの他のサービスからもアクセスできます。 ## 前提条件 AWS Glue でマテリアライズドビューを使用するには、以下が必要です。 + アカウント + AWS Glue バージョン 5.1 以降 + Glue Data Catalog に登録された Apache Iceberg AWS 形式のソーステーブル + ソーステーブルとターゲットデータベース用に設定された AWS Lake Formation アクセス許可 + マテリアライズドビューデータを保存するために AWS Lake Formation に登録された S3 Tables バケットまたは S3 汎用バケット + AWS Glue Data Catalog と Amazon S3 へのアクセス許可を持つ IAM ロール ## マテリアライズドビューを使用するように Spark を設定する AWS Glue でマテリアライズドビューを作成および管理するには、必要な Iceberg 拡張機能とカタログ設定をで Spark セッションを設定します。設定方法は、AWS Glue ジョブと AWS Glue Studio ノートブックのどちらを使用しているかに応じて異なります。 ### AWS Glue ジョブを設定する AWS Glue ジョブを作成または更新するときは、次の設定パラメータをジョブパラメータとして追加します。 #### S3 Tables バケットの場合 ``` job = glue.create_job( Name='materialized-view-job', Role='arn:aws:iam::111122223333:role/GlueServiceRole', Command={ 'Name': 'glueetl', 'ScriptLocation': 's3://amzn-s3-demo-bucket/scripts/mv-script.py', 'PythonVersion': '3' }, DefaultArguments={ '--enable-glue-datacatalog': 'true', '--conf': 'spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions ' '--conf spark.sql.catalog.glue_catalog=org.apache.iceberg.spark.SparkCatalog ' '--conf spark.sql.catalog.glue_catalog.type=glue ' '--conf spark.sql.catalog.glue_catalog.warehouse=s3://amzn-s3-demo-bucket/warehouse ' '--conf spark.sql.catalog.glue_catalog.glue.region=us-east-1 ' '--conf spark.sql.catalog.glue_catalog.glue.id=111122223333 ' '--conf spark.sql.catalog.glue_catalog.glue.account-id=111122223333 ', '--conf spark.sql.catalog.glue_catalog.glue.lakeformation-enabled=true ', '--conf spark.sql.catalog.s3t_catalog=org.apache.iceberg.spark.SparkCatalog ' '--conf spark.sql.catalog.s3t_catalog.type=glue ' '--conf spark.sql.catalog.s3t_catalog.glue.id=111122223333:s3tablescatalog/my-table-bucket ', '--conf spark.sql.catalog.s3t_catalog.glue.account-id=111122223333 ', '--conf spark.sql.catalog.s3t_catalog.glue.lakeformation-enabled=true ', '--conf spark.sql.catalog.s3t_catalog.warehouse=s3://amzn-s3-demo-bucket/mv-warehouse ' '--conf spark.sql.catalog.s3t_catalog.glue.region=us-east-1 ' '--conf spark.sql.defaultCatalog=s3t_catalog ' '--conf spark.sql.optimizer.answerQueriesWithMVs.enabled=true ' '--conf spark.sql.materializedViews.metadataCache.enabled=true' }, GlueVersion='5.1' ) ``` #### S3 汎用バケットの場合 ``` job = glue.create_job( Name='materialized-view-job', Role='arn:aws:iam::111122223333:role/GlueServiceRole', Command={ 'Name': 'glueetl', 'ScriptLocation': 's3://amzn-s3-demo-bucket/scripts/mv-script.py', 'PythonVersion': '3' }, DefaultArguments={ '--enable-glue-datacatalog': 'true', '--conf': 'spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions ' '--conf spark.sql.catalog.glue_catalog=org.apache.iceberg.spark.SparkCatalog ' '--conf spark.sql.catalog.glue_catalog.type=glue ' '--conf spark.sql.catalog.glue_catalog.warehouse=s3://amzn-s3-demo-bucket/warehouse ' '--conf spark.sql.catalog.glue_catalog.glue.region=us-east-1 ' '--conf spark.sql.catalog.glue_catalog.glue.id=111122223333 ', '--conf spark.sql.catalog.glue_catalog.glue.account-id=111122223333 ', '--conf spark.sql.catalog.glue_catalog.glue.lakeformation-enabled=true ', '--conf spark.sql.defaultCatalog=glue_catalog ' '--conf spark.sql.optimizer.answerQueriesWithMVs.enabled=true ' '--conf spark.sql.materializedViews.metadataCache.enabled=true' }, GlueVersion='5.1' ) ``` ### AWS Glue Studio ノートブックを設定する AWS Glue Studio ノートブックで、ノートブックの先頭で %%configure マジックコマンドを使用して Spark セッションを設定します。 ``` %%configure { "conf": { "spark.sql.extensions": "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions", "spark.sql.catalog.glue_catalog": "org.apache.iceberg.spark.SparkCatalog", "spark.sql.catalog.glue_catalog.type": "glue", "spark.sql.catalog.glue_catalog.warehouse": "s3://amzn-s3-demo-bucket/warehouse", "spark.sql.catalog.glue_catalog.glue.region": "us-east-1", "spark.sql.catalog.glue_catalog.glue.id": "111122223333", "spark.sql.catalog.glue_catalog.glue.account-id": "111122223333", "spark.sql.catalog.glue_catalog.glue.lakeformation-enabled": "true", "spark.sql.defaultCatalog": "glue_catalog", "spark.sql.optimizer.answerQueriesWithMVs.enabled": "true", "spark.sql.materializedViews.metadataCache.enabled": "true" } } ``` ### 増分更新を有効化する 増分更新の最適化を有効にするには、ジョブパラメータまたはノートブック設定に次の設定プロパティを追加します。 ``` --conf spark.sql.optimizer.incrementalMVRefresh.enabled=true --conf spark.sql.optimizer.incrementalMVRefresh.deltaThresholdCheckEnabled=false ``` ### 設定パラメータ 次の設定パラメータは、マテリアライズドビューの動作を制御します。 + `spark.sql.extensions` – マテリアライズドビューのサポートに必要な Iceberg Spark セッション拡張機能を有効にします。 + `spark.sql.optimizer.answerQueriesWithMVs.enabled` – マテリアライズドビューを使用するための自動クエリ書き換えを有効にします。この最適化をアクティブ化するには、true に設定します。 + `spark.sql.materializedViews.metadataCache.enabled` – クエリ最適化のためのマテリアライズドビューメタデータのキャッシュを有効にします。クエリの書き換えパフォーマンスを向上させるには、true に設定します。 + `spark.sql.optimizer.incrementalMVRefresh.enabled` – 増分更新の最適化を有効にします。更新オペレーション中に変更されたデータのみを処理するには、true に設定します。 + `spark.sql.optimizer.answerQueriesWithMVs.decimalAggregateCheckEnabled` – クエリの書き換えにおける 10 進集計オペレーションの検証を制御します。false に設定すると、特定の 10 進オーバーフローチェックが無効になります。 ## マテリアライズドビューの作成 AWS Glue ジョブまたはノートブックで CREATE MATERIALIZED VIEW SQL ステートメントを使用してマテリアライズドビューを作成します。ビュー定義は、変換ロジックを 1 つまたは複数のソーステーブルを参照する SQL クエリとして指定します。 ### AWS Glue ジョブで基本的なマテリアライズドビューを作成する 次の例は、AWS Glue ジョブスクリプトでマテリアライズドビューを作成し、ビュー定義で 3 つの部分で構成される命名規則を持つ完全修飾されたテーブル名を使用する方法を示しています。 ``` from awsglue.context import GlueContext from pyspark.context import SparkContext sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session # Create materialized view spark.sql(""" CREATE MATERIALIZED VIEW customer_orders AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name """) ``` ### 自動更新でマテリアライズドビューを作成する 自動更新を設定するには、ビューの作成時に、ビュー定義で 3 つの部分で構成される命名規則を持つ完全修飾されたテーブル名を使用して更新スケジュールを指定します。 ``` spark.sql(""" CREATE MATERIALIZED VIEW customer_orders SCHEDULE REFRESH EVERY 1 HOUR AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name """) ``` ### クロスカタログ参照でマテリアライズドビューを作成する ソーステーブルがマテリアライズドビューとは異なるカタログにある場合は、ビュー名とビュー定義の両方に 3 つの部分で構成される命名規則を持つ完全修飾されたテーブル名を使用します。 ``` spark.sql(""" CREATE MATERIALIZED VIEW s3t_catalog.analytics.customer_summary AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name """) ``` ### AWS Glue Studio ノートブックにマテリアライズドビューを作成する AWS Glue Studio ノートブックでは、ビュー定義で 3 つの部分から構成される命名規則を持つ完全修飾されたテーブル名を使用して、%%sql マジックコマンドでマテリアライズドビューを作成できます。 ``` %%sql CREATE MATERIALIZED VIEW customer_orders AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name ``` ## マテリアライズドビューのクエリ マテリアライズドビューを作成したら、AWS Glue ジョブまたはノートブックで標準の SQL SELECT ステートメントを使用して、他のテーブルと同様にクエリを実行できます。 ### AWS Glue ジョブでクエリする ``` from awsglue.context import GlueContext from pyspark.context import SparkContext sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session # Query materialized view result = spark.sql("SELECT * FROM customer_orders") result.show() ``` ### AWS Glue Studio ノートブックでクエリする ``` %%sql SELECT * FROM customer_orders ``` ### 自動クエリ書き換え 自動クエリ書き換えを有効にすると、Spark オプティマイザはクエリを分析し、パフォーマンスを向上させることができるときにマテリアライズドビューを自動的に使用します。例えば、次のクエリを実行した場合を考えてみます。 ``` result = spark.sql(""" SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM orders GROUP BY customer_name """) ``` マテリアライズドビューが最新である場合、Spark オプティマイザは、ベースの orders テーブルを処理する代わりに customer\$1orders マテリアライズドビューを使用するよう、このクエリを自動的に書き換えます。 ### 自動クエリ書き換えを検証する クエリが自動クエリ書き換えを使用するかどうかを確認するには、EXPLAIN EXTENDED コマンドを使用します。 ``` spark.sql(""" EXPLAIN EXTENDED SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM orders GROUP BY customer_name """).show(truncate=False) ``` 実行プランで、BatchScan オペレーションでマテリアライズドビュー名を探します。BatchScan glue\$1catalog.sales.orders ではなく BatchScan glue\$1catalog.analytics.customer\$1orders がプランに表示される場合、マテリアライズドビューを使用するようにクエリが自動的に書き換えられています。 自動クエリ書き換えには、マテリアライズドビューの作成後に Spark メタデータキャッシュに入力する時間が必要であることに注意してください。通常、この処理は 30 秒以内に完了します。 ## 「マテリアライズドビューの更新」 マテリアライズドビューは、2 つの方法 (フル更新または増分更新) で更新できます。フル更新では、すべてのベーステーブルデータからマテリアライズドビュー全体が再計算されますが、増分更新では、前回の更新以降に変更されたデータのみが処理されます。 ### AWS Glue ジョブの手動フル更新 マテリアライズドビューの完全な更新を実行するには: ``` spark.sql("REFRESH MATERIALIZED VIEW customer_orders FULL") # Verify updated results result = spark.sql("SELECT * FROM customer_orders") result.show() ``` ### AWS Glue ジョブの手動増分更新 増分更新を実行するには、Spark セッション設定で増分更新が有効になっていることを確認して次を実行します。 ``` spark.sql("REFRESH MATERIALIZED VIEW customer_orders") # Verify updated results result = spark.sql("SELECT * FROM customer_orders") result.show() ``` AWS Glue Data Catalog は、ビュー定義と変更されたデータの量に基づいて、増分更新が適用されるかどうかを自動的に判断します。増分更新が不可能な場合、オペレーションはフル更新に戻ります。 ### AWS Glue Studio ノートブックで更新する ノートブックで、%%sql マジックコマンドを使用します。 ``` %%sql REFRESH MATERIALIZED VIEW customer_orders FULL ``` ### 増分更新の実行を検証する 増分更新が正常に実行されたことを確認するには、AWS Glue ジョブでデバッグログ記録を有効にします。 ``` from awsglue.context import GlueContext from pyspark.context import SparkContext import logging sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session # Enable debug logging logger = logging.getLogger('org.apache.spark.sql') logger.setLevel(logging.DEBUG) # Execute refresh spark.sql("REFRESH MATERIALIZED VIEW customer_orders") ``` AWS Glue ジョブログで次のメッセージを探します。 ``` DEBUG RefreshMaterializedViewExec: Executed Incremental Refresh ``` ## マテリアライズドビューを管理する AWS Glue には、ジョブとノートブックのマテリアライズドビューのライフサイクルを管理するための SQL コマンドが用意されています。 ### マテリアライズドビューを説明する マテリアライズドビューに関するメタデータ (定義、更新ステータス、最終更新タイムスタンプなど) を表示するには: ``` spark.sql("DESCRIBE EXTENDED customer_orders").show(truncate=False) ``` ### マテリアライズドビューを変更する 既存のマテリアライズドビューの更新スケジュールを変更するには: ``` spark.sql(""" ALTER MATERIALIZED VIEW customer_orders ADD SCHEDULE REFRESH EVERY 2 HOURS """) ``` 自動更新を削除するには: ``` spark.sql(""" ALTER MATERIALIZED VIEW customer_orders DROP SCHEDULE """) ``` ### マテリアライズドビューを削除する マテリアライズドビューを削除するには: ``` spark.sql("DROP MATERIALIZED VIEW customer_orders") ``` このコマンドは、AWS Glue Data Catalog からマテリアライズドビュー定義を削除し、基盤となる Iceberg テーブルデータを S3 バケットから削除します。 ### マテリアライズドビューを一覧表示する データベース内のすべてのマテリアライズドビューを一覧表示するには: ``` spark.sql("SHOW VIEWS FROM analytics").show() ``` ## マテリアライズドビューのアクセス許可 マテリアライズドビューを作成および管理するには、AWS Lake Formation アクセス許可を設定する必要があります。マテリアライズドビューを作成する IAM ロール (定義ロール) には、ソーステーブルとターゲットデータベースに対する特定のアクセス許可が必要です。 ### 定義者ロールに必要なアクセス許可 定義者ロールには、次の Lake Formation アクセス許可が必要です。 + ソーステーブル – 行、列、またはセルフィルターが適用されていない SELECT または ALL アクセス許可 + ターゲットデータベース – CREATE\$1TABLE アクセス許可 + AWS Glue Data Catalog – GetTable および CreateTable API アクセス許可 マテリアライズドビューを作成すると、定義ロールの ARN がビュー定義に保存されます。AWS Glue Data Catalog は、自動更新オペレーションを実行するときにこのロールを引き受けます。定義者ロールがソーステーブルへのアクセスを失った場合、アクセス許可が復元されるまで更新オペレーションは失敗します。 ### AWS Glue ジョブの IAM アクセス許可 AWS Glue ジョブの IAM ロールには、次のアクセス許可が必要です。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetCatalog", "glue:GetCatalogs", "glue:GetTable", "glue:GetTables", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetDatabase", "glue:GetDatabases", "cloudwatch:PutMetricData" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:*:*:*:/aws-glue/*" ] }, { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": "*" } ] } ``` マテリアライズドビューの自動更新に使用するロールには、ロールに対する iam:PassRole アクセス許可が必要です。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/materialized-view-role-name" ] } ] } ``` Glue でマテリアライズドビューを自動的に更新するには、サービスがロールを引き受けることができる次の信頼ポリシーもロールに必要です。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/materialized-view-role-name" ] } ] } ``` マテリアライズドビューが S3 Tables バケットに保存されている場合は、ロールに次のアクセス許可も追加する必要があります。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3tables:PutTableMaintenanceConfiguration" ], "Resource": "arn:aws:s3tables:*:123456789012:*" } ] } ``` ### マテリアライズドビューへのアクセスを付与する マテリアライズドビューをクエリするアクセス許可を他のユーザーに付与するには、 AWS Lake Formation を使用してマテリアライズドビューテーブルに対する SELECT アクセス許可を付与します。ユーザーは、マテリアライズドビューをクエリできます。基盤となるソーステーブルに直接アクセスする必要はありません。 詳細については、「AWS Lake Formation デベロッパーガイド」の「データカタログリソースに対するアクセス許可の付与」を参照してください。 ## マテリアライズドビューオペレーションをモニタリングする AWS Glue Data Catalog は、マテリアライズドビューの更新オペレーションのメトリクスとログを Amazon CloudWatch にパブリッシュします。更新ステータス、期間、処理されたデータボリュームを CloudWatch メトリクスからモニタリングできます。 ### ジョブログを表示する マテリアライズドビューを作成または更新する AWS Glue ジョブのログを表示するには: 1. AWS Glue コンソールを開きます。 1. ナビゲーションペインで、[Jobs] を選択します。 1. 目的のジョブを選択し、[Runs] を選択します。 1. 特定の実行を選択し、[Logs] を選択して CloudWatch ログを表示します。 ### アラームを設定する 更新オペレーションが失敗したとき、または想定期間を超えたときに通知を受け取るには、マテリアライズドビューメトリクスで CloudWatch アラームを作成します。Amazon EventBridge ルールを設定して、更新イベントへの自動応答をトリガーすることもできます。 ## 例: ワークフローの完了 次の例は、AWS Glue でマテリアライズドビューを作成して使用する完全なワークフローを示します。 ### AWS Glue ジョブスクリプトの例 ``` import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) # Create database and base table spark.sql("CREATE DATABASE IF NOT EXISTS sales") spark.sql("USE sales") spark.sql(""" CREATE TABLE IF NOT EXISTS orders ( id INT, customer_name STRING, amount DECIMAL(10,2), order_date DATE ) """) # Insert sample data spark.sql(""" INSERT INTO orders VALUES (1, 'John Doe', 150.00, DATE('2024-01-15')), (2, 'Jane Smith', 200.50, DATE('2024-01-16')), (3, 'Bob Johnson', 75.25, DATE('2024-01-17')) """) # Create materialized view spark.sql(""" CREATE MATERIALIZED VIEW customer_summary AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name """) # Query the materialized view print("Initial materialized view data:") spark.sql("SELECT * FROM customer_summary").show() # Insert additional data spark.sql(""" INSERT INTO orders VALUES (4, 'Jane Smith', 350.00, DATE('2024-01-18')), (5, 'Bob Johnson', 100.25, DATE('2024-01-19')) """) # Refresh the materialized view spark.sql("REFRESH MATERIALIZED VIEW customer_summary FULL") # Query updated results print("Updated materialized view data:") spark.sql("SELECT * FROM customer_summary").show() job.commit() ``` ### AWS Glue Studio ノートブックの例 ``` %%configure { "conf": { "spark.sql.extensions": "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions", "spark.sql.catalog.glue_catalog": "org.apache.iceberg.spark.SparkCatalog", "spark.sql.catalog.glue_catalog.type": "glue", "spark.sql.catalog.glue_catalog.warehouse": "s3://amzn-s3-demo-bucket/warehouse", "spark.sql.catalog.glue_catalog.glue.region": "us-east-1", "spark.sql.catalog.glue_catalog.glue.id": "111122223333", "spark.sql.catalog.glue_catalog.glue.account-id": "111122223333", "spark.sql.catalog.glue_catalog.glue.lakeformation-enabled": "true", "spark.sql.defaultCatalog": "glue_catalog", "spark.sql.optimizer.answerQueriesWithMVs.enabled": "true", "spark.sql.materializedViews.metadataCache.enabled": "true" } } ``` ``` %%sql CREATE DATABASE IF NOT EXISTS sales ``` ``` %%sql USE sales ``` ``` %%sql CREATE TABLE IF NOT EXISTS orders ( id INT, customer_name STRING, amount DECIMAL(10,2), order_date DATE ) ``` ``` %%sql INSERT INTO orders VALUES (1, 'John Doe', 150.00, DATE('2024-01-15')), (2, 'Jane Smith', 200.50, DATE('2024-01-16')), (3, 'Bob Johnson', 75.25, DATE('2024-01-17')) ``` ``` %%sql CREATE MATERIALIZED VIEW customer_summary AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name ``` ``` %%sql SELECT * FROM customer_summary ``` ``` %%sql INSERT INTO orders VALUES (4, 'Jane Smith', 350.00, DATE('2024-01-18')), (5, 'Bob Johnson', 100.25, DATE('2024-01-19')) ``` ``` %%sql REFRESH MATERIALIZED VIEW customer_summary FULL ``` ``` %%sql SELECT * FROM customer_summary ``` ## 考慮事項と制限事項 AWS Glue でマテリアライズドビューを使用する場合は、次の点を考慮してください。 + マテリアライズドビューには AWS Glue バージョン 5.1 以降が必要です。 + ソーステーブルは、AWS Glue Data Catalog に登録されている Apache Iceberg テーブルである必要があります。ローンチの時点では、Apache Hive、Apache Hudi、Linux Foundation Delta Lake テーブルはサポートされていません。 + ソーステーブルは、マテリアライズドビューと同じリージョンとアカウントに存在する必要があります。 + すべてのソーステーブルは AWS Lake Formation によって管理される必要があります。IAM のみのアクセス許可とハイブリッドアクセスはサポートされていません。 + マテリアライズドビューは、AWS Glue Data Catalog ビュー、マルチダイアレクトビュー、その他のマテリアライズドビューをソーステーブルとして参照することはできません。 + ビュー定義ロールには、行、列、またはセルフィルターが適用されていないすべてのソーステーブルに対するフル読み取りアクセス (SELECT または ALL アクセス許可) が必要です。 + マテリアライズドビューは、結果的にソーステーブルと整合します。更新中に、クエリが古いデータを返すことがあります。即自的な整合性が必要な場合は手動更新を実行します。 + 自動更新の最小間隔は 1 時間です。 + 増分更新は、SQL オペレーションの制限されたサブセットをサポートします。ビュー定義は単一の SELECT-FROM-WHERE-GROUP BY-HAVING ブロックである必要があり、セットオペレーション、サブクエリ、SELECT または集計関数の DISTINCT キーワード、ウィンドウ関数、INNER JOIN 以外の結合を含むことはできません。 + 増分更新は、ユーザー定義関数と特定の組み込み関数をサポートしていません。Spark SQL 組み込み関数のサブセットのみがサポートされています。 + クエリの自動書き換えでは、増分更新の制限と同様に、制限された SQL サブセットに定義が属するマテリアライズドビューのみが考慮されます。 + 英数字とアンダースコア以外の特殊文字を含む識別子は、CREATE MATERIALIZED VIEW クエリでサポートされません。これは、カタログ/名前空間/テーブル名、列名と構造体フィールド名、CTE、エイリアスを始めとするすべての識別子タイプに適用されます。 + \$1\$1ivm プレフィックスで始まるマテリアライズドビュー列は、システム用に予約されています。Amazon は、将来のリリースでこれらの列を変更または削除する権利を留保します。 + SORT BY、LIMIT、OFFSET、CLUSTER BY、ORDER BY の句は、マテリアライズドビュー定義ではサポートされません。 + クロスリージョンソーステーブルとクロスアカウントソーステーブルはサポートされません。 + 自動更新ではデフォルトのカタログ設定とデータベース設定が使用されないため、ビュークエリで参照されるテーブルは 3 つの部分で構成される命名規則 (glue\$1catalog.my\$1db.my\$1table など) を使用する必要があります。 + フル更新オペレーションはテーブル全体を上書きし、以前のスナップショットが使用できなくなります。 + rand() や current\$1timestamp() などの非決定論的関数は、マテリアライズドビュー定義でサポートされません。 # AWS Glue ワーカータイプ ## 概要 AWS Glue では、小規模なストリーミングジョブから大規模なメモリ集約型のデータ処理タスクにおよぶ、さまざまなワークロード要件に対応するための複数のワーカータイプが提供されています。このセクションでは、利用可能なすべてのワーカータイプ、それらの仕様、および使用上の推奨事項に関する包括的な情報を提供します。 ### ワーカータイプカテゴリ AWS Glue には、2 つの主なワーカータイプカテゴリがあります。 + **G ワーカータイプ**: 標準 ETL ワークロード用に最適化された汎用コンピューティングワーカー + **R ワーカータイプ**: メモリ集約型の Spark アプリケーション用に設計されたメモリ最適化ワーカー ### データ処理ユニット (DPU) AWS Glue ワーカーで利用可能なリソースは DPU 単位で測定されます。DPU は処理能力を相対的に測定するもので、4 個の vCPU のコンピューティング性能と 16 GB のメモリで構成されています。 **メモリ最適化 DPU (M-DPU)**: R タイプのワーカーは M-DPU を使用します。M-DPU では、特定のサイズに対するメモリ割り当てが標準 DPU の 2 倍になります。つまり、標準 DPU が 16 GB のメモリを提供する一方で、R タイプワーカーの M-DPU はメモリ集約型 Spark アプリケーション用に最適化された 32 GB のメモリを提供します。 ## 利用可能なワーカータイプ ### G.1X + **DPU**: 1 DPU (4 vCPU、16 GB メモリ) + **ストレージ**: 94 GB ディスク (空き容量約 44 GB) + **ユースケース**: データ変換、結合、クエリ - ほとんどのジョブに対して優れたスケーラビリティとコスト効率性を実現 ### G.2X + **DPU**: 2 DPU (8 vCPU、32 GB メモリ) + **ストレージ**: 138 GB ディスク (空き容量約 78 GB) + **ユースケース**: データ変換、結合、クエリ - ほとんどのジョブに対して優れたスケーラビリティとコスト効率性を実現 ### G.4X + **DPU**: 4 DPU (16 vCPU、64 GB メモリ) + **ストレージ**: 256 GB ディスク (空き容量約 230 GB) + **ユースケース**: 要求の厳しい変換、集約、結合、クエリ ### G.8X + **DPU**: 8 DPU (32 vCPU、128 GB メモリ) + **ストレージ**: 512 GB ディスク (空き容量約 485 GB) + **ユースケース**: 要求の厳しい変換、集約、結合、クエリ ### G.12X + **DPU**: 12 DPU (48 vCPU、192 GB メモリ) + **ストレージ**: 768 GB ディスク (空き容量約 741 GB) + **ユースケース**: 大量のコンピューティングキャパシティを必要とする極めて大規模なリソース集約型ワークロード ### G.16X + **DPU**: 16 DPU (64 vCPU、256 GB メモリ) + **ストレージ**: 1024 GB ディスク (空き容量約 996 GB) + **ユースケース**: 最大限のコンピューティングキャパシティを必要とする最も大規模で最もリソース集約型のワークロード ### R.1X - メモリ最適化\$1 + **DPU**: 1 M-DPU (4 vCPU、32 GB メモリ) + **ユースケース**: メモリ不足エラーが頻繁に発生する、または高いメモリ対CPU比要件を伴うメモリ集約型ワークロード ### R.2X - メモリ最適化\$1 + **DPU**: 2 M-DPU (8 vCPU、64 GB メモリ) + **ユースケース**: メモリ不足エラーが頻繁に発生する、または高いメモリ対CPU比要件を伴うメモリ集約型ワークロード ### R.4X - メモリ最適化\$1 + **DPU**: 4 M-DPU (16 vCPU、128 GB メモリ) + **ユースケース**: メモリ不足エラーが頻繁に発生する、または高いメモリ対CPU比要件を伴う大規模メモリ集約型ワークロード ### R.8X - メモリ最適化\$1 + **DPU**: 8 M-DPU (32 vCPU、256 GB メモリ) + **ユースケース**: メモリ不足エラーが頻繁に発生する、または高いメモリ対CPU比要件を伴う超大規模メモリ集約型ワークロード **\$1** これらのワーカーでは、高い起動レイテンシーが発生する可能性があります。この問題を解決するには、以下の手順を実行します。 + 数分間待ってからジョブを再度送信する。 + ワーカー数を減らした新しいジョブを送信する。 + 別のワーカータイプまたはサイズを使用して新しいジョブを送信する。 ## ワーカータイプ仕様表 **ワーカータイプの仕様** | ワーカータイプ | ノードあたりの DPU | vCPU | メモリ (GB) | ディスク (GB) | おおよその空きディスク容量 (GB) | ノードあたりの Spark エグゼキューター | | --- | --- | --- | --- | --- | --- | --- | | G.1X | 1 | 4 | 16 | 94 | 44 | 1 | | G.2X | 2 | 8 | 32 | 138 | 78 | 1 | | G.4X | 4 | 16 | 64 | 256 | 230 | 1 | | G.8X | 8 | 32 | 128 | 512 | 485 | 1 | | G.12X | 12 | 48 | 192 | 768 | 741 | 1 | | G.16X | 16 | 64 | 256 | 1024 | 996 | 1 | | R.1X | 1 | 4 | 32 | 94 | 44 | 1 | | R.2X | 2 | 8 | 64 | 138 | 78 | 1 | | R.4X | 4 | 16 | 128 | 256 | 230 | 1 | | R.8X | 8 | 32 | 256 | 512 | 485 | 1 | *注意*: R ワーカータイプは、メモリ集約型ワークロード用に最適化された仕様のメモリ最適化構成になっています。 ## 重要な考慮事項 ### 起動レイテンシー **重要** G.12X と G.16X のワーカータイプ、およびすべての R ワーカータイプ (R.1X～R.8X) では、高い起動レイテンシーが発生する可能性があります。この問題を解決するには、以下の手順を実行します。 数分間待ってからジョブを再度送信する。 ワーカー数を減らした新しいジョブを送信する。 別のワーカータイプとサイズを使用して新しいジョブを送信する。 ## 適切なワーカータイプの選択 ### 標準 ETL ワークロードの場合 + **G.1X または G.2X**: 一般的なデータ変換、結合、クエリ向けのコスト効率性が最も高いワーカータイプ + **G.4X または G.8X**: より大きなデータセットを使用する要求の厳しいワークロード向け ### 大規模なワークロードの場合 + **G.12X**: 大量のコンピューティングリソースを必要とする極めて大規模なデータセット向け + **G.16X**: 要求が最も厳しいワークロードに最大のコンピューティングキャパシティを提供 ### メモリ集約型ワークロードの場合 + **R.1X または R.2X**: 小規模から中規模のメモリ集約型ジョブ向け + **R.4X または R.8X**: OOM エラーが頻繁に発生する大規模なメモリ集約型ワークロード向け ## コスト最適化に関する考慮事項 + **標準 G ワーカー**: コンピューティング、メモリ、ネットワークリソース間のバランスが取れたワーカーで、多種多様なワークロードに低コストで利用可能 + **R ワーカー**: メモリ集約型のタスクに特化しており、メモリ内で大規模なデータセットを処理するワークロードに高速パフォーマンスを提供 ## ベストプラクティス ### ワーカーの選択ガイドライン 1. ほとんどのワークロードについては**標準ワーカー (G.1X、G.2X)**から開始する 1. メモリ不足エラーが頻繁に発生する場合や、キャッシュ、シャッフル、集約などのメモリ集約型操作を行うワークロードの場合は **R ワーカーを使用する** 1. 最大のリソースを必要とするコンピューティング集約型ワークロードには **G.12X/G.16X を検討する** 1. 時間的な制約があるワークフローで新しいワーカータイプを使用するときは**キャパシティの制約を考慮する** ### パフォーマンスの最適化 + CloudWatch メトリクスを監視してリソースの使用状況を把握する + データサイズと複雑性に基づいて適切なワーカー数を使用する + ワーカーの効率を最適化するためのデータパーティショニング戦略を検討する # AWS Glue でのストリーミング ETL ジョブ 連続的に実行されるストリーミング抽出/変換/ロード (ETL) ジョブを作成し、Amazon Kinesis Data Streams、Apache Kafka、Amazon Managed Streaming for Apache Kafka (Amazon MSK) などのストリーミングソースからのデータを使用できます。ジョブはデータをクレンジングして変換し、その結果を Amazon S3 データレイクまたは JDBC データストアにロードします。 さらに、Amazon Kinesis Data Streams ストリーム用のデータを生成できます。この機能は AWS Glue スクリプトを作成中のみ使用できます。詳細については、「[Kinesis 接続](aws-glue-programming-etl-connect-kinesis-home.md)」を参照してください。 デフォルトでは、AWS Glue は 100 秒ウィンドウ単位でデータ処理と書き出しを行います。これにより、データを効率的に処理しつつ、想定より遅く到着したデータに対する集計を実行できます。このウィンドウサイズを変更して、タイムリーで高精度の集計にできます。AWS Glue ストリーミングジョブでは、ジョブブックマークではなくチェックポイントを使用して、読み取られたデータを追跡します。 **注記** AWS Glue では、実行中の ETL ジョブのストリーミングに対して 1 時間ごとに課金します。 このビデオでは、ストリーミング ETL のコストに関する課題と、AWS Glue のコスト削減機能について説明しています。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/6ggTFOtfUxU/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/6ggTFOtfUxU) ストリーミング ETL ジョブを作成するには、次の手順を実行します。 1. Apache Kafka ストリーミングソースの場合は、Kafka ソースまたは Amazon MSK クラスターへの AWS Glue 接続を作成します。 1. ストリーミングソースの Data Catalog テーブルを手動で作成します。 1. ストリーミングデータソースの ETL ジョブを作成します。ストリーミング固有のジョブプロパティを定義し、独自のスクリプトを指定するか、生成されたスクリプトを必要に応じて変更します。 詳細については、「[AWS Glue でのストリーミング ETL](components-overview.md#streaming-etl-intro)」を参照してください。 Amazon Kinesis Data Streams にストリーミング ETL ジョブを作成する場合、AWS Glue 接続を作成する必要はありません。ただし、Kinesis Data Streams をソースとする AWS Glue ストリーミング ETL ジョブへの接続がある場合は、の場合は、Kinesis への Virtual Private Cloud (VPC) エンドポイントが必要です。詳細については、「Amazon VPC ユーザーガイド」の[インターフェイスエンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint)を参照してください。別のアカウントで Amazon Kinesis Data Streams ストリームを指定する場合は、クロスアカウントアクセスを許可するようにロールおよびポリシーを設定する必要があります。詳細については、「[例: 別のアカウントで Kinesis Stream から読み込む](https://docs.aws.amazon.com/kinesisanalytics/latest/java/examples-cross.html)」を参照してください。 AWS Glue ストリーミング ETL ジョブにより、圧縮データの自動検出が行えます。また、ストリーミングデータを透過的に解凍し、入力ソースに対して一般的な変換を実行して、出力ストアにロードすることができます。 AWS Glue は、入力形式に対して指定された、以下の圧縮タイプのための自動解凍をサポートしています。 | 圧縮タイプ | Avro ファイル | Avro データム | JSON | CSV | Grok | | --- | --- | --- | --- | --- | --- | | BZIP2 | あり | はい | はい | はい | はい | | GZIP | いいえ | はい | はい | はい | はい | | SNAPPY | はい (raw Snappy) | はい (framed Snappy) | はい (フレーム付 Snappy) | はい (フレーム付 Snappy) | はい (フレーム付 Snappy) | | XZ | あり | はい | はい | はい | はい | | ZSTD | はい | なし | なし | なし | いいえ | | DEFLATE | あり | はい | はい | はい | はい | **Topics** + [Apache Kafka データストリームの AWS Glue 接続の作成](#create-conn-streaming) + [ストリーミングソースの Data Catalog テーブルの作成](#create-table-streaming) + [Avro ストリーミングソースに関する注意事項と制約事項](#streaming-avro-notes) + [ストリーミングソースへの grok パターンの適用](#create-table-streaming-grok) + [ストリーミング ETL ジョブのジョブプロパティの定義](#create-job-streaming-properties) + [ストリーミング ETL に関する注意と制限](#create-job-streaming-restrictions) ## Apache Kafka データストリームの AWS Glue 接続の作成 Apache Kafka ストリームから読み取りを行うには、AWS Glue 接続を作成する必要があります。 **Kafka ソース用の AWS Glue 接続を作成するには (コンソール)** 1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/) で AWS Glue コンソール を開きます。 1. ナビゲーションペインの [**データカタログ**] で [**接続**] を選択します。 1. [**接続の追加**] を選択し、[**接続のプロパティを設定します**] ページで接続名を入力します。 **注記** 接続プロパティ指定の詳細については、「[AWS Glue connection properties.](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-connections)」( の接続プロパティ) を参照してください。 1. [**接続タイプ**] で、[**Kafka**] を選択します。 1. **Kafka のブートストラップサーバーの URL** として、Amazon MSK クラスターまたは Apache Kafka クラスターのブートストラップブローカーのホストとポート番号を入力します。Kafka クラスターへの初期接続を確立するには、Transport Layer Security (TLS) エンドポイントのみを使用します。Plaintext エンドポイントはサポートされていません。 Amazon MSK クラスターのホスト名とポート番号のペアのリスト例を次に示します。 ``` myserver1.kafka.us-east-1.amazonaws.com:9094,myserver2.kafka.us-east-1.amazonaws.com:9094, myserver3.kafka.us-east-1.amazonaws.com:9094 ``` ブートストラップブローカー情報の取得の詳細については、「*Amazon Managed Streaming for Apache Kafka デベロッパーガイド*」の「[Getting the Bootstrap Brokers for an Amazon MSK Cluster](https://docs.aws.amazon.com/msk/latest/developerguide/msk-get-bootstrap-brokers.html)」を参照してください。 1. Kafka データソースへのセキュアな接続が必要な場合は、[**Require SSL connection**] (SSL 接続が必要) を選択し、[**Kafka private CA certificate location**] (Kafka　のプライベート CA 証明書の場所) に、カスタム SSL 証明書への有効な Amazon S3 パスを入力します。 自己管理型 Kafka への SSL 接続の場合、カスタム証明書は必須です。Amazon MSK ではオプションです。 Kafka のカスタム証明書を指定する方法の詳細については、「[AWS Glue SSL 接続プロパティ](connection-properties.md#connection-properties-SSL)」を参照してください。 1. AWS Glue Studio または AWS CLI を使用して、Kafka クライアントの認証方法を指定します。AWS Glue Studio にアクセスするには、左側のナビゲーションペインの [**ETL**] メニューから **[AWS Glue]** を選択します。 Kafka クライアントの認証方法の詳細については、「[クライアント認証用の AWS Glue Kafka 接続プロパティ](#connection-properties-kafka-client-auth)」を参照してください。 1. 必要に応じて説明を入力し、[**Next**] (次へ) をクリックします。 1. Amazon MSK クラスターの場合は、その Virtual Private Cloud (VPC)、サブネット、およびセキュリティグループを指定します。VPC 情報は、自己管理型 Kafka の場合はオプションです。 1. [**Next**] (次へ) をクリックして、すべての接続プロパティを確認し、[**Finish**] (完了) をクリックします。 AWS Glue 接続の詳細については、「[データへの接続](glue-connections.md)」を参照してください。 ### クライアント認証用の AWS Glue Kafka 接続プロパティ **SASL/GSSAPI (Kerberos) 認証** この認証方法を選択すると、Kerberos のプロパティを指定できます。 **Kerberos のキータブ** キータブファイルの場所を選択します。キータブには、1 つ以上のプリンシパルの長期キーが保存されます。詳細については、「[MIT Kerberos ドキュメント: キータブ](https://web.mit.edu/kerberos/krb5-latest/doc/basic/keytab_def.html)」を参照してください。 **Kerberos の krb5.conf ファイル** krb5.conf ファイルを選択します。これには、デフォルトの領域 (同じ KDC のシステムのグループを定義する論理ネットワークで、ドメインに類似しています) と KDC サーバーの場所が含まれます。詳細については、「[MIT Kerberos ドキュメント: krb5.conf](https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html)」を参照してください。 **Kerberos のプリンシパルと Kerberos のサービス名** Kerberos のプリンシパルとサービス名を入力します。詳細については、「[MIT Kerberos ドキュメント: Kerberos のプリンシパル](https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/What-is-a-Kerberos-Principal_003f.html)」を参照してください。 **SASL/SCRAM-SHA-512 認証** この認証方法を選択すると、認証情報を指定することができます。 **AWS Secrets Manager** [Search] (検索) ボックスに名前または ARN を入力して、トークンを検索します。 **プロバイダのユーザー名とパスワードを直接入力** [Search] (検索) ボックスに名前または ARN を入力して、トークンを検索します。 **SSL クライアント認証** この認証方法を選択すると、Amazon S3 を参照することによって Kafka クライアントキーストアの場所を選択できます。オプションで、Kafka クライアントキーストアのパスワードと Kafka クライアントキーのパスワードを入力できます。 **IAM 認証** この認証方法は追加の仕様を必要とせず、ストリーミングソースが MSK Kafka の場合にのみ適用されます。 **SASL/PLAIN 認証** この認証方法を選択すると、認証情報を指定することができます。 ## ストリーミングソースの Data Catalog テーブルの作成 データスキーマなど、ソースデータストリームのプロパティを指定するデータカタログテーブルを手動でストリーミングソースに対して作成できます。このテーブルは、ストリーミング ETL ジョブのデータソースとして使用されます。 ソースデータストリーム内のデータのスキーマがわからない場合は、スキーマなしでテーブルを作成できます。次に、ストリーミング ETL ジョブを作成するときに、AWS Glue スキーマ検出機能を有効にできます。AWS Glue では、ストリーミングデータからスキーマを決定します。 テーブルを作成するには、[AWS Glue コンソール](https://console.aws.amazon.com/glue/)、AWS Command Line Interface (AWS CLI)、または AWS Glue API を使用します。AWS Glue コンソールを使用して手動でテーブルを作成する方法については、「[テーブルの作成](tables-described.md)」を参照してください。 **注記** AWS Lake Formation コンソールを使用してテーブルを作成することはできません。AWS Glue コンソールを使用する必要があります。 また、Avro 形式のストリーミングソースや Grok パターンを適用できるログデータについては、次の情報を考慮します。 + [Avro ストリーミングソースに関する注意事項と制約事項](#streaming-avro-notes) + [ストリーミングソースへの grok パターンの適用](#create-table-streaming-grok) **Topics** + [Kinesis データソース](#kinesis-source) + [Kafka データソース](#kafka-source) + [AWS Glue スキーマレジストリテーブルのソース](#schema-registry-table) ### Kinesis データソース テーブルを作成するときは、次のストリーミング ETL プロパティ (コンソール) を設定します。 **ソースの種類** **Kinesis** **同じアカウント内の Kinesis ソースの場合:** **リージョン** Amazon Kinesis Data Streams サービスが存在する AWS リージョン。リージョンと Kinesis ストリーム名は一緒にストリーム ARN に変換されます。 例: https://kinesis.us-east-1.amazonaws.com **Kinesis ストリーム名** 「*Amazon Kinesis Data Streams デベロッパーガイド*」の「[Creating a Stream](https://docs.aws.amazon.com/streams/latest/dev/kinesis-using-sdk-java-create-stream.html)」に記載されているストリーム名。 **別のアカウントの Kinesis ソースについては、[この例](https://docs.aws.amazon.com/kinesisanalytics/latest/java/examples-cross.html) を参照して、アカウント間アクセスを許可するようにロールとポリシーを設定します。これらの設定を行います。** **ストリーム ARN** コンシューマーを登録する Kinesis データストリームの ARN。詳細については、*AWS 全般のリファレンス* の「[Amazon リソースネーム (ARN) と AWS サービス ネームスぺース](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」を参照してください。 **引き受けたロールの ARN** 引き受けるロールの Amazon リソースネーム (ARN)。 **セッション名 (オプション)** 引き受けたロールセッションの識別子。 異なるプリンシパルによって同じロールが引き継がれた場合にセッションを一意に識別するために、またはその他の理由で、ロールセッション名を使用します。クロスアカウントシナリオでは、ロールセッション名が表示され、ロールを所有するアカウントでログ記録できます。引き受けたロールプリンシパルの ARN では、ロールセッション名も使用されます。つまり、一時的なセキュリティ認証情報を使用する後続のクロスアカウント API リクエストでは、ロールセッション名が AWS CloudTrail ログとして外部アカウントに開示されます。 **Amazon Kinesis Data Streams のストリーミング ETL プロパティを設定するには (AWS Glue API または AWS CLI)** + 同じアカウント内の Kinesis ソースのストリーミング ETL プロパティを設定するには、`CreateTable` API オペレーションまたは `create_table` CLI コマンドの `StorageDescriptor` データ構造の `streamName` および `endpointUrl` パラメータを指定します。 ``` "StorageDescriptor": { "Parameters": { "typeOfData": "kinesis", "streamName": "sample-stream", "endpointUrl": "https://kinesis.us-east-1.amazonaws.com" } ... } ``` または、`streamARN` を指定します。 **Example** ``` "StorageDescriptor": { "Parameters": { "typeOfData": "kinesis", "streamARN": "arn:aws:kinesis:us-east-1:123456789:stream/sample-stream" } ... } ``` + 別のアカウントの Kinesis ソースのストリーミング ETL プロパティを設定するには、`CreateTable` API オペレーションまたは `create_table` CLI コマンドの `StorageDescriptor` データ構造の `streamARN`、`awsSTSRoleARN`、および `awsSTSSessionName` (オプション) パラメータを指定します。 ``` "StorageDescriptor": { "Parameters": { "typeOfData": "kinesis", "streamARN": "arn:aws:kinesis:us-east-1:123456789:stream/sample-stream", "awsSTSRoleARN": "arn:aws:iam::123456789:role/sample-assume-role-arn", "awsSTSSessionName": "optional-session" } ... } ``` ### Kafka データソース テーブルを作成するときは、次のストリーミング ETL プロパティ (コンソール) を設定します。 **ソースの種類** **Kafka** **Kafka ソースの場合:** **トピック名** Kafka で指定されたトピック名。 **接続** Kafka ソースを参照する AWS Glue 接続 (「[Apache Kafka データストリームの AWS Glue 接続の作成](#create-conn-streaming)」を参照)。 ### AWS Glue スキーマレジストリテーブルのソース AWS Glue スキーマレジストリをストリーミングジョブに使用するには、[ユースケース: AWS Glue Data Catalog](schema-registry-integrations.md#schema-registry-integrations-aws-glue-data-catalog) スキーマレジストリのテーブルを作成または更新する手順に従ってください。 現在、AWS Glue ストリーミングは、`false` にスキーマ推論が設定されたGlue スキーマレジストリ Avro 形式のみをサポートします。 ## Avro ストリーミングソースに関する注意事項と制約事項 Avro 形式のストリーミングソースには、次の注意事項と制限事項が適用されます。 + スキーマの検出が有効になっている場合、Avro スキーマをペイロードに含める必要があります。無効にすると、ペイロードにはデータのみが含まれます。 + 一部の Avro データ型は、ダイナミックフレームでサポートされていません。AWS Glue コンソールの [create table] (テーブル作成) ウィザードの [**Define a schema**] (スキーマの定義) でスキーマを定義するときに、これらのデータ型を指定することはできません。スキーマの検出中に、Avro スキーマでサポートされていない型は、次のようにサポートされている型に変換されます。 + `EnumType => StringType` + `FixedType => BinaryType` + `UnionType => StructType` + コンソールの [**Define a schema**] (スキーマの定義) ページでテーブルスキーマを定義する場合は、スキーマの暗黙のルート要素タイプは `record` です。`record` 以外のルート要素タイプ (`array` や `map` など) が必要な場合、[**Define a schema**] (スキーマの定義) ページでスキーマを指定することはできません。代わりに、そのページをスキップして、スキーマをテーブルプロパティとして、または ETL スクリプト内で指定する必要があります。 + テーブルのプロパティでスキーマを指定するには、テーブル作成ウィザードを完了し、テーブルの詳細を編集し、[**Table properties**] (テーブルのプロパティ) に新しいキーと値のペアを追加します。`avroSchema` キーを使用して、次のスクリーンショットに示すように、値のスキーマ JSON オブジェクトを入力します。 ![\[[Table properties] (テーブルのプロパティ) の見出しの下に、2 列のテキストフィールドがあります。左側の列見出しは [Key] (キー) であり、右側の列見出しは [Value] (値) です。最初の行のキー/値のペアは、classification/avro です。2 行目のキー/値のペアは、avroSchema/{"type":"array","items":"string"} です。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/table_properties_avro.png) + ETL スクリプトでスキーマを指定するには、次の Python と Scala の例に示すように、`datasource0` 代入ステートメントを修正し、`avroSchema` キーを `additional_options` 引数に追加します。 ------ #### [ Python ] ``` SCHEMA_STRING = ‘{"type":"array","items":"string"}’ datasource0 = glueContext.create_data_frame.from_catalog(database = "database", table_name = "table_name", transformation_ctx = "datasource0", additional_options = {"startingPosition": "TRIM_HORIZON", "inferSchema": "false", "avroSchema": SCHEMA_STRING}) ``` ------ #### [ Scala ] ``` val SCHEMA_STRING = """{"type":"array","items":"string"}""" val datasource0 = glueContext.getCatalogSource(database = "database", tableName = "table_name", redshiftTmpDir = "", transformationContext = "datasource0", additionalOptions = JsonOptions(s"""{"startingPosition": "TRIM_HORIZON", "inferSchema": "false", "avroSchema":"$SCHEMA_STRING"}""")).getDataFrame() ``` ------ ## ストリーミングソースへの grok パターンの適用 ログデータソース用のストリーミング ETL ジョブを作成し、Grok パターンを使用してログを構造化データに変換できます。その後、ETL ジョブは、データを構造化データソースとして処理します。ストリーミングソースの Data Catalog テーブルを作成するときに適用する Grok パターンを指定します。 Grok パターンとカスタムパターン文字列値については、「[Grok カスタム分類子の書き込み](custom-classifier.md#custom-classifier-grok)」を参照してください。 **Grok パターンを Data Catalog テーブルに追加するには (コンソール)** + [create table] (テーブル作成) ウィザードを使用し、[ストリーミングソースの Data Catalog テーブルの作成](#create-table-streaming) に指定されたパラメータでテーブルを作成します。データ形式を Grok として指定し、[**Grok pattern**] (Grok パターン) フィールドに入力し、必要に応じてカスタムパターンを [**Custom patterns (optional)**] (カスタムパターン (オプション)) に追加します。 ![\[*\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/grok-data-format-create-table.png) 各カスタムパターンの後に、**Enter** を押します。 **Grok パターンを Data Catalog テーブルに追加するには (AWS Glue API または AWS CLI)** + `GrokPattern` パラメータと、必要に応じて `CustomPatterns` パラメータを `CreateTable` API オペレーションまたは `create_table` CLI コマンドに追加します。 ``` "Parameters": { ... "grokPattern": "string", "grokCustomPatterns": "string", ... }, ``` `grokCustomPatterns` を文字列として表現し、パターン間の区切りとして「\$1n」を使用します。 これらのパラメータの指定の例を次に示します。 **Example** ``` "parameters": { ... "grokPattern": "%{USERNAME:username} %{DIGIT:digit:int}", "grokCustomPatterns": "digit \d", ... } ``` ## ストリーミング ETL ジョブのジョブプロパティの定義 AWS Glue コンソールでストリーミング ETL ジョブを定義する場合は、次に示すストリーム固有のプロパティを指定します。その他のジョブプロパティの説明については、「[Spark ジョブのジョブプロパティの定義](add-job.md#create-job)」を参照してください。 **IAM ロール** ジョブの実行、ストリーミングソースへのアクセス、およびターゲットデータストアへのアクセスに使用されるリソースへの権限付与に使用される AWS Identity and Access Management (IAM) ロールを指定します。 Amazon Kinesis Data Streams にアクセスする場合は、 AWS 管理ポリシー `AmazonKinesisFullAccess` をロールにアタッチするか、よりきめ細かにアクセスを許可する同様の IAM ポリシーをアタッチします。サンプルポリシーについては、「[IAM を使用して Amazon Kinesis Data Streams リソースへのアクセスを制御する](https://docs.aws.amazon.com/streams/latest/dev/controlling-access.html)」を参照してください。 AWS Glue でジョブを実行するためのアクセス権限の詳細については、[AWS Glue のアイデンティティとアクセスの管理](security-iam.md) を参照してください。 **タイプ** [**Spark Streaming**] (スパークストリーミング)を選択します。 **AWS Glue バージョン** AWS Glue バージョンによって、ジョブで使用できる Apache Spark、および Python または Scala のバージョンが決まります。ジョブで使用可能な Python または Scala のバージョンを指定する選択肢を選択します。AWS Glueバージョン 2.0 (Python 3 をサポート) は、ストリーミング ETL ジョブのデフォルトです。 **メンテナンスウィンドウ** ストリーミングジョブを再起動できるウィンドウを指定します。「[AWS Glue ストリーミングのメンテナンスウィンドウ](glue-streaming-maintenance.md)」を参照してください。 **ジョブのタイムアウト** 必要に応じて、長さを分単位で入力します。デフォルト値は空白です。 + ストリーミングジョブのタイムアウト値は 7 日または 10080 分未満である必要があります。 + 値が空白の場合、メンテナンスウィンドウを設定していない場合、ジョブは 7 日後に再起動されます。メンテナンスウィンドウを設定している場合、ジョブは7 日後にメンテナンスウィンドウ中に再起動されます。 **データソース** 「[ストリーミングソースの Data Catalog テーブルの作成](#create-table-streaming)」で作成したテーブルを指定します。 **データターゲット** 次のいずれかを行います。 + [**データターゲットでテーブルを作成する**] を選択し、次に示すデータターゲットプロパティを指定します。 **データストア** Amazon S3 または JDBC を選択します。 **形式** 任意の形式を選択します。ストリーミングではすべてがサポートされています。 + [**Use tables in the data catalog and update your data target**] (データカタログのテーブルを使用し、データターゲットを更新する) を選択し、JDBC データストアのテーブルを選択します。 **出力スキーマ定義** 次のいずれかを行います。 + [**Automatically detect schema of each record**] (各レコードのスキーマを自動的に検出) を選択してスキーマ検出を有効にします。AWS Glue は、ストリーミングデータからスキーマを決定します。 + [**Specify output schema for all records**] (すべてのレコードの出力スキーマを指定する) を選択して、[Apply Mapping] (マッピングの適用) 変換を使用して出力スキーマを定義します。 **スクリプト** 必要に応じて、独自のスクリプトを指定するか、生成されたスクリプトを変更して、Apache Spark 構造化ストリーミングエンジンでサポートされる操作を実行します。使用可能な操作の詳細については、「[Operations on streaming DataFrames/Datasets](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#operations-on-streaming-dataframesdatasets)」を参照してください。 ## ストリーミング ETL に関する注意と制限 次の注意事項と制限事項に留意してください。 + AWS Glue ストリーミング ETL ジョブでの自動解凍は、サポートされた圧縮タイプに対してのみ使用できます。また、以下の点にも注意してください。 + Framed Snappy とは、公式の[フレーミング形式](https://github.com/google/snappy/blob/main/framing_format.txt)を使用する Snappy を指します。 + Deflate がサポートされるのは、Glue バージョン 3.0 です (Glue バージョン 2.0 ではサポートされません)。 + スキーマ検出を使用する場合、ストリーミングデータの結合を実行できません。 + AWS Glue のストリーミング ETL ジョブは、Avro 形式の AWS Glue スキーマレジストリに対する Union データ型をサポートしません。 + ETL スクリプトでは、AWS Glue の組み込み変換と Apache Spark 構造化ストリーミングのネイティブな変換を使用できます。詳細については、Apache Spark ウェブサイトの「[ストリーミング DataFrames/Datasets の操作](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#operations-on-streaming-dataframesdatasets)」または「[AWS Glue PySpark 変換リファレンス](aws-glue-programming-python-transforms.md)」を参照してください。 + AWS Glue ストリーミング ETL ジョブでは、チェックポイントを使用して、読み取ったデータの追跡が行われます。このため、停止して再起動されたジョブは、ストリーム内で中断した位置から開始されます。データを再処理する場合は、スクリプト内で参照されているチェックポイントフォルダを削除することができます。 + ジョブのブックマークはサポートされていません。 + ジョブで Kinesis Data Streams の拡張ファンアウト機能を使用するには、「[Kinesis ストリーミングジョブでの拡張ファンアウトの使用](aws-glue-programming-etl-connect-kinesis-efo.md)」を参照してください。 + AWS Glue スキーマレジストリ から作成されたData Catalog テーブルを使用する場合、新しいスキーマバージョンが使用可能になったら、新しいスキーマを反映するには、次の操作を行う必要があります。 1. テーブルに関連するジョブを停止します。 1. Data Catalog テーブルのスキーマを更新します。 1. テーブルに関連付するジョブを再起動します。 # AWS Lake Formation FindMatches によるレコードのマッチング **注記** レコードの照合は現在、次のリージョンの AWS Glue コンソールではご利用いただけません: 中東 (アラブ首長国連邦)、欧州 (スペイン)、アジアパシフィック (ジャカルタ)、欧州 (チューリッヒ)。 AWS Lake Formation には、カスタム変換を作成するための機械学習機能が用意されています。現在、FindMatches という名前の変換が 1 つあります。FindMatches 変換を使用すると、レコードに共通の一意の識別子がなく、正確に一致するフィールドがない場合でも、データセット内の重複レコードまたは一致するレコードを識別できます。そのため、コードを記述したり、機械学習の仕組みを知ったりする必要はありません。FindMatches は、次のようなさまざまな問題で役立ちます。 + **一致する顧客**: 多くの顧客フィールドがデータベース間で正確に一致しない場合でも（名前のスペルや住所の違い、データの欠落や不正確ななど）、異なる顧客データベース間で顧客レコードをリンクします。 + **製品のマッチング**: カタログ内の製品を、競合他社のカタログに対する製品カタログなど、他の製品ソースと照合します。エントリの構造は異なります。 + **不正検出の向上**: 重複した顧客アカウントを特定し、新しく作成したアカウントが、以前に知られている不正ユーザーと一致する（またはその可能性のある）タイミングを判断します。 + **マッチングに関するその他の問題**: マッチアドレス、映画、パーツリストなど。一般的に、人間がデータベース行を見て、それらが一致していると判断した場合、FindMatches 変換が役に立つ可能性は非常にあります。 これらの変換は、ジョブの作成時に作成できます。作成する変換は、ラベル付けするソースデータセットからのストアスキーマとサンプルデータに基づいています (このプロセスを変換の「トレーニング」と呼びます)。ラベルを付けるレコードは、ソースデータセットに存在する必要があります。このプロセスでは、ラベル付けしたファイルを生成し、変換が学習する方法でアップロードし直します。変換を教えたら、Spark ベースの AWS Glue ジョブ (PySpark または Scala Spark) から呼び出し、互換性のあるソースデータストアを持つ他のスクリプトで使用できます。 作成した変換は AWS Glue に保存されます。AWS Glue コンソールで、作成した変換を管理できます。**[データ統合とETL]** のナビゲーションペインで **[データ分類ツール] > [レコードのマッチング]** の順に移動して、機械学習変換を編集し、トレーニングを継続できます。コンソールで変換を管理する方法の詳細については、「 [機械学習変換の使用](console-machine-learning-transforms.md)」を参照してください。 **注記** AWS Glue version 2.0 FindMatchesジョブは、transformがデータを処理している間、`aws-glue-temp--` 一時ファイルを保存するためにAmazon S3バケットを使用します。このデータは、手動または Amazon S3 ライフサイクルルールを設定して、実行の完了後に削除する事ができます。 ## 機械学習変換のタイプ 機械学習変換を作成して、データを最適化できます。これらの変換は、ETL スクリプトから呼び出すことができます。データは、変換から変換へと *DynamicFrame* というデータ構造で渡されます。これは、Apache Spark SQL `DataFrame` を拡張したものです。`DynamicFrame` にはデータが含まれており、データを処理するためにそのスキーマを参照します。 次のタイプの機械学習変換を利用できます。 *Find matches (一致の検索)* ソースデータの重複したレコードを見つけます。この機械学習変換をトレーニングするには、サンプルデータセットにラベルを付けて、どの行が一致するかを示します。機械学習変換は、ラベル付けしたサンプルデータを使用してトレーニングするほど、どの行が一致するかを学習します。変換の設定方法に応じて、出力は次のいずれかになります。 + 入力テーブルのコピーと、一致するレコードのセットを示す値が入力された `match_id` 列。`match_id` 列は任意の識別子です。同じ `match_id` を持つレコードは、互いに一致するレコードとして識別されています。`match_id` が異なるレコードが一致しません。 + 重複する行が削除された入力テーブルのコピー。複数の重複が見つかった場合、最も低いプライマリキーを持つレコードが保持されます。 *インクリメンタルマッチを検索する* Find matches トランスフォームは、既存のフレームとインクリメンタルフレーム間で一致を検索し、一致グループごとに一意の ID を含む列を出力として返すように構成することもできます。 詳細については、「[インクリメンタルマッチを検索する。](machine-learning-incremental-matches.md)」を参照してください。 ### FindMatches 変換の使用 `FindMatches` 変換を使用してソースデータの重複したレコードを見つけることができます。変換をトレーニングするために役立つラベリングファイルが生成または提供されます。 **注記** 現在、カスタム暗号化キーを使用する `FindMatches` 変換は、次のリージョンではサポートされていません。 アジアパシフィック (大阪) - `ap-northeast-3` FindMatches 変換の使用を開始する場合は、以下の手順に従ってください。より高度で詳細な例については、**AWS ビッグデータブログ**の「[Harmonize data using AWS Glue and AWS Lake Formation FindMatches ML to build a customer 360 view](https://aws.amazon.com/blogs/big-data/harmonize-data-using-aws-glue-and-aws-lake-formation-findmatches-ml-to-build-a-customer-360-view/)」を参照してください。 #### Find Matches Transform (一致の検索変換) の使用開始 `FindMatches` 変換の使用を開始するには、次の手順に従います。 1. 最適化するソースデータ用のテーブルを AWS Glue Data Catalog に作成します。クローラーの作成方法については、「[Working with Crawlers on the AWS Glue Console](https://docs.aws.amazon.com/glue/latest/dg/console-crawlers.html)」を参照してください。 ソースデータがカンマ区切り値 (CSV) ファイルなどのテキストベースのファイルである場合は、以下の点を考慮してください。 + 入力レコード CSV ファイルとラベリングファイルを別個のフォルダに保持します。そうしないと、AWS Glue クローラーはこれらのファイルを同じテーブルの複数の部分と見なして、データカタログに誤ったテーブルを作成する場合があります。 + CSV ファイルに ASCII 文字のみが含まれている場合を除き、CSV ファイルには必ず BOM (バイトオーダーマーク) なしの UTF-8 エンコードを使用します。Microsoft Excel は、UTF-8 CSV ファイルの先頭に BOM を追加することがよくあります。これを削除するには、CSV ファイルをテキストエディタで開き、ファイルを **BOM なしの UTF-8** として保存し直します。 1. AWS Glue コンソールでジョブを作成し、[**Find matches (一致の検索)**] 変換タイプを選択します。 **重要** ジョブ用に選択するデータソーステーブルの列数は 100 を超えることはできません。 1. [**Generate labeling file**] (ラベルファイルを生成) を選択して、ラベル付けファイルを生成するように AWS Glue に伝えます。AWS Glue は、各 `labeling_set_id` に対して類似のレコードをグループ化する最初のパスを実行し、グループ化を確認できるようにします。`label` 列で一致のラベルを付けます。 + ラベル付けファイルが既にある場合 (つまり、一致する行を示すサンプルレコードがある場合) は、そのファイルを Amazon Simple Storage Service (Amazon S3) にアップロードします。ラベリングファイルの形式の詳細については、「[ラベリングファイルの形式](#machine-learning-labeling-file)」を参照してください。ステップ 4 に進みます。 1. ラベル付けファイルをダウンロードし、「[ラベリング](#machine-learning-labeling) 」 セクションの説明に従ってファイルにラベルを付けます。 1. 修正したラベル付きファイルをアップロードします。AWS Glue は一致の検索方法について変換をトレーニングするためのタスクを実行します。 [**Machine learning transforms (機会学習変換)**] リストのページで、[**History (履歴)**] タブを選択します。このページは、AWS Glue で以下のタスクを実行するタイミングを指定します。 + **ラベルのインポート** + **ラベルのエクスポート** + **ラベルの生成** + **品質の推定** 1. より適切な変換を作成するには、ラベル付きファイルのダウンロード、ラベル付け、アップロードを繰り返すことができます。初期の実行では、レコードのミスマッチがより多く発生しがちです。ただし、ラベリングファイルを検証して継続的にトレーニングすることで、AWS Glue は学習します。 1. 変換を評価して微調整するには、一致の検索のパフォーマンスと結果を評価します。詳細については、「[AWS Glue での機械学変換の調整](add-job-machine-learning-transform-tuning.md)」を参照してください。 #### ラベリング `FindMatches` がラベル付けファイルを生成すると、ソーステーブルからレコードが選択されます。これまでのトレーニングに基づき、`FindMatches` は最も学習価値が高いレコードを特定します。 *ラベル付け*では、ラベリングファイル（Microsoft Excel などのスプレッドシートの使用を推奨）を編集し、一致するレコードと一致しないレコードを識別する `label` 列に識別子またはラベルを追加します。ソースデータの一致について一貫した明確な定義を持つことが重要です。`FindMatches` は、ユーザーが一致 (または不一致) として指定したレコードから学習します。また、ユーザーの判断を使用して重複するレコードを見つける方法を学習します。 ラベリングファイルが `FindMatches` で生成されると、約 100 個のレコードが生成されます。これらの 100 個のレコードは通常 10 個の*ラベリングセット*に分割され、各ラベリングセットは `FindMatches` により生成される一意の `labeling_set_id` により識別されます。各ラベリングセットは、他のラベリングセットとは独立した個別のラベリングタスクとして表示する必要があります。タスクは、各ラベリングセット内の一致レコードと非一致レコードを識別することです。 ##### スプレッドシートでラベル付けファイルを編集するためのヒント スプレッドシートアプリケーションでラベリングファイルを編集する場合は、以下の点を考慮してください。 + ファイルを開いたときに、列フィールドが完全に展開されていない場合があります。必要に応じて `labeling_set_id` 列と `label` 列を展開し、これらのセルの内容を表示してください。 + プライマリキー列が数値 (`long` データ型など) である場合、スプレッドシートはこれを数値として解釈し、値を変更する場合があります。このキー値は、テキストとして扱う必要があります。この問題を修正するには、プライマリキー列のすべてのセルを **テキストデータ**としてフォーマットします。 #### ラベリングファイルの形式 `FindMatches` 変換をトレーニングするために AWS Glue により生成されたラベリングファイルは、次の形式を使用します。AWS Glue 用に独自のファイルを生成する場合は、次の形式にも従う必要があります。 + これは、カンマ区切り値 (CSV) ファイルです。 + `UTF-8` でエンコードする必要があります。Microsoft Windows を使用してファイルを編集すると、ファイルは `cp1252` でエンコードされる場合があります。 + このファイルを AWS Glue に渡すには、ファイルを Amazon S3 の場所に配置する必要があります。 + 各ラベル付けタスクに使用する行は多すぎないようにします。タスクごとに許容される行数は 2～30 行ですが、10～20 行をお勧めします。50 行を超えるタスクは推奨されません。粗悪な結果やシステム障害を引き起こす可能性があります。 + 「一致」または「不一致」とラベリングされたレコードのペアで構成される、ラベリングされたデータがすでにある場合、これは問題ありません。これらのラベリングされたペアは、サイズ 2 のラベリングセットとして表すことができます。この場合、両方のレコードに一致する場合は文字「A」とラベリングし、一致しない場合は「Ｂ」とラベリングします。 **注記** ラベリングファイルには追加の列が含まれているため、ソースデータが含まれているファイルとはスキーマが異なります。ラベリングファイルは、他のすべての変換入力 CSV ファイルとは異なるフォルダに配置し、データカタログのテーブルの作成時に AWS Glue クローラーによって同種のファイルと見なされないようにします。そうしないと、AWS Glue クローラーで作成されたテーブルではデータが正しく表現されない場合があります。 + 最初の 2 つの列 (`labeling_set_id`、`label`) は AWS Glue の必須列です。残りの列は、処理するデータのスキーマと一致する必要があります。 + `labeling_set_id` ごとに、同じラベルを使用してすべての一致するレコードを特定します。ラベルは `label` 列に配置されている一意の文字列です。シンプルな文字 (A、B、C など) を含むラベルを使用することをお勧めします。ラベルは、大文字と小文字が区別され、 `label` 列に入力されます。 + 同じ `labeling_set_id` と同じラベルを含む行は、一致とみなされ、ラベリングされます。 + 同じ `labeling_set_id` と異なるラベルを含む行は、*不*一致とみなされ、ラベリングされます。 + 異なる `labeling_set_id` を含む行は、一致に関するいかなる情報も伝達しないとみなされます。 以下に示しているのは、データのラベル付けの例です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/machine-learning.html) + 上記の例では、John/Johnny/Jon Doe を一致と認識し、これらのレコードは Jane Smith と一致しないことをシステムにトレーニングします。これとは別に、Richard と Rich Jones は同一人物であるが、これらのレコードは Sarah Jones/Jones-Walker および Jones Jr. とは一致しないとシステムをトレーニングします。 + ご覧のとおり、ラベルの範囲は `labeling_set_id` に制限されています。したがって、ラベルは `labeling_set_id` 境界を超えません。たとえば、`labeling_set_id` 1 のラベル「A」は、`labeling_set_id` 2 のラベル「A」とは何の関係もありません。 + ラベリングセット内に一致するものがほかにないレコードには、一意のラベルを割り当てます。たとえば、Jane Smith はラベリングセット ABC123 内のどのレコードとも一致しないため、そのラベリングセット内で唯一の、ラベル B を持つレコードです。 + ラベリングセット「GHI678」は、ラベリングセットが、同じラベルが付与された 2 つのレコードのみで構成されることを表示し、一致していることを示します。同様に、「XYZABC」は、異なるラベルが付与された 2 つのレコードを表示し、一致しないことを示します。 + ラベリングセットには一致が含まれていないこと（ラベリングセット内のレコードそれぞれに異なるラベルを付ける）も、ラベリングセットがすべて「同じ」こと（すべてに同じラベルを付けた）もあります。これは、ラベリングセットに、基準によって「同じ」レコードと「同じでない」レコードの例がまとめて含まれている限り、問題ありません。 **重要** AWS Glue に渡す IAM ロールに、ラベリングファイルが格納されている Amazon S3 バケットへのアクセス権があることを確認してください。慣例として、AWS Glue ポリシーでは、名前に「**aws-glue-**」というプレフィックスが付いている Amazon S3 バケットまたはフォルダにアクセス許可を付与します。ラベリングファイルが別の場所にある場合、IAM ロールで、その場所に対してアクセス許可を追加します。 # AWS Glue での機械学変換の調整 AWS Glue で機械学習変換を調整することで、目的に応じてデータクレンジングジョブの結果を改善できます。変換を改善するには、変換をトレーニングします。そのためには、ラベリングセットを生成し、ラベルを追加します。これらのステップを、目的の結果が得られるまで何回も繰り返します。いくつかの機械学習パラメータを変更することで調整することもできます。 機械学習変換の詳細については、「[AWS Lake Formation FindMatches によるレコードのマッチング](machine-learning.md)」を参照してください。 **Topics** + [機械学習の測定](machine-learning-terminology.md) + [適合率と再現率のトレードオフ](machine-learning-precision-recall-tradeoff.md) + [精度とコストのトレードオフ](machine-learning-accuracy-cost-tradeoff.md) + [一致信頼度スコアを使用して一致の品質を見積もります。](match-scoring.md) + [「一致の検索」変換のトレーニング](machine-learning-teaching.md) # 機械学習の測定 機械学習変換の調整に使用する測定を理解するには、以下の用語を理解しておく必要があります。 **真陽性 (TP)** 変換が正しく検出したデータ内の一致。*ヒット*とも呼ばれます。 **真陰性 (TN)** 変換が正しく拒否したデータ内の不一致。 **偽陽性 (FP)** 変換が誤って一致として分類したデータ内の不一致。*誤警告*とも呼ばれます。 **偽陰性 (FN)** 変換が検出しなかったデータ内の一致。 *ミス*とも呼ばれます。 機械学習で使用される用語の詳細については、Wikipedia の「[混同行列](https://en.wikipedia.org/wiki/Confusion_matrix)」を参照してください。 機械学習変換を調整するには、変換の [**詳細プロパティ**] で以下の測定値を変更できます。 + **適合率**は、変換で要請と判定されたレコードの総数 (真陽性と偽陽性) のうち、どの程度真陽性を検出するかの尺度です。詳細については、Wikipedia の「 [適合率と再現率](https://en.wikipedia.org/wiki/Precision_and_recall)」を参照してください。 + **再現率**は、変換がソースデータのレコード総数から真陽性を見つける割合を測定します。詳細については、Wikipedia の「 [適合率と再現率](https://en.wikipedia.org/wiki/Precision_and_recall)」を参照してください。 + **精度**は、変換が真陽性と真陰性を見つける割合を測定します。精度を高めるには、マシンリソースとコストを増やす必要があります。ただし、再現率も高くなります。詳細については、Wikipedia の「[適合率と再現率](https://en.wikipedia.org/wiki/Accuracy_and_precision#In_information_systems)」を参照してください。 + **コスト**は、変換を実行するために消費されるコンピューティングリソースの数およびそれに伴う金額を測定します。 # 適合率と再現率のトレードオフ 各 `FindMatches` 変換には、`precision-recall` パラメータが含まれています。このパラメータを使用して、次のいずれかを指定します。 + 変換の結果で、2 つのレコードが誤って一致すると報告され、実際には一致していない場合は、*適合率*を高めます。 + 変換の結果で、2 つのレコードが実際には一致しているにもかかわらず、一致として検出されない場合は、*再現率*を高めます。 このトレードオフを行うには、AWS Glue コンソールまたは AWS Glue 機械学習 API オペレーションを使用できます。 **適合率を優先する場合** `FindMatches` で実際には一致しないレコードのペアが一致と見なされるリスクに対処するには、適合率を優先します。適合率を優先するには、適合率-再現率トレードオフとして*より高い*値を選択します。値を高くするほど、`FindMatches` 変換でレコードのペアを一致と見なす根拠がさらに必要となります。変換は調整されて、レコードのペアが一致しないと判断する傾向が強化されます。 たとえば、`FindMatches` を使用してビデオカタログ内の重複する商品を検出する際に、適合率-再現率のより高い値を変換に指定したとします。変換で「*スターウォーズ: 新たなる希望*」と「*スターウォーズ: 帝国の逆襲*」が誤って同じものとして検出された場合、「*新たなる希望*」を欲しい利用者に「*帝国の逆襲*」が提供される可能性があります。これは、カスタマーエクスペリエンスを悪化させることになります。 一方、変換で「*スターウォーズ: 新たなる希望*」と「*スターウォーズ エピソード 4/新たなる希望*」が同じ商品として検出されない場合、利用者は最初は混乱するとしても、最終的には同じものとして認識する可能性があります。これは誤検出ではあっても、前の例ほど深刻ではありません。 **再現率を優先する場合** `FindMatches` 変換の結果で、実際には一致するレコードのペアが一致として検出されないリスクに対処するには、再現率を優先します。再現率を優先するには、適合率-再現率トレードオフとして*より低い*値を選択します。値を低くするほど、`FindMatches` 変換でレコードのペアを一致と見なす根拠が少なくて済みます。変換は調整されて、レコードのペアが一致すると判断する傾向が強化されます。 たとえば、これはセキュリティを重視する組織で優先される場合があります。利用者を詐欺行為者のリストと照合する場合、利用者が詐欺行為者であるかどうかを判断することが重要です。`FindMatches` を使用して利用者リストと詐欺行為者リストを照合するとします。`FindMatches` において 2 つのリスト間で一致が検出されるたびに、該当する利用者が実際に詐欺行為者であるかどうかを人間の監査担当者が確認します。このような組織では、適合率よりも再現率を優先できます。つまり、利用者が実際に詐欺行為者リストに該当することを見逃すよりは、利用者が詐欺行為者ではないことを監査担当者が手動で確認して除外することを優先します。 **適合率と再現率の両方を優先する方法** 適合率と再現率の両方を改善する最適な方法は、ラベル付けするデータを増やすことです。より多くのデータをラベル付けすると、`FindMatches` 変換全体の精度が向上するため、適合率と再現率の両方が向上します。ただし、最も正確な変換であっても、適合率の優先、再現率の優先、または中間値の選択を試す必要があるグレー領域が常に存在します。 # 精度とコストのトレードオフ 各 `FindMatches` 変換には、`accuracy-cost` パラメータが含まれています。このパラメータを使用して、次のいずれかを指定できます。 + 変換で 2 つのレコードの一致が正確に報告されることをより重視する場合は、*精度*を強調します。 + 変換を実行するコストまたはスピードをより重視する場合は、*より低いコスト*を強調します。 このトレードオフを行うには、AWS Glue コンソールまたは AWS Glue 機械学習 API オペレーションを使用できます。 **精度を優先する場合** `find matches` の結果に一致が含まれないリスクに対処するには、精度を優先します。精度を優先するには、精度-コストトレードオフの*より高い*値を選択します。値が高いほど、`FindMatches` 変換でレコードを正しく一致させるために、より詳細な検索を行う時間を増やす必要があります。このパラメータは、一致しないレコードのペアを誤って一致と判断する可能性を減らすものではありません。変換は調整されて、一致の検索に費やす時間が増加されます。 **コストを優先する場合** 一致の検索数よりも `find matches` 変換を実行するコストをより重視する場合は、コストを優先します。コストを優先するには、精度-コストトレードオフの*より低い*値を選択します。値を低くするほど、 `FindMatches` 変換で実行する必要があるリソース数が減ります。一致の検索数を減らすように、変換が調整されます。より低いコストを優先したときの結果が許容できるものであれば、この設定を使用します。 **精度とより低いコストの両方を優先する方法** レコードが一致するかどうかを判断するためにより多くのレコードのペアを調査するには、より多くのマシン時間が必要になります。品質を下げずにコストを削減するには、以下を実行できます。 + 一致の対象としないレコードをデータソースから除外します。 + 一致/不一致の判断に役立たないことが確実な列をデータソースから除外します。これを決める適切な方法としては、一連のレコードが「同じ」であるかどうかの判断に影響しないと思われる列を除外します。 # 一致信頼度スコアを使用して一致の品質を見積もります。 一致信頼度スコアは、機械学習モデルの信頼度が高い、不確か、またはありそうにない一致レコードを区別するために、findMatches によって検出された一致の品質を推定します。一致信頼度スコアは 0 から 1 の間で、スコアが高いほど類似度が高くなります。一致信頼度スコアを調べると、システムが非常に信頼できる一致のクラスター（マージすることを決定する可能性があります）、システムが不確実であるクラスター（人間がレビューしたと決定する可能性がある）、および一致のクラスターを区別できます。 システムは可能性が低いと見なします（拒否することを決定する場合があります）。 一致信頼度スコアが高いが一致がないと判断した場合、またはスコアが低いが実際に一致しているかどうかを判断する状況では、トレーニングデータを調整できます。 信頼度スコアは、すべての FindMatches 決定を確認することが不可能な、大規模な産業用データセットがある場合に特に役立ちます。 一致信頼度スコアは AWS Glue バージョン 2.0 以降。 ## マッチ信頼度スコアの生成 ブール値を `computeMatchConfidenceScores` Trueに設定するか、`FindMatches` または `FindIncrementalMatches` APIを呼び出すときに一致信頼スコアを生成できます。 AWS Glue 新規に `column match_confidence_score` を出力に追加します。 ## スコアリングの例に一致 たとえば、次のマッチングレコードを考えてみましょう。 **スコア >= 0.9** 一致したレコードのサマリー: ``` primary_id | match_id | match_confidence_score 3281355037663 85899345947 0.9823658302132061 1546188247619 85899345947 0.9823658302132061 ``` 詳細: ![\[インターネットゲートウェイを使用したルートテーブルの例。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/match_score1.png) この例から、2 つのレコードが非常によく似ていて、`display_position`、`primary_name`、および`street name` を共有していることがわかります。 **スコア >= 0.8、得点 < 0.9** 一致したレコードのサマリー: ``` primary_id | match_id | match_confidence_score 309237680432 85899345928 0.8309852373674638 3590592666790 85899345928 0.8309852373674638 343597390617 85899345928 0.8309852373674638 249108124906 85899345928 0.8309852373674638 463856477937 85899345928 0.8309852373674638 ``` 詳細: ![\[インターネットゲートウェイを使用したルートテーブルの例。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/match_score2.png) この例から、これらのレコードが同じ `primary_name` および `country` を共有していることがわかります。 **スコア >= 0.6、得点 < 0.7** 一致したレコードのサマリー: ``` primary_id | match_id | match_confidence_score 2164663519676 85899345930 0.6971099896480333 317827595278 85899345930 0.6971099896480333 472446424341 85899345930 0.6971099896480333 3118146262932 85899345930 0.6971099896480333 214748380804 85899345930 0.6971099896480333 ``` 詳細: ![\[インターネットゲートウェイを使用したルートテーブルの例。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/match_score3.png) この例から、これらのレコードが同じもの `primary_name` を共有しているだけであることがわかります 。 詳細については、以下を参照してください。 + [ステップ 5: 機械学習変換でジョブを追加して実行する](machine-learning-transform-tutorial.md#ml-transform-tutorial-add-job) + PySpark: [FindMatches クラス](aws-glue-api-crawler-pyspark-transforms-findmatches.md) + PySpark: [FindIncrementalMatches クラス](aws-glue-api-crawler-pyspark-transforms-findincrementalmatches.md) + Scala: [FindMatches クラス](glue-etl-scala-apis-glue-ml-findmatches.md) + Scala: [FindIncrementalMatches クラス](glue-etl-scala-apis-glue-ml-findincrementalmatches.md) # 「一致の検索」変換のトレーニング 一致と不一致を見分けられるように各 `FindMatches` 変換をトレーニングする必要があります。変換をトレーニングするには、ファイルにラベルを追加して選択結果を AWS Glue にアップロードします。 このラベル付けは、AWS Glue コンソールまたは AWS Glue 機械学習 API オペレーションを使用して調整できます。 **ラベルを追加する回数は? 必要なラベルの数は?** これらの質問に対する回答は、主にユーザーが決定します。`FindMatches` で必要な精度レベルを達成できるかどうか、さらにラベル付けの作業を追加するメリットがあるかどうかは、ユーザーが評価する必要があります。これを決定する最善の方法は、AWS Glue コンソールで [**Estimate quality**] (品質の推定) を選択して、「適合率」、「再現率」、「適合率再現率曲線の下の面積」のメトリクスを調べることです。さらに多くのタスクセットにラベル付けをしたら、これらのメトリクスを再実行して結果が改善されたかどうかを確認します。いくつかのタスクセットをラベル付けをした後で、注目しているメトリクスに改善が見られなかった場合、変換の品質はそれ以上向上しない状態に達している可能性があります。 **真陽性と真陰性の両方のラベルが必要な理由は?** `FindMatches` 変換は、ユーザーが何を一致と見なしているかを学習するために真陽性と真陰性の両方のサンプルを必要とします。`FindMatches` で生成されるトレーニングデータ ([**I do not have labels (ラベルがありません)**] オプションなどを使用した場合) にラベル付けを行う場合、`FindMatches` はユーザーに代わって「ラベルセット ID」を生成しようとします。各タスク内で、一部のレコードに同じ「ラベル」を付け、他のレコードに異なる「ラベル」を付けます。つまり、通常、タスクがすべて同じものであったり、すべて異なるものであったりすることはありません (ただし、特定のタスク内のレコードがすべて「同じ」ものであったり、すべて「異なる」ものであったりすることは問題ありません)。 [**Upload labels from S3**] (S3 からラベルをアップロードする) オプションを使用して `FindMatches` 変換をトレーニングする場合は、一致レコードと不一致レコードの両方を含めるようにしてください。1 つのタイプのみを使用することもできます。これらのラベルはより正確な `FindMatches` 変換の構築に役立ちますが、[**Generate labeling file (ラベリングファイルの生成)**] オプションを使用して生成する一部のレコードには依然としてラベル付けを行う必要があります。 **どうしたら、ユーザーがトレーニングしたとおりのマッチングを変換に実行させることができるか?** `FindMatches` 変換は、ユーザーが指定したラベルから学習するため、指定したラベルを優先しないレコードのペアが生成される場合があります。ユーザーのラベルを優先するように `FindMatches` 変換を強制するには、 [**FindMatchesParameter**] の [**EnforceProvidedLabels**] を選択します。 **ML 変換が真の一致ではない項目を一致として識別した場合、どのように対策できますか?** 以下の対策を実行できます。 + `precisionRecallTradeoff` の値をより高くします。これにより、検出される一致の数が減りますが、十分に高い値に達すると、大きなクラスターの分割も行われます。 + 不正確な結果に対応する出力行を取得し、これらの行をラベリングセットとして再フォーマットします (`match_id` 列を削除し、`labeling_set_id` 列および `label` 列を追加します)。必要に応じて、複数のラベリングセットに分割 (再分割) し、ラベラーが各ラベリングセットに留意しながらラベルの割り当てができるようにします。次に、一致するセットに正しくラベル付けを行い、ラベルファイルをアップロードして既存のラベルに付加します。これにより、パターンを理解するためにどのようなデータが必要であるかについてトランスフォーマーが十分にトレーニングされます。 + (高度) 最後に、そのデータを確認し、システムが気付いていないパターンを検出できるかどうかを判断します。標準の AWS Glue 関数を使用してそのデータを事前処理し、データを*正規化*します。データの種類が十分に異なることが判明している場合は、データを種類別に分離し、アルゴリズムに学習させるデータを明確にします。または、複数の列のデータが関連していることが判明している場合は、これらの列を結合します。 # 機械学習変換の使用 AWS Glue に使用して、データの最適化に使用できるカスタム機械学習変換を作成できます。これらの変換は、AWS Glue コンソールでのジョブの作成時に使用できます。 機械学習変換の作成方法の詳細については、「[AWS Lake Formation FindMatches によるレコードのマッチング](machine-learning.md)」を参照してください。 **Topics** + [変換のプロパティ](#console-machine-learning-properties) + [機械学習変換の追加と編集](#console-machine-learning-transforms-actions) + [変換の詳細の確認](#console-machine-learning-transforms-details) + [ラベルを使って変換を教える](#console-machine-learning-transforms-teaching-transforms) ## 変換のプロパティ 既存の機械学習変換を表示するには、AWS マネジメントコンソール にサインインして、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。**[データ統合と ETL]** のナビゲーションペインで、**[データ分類ツール] > [レコードのマッチング]** の順に選択します。 各変換のプロパティ: **変換名** 変換の作成時に付けた一意の変換名。 **ID** 変換の一意の識別子。 **[Label count] (ラベル数)** 変換のトレーニングに役立てるために指定されたラベリングファイル内のラベルの数。 **ステータス** 変換が [**Ready**] (使用可能) であるか、[**Needs training**] (トレーニングが必要) であるかを示します。ジョブで機械学習変換を正常に実行するには、ジョブのステータスが [**Ready**] (使用可能) であることが必要です。 **作成** 変換の作成日。 **変更済み** 変換が最後に更新された日付。 **説明** 変換の説明 (説明が入力された場合)。 **AWS Glue バージョン** 使用する AWS Glue のバージョン。 **実行 ID** 変換の作成時に付けた一意の変換名。 **タスクタイプ** 機械学習変換のタイプ (**一致するレコードの検索**など)。 **ステータス** タスク実行のステータスを示します。次のようなステータスがあります。 + スタート + 実行中 + 停止中 + 停止 + 成功 + 失敗 + タイムアウト **エラー** ステータスが [失敗] の場合、失敗の理由を説明するエラーメッセージが表示されます。 ## 機械学習変換の追加と編集 AWS Glue コンソールで変換の表示、削除、セットアップ、トレーニング、および調整を行うことができます。リストの変換の横にあるチェックボックスをオンにし、 [**アクション**] を選択して、実行するアクションを選択します。 ### 新しい ML 変換の作成 新しい機械学習変換を追加するには、**[変換の作成]** を選択します。次に、**[ジョブの追加]** ウィザードの手順に従います。詳細については、「[AWS Lake Formation FindMatches によるレコードのマッチング](machine-learning.md)」を参照してください。 #### ステップ 1. 変換のプロパティを設定する。 1. 名前と説明 (オプション) を入力します。 1. オプションで、セキュリティ設定を設定します。「[機械学習変換でのデータ暗号化の使用](#ml_transform_sec_config)」を参照してください。 1. オプションで、タスク実行の設定を設定します。タスク実行の設定では、タスクの実行方法をカスタマイズできます。ワーカータイプ、ワーカーの数、タスクのタイムアウト (分単位)、再試行回数、AWS Glue バージョンを選択します。 1. 必要に応じて、タグを設定します。タグとは、AWS リソースに割り当てることができるラベルです。各タグは、キーおよび値 (オプション) で構成されます。タグを使用して、リソースを検索およびフィルタリングしたり、AWS のコストを追跡できます。 #### ステップ 2. テーブルとプライマリキーを選択する。 1. AWS Glue カタログデータベースおよびテーブルを選択します。 1. 選択したテーブルからプライマリキーを選択します。プライマリキー列には通常、データソース内のすべてのレコードの固有の識別子が含まれます。 #### ステップ 3. 調整オプションを選択する。 1. **[再現率と適合率]** では、再現率または適合率を優先するように変換を調整する調整値を選択します。デフォルトでは **[バランス]** が選択されていますが、再現率または適合率を優先するように選択するか、**[カスタム]** を選択して 0.0～1.0 (両端を含む) の値を入力できます。 1. **[コスト削減と正確度]** では、コスト削減または正確度を優先するように調整値を選択するか、**[カスタム]** を選択して 0.0～1.0 (両端を含む) の値を入力できます。 1. 使用するラベルと出力を一致させることで ML 変換を教える場合は、**[一致のエンフォースメント]** で、**[出力をラベルに一致させる]** を選択します。 #### ステップ 4. 確認して作成します。 1. ステップ 1～3 のオプションを確認します。 1. 変更が必要な手順については、**[編集]** を選択します。**[変換の作成]** を選択して、変換の作成ウィザードを完了します。 ### 機械学習変換でのデータ暗号化の使用 機械学習変換を AWS Glue に追加する際に、データソースまたはデータターゲットに関連付けられたセキュリティ設定をオプションで指定できます。データの格納に使用される Amazon S3 バケットがセキュリティ設定で暗号化されている場合は、変換の作成時に同じセキュリティ設定を指定します。 AWS KMS (SSE-KMS) でサーバー側の暗号化を使用して、モデルとラベルを暗号化し、許可されていない人に閲覧されるのを防ぐという選択もできます。このオプションを選択した場合は、AWS KMS key の名前を選択するように求められます。[**Enter a key ARN**] (キーの ARN を入力) を選択することもできます。KMS キーの ARN を入力することを選択した場合、KMS キー ARN を入力できる 2 番目のフィールドが表示されます。 **注記** 現在、次のリージョンではカスタム暗号化キーを使用する ML 変換がサポートされていません。 アジアパシフィック (大阪) - `ap-northeast-3` ## 変換の詳細の確認 ### 変換のプロパティを確認する **[変換プロパティ]** ページには、変換の属性が含まれます。変換定義に関する詳細として、以下の内容が表示されます。 + [**変換名**] は変換の名前を示します。 + [**タイプ**] は変換のタイプを一覧表示します。 + [**ステータス**] は、変換がスクリプトまたはジョブで使用可能かどうかを示します。 + [**Force output to match labels (出力をラベルに一致させる)**] は、ユーザーから提供されたラベルに出力を一致させるかどうかを示します。 + [**Spark version**] (Spark バージョン) は、変換を追加したときに [**Task run properties**] (タスク実行のプロパティ) で選択した AWS Glue のバージョンに関連しています。ほとんどのお客様に AWS Glue 1.0 および Spark 2.4 が推奨されます。詳細については、「[AWS Glue Versions](https://docs.aws.amazon.com/glue/latest/dg/release-notes.html#release-notes-versions)」を参照してください。 ### [履歴]、[品質を推定する]、[タグ] タブ 変換の詳細には、変換の作成時に定義した情報が含まれます。変換の詳細を確認するには、**機械学習変換**のリストで変換を選択し、以下のタブの情報を確認します。 + 履歴 + 品質の推定 + タグ #### 履歴 [**履歴**] タブには、変換のタスク実行の履歴が表示されます。変換をトレーニングするには、複数のタイプのタスクを実行します。タスクごとに、実行メトリクスとして以下が含まれます。 + [**実行 ID**] は、このタスクの実行ごとに AWS Glue によって作成される識別子です。 + [**Task type (タスクタイプ)**] は、タスク実行のタイプを示します。 + [**実行ステータス**] は、各タスクの成功した実行を一覧表示します。最新の実行が一番上に表示されます。 + [**Error (エラー)**] には、実行が正常に行われなかった場合のエラーメッセージの詳細が表示されます。 + [**開始時刻**] は、タスクの開始日時 (現地時間) を示します。 + **[終了時刻]** には、タスクの終了日時 (現地時間) が表示されます。 + [**ログ**] は、このジョブ実行の `stdout` に書き込まれたログにリンクされています。 [**Logs**] (ログ) のリンク先は Amazon CloudWatch Logs です。このリンク先では、AWS Glue Data Catalog で作成されたテーブルと、発生したエラーに関する詳細を確認できます。ログの保持期間は、CloudWatch コンソールで管理できます。デフォルトのログ保持期間は `Never Expire` です。保持期間を変更する方法の詳細については、*Amazon CloudWatch Logs ユーザーガイド*の「[CloudWatch Logs でログデータ保管期間を変更する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)」を参照してください。 + **[ラベルファイル]** には、生成されたラベリングファイル用の Amazon S3 へのリンクが示されます。 #### 品質の推定 [**Estimate Quality (品質の推定)**] タブは、変換の品質を測定するために使用するメトリクスを示します。推定値は、ラベル付きデータのサブセットを使用して、指定したラベルに変換一致予測を比較することによって計算されます。これらの推定値はおおよその値です。このタブから [**Estimate quality (品質の推定)**] タスク実行を呼び出すことができます。 **Estimate quality** タブには、次のプロパティを含む最後の **Estimate quality** の実行のメトリクスが表示されます。 + **Precision-Recall 曲線の下にある領域**は、変換の全体的な品質の上限を推定する単一の数値です。これは適合率-再現率パラメータ用に行った選択とは関係ありません。値が高いほど、適合率と再現率のトレードオフが適切であることを示します。 + **適合率**は、変換が一致を推定して、その推定が正確である度合いを見積もります。 + **再現率の上限**は、実際の一致件数に対して、変換が推定した一致件数の割合の見積もりです。 + **[F1]** は、変換の正確性 (1～0) を示します。1 は正確性が最適であることを表します。詳細については、Wikipedia の「[F1 スコア](https://en.wikipedia.org/wiki/F1_score)」を参照してください。 + [**Column importance**] (列の重要度) テーブルには、各列の列名と重要度スコアが表示されます。列の重要度は、レコード内のどの列がマッチングを行うために最も使用されているかを識別することで、列がモデルにどの程度寄与しているかを理解するのに役立ちます。列の重要度を上げたり下げたりするために、このデータをラベルセットに追加したりラベルセットを変更したりするように促されることがあります。 [Importance] (重要度) 列には、各列の数値スコアが 1.0 以下の 10 進数で示されます。 品質の推定と真の品質の比較については、「 [品質の推定とエンドツーエンド (真の) 品質の比較](#console-machine-learning-quality-estimates-true-quality)」を参照してください。 変換の調整の詳細については、「[AWS Glue での機械学変換の調整](add-job-machine-learning-transform-tuning.md)」を参照してください。 #### 品質の推定とエンドツーエンド (真の) 品質の比較 AWS Glue は、変換の品質を推定するために、内部の機械学習モデルに対してレコードのペアをいくつか提示します。これらのレコードのペアは、一致のラベルを指定したレコードですが、モデルは初見のものです。これらの品質の推定は、機械学習モデルの品質の関数です (モデルは、ユーザーが変換を「トレーニング」するためにラベル付けするレコードの数から影響を受けます)。エンドツーエンド、または真の再現率 (`ML transform` 変換によって自動的に計算されません) は、機械学習モデルに対してさまざまな一致を提案する `ML transform` フィルタリングメカニズムの影響を受けます。 このフィルタリング方法を調整するには、主に **[低コスト - 正確性]** の調整値を指定します。**[正確性]** を優先するようにこの調整値を近づけるほど、システムは一致する可能性のあるレコードのペアをより深く、広く検索します。機械学習モデルに取り込まれるレコードのペアが増えると、`ML transform` のエンドツーエンド、または真の再現率がより推定の再現率メトリクスに近づきます。その結果、マッチングのコスト/精度のトレードオフの変更によるマッチングのエンドツーエンドの品質の変更は、通常、品質の見積りには反映されません。 #### タグ タグとは、AWS リソースに割り当てることができるラベルです。各タグは、キーおよび値 (オプション) で構成されます。タグを使用して、リソースを検索およびフィルタリングしたり、AWS のコストを追跡できます。 ## ラベルを使って変換を教える ML 変換の詳細ページから **[変換を教える]** を選択すると、ラベル (例) を使用して ML 変換を教えることができます。例 (ラベルと呼ばれます) を提供して機械学習のアルゴリズムを教える場合、使用する既存のラベルを選択したり、ラベリングファイルを作成できます。 ![\[このスクリーンショットは、[ラベルを使って変換を教える] のウィザードの画面を示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/machine-learning-teach-transform.png) + **[ラベリング]** — ラベルがある場合は、**[ラベルがあります]** を選択します。ラベルがない場合でも、ラベリングファイルを生成する次の手順に進むことができます。 + **[ラベリングファイルを生成する]** — AWS Glue により、ソースデータからレコードが抽出され、一致する可能性のあるレコードが提案されます。生成されたラベルファイルを保存する Amazon S3 バケットを選択します。**[ラベルリングファイルを生成する]** を選択してプロセスを開始します。完了したら、**[ラベリングファイルをダウンロードする]** を選択します。ダウンロードしたファイルには、ラベルを入力できるラベル用の列があります。 + **[Amazon S3 からラベルをアップロードする]** — ラベルファイルが保存されている Amazon S3 バケットから、完成したラベリングファイルを選択します。その後、既存のラベルにラベルを追加するか、既存のラベルを上書きするかを選択します。**[Amazon S3 からラベルリングファイルをアップロードする]** を選択します。 # チュートリアル: AWS Glue で機械学習変換を作成する このチュートリアルでは、AWS Glue を使用して機械学習 (ML) 変換を作成および管理するためのアクションについてガイドします。このチュートリアルを使用するには、 AWS Glue コンソールを使用してクローラとジョブを追加し、スクリプトを編集する方法をよく理解している必要があります。Amazon Simple Storage Service (Amazon S3) で、ファイルを検索してダウンロードする方法についてもよく理解している必要があります。 次の例では、一致するレコードを見つけるための `FindMatches` 変換を作成します。また、一致する/一致しないレコードを識別する方法を、この変換にトレーニングして AWS Glue ジョブで使用します。AWS Glue ジョブは、`match_id` という別の列を追加して新しい Amazon S3 ファイルを作成します。 このチュートリアルで使用されているソースデータは、`dblp_acm_records.csv` という名前のファイルです。このファイルは、元の [DBLP ACM データセット](https://doi.org/10.3886/E100843V2)から入手できる学術刊行物 (DBLP および ACM) の修正バージョンです。`dblp_acm_records.csv` ファイルは、BOM (バイトオーダーマーク) なしの UTF-8 形式でエンコードされたカンマ区切り値 (CSV) ファイルです。 2 番目のファイル `dblp_acm_labels.csv` はサンプルのラベリングファイルです。このファイルには、チュートリアルの一環として変換をトレーニングするために使用する、一致する/一致しないレコードの両方が含まれています。 **Topics** + [ステップ 1: ソースデータをクロールする](#ml-transform-tutorial-crawler) + [ステップ 2: 機械学習変換を追加する](#ml-transform-tutorial-create) + [ステップ 3: 機械学習変換をトレーニングする](#ml-transform-tutorial-teach) + [ステップ 4: 機械学習変換の品質を推定する](#ml-transform-tutorial-estimate-quality) + [ステップ 5: 機械学習変換でジョブを追加して実行する](#ml-transform-tutorial-add-job) + [ステップ 6: Amazon S3 の出力データを確認する](#ml-transform-tutorial-data-output) ## ステップ 1: ソースデータをクロールする まず、ソースである Amazon S3 CSV ファイルをクロールして、対応するメタデータテーブルを Data Catalog に作成します。 **重要** CSV ファイルのみのテーブルを作成するようクローラに指示するために、CSV ソースデータを他のファイルとは異なる Amazon S3 フォルダに保存します。 1. AWS マネジメントコンソール にサインインし、AWS Glue コンソール ([https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)) を開きます。 1. ナビゲーションペインで、[**クローラ**]、[**クローラの追加**] の順に選択します。 1. ウィザードに従って `demo-crawl-dblp-acm` というクローラを作成して実行し、出力をデータベース `demo-db-dblp-acm` に保存します。ウィザードの実行時に、データベース`demo-db-dblp-acm` がまだ存在していない場合は、これを作成します。現在の AWS リージョンでのサンプルデータへの Amazon S3 インクルードパスを選択します。例えば、`us-east-1` の場合、ソースファイルへの Amazon S3 インクルードパスは `s3://ml-transforms-public-datasets-us-east-1/dblp-acm/records/dblp_acm_records.csv` です。 完了すると、クローラによってテーブル `dblp_acm_records_csv` が作成され、テーブルの列として、ID、タイトル、作成者、場所、年、およびソースが設定されます。 ## ステップ 2: 機械学習変換を追加する 次に、`demo-crawl-dblp-acm` というクローラで作成されたデータソーステーブルのスキーマに基づく機械学習変換を追加します。 1. AWS Glue コンソールにある **[データ統合と ETL]** のナビゲーションペインで、**[データ分類ツール] > [レコードのマッチング]** の順に選択し、**[変換の追加]** を選択します。ウィザードに従って、以下のプロパティを持つ `Find matches` 変換を作成します。 1. [**変換の名前**] に、「**demo-xform-dblp-acm**」と入力します。これは、ソースデータの一致を見つけるために使用する変換の名前です。 1. [**IAM role**] (IAM ロール) で、Amazon S3 ソースデータ、ラベリングファイル、および AWS Glue API オペレーションへのアクセス許可を持つ IAM ロールを選択します。詳細については、「*AWS Glue デベロッパーガイド*」の「[Create an IAM Role for AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/create-an-iam-role.html)」を参照してください。 1. [**Data source**] (データソース) に、**demo-db-dblp-acm** というデータベースの **dblp\$1acm\$1records\$1csv** という名前のテーブルを選択します。 1. [**Primary key (プライマリキー)**] で、テーブルのプライマリキー列である [**ID**] を選択します。 1. ウィザードで、[**完了**] を選択し、[**ML 変換**] リストに戻ります。 ## ステップ 3: 機械学習変換をトレーニングする 次に、チュートリアルのサンプルのラベリングファイルを使用して、機械学習変換をトレーニングします。 機械学習変換は、そのステータスが [**Ready for use (使用可能)**] になるまで、ETL (抽出、変換、ロード) ジョブで使用できません。変換を使用可能にするには、一致するレコードと一致しないレコードのサンプルを提供し、レコードの一致/不一致を見分ける方法について変換をトレーニングする必要があります。変換をトレーニングするには、**ラベルファイルを生成**して、ラベルを追加し、**ラベルファイルをアップロード**します。このチュートリアルでは、`dblp_acm_labels.csv` というサンプルラベリングファイルを使用できます。ラベリングプロセスの詳細については、「[ラベリング](machine-learning.md#machine-learning-labeling)」を参照してください。 1. AWS Glue コンソールのナビゲーションペインで、**[レコードのマッチング]** を選択します。 1. `demo-xform-dblp-acm` 変換を選択し、次に [**アクション**]、[**Teach (トレーニング)**] の順に選択します。ウィザードに従って、`Find matches` 変換をトレーニングします。 1. 変換のプロパティページで、[**I have labels (ラベルがあります)**] を選択します。現在の AWS リージョンでサンプルラベリングファイルへの Amazon S3 パスを選択します。例えば、`us-east-1` の場合、指定したラベリングファイルを Amazon S3 パス `s3://ml-transforms-public-datasets-us-east-1/dblp-acm/labels/dblp_acm_labels.csv` からアップロードします。この際に、既存のラベルを**上書き**するオプションを使用します。ラベリングファイルは、AWS Glue コンソールと同じリージョンの Amazon S3 に配置する必要があります。 ラベリングファイルをアップロードすると、データソースの処理方法について変換をトレーニングするために使用するラベルを追加または上書きするためのタスクが AWS Glue で開始されます。 1. ウィザードの最後のページで、[**完了**] を選択し、[**ML 変換**] リストに戻ります。 ## ステップ 4: 機械学習変換の品質を推定する 次に、機械学習変換の品質を推定できます。品質は、どれだけのラベル付けを実施したかに応じて異なります。品質の推定の詳細については、「[品質の推定](console-machine-learning-transforms.md#console-machine-learning-transforms-metrics)」を参照してください。 1. AWS Glue コンソールにある **[データ統合と ETL]** のナビゲーションペインで、**[データ分類ツール] > [レコードのマッチング]** の順に選択します。 1. `demo-xform-dblp-acm` 変換を選択し、[**Estimate quality (品質の推定)**] タブをクリックします。このタブには、変換の現在の品質の推定 (使用可能な場合) が表示されます。 1. [**Estimate quality (品質の推定)**] を選択して、変換の品質を推定するためのタスクを開始します。品質の推定の精度はソースデータのラベル付けに基づきます。 1. [**履歴**] タブに移動します。このペインには、変換のタスク実行が一覧表示されます。これには、**品質の推定**タスクも含まれます。実行の詳細を参照するには、[**ログ**] を選択します。実行が完了したときの実行ステータスが [**成功**] になっていることを確認します。 ## ステップ 5: 機械学習変換でジョブを追加して実行する このステップでは、機械学習変換を使用して AWS Glue にジョブを追加して実行します。変換 `demo-xform-dblp-acm` は、[**Ready for use (使用可能)**] である場合に、ETL ジョブで使用できます。 1. AWS Glue コンソールのナビゲーションペインで、[**ジョブ**] を選択します。 1. [**Add job (ジョブの追加)**] を選択し、ウィザードの手順に従い、生成されたスクリプトを使用して ETL Spark ジョブを作成します。変換のプロパティ値として以下を選択します。 1. [**名前**] で、このチュートリアルのサンプルジョブである **demo-etl-dblp-acm** を選択します。 1. [**IAM role**] (IAM ロール) に、Amazon S3 ソースデータ、ラベリングファイル、および AWS Glue API オペレーションへのアクセス許可を持つ IAM ロールを選択します。詳細については、「*AWS Glue デベロッパーガイド*」の「[Create an IAM Role for AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/create-an-iam-role.html)」を参照してください。 1. [**ETL 言語**] で、[**Scala**] を選択します。これは ETL スクリプトのプログラミング言語です。 1. [**スクリプトファイル名**] で、[**demo-etl-dblp-acm**] を選択します。これは Scala スクリプトのファイル名です (ジョブ名と同じです)。 1. [**データソース**] で、[**dblp\$1acm\$1records\$1csv**] を選択します。選択したデータソースは、機械学習変換のデータソーススキーマと一致する必要があります。 1. [**Transform type (変換タイプ)**] で、[**Find matching records (一致するレコードの検索)**] を選択し、機械学習変換を使用してジョブを作成します。 1. [**Remove duplicate records (重複するレコードの削除)**] をオフにします。重複するレコードを削除しない理由は、書き込まれる出力レコードに別の `match_id` フィールドが追加されるためです。 1. [**変換**] で、ジョブによって使用される機械学習変換である **demo-xform-dblp-acm** を選択します。 1. [**データターゲットでテーブルを作成する**] で、次のプロパティを使用してテーブルを作成することを選択します。 + [**Data store type**] (データストアのタイプ) – **Amazon S3** + [**Format**] (形式) – **CSV** + [**Compression type**] (圧縮タイプ) – **None** + [**Target path**] (ターゲットパス) – ジョブの出力が書き込まれる Amazon S3 パス (現在のコンソールの AWS リージョン) 1. [**ジョブを保存してスクリプトを編集する**] を選択して、スクリプトエディタページを表示します。 1. スクリプトを編集し、**ターゲットパス**へのジョブ出力を単一のパーティションファイルに書き込ませるためのステートメントを追加します。このステートメントは、`FindMatches` 変換を実行するステートメントの直後に追加します。このステートメントは次のようになります。 ``` val single_partition = findmatches1.repartition(1) ``` 出力を`.writeDynamicFrame(single_partion)` として書き込むには、`.writeDynamicFrame(findmatches1)` ステートメントを変更する必要があります。 1. スクリプトを編集したら、[**保存**] を選択します。変更後のスクリプトは次のコードのようになりますが、使用環境向けにカスタマイズされます。 ``` import com.amazonaws.services.glue.GlueContext import com.amazonaws.services.glue.errors.CallSite import com.amazonaws.services.glue.ml.FindMatches import com.amazonaws.services.glue.util.GlueArgParser import com.amazonaws.services.glue.util.Job import com.amazonaws.services.glue.util.JsonOptions import org.apache.spark.SparkContext import scala.collection.JavaConverters._ object GlueApp { def main(sysArgs: Array[String]) { val spark: SparkContext = new SparkContext() val glueContext: GlueContext = new GlueContext(spark) // @params: [JOB_NAME] val args = GlueArgParser.getResolvedOptions(sysArgs, Seq("JOB_NAME").toArray) Job.init(args("JOB_NAME"), glueContext, args.asJava) // @type: DataSource // @args: [database = "demo-db-dblp-acm", table_name = "dblp_acm_records_csv", transformation_ctx = "datasource0"] // @return: datasource0 // @inputs: [] val datasource0 = glueContext.getCatalogSource(database = "demo-db-dblp-acm", tableName = "dblp_acm_records_csv", redshiftTmpDir = "", transformationContext = "datasource0").getDynamicFrame() // @type: FindMatches // @args: [transformId = "tfm-123456789012", emitFusion = false, survivorComparisonField = "", transformation_ctx = "findmatches1"] // @return: findmatches1 // @inputs: [frame = datasource0] val findmatches1 = FindMatches.apply(frame = datasource0, transformId = "tfm-123456789012", transformationContext = "findmatches1", computeMatchConfidenceScores = true) // Repartition the previous DynamicFrame into a single partition. val single_partition = findmatches1.repartition(1) // @type: DataSink // @args: [connection_type = "s3", connection_options = {"path": "s3://aws-glue-ml-transforms-data/sal"}, format = "csv", transformation_ctx = "datasink2"] // @return: datasink2 // @inputs: [frame = findmatches1] val datasink2 = glueContext.getSinkWithFormat(connectionType = "s3", options = JsonOptions("""{"path": "s3://aws-glue-ml-transforms-data/sal"}"""), transformationContext = "datasink2", format = "csv").writeDynamicFrame(single_partition) Job.commit() } } ``` 1. [**ジョブの実行**] を選択してジョブの実行を開始します。ジョブリストでジョブのステータスを確認します。ジョブが完了すると、[**ML 変換**] の [**履歴**] タブに、[**ETL ジョブ**] タイプの新しい [**実行 ID**] 行が追加されます。 1. [**ジョブ**]、[**履歴**] タブの順に移動します。このペインには、ジョブの実行が一覧表示されます。実行の詳細を参照するには、[**ログ**] を選択します。実行が完了したときの実行ステータスが [**成功**] になっていることを確認します。 ## ステップ 6: Amazon S3 の出力データを確認する このステップでは、ジョブの追加時に選択した Amazon S3 バケットのジョブ実行の出力を確認します。出力ファイルをローカルマシンにダウンロードして、一致するレコードが識別されていることを確認します。 1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。 1. ジョブ `demo-etl-dblp-acm` のターゲット出力ファイルをダウンロードします。このファイルをスプレッドシートアプリケーションで開きます (ファイルを正常に開くには、必要に応じてファイル拡張子 `.csv` を追加します)。 次の図は、Microsoft Excel で開いた出力の抜粋を示しています。 ![\[変換の出力を示す Excel スプレッドシート。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/demo_output_dblp_acm.png) データソースおよびターゲットファイルの両方に 4,911 個のレコードがあります。ただし、`Find matches` 変換には、出力内の一致するレコードを識別するために `match_id` という別の列が追加されています。同じ `match_id` の行は、一致するレコードと見なされます。`match_confidence_score` は 0～1 の間の数値で、`Find matches` によって検出された次の値で一致の品質を推定します。 1. 出力ファイルを `match_id` で並べ替えると、どのレコードが一致しているか簡単にわかります。他の列の値と比較して、`Find matches` 変換の結果が適切であるかどうかを判断します。適切でない場合は、さらにラベルを追加することで、引き続き変換をトレーニングします。 ファイルをソートするために別のフィールド (`title` など) を使用して、同じようなタイトルのレコードが同じ `match_id` を持っているかどうかを確認することもできます。 # インクリメンタルマッチを検索する。 FindMatches 変換を使用すると、レコードに共通の一意の識別子がなく、正確に一致するフィールドがない場合でも、データセット内の重複レコードまたは一致するレコードを識別できます。検索マッチ変換の最初のリリースでは、単一のデータセット内で一致するレコードが識別されました。データセットに新しいデータを追加する場合、既存のクリーンなデータセットとマージし、マージされた完全なデータセットに対してマッチングを再実行する必要があります。 インクリメンタルマッチング機能を使用すると、既存の一致したデータセットに対するインクリメンタルレコードとの照合が簡単になります。既存の顧客データセットと見込み客のデータを照合するとします。差分一致機能を使用すると、結果を単一のデータベースまたはテーブルにマージすることで、数十万の新規プロスペクトを既存のプロスペクトと顧客の既存のデータベースと照合できる柔軟性が得られます。新規データセットと既存のデータセット間のみ照合を行うことで、差分一致の検索最適化によって計算時間が短縮され、コストも削減されます。 インクリメンタルマッチングの使用法は、[チュートリアル: AWS Glue で機械学習変換を作成する](machine-learning-transform-tutorial.md) で説明されているように、「一致を検索」と似ています。このトピックでは、インクリメンタルマッチングの相違点のみについて説明します。 詳細については、[インクリメンタルデータマッチング](https://aws.amazon.com/blogs/big-data/incremental-data-matching-using-aws-lake-formation/)のブログ記事を参照してください。 ## インクリメンタルマッチングジョブの実行 次の手順では、次の様に仮定します。 + 既存のデータセット内をクロールして first\$1records テーブルに到達しました。first\$1records データセットは、一致したデータセット、または一致したジョブの出力であるはずです。 + AWS Glue バージョン 2.0 を使用して、一致検索変換の作成とトレーニングが完了しました。このバージョンが唯一インクリメンタルマッチを AWS Glue サポートしています。 + ETL 言語は Scala です。Python もサポートされていることに注意してください。 + 既に生成されたモデルは `demo-xform` と呼ばれます。 1. インクリメンタルデータセットを、テーブル *second records* にクロールする。 1. AWS Glue コンソールのナビゲーションペインで、[**ジョブ**] を選択します。 1. [**Add job (ジョブの追加)**] を選択し、ウィザードの手順に従い、生成されたスクリプトを使用して ETL Spark ジョブを作成します。変換のプロパティ値として以下を選択します。 1. **名前**で、**デモetl**を使用する場合。 1. **IAM ロール** に、Amazon S3 ソースデータ、ラベリングファイル、および [AWS GlueAPI オペレーション](https://docs.aws.amazon.com/glue/latest/dg/create-an-iam-role.html)へのアクセス許可を持つ IAM ロールを選択します。 1. [**ETL 言語**] で、[**Scala**] を選択します。 1. [**スクリプトファイル名**] で、[**demo-etl**] を選択します。これは Scala スクリプトのファイル名です。 1. **データソース**は**first records**を選択します。選択したデータソースは、機械学習変換のデータソーススキーマと一致する必要があります。 1. [**Transform type (変換タイプ)**] で、[**Find matching records (一致するレコードの検索)**] を選択し、機械学習変換を使用してジョブを作成します。 1. インクリメンタルマッチングのオプションを選択し、**データ・ソース**に**second\$1records**という名前のテーブルを選択します。 1. [**トランスフォーム**] で、ジョブによって使用される機械学習変換である **demo-xform-dblp-acm** を選択します。 1. **データターゲットにテーブルを作成する**か、**データカタログのテーブルを使用してデータターゲットを更新する**を選択します。 1. [**ジョブを保存してスクリプトを編集する**] を選択して、スクリプトエディタページを表示します。 1. [**ジョブの実行**] を選択してジョブの実行を開始します。 # ビジュアルジョブでの FindMatches の使用 AWS Glue Studio で **FindMatches** 変換を使用するには、FindMatches API を呼び出す **カスタム変換** ノードを使用します。カスタム変換の使用に関する詳細については、「[カスタム変換を作成する](https://docs.aws.amazon.com/glue/latest/ug/transforms-custom.html)」を参照してください。 **注記** 現在、FindMatches API は、`Glue 2.0` でのみ動作します。FindMatches API を呼び出すカスタム変換を使用してジョブを実行するには、AWS Glue のバージョンが **[ジョブの詳細]** タブの `Glue 2.0` に表示されていることを確認してください。AWS Glue のバージョンが `Glue 2.0` でない場合、ジョブは実行時に失敗し、「'awsglueml.transforms' から 'FindMatches' という名前の変換をインポートできません」というエラーメッセージが表示されます。 ## 前提条件 + **一致の検索** 変換を使用するには、AWS Glue Studio で [[https://console.aws.amazon.com/gluestudio/](https://console.aws.amazon.com/gluestudio/)] コンソールを開きます。 + 機械学習変換を作成します。作成すると、transformId が生成されます。この ID は以下の手順で必要になります。機械学習変換の作成方法の詳細については、「[機械学習変換の追加と編集](https://docs.aws.amazon.com/glue/latest/dg/console-machine-learning-transforms.html#console-machine-learning-transforms-actions)」を参照してください。 ## FindMatches 変換の追加 **FindMatches 変換を追加するには** 1. AWS Glue Studio ジョブエディターで、ビジュアルジョブグラフの左上隅にある十字記号をクリックして [リソース] パネルを開き、**[データ]** タブを選択してデータソースを選択します。これは、一致を確認するデータ ソースです。 ![\[スクリーンショットには、円の中に十字のシンボルが表示されています。ビジュアルジョブエディタでこれをクリックすると、[リソース] パネルが開きます。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/resource-panel-blank-canvas.png) 1. データソースノードを選択し、ビジュアルジョブグラフの左上隅にある十字記号をクリックして [リソース] パネルを開き、「custom transform」を検索します。**カスタム変換**ノードを選択してグラフに追加します。**カスタム変換**はデータソースノードにリンクされています。リンクされていない場合は、**カスタム変換**ノードをクリックして**[ノードプロパティ]** タブを選択し、**[ノードの親]** でデータソースを選択します。 1. ビジュアルグラフの**[カスタム変換]**ノードをクリックし、**[ノードプロパティ]**タブを選択し、カスタム変換に名前を付けます。ビジュアルグラフに表示される変換名は、わかりやすい名前に変更することをお勧めします。 1. コードブロックを編集するには、**[変換]** タブを選択します。ここで、FindMatches API を呼び出すコードを追加できます。 ![\[このスクリーンショットは、[カスタム変換] ノードを選択したときの [Transform] タブのコードブロックを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/custom-transform-code-block.png) コードブロックには、すぐに始めることができるようにコードが予め入力されています。予め入力されているコードを下記のテンプレートで上書きします。テンプレートには、入力できる **transformId** のプレースホルダーが表示されています。 ``` def MyTransform (glueContext, dfc) -> DynamicFrameCollection: dynf = dfc.select(list(dfc.keys())[0]) from awsglueml.transforms import FindMatches findmatches = FindMatches.apply(frame = dynf, transformId = "") return(DynamicFrameCollection({"FindMatches": findmatches}, glueContext)) ``` 1. ビジュアルグラフの**[カスタム変換]**ノードをクリックし、ビジュアルジョブグラフの左上隅にある十字記号をクリックして[リソース] パネルを開き、「Select From Collection」を検索します。コレクションには DynamicFrame が 1 つしかないため、デフォルトの選択を変更する必要はありません。 1. 続けて変換を追加したり、結果を保存したりすることができます。結果には、[一致の検索] 列が追加されました。これらの新しい列を下流の変換で参照する場合は、それらを変換出力スキーマに追加する必要があります。それを行う最も簡単な方法は、**[データプレビュー]** タブを選択し、[スキーマ] タブで [データプレビュースキーマの使用] を選択することです。 1. FindMatches をカスタマイズするには、「apply」メソッドに渡すパラメーターを追加できます。[FindMatches クラス](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-pyspark-transforms-findmatches.html)を参照してください。 ## 「FindMatches」段階的な変換の追加 インクリメンタルマッチングの場合、プロセスは **FindMatches 変換の追加**と同じですが、次の点が異なります。 + カスタム変換の親ノードの代わりに、2 つの親ノードが必要です。 + 最初の親ノードはデータセットでなければなりません。 + 2 番目の親ノードはインクリメンタルデータセットでなければなりません。 テンプレートコードブロックで `transformId` を`transformId` に置き換えてください。 ``` def MyTransform (glueContext, dfc) -> DynamicFrameCollection: dfs = list(dfc.values()) dynf = dfs[0] inc_dynf = dfs[1] from awsglueml.transforms import FindIncrementalMatches findmatches = FindIncrementalMatches.apply(existingFrame = dynf, incrementalFrame = inc_dynf, transformId = "") return(DynamicFrameCollection({"FindMatches": findmatches}, glueContext)) ``` + オプションのパラメータについては、「[FindIncrementalMatches クラス](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-crawler-pyspark-transforms-findincrementalmatches.html)」を参照してください。 # Apache Spark プログラムを AWS Glue に移行する Apache Spark は、大規模なデータセットで実行される分散コンピューティングワークロード向けのオープンソースプラットフォームです。AWS Glue は、Spark の機能を活用して ETL に最適化されたエクスペリエンスを提供します。Spark プログラムは、AWS Glue に移行することで機能を最大限に活用できます。AWS Glue は、Amazon EMR の Apache Spark と同等のパフォーマンス向上を実現します。 ## Spark コードを実行する ネイティブ Spark コードは、AWS Glue 環境で追加設定なしですぐに使用できます。スクリプトは多くの場合、インタラクティブセッションに適したワークフローであるコードを繰り返し変更することによって開発されます。ただし、既存のコードの方が AWS Glue ジョブでの実行に適しています。これにより、スクリプトを実行するたびにログとメトリクスをスケジュールし、一貫して取得できます。コンソールから既存のスクリプトをアップロードして編集できます。 1. スクリプトのソースを取得します。この例では、Apache Spark リポジトリのサンプルスクリプトを使用します。[バイナライザーの例](https://github.com/apache/spark/blob/master/examples/src/main/python/ml/binarizer_example.py) 1. AWS Glue コンソールで、左側のナビゲーションペインを展開し、[**ETL**] > [**Jobs**] (ジョブ) を選択します。 [**Create job**] (ジョブの作成) パネルで、[**Spark script editor**] (Spark スクリプトエディタ) を選択します。[**Options**] (オプション) セクションが表示されます。[**Options**] (オプション) で [**Upload and edit an existing script]** (既存のスクリプトのアップロードと編集) を選択します。 [**File upload**] (ファイルのアップロード) セクションが表示されます。[**File upload**] (ファイルのアップロード) で [**Choose file**] (ファイルを選択) をクリックします。システムファイル選択ダイアログが表示されます。`binarizer_example.py` を保存した場所に移動してこの場所を選択し、選択を確定します。 [**Create job**] (ジョブの作成) パネルのヘッダーに [**Create**] (作成) ボタンが表示されます。このボタンをクリックします。 ![\[Spark スクリプトエディタが選択されている AWS Glue Studio ジョブページ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/migrate-apache-spark-01-upload-job.png) 1. ブラウザがスクリプトエディタに移動します。ヘッダーで、[**Job details**] (ジョブの詳細) タブをクリックします。**名前**と **IAM ロール**を設定します。AWS Glue IAM ロールに関するガイダンスについては、「[AWS Glue 用の IAM アクセス許可のセットアップ](set-up-iam.md)」を参照してください。 必要に応じて、[**Requested number of workers**] (要求されたワーカー数) を `2` に、[**Number of retries**] (再試行回数) を `1` に設定します。これらのオプションは本番ジョブを実行する場合に役立ちますが、無効にすると、機能をテストする際のエクスペリエンスが合理化されます。 タイトルバーで、[**Save**] (保存) をクリックし、続いて [**Run**] (実行) をクリックします。 ![\[指示どおりにオプションが設定されたジョブの詳細ページ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/migrate-apache-spark-02-job-details.png) 1. [**Runs**] (実行) タブに移動します。ジョブの実行に対応するパネルが表示されます。数分間待機した後、ページが自動的に更新され、[**Run status**] (実行ステータス) の下に[**Succeeded**] (成功) が表示されます。 ![\[ジョブの実行が成功したジョブの実行ページ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/migrate-apache-spark-03-job-runs.png) 1. 出力を調べて、Spark スクリプトが意図したとおりに実行されたことを確認する必要があります。この Apache Spark サンプルスクリプトは、出力ストリームに文字列を書き込む必要があります。これは、実行が成功したジョブのパネル内の [**Cloudwatch Logs**] の下にある [**Output logs**] (出力ログ) に移動して確認できます。ジョブ実行 ID をメモします。これは、`jr_`で始まる [**ID**] ラベルの下に生成されます。 これにより、CloudWatch コンソールが開き、デフォルトの AWS Glue ロググループ`/aws-glue/jobs/output`のコンテンツを視覚化するように設定されます。これで、ジョブ実行 ID のログストリームのコンテンツに絞り込まれます。各ワーカーはログストリームを生成し、[**Log streams**] (ログストリーム) の下の行として表示されます。1 人のワーカーが要求されたコードを実行しているはずです。正しいワーカーを特定するには、すべてのログストリームを開く必要があります。適切なワーカーが見つかると、次の画像に示すように、スクリプトの出力が表示されます。 ![\[Spark プログラムの出力を含む CloudWatch コンソールページ。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/migrate-apache-spark-04-log-output.png) ## Spark プログラムの移行に必要な一般的な手順 ### Spark バージョンサポートの評価 AWS Glue リリースバージョンは、AWS Glue ジョブで使用できる Apache Spark と Python のバージョンを決定します。AWS Glue バージョンとそのサポート対象については、「[AWS Glue バージョン](release-notes.md#release-notes-versions)」をご覧ください。特定の AWS Glue 機能にアクセスするには、Spark プログラムを新しいバージョンの Spark と互換性があるように更新する必要がある場合があります。 ### サードパーティライブラリを含める 既存の Spark プログラムの多くは、プライベートアーティファクトとパブリックアーティファクトの両方に依存しています。AWS Glue は、Scala ジョブの JAR スタイルの依存関係と、Python ジョブのホイールとソース Pure-Python 依存関係をサポートします。 **Python**-Python の依存関係については、「[AWS Glue での Python ライブラリの使用](aws-glue-programming-python-libraries.md)」を参照してください。 一般的な Python の依存関係は、一般的に要求される [Pandas](https://pandas.pydata.org/) ライブラリなどを含めて AWS Glue 環境で提供されています。依存関係は AWS Glue バージョン 2.0 以降に含まれています。提供されるモジュールの詳細については、「[AWS Glue で提供済みの Python モジュール](aws-glue-programming-python-libraries.md#glue-modules-provided)」を参照してください。デフォルトで含まれている依存関係の別のバージョンをジョブに提供する必要がある場合は、`--additional-python-modules` を使用します。ジョブ引数の詳細については、「[AWS Glue ジョブでジョブパラメータを使用する](aws-glue-programming-etl-glue-arguments.md)」を参照してください。 追加の Python 依存関係は、`--extra-py-files` ジョブ引数で指定できます。Spark プログラムからジョブを移行する場合、このパラメータは良いオプションです。PySpark の `--py-files` フラグと機能的に同等で、同じ制限が適用されるからです。`--extra-py-files` パラメータの詳細については、「[PySpark のネイティブ機能を使用して Python ファイルを含める](aws-glue-programming-python-libraries.md#extra-py-files-support)」を参照してください。 新しいジョブについては、`--additional-python-modules` 引数を使用してPython の依存関係を管理できます。この引数を使用すると、より徹底した依存関係管理が可能になります。このパラメータは、Amazon Linux 2 と互換性のあるネイティブコードバインディングを含むホイールスタイルの依存関係をサポートします。 **Scala** 追加の Scala 依存関係は、`--extra-jars` ジョブ引数で指定できます。依存関係は Amazon S3 でホストされている必要があり、引数の値は、スペースを含まない Amazon S3 パスのカンマ区切りリストである必要があります。依存関係をホストして設定する前に再バンドルすると、設定を管理しやすくなる場合があります。AWS GlueJAR 依存関係には Java バイトコードが含まれており、任意の JVM 言語から生成できます。Java などの他の JVM 言語を使用して、カスタムの依存関係を記述できます。 ### データソース認証情報の管理 既存の Spark プログラムには、データソースからデータを取得するための複雑な構成またはカスタム構成が付属している場合があります。一般的なデータソース認証フローは、AWS Glue 接続でサポートされます。AWS Glue 接続の詳細については、「[データへの接続](glue-connections.md)」を参照してください。 AWS Glue 接続は、主に次の 2 つの方法 (ライブラリへのメソッド呼び出しと、AWS コンソールで [**Additional network connection**] (追加のネットワーク接続) を設定する) を通じて、ジョブをさまざまなタイプのデータストアに接続しやすくします。また、接続から情報を取得するため、ジョブ内からの AWS SDK を呼び出すこともできます。 **メソッドの呼び出し** – AWS Glue 接続は、AWS Glue データカタログと密接に統合されています。これは、データセットに関する情報と、この情報が反映された AWS Glue 接続の操作に使用できるメソッドの管理に利用できます。JDBC 接続で再利用したい既存の認証設定がある場合は、`GlueContext` の `extract_jdbc_conf` メソッドを介して AWS Glue 接続の設定にアクセスできます。詳細については、「[extract\$1jdbc\$1conf](aws-glue-api-crawler-pyspark-extensions-glue-context.md#aws-glue-api-crawler-pyspark-extensions-glue-context-extract_jdbc_conf)」を参照してください。 **コンソール設定** – AWS Glue ジョブは、関連する AWS Glue 接続を使用して Amazon VPC サブネットへの接続を設定します。セキュリティ資料を直接管理している場合は、AWSコンソールで、`NETWORK` タイプ [**Additional network connection**] (追加のネットワーク接続) を指定してルーティングを設定します。AWS Glue 接続 API の詳細については、「[接続 API](aws-glue-api-catalog-connections.md)」を参照してください Spark プログラムにカスタム認証フローまたは一般的でない認証フローがある場合、セキュリティ資料をハンズオンで管理する必要があるかもしれません。AWS Glue 接続が適切でない場合、セキュリティ資料をシークレットマネージャーで安全にホストし、ジョブで提供される boto3 または AWS SDK を介してアクセスします。 ### Apache Spark の設定 複雑な移行では、ワークロードに対応するために Spark 設定が変更されることがよくあります。Apache Spark の最新バージョンでは、ランタイム設定を `SparkSession` で設定できます。AWS Glue3.0 以降のジョブでは `SparkSession` が提供され、ランタイム設定の変更ができます。[Apache Spark 設定](https://spark.apache.org/docs/latest/configuration.html)。Spark のチューニングは複雑で、AWS Glue は、すべての Spark 設定に対するサポートを保証するものではありません。移行に相当する Spark レベルの設定が必要な場合は、サポートにお問い合わせください。 ### カスタム設定のセット 移行された Spark プログラムは、カスタム設定を選択するように設計されている場合があります。AWS Glue はジョブ引数を使用して、ジョブとジョブの実行レベルで構成を設定できます。ジョブ引数の詳細については、「[AWS Glue ジョブでジョブパラメータを使用する](aws-glue-programming-etl-glue-arguments.md)」を参照してください。ライブラリを通じて、ジョブのコンテキスト内でジョブの引数にアクセスできます。AWS Glue は、ジョブに設定された引数とジョブ実行時に設定された引数の間で一貫したビューを提供するユーティリティ関数を提供します。Python の「[`getResolvedOptions` を使用して、パラメータにアクセスする](aws-glue-api-crawler-pyspark-extensions-get-resolved-options.md)」、Scala の「[AWS Glue Scala GlueArgParser API](glue-etl-scala-apis-glue-util-glueargparser.md)」を参照してください。 ### Java コードの移行 「[サードパーティライブラリを含める](#glue-author-migrate-apache-spark-third-party-libraries)」で説明されているように、Java や Scala などの JVM 言語で生成されたクラスを依存関係に含めることができます。依存関係には `main` メソッドが含まれます。AWS Glue Scala ジョブのエントリポイントとして、依存関係内に `main` メソッドを使用できます。これにより、Java に `main` メソッドを記述するか、独自のライブラリ標準にパッケージ化された `main` メソッドを再使用できます。 依存関係から `main` メソッドを使用するには、次のいずれかの方法を実行します: デフォルトの `GlueApp` オブジェクトを提供する編集ペインの内容をクリアします。依存関係内のクラスの完全修飾名を、キー `--class` を使用したジョブ引数として指定します。これで、ジョブ実行をトリガーできるようになります。 AWS Glue が `main` メソッドに引き渡す引数の順序や構造は設定できません。既存のコードで、AWS Glue の設定を読み取る必要がある場合、以前のコードとの非互換性を引き起こす可能性があります。`getResolvedOptions` を使用していると、このメソッドを呼び出すのに適した条件もありません。AWS Glue で生成されたメインメソッドから依存関係を直接呼び出すことをおすすめします。この例については、以下の AWS Glue ETL スクリプトをご覧ください。 ``` import com.amazonaws.services.glue.util.GlueArgParser object GlueApp { def main(sysArgs: Array[String]) { val args = GlueArgParser.getResolvedOptions(sysArgs, Seq("JOB_NAME").toArray) // Invoke static method from JAR. Pass some sample arguments as a String[], one defined inline and one taken from the job arguments, using getResolvedOptions com.mycompany.myproject.MyClass.myStaticPublicMethod(Array("string parameter1", args("JOB_NAME"))) // Alternatively, invoke a non-static public method. (new com.mycompany.myproject.MyClass).someMethod() } } ```