AWS Glue での Python ライブラリの使用

AWS Glue ETL で使用する追加の Python モジュールとライブラリをインストールできます。AWS Glue 2.0 以上の場合、AWS Glue は Python パッケージインストーラ (pip3) を使用して、AWS Glue ETL で使用する追加モジュールをインストールします。AWSGlue には、追加の Python モジュールを AWS Glue ジョブ環境に持ち込むための複数のオプションが用意されています。Python wheel ファイル、Requirements ファイル (requirement.txt、AWS Glue 5.0 以降)、またはカンマ区切りの Python モジュールのリストを使用してモジュールを取り込むため、「—additional-python-modules」パラメータを使用できます。

pip を使用して追加の Python モジュールを AWS Glue 2.0 以降にインストールする

AWS Glue は Python パッケージインストーラー (pip3) を使用して、AWS Glue ETL で使用する追加モジュールをインストールします。--additional-python-modules パラメータでコンマ区切りの Python モジュールのリストを指定することで、新しいモジュールを追加したり、既存のモジュールのバージョンを変更したりできます。Amazon S3 にディストリビューションをアップロードすることでライブラリのカスタムディストリビューションをインストールできます。その後で、モジュールのリストに Amazon S3 オブジェクトへのパスを含めます。

--python-modules-installer-option パラメータを使用すると、pip3 に追加オプションを渡すことができます。例えば "--upgrade" を渡すことで、"--additional-python-modules" で指定されたパッケージをアップグレードできます。その他の例については、AWS Glue 2.0 を使用して Spark ETL ワークロード用のホイールから Python モジュールを構築する を参照してください。

--additional-python-modules s3://amzn-s3-demo-bucket/path/to/package-1.0.0-py3-none-any.whl,s3://your-bucket/path/to/another-package-2.1.0-cp311-cp311-linux_x86_64.whl

awswrangler==3.9.1
elasticsearch==8.15.1
PyAthena==3.9.0
PyMySQL==1.1.1
PyYAML==6.0.2
pyodbc==5.2.0
pyorc==0.9.0
redshift-connector==2.1.3
scipy==1.14.1
scikit-learn==1.5.2
SQLAlchemy==2.0.36

PySpark のネイティブ機能を使用して Python ファイルを含める

AWS Glue では、PySpark を使用して、AWS Glue ETL ジョブに Python ファイルを含めます。可能な場合には、依存関係を管理するために、--additional-python-modules を使用することが必要になります。Python ファイルをインクルードするには、--extra-py-files ジョブパラメータを使用します。依存関係は Amazon S3 でホストされている必要があり、引数の値は、スペースを含まない Amazon S3 パスのカンマ区切りリストである必要があります。この機能は、Spark で使用する Python の依存関係管理のように動作します。Spark での Python の依存関係管理の詳細については、Apache Spark ドキュメントの「Using PySpark Native Features」(PySpark のネイティブ機能を使う) ページを参照してください。追加のコードがパッケージ化されていない場合や、依存関係を管理するために既存のツールチェーンを使用して Spark プログラムを移行する場合には、--extra-py-files が便利です。依存関係ツールをメンテナンス可能にするには、送信する前に依存関係をバンドルする必要があります。

ビジュアル変換を使用するプログラミングスクリプト

AWS Glue Studio のビジュアルインターフェイスを使用して AWS Glue ジョブを作成するとき、マネージドデータトランスフォームノードおよびカスタムビジュアル変換を使用してデータを変換できます。マネージドデータ変換ノードの詳細については、AWS Glue マネージド変換によるデータの変換 を参照してください。カスタムビジュアル変換の詳細については、 カスタムビジュアル変換によるデータの変換 を参照してください。ビジュアル変換を使用するスクリプトは、ジョブの [言語] が Python を使用するように設定されている場合にのみ生成できます。

ビジュアル変換を使用して AWS Glue ジョブを生成する場合、AWS Glue Studio はジョブ設定の --extra-py-files パラメータを使用し、これらの変換をランタイム環境に組み込みます。ジョブパラメータについては、AWS Glue ジョブでジョブパラメータを使用する を参照してください。生成されたスクリプトまたはランタイム環境を変更するとき、スクリプトを正常に実行するためにこのジョブ設定を保存する必要があります。

取り込みのためのライブラリの圧縮

ライブラリは、単一の .py ファイルに含まれていない限り、.zip アーカイブにパッケージ化される必要があります。パッケージディレクトリは、アーカイブのルートにあって、パッケージの __init__.py ファイルを含んでいる必要があります。そうすると、Python は通常の方法でパッケージをインポートできるようになります。

ライブラリが 1 つの .py ファイルにある単一の Python モジュールでのみ構成されている場合、.zip ファイルに入れる必要はありません。

Glue Studio ノートブックでの Python AWS ライブラリのロード

Glue Studio ノートブックで Python AWS ライブラリを指定するには、追加 Python モジュールのインストール を参照してください。

AWS Glue 0.9/1.0 の開発エンドポイントへの Python ライブラリのロード

異なる ETL スクリプトに異なるライブラリセットを使用している場合、各セットに別々の開発エンドポイントをセットアップするか、スクリプトを切り替えるたびに開発エンドポイントがロードするライブラリ .zip ファイルを上書きすることができます。

コンソールを使用して、作成時に開発エンドポイントに 1 つまたは複数のライブラリ .zip ファイルを指定できます。名前と IAM ロールを割り当てた後、[Script Libraries and job parameters (optional)] (スクリプトライブラリおよびジョブパラメータ (任意)) をクリックし、[Python library path] (Python ライブラリパス) ボックスに、ライブラリ .zip ファイルへの完全な Amazon S3 パスを入力します。例:

s3://bucket/prefix/site-packages.zip

必要に応じてファイルへの複数のフルパスを指定できますが、以下のように、スペースなしでカンマで区切ります。

s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zip

これらの .zip ファイルを後で更新する場合は、コンソールを使用して開発エンドポイントにそのファイルを再インポートできます。該当する開発エンドポイントに移動し、横にあるチェックボックスをオンにして、[Action] (アクション) メニューから [Update ETL libraries] (ETL ライブラリの更新) を選択します。

同様の方法で、AWS Glue API を使用してライブラリファイルを指定できます。CreateDevEndpoint アクション (Python: create_dev_endpoint) を呼び出して開発エンドポイントを作成する場合、ExtraPythonLibsS3Path パラメータでライブラリへの 1 つ以上のフルパスを指定できます。以下のような呼び出しになります。

dep = glue.create_dev_endpoint(
             EndpointName="testDevEndpoint",
             RoleArn="arn:aws:iam::123456789012",
             SecurityGroupIds="sg-7f5ad1ff",
             SubnetId="subnet-c12fdba4",
             PublicKey="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtp04H/y...",
             NumberOfNodes=3,
             ExtraPythonLibsS3Path="s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zip")

開発エンドポイントを更新するときに、DevEndpointCustomLibraries オブジェクトを使用し UpdateEtlLibraries の呼び出し時に True パラメータを UpdateDevEndpoint (update_dev_endpoint) に設定して、ロードするライブラリも更新できます。

ジョブまたは JobRun での Python ライブラリの使用

コンソールで新しいジョブを作成する際、[Script Libraries and job parameters (optional)] (スクリプトライブラリおよびジョブパラメータ (任意)) をクリックし、開発エンドポイント作成時と同じ方法で Amazon S3 ライブラリの完全なパスを入力することで、1 つ以上のライブラリ .zip ファイルを指定できます。

s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zip

CreateJob (create_job) を呼び出している場合は、以下のようにデフォルトの --extra-py-files パラメータを使用してデフォルトのライブラリへの 1 つ以上のフルパスを指定できます。

job = glue.create_job(Name='sampleJob',
                      Role='Glue_DefaultRole',
                      Command={'Name': 'glueetl',
                               'ScriptLocation': 's3://my_script_bucket/scripts/my_etl_script.py'},
                      DefaultArguments={'--extra-py-files': 's3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zip'})

その後 JobRun を開始するときに、デフォルトのライブラリ設定を別のもので上書きできます。

runId = glue.start_job_run(JobName='sampleJob',
                           Arguments={'--extra-py-files': 's3://bucket/prefix/lib_B.zip'})

Python の依存関係をプロアクティブに分析する

AWS Glue にデプロイする前に潜在的な依存関係の問題をプロアクティブに特定するには、依存関係分析ツールを使用して、ターゲット AWS Glue 環境に対して Python パッケージを検証できます。

AWS は、AWS Glue 環境専用に設計されたオープンソースの Python 依存関係アナライザーツールを提供します。このツールは AWS Glue サンプルリポジトリで入手でき、デプロイ前にローカルで使用して依存関係を検証できます。

この分析は、一貫した本番稼働用デプロイのためにすべてのライブラリバージョンを固定するという推奨プラクティスを依存関係が確実に遵守するのに役立ちます。詳細については、ツールの README を参照してください。

# Analyze a single Glue job
python glue_dependency_analyzer.py -j my-glue-job

# Analyze multiple jobs with specific AWS configuration
python glue_dependency_analyzer.py -j job1 -j job2 --aws-profile production --aws-region us-west-2

I have an AWS Glue job named <Job-Name> that has failed due to Python module installation conflicts. Please assist in diagnosing and resolving this issue using the following systematic approach. Proceed once sufficient information is available.

Objective: Implement a fix that addresses the root cause module while minimizing disruption to the existing working environment.

Step 1: Root Cause Analysis
• Retrieve the most recent failed job run ID for the specified Glue job
• Extract error logs from CloudWatch Logs using the job run ID as a log stream prefix
• Analyze the logs to identify:
  • The recently added or modified Python module that triggered the dependency conflict
  • The specific dependency chain causing the installation failure
  • Version compatibility conflicts between required and existing modules

Step 2: Baseline Configuration Identification
• Locate the last successful job run ID prior to the dependency failure
• Document the Python module versions that were functioning correctly in that baseline run
• Establish the compatible version constraints for conflicting dependencies

Step 3: Targeted Resolution Implementation
• Apply pinning by updating the job's additional_python_modules parameter
• Pin only the root cause module and its directly conflicting dependencies to compatible versions, and do not remove python modules unless necessary
• Preserve flexibility for non-conflicting modules by avoiding unnecessary version constraints
• Deploy the configuration changes with minimal changes to the existing configuration and execute a validation test run. Do not change the Glue versions.

Implementation Example:
Scenario: Recently added pandas==2.0.0 to additional_python_modules
Error: numpy version conflict (pandas 2.0.0 requires numpy>=1.21, but existing job code requires numpy<1.20)
Resolution: Update additional_python_modules to "pandas==1.5.3,numpy==1.19.5"
Rationale: Use pandas 1.5.3 (compatible with numpy 1.19.5) and pin numpy to last known working version

Expected Outcome: Restore job functionality with minimal configuration changes while maintaining system stability.

AWS Glue で提供済みの Python モジュール

これらの提供済みモジュールのバージョンを変更するには、--additional-python-modules ジョブパラメータにより新しいバージョンを指定します。