Usar bibliotecas Python com o AWS Glue
É possível instalar módulos e bibliotecas Python adicionais para uso com o ETL do AWS Glue. Para o AWS Glue 2.0 ou superior, o AWS Glue usa o Python Package Installer (pip3) para instalar módulos adicionais a serem usados pelo ETL do AWS Glue. AWS O Glue oferece várias opções para levar os módulos adicionais do Python ao seu ambiente de trabalho do AWS Glue. O parâmetro "—additional-python-modules" pode ser utilizado para trazer módulos por meio de arquivos wheel do Python, arquivo de requisitos (requirement.txt, AWS Glue 5.0 e superior) ou uma lista de módulos Python separados por vírgula.
Tópicos
| Versão do Glue | Versão do Python | Imagem base | versão glibc | Métodos de instalação compatíveis |
|---|---|---|---|---|
| 5,0 | 3.11 | Amazon Linux 2023 (AL2023) |
2.34 | |
| 4.0 | 3.10 | Amazon Linux 2 (AL2) |
2.26 |
Práticas recomendadas para instalar bibliotecas Python adicionais no AWS Glue |
| 3.0 | 3.7 | Amazon Linux 2 (AL2) |
2.26 |
Práticas recomendadas para instalar bibliotecas Python adicionais no AWS Glue |
| 2.0 | 3.7 | Amazon Linux AMI (AL1) |
2.17 | Práticas recomendadas para instalar bibliotecas Python adicionais no AWS Glue |
| 1,0 | 3.6 | Amazon Linux AMI (AL1) |
2.17 |
Práticas recomendadas para instalar bibliotecas Python adicionais no AWS Glue |
| 0.9 | 2.7 | Amazon Linux AMI (AL1) |
2.17 | Práticas recomendadas para instalar bibliotecas Python adicionais no AWS Glue |
No modelo de responsabilidade compartilhada da AWS
O AWS Glue não oferece suporte à compilação de código nativo no ambiente de trabalho. No entanto, os trabalhos do AWS Glue são executados em um ambiente Linux gerenciado pela Amazon. Talvez você possa fornecer suas dependências nativas em formato compilado por meio de um arquivo wheel Python. Consulte a tabela acima para obter detalhes sobre a compatibilidade de versões do AWS Glue.
Se suas dependências do Python dependerem provisoriamente de código compilado nativo, você poderá se deparar com a seguinte limitação: o AWS Glue não é compatível com a compilação de código nativo no ambiente de trabalho. No entanto, os trabalhos do AWS Glue são executados em um ambiente Linux gerenciado pela Amazon. Talvez você possa fornecer suas dependências nativas em formato compilado por meio de uma distribuição wheel. Consulte a tabela acima para obter detalhes sobre a compatibilidade de versões do AWS Glue.
Importante
O uso de dependências incompatíveis pode resultar em problemas de tempo de execução, especialmente para bibliotecas com extensões nativas que devem corresponder à arquitetura e às bibliotecas do sistema do ambiente de destino. Cada versão do AWS Glue é executada em uma versão específica do Python com bibliotecas pré-instaladas e configurações do sistema.
Instalar módulos Python adicionais com pip no AWS Glue 2.0 ou posterior
O AWS Glue usa o Python Package Installer (pip3) para instalar módulos adicionais a serem usados pelo ETL do AWS Glue. Você pode usar o parâmetro --additional-python-modules com uma lista de módulos do Python separados por vírgulas para adicionar um novo módulo ou alterar a versão de um módulo existente. Você pode instalar distribuições personalizadas de uma biblioteca carregando a distribuição para o Amazon S3 e incluindo o caminho para o objeto do Amazon S3 na sua lista de módulos.
Você pode transmitir opções adicionais para o pip3 com o parâmetro --python-modules-installer-option. Por exemplo, você pode transmitir "--upgrade" para atualizar os pacotes especificados por "--additional-python-modules". Para obter mais exemplos, consulte Desenvolver módulos do Python de um wheel para workloads de ETL do Spark usando o AWS Glue 2.0
O AWS Glue oferece suporte à instalação de pacotes Python personalizados usando arquivos wheel (.whl) armazenados no Amazon S3. Para incluir arquivos wheel em seus trabalhos do AWS Glue, forneça uma lista separada por vírgula dos arquivos wheel armazenados no S3 para o parâmetro do trabalho do --additional-python-modules. Por exemplo:
--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
Essa abordagem também pode ser aplicada quando você precisa de distribuições personalizadas ou pacotes com dependências nativas pré-compilados para o sistema operacional correto. Para obter mais exemplos, consulte Desenvolver módulos Python de um wheel para workloads de ETL do Spark usando o AWS Glue 2.0
Especifique --additional-python-modules no campo Parâmetros de trabalho do console do AWS Glue ou alterando os argumentos do trabalho no AWS SDK. Para obter mais informações sobre como configurar parâmetros de trabalho, consulte Usar parâmetros de trabalho em trabalhos do AWS Glue.
No AWS Glue 5.0, você pode fornecer o arquivo requirements.txt padrão de fábrica para gerenciar as dependências da biblioteca Python. Para fazer isso, forneça os seguintes dois parâmetros de trabalho:
-
Chave:
--python-modules-installer-optionValor:
-r -
Chave:
--additional-python-modulesValor:
s3://path_to_requirements.txt
Os nós do AWS Glue 5.0 carregam inicialmente as bibliotecas Python especificadas em requirements.txt.
Exemplo de requirements.txt:
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
Importante
Evite versões de biblioteca não fixadas em seu arquivo requirements.txt para garantir que você tenha um ambiente AWS Glue confiável e determinístico para seus trabalhos.
Ao usar o wheel para dependências diretas, existe a possibilidade de você transportar uma versão incompatível das suas dependências transitivas se elas não estiverem fixadas corretamente. Como prática recomendada, todas as versões da biblioteca devem ser fixadas para garantir a consistência em trabalhos do AWS Glue. AWS O Glue recomenda empacotar seu ambiente python em um arquivo de wheel para garantir a consistência e a confiabilidade da sua workload de produção.
Para atualizar ou adicionar um novo módulo do AWS Glue, é possível passar parâmetros --additional-python-modules com uma lista de módulos Python separados por vírgulas como valores. Por exemplo, para atualizar ou adicionar o módulo scikit-learn, use a seguinte chave/valor: "--additional-python-modules",
"scikit-learn==0.21.3". Existem duas opções para configurar diretamente os módulos Python.
-
Módulo Python fixado (recomendado)
"--additional-python-modules", "scikit-learn==0.21.3,ephem==4.1.6" -
Módulo Python não fixado: (não recomendado para workloads de produção)
"--additional-python-modules", "scikit-learn>==0.20.0,ephem>=4.0.0"OU
"--additional-python-modules", "scikit-learn,ephem"
Importante
Quando os módulos Python são configurados diretamente em --additional-python-modules, o AWS Glue recomenda usar versões fixas da biblioteca para garantir a consistência no ambiente de trabalho do AWS Glue. Usar versões de biblioteca não fixadas extrai a versão mais recente dos módulos Python. No entanto, isso pode introduzir alterações significativas ou transportar um módulo Python incompatível e fazer com que um trabalho falhe devido à falha na instalação do Python no ambiente de trabalho do AWS Glue. Recomendamos que os clientes não usem versões de biblioteca não fixadas para workloads de produção. Como prática recomendada do AWS Glue, empacote seu ambiente Python em um arquivo wheel para garantir a consistência e a confiabilidade da sua workload de produção.
Práticas recomendadas para instalar bibliotecas Python adicionais no AWS Glue
(Recomendado) Empacotar o ambiente Python em um único arquivo de wheel
Para um ambiente seguro e consistente, o AWS Glue recomenda criar um snapshot e empacotar seu ambiente Python em um arquivo wheel. A vantagem disso é que seu ambiente Python para módulos Python de referência e suas dependências transitivas serão bloqueados. Isso garante que sua tarefa do AWS Glue não seja afetada quando um repositório upstream, como PyPI ou dependências, introduz atualizações incompatíveis.
Esse arquivo pode então ser usado em sua tarefa do AWS Glue com o sinalizador --additional-python-modules.
Importante
É necessário executar o script a seguir em um ambiente semelhante à versão do AWS Glue que você está executando. Consulte a tabela de detalhes do ambiente do Glue e verifique se você está usando a mesma imagem básica do sistema operacional e versão do Python.
#!/bin/bash set -e REQUIREMENTS_FILE="requirements.txt" FINAL_WHEEL_OUTPUT_DIRECTORY="." PACKAGE_NAME=$(basename "$(pwd)") PACKAGE_VERSION="0.1.0" # Help message show_help() { echo "Usage: $0 [options]" echo "" echo "Options:" echo " -r, --requirements FILE Path to requirements.txt file (default: requirements.txt)" echo " -o, --wheel-output DIR Output directory for final wheel (default: current directory)" echo " -n, --name NAME Package name (default: current directory name)" echo " -v, --version VERSION Package version (default: 0.1.0)" echo " -h, --help Show this help message" echo " -g, --glue-version Glue version (required)" echo "" echo "Example:" echo " $0 -r custom-requirements.txt -o dist -n my_package -v 1.2.3 -g 4.0" } # Parse command line arguments while [[ $# -gt 0 ]]; do key="$1" case $key in -r | --requirements) REQUIREMENTS_FILE="$2" shift 2 ;; -o | --wheel-output) FINAL_WHEEL_OUTPUT_DIRECTORY="$2" shift 2 ;; -n | --name) PACKAGE_NAME="$2" shift 2 ;; -v | --version) PACKAGE_VERSION="$2" shift 2 ;; -g | --glue-version) GLUE_VERSION="$2" shift 2 ;; -h | --help) show_help exit 0 ;; *) echo "Unknown option: $1" show_help exit 1 ;; esac done # If package name has dashes, convert to underscores and notify user. We need to check this since we cant import a package with dashes. if [[ "$PACKAGE_NAME" =~ "-" ]]; then echo "Warning: Package name '$PACKAGE_NAME' contains dashes. Converting to underscores." PACKAGE_NAME=$(echo "$PACKAGE_NAME" | tr '-' '_') fi UBER_WHEEL_NAME="${PACKAGE_NAME}-${PACKAGE_VERSION}-py3-none-any.whl" # Check if glue version is provided if [ -z "$GLUE_VERSION" ]; then echo "Error: Glue version is required." exit 1 fi # Validate version format (basic check) if [[ ! "$PACKAGE_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]] && [[ ! "$PACKAGE_VERSION" =~ ^[0-9]+\.[0-9]+$ ]]; then echo "Warning: Version '$PACKAGE_VERSION' doesn't follow semantic versioning (x.y.z or x.y)" fi # Check if requirements file exists if [ ! -f "$REQUIREMENTS_FILE" ]; then echo "Error: Requirements file '$REQUIREMENTS_FILE' not found." exit 1 fi # Get relevant platform tags/python versions based on glue version if [[ "$GLUE_VERSION" == "5.0" ]]; then PYTHON_VERSION="3.11" GLIBC_VERSION="2.34" elif [[ "$GLUE_VERSION" == "4.0" ]]; then PYTHON_VERSION="3.10" GLIBC_VERSION="2.26" elif [[ "$GLUE_VERSION" == "3.0" ]]; then PYTHON_VERSION="3.7" GLIBC_VERSION="2.26" elif [[ "$GLUE_VERSION" == "2.0" ]]; then PYTHON_VERSION="3.7" GLIBC_VERSION="2.17" elif [[ "$GLUE_VERSION" == "1.0" ]]; then PYTHON_VERSION="3.6" GLIBC_VERSION="2.17" elif [[ "$GLUE_VERSION" == "0.9" ]]; then PYTHON_VERSION="2.7" GLIBC_VERSION="2.17" else echo "Error: Unsupported glue version '$GLUE_VERSION'." exit 1 fi echo "Using Glue version $GLUE_VERSION" echo "Using Glue python version $PYTHON_VERSION" echo "Using Glue glibc version $GLIBC_VERSION" PIP_PLATFORM_FLAG="" is_glibc_compatible() { # assumes glibc version in the form of major.minor (ex: 2.17) # glue glibc must be >= platform glibc local glue_glibc_version="$GLIBC_VERSION" local platform_glibc_version="$1" # 2.27 (platform) can run on 2.27 (glue) if [[ "$platform_glibc_version" == "$glue_glibc_version" ]]; then return 0 fi local glue_glibc_major="${glue_glibc_version%%.*}" local glue_glibc_minor="${glue_glibc_version#*.}" local platform_glibc_major="${platform_glibc_version%%.*}" local platform_glibc_minor="${platform_glibc_version#*.}" # 3.27 (platform) cannot run on 2.27 (glue) if [[ "$platform_glibc_major" -gt "$glue_glibc_major" ]]; then return 1 fi # 2.34 (platform) cannot run on 2.27 (glue) if [[ "$platform_glibc_major" -eq "$glue_glibc_major" ]] && [[ "$platform_glibc_minor" -gt "$glue_glibc_minor" ]]; then return 1 fi # 2.17 (platform) can run on 2.27 (glue) return 0 } PIP_PLATFORM_FLAG="" if is_glibc_compatible "2.17"; then PIP_PLATFORM_FLAG="${PIP_PLATFORM_FLAG} --platform manylinux2014_x86_64" fi if is_glibc_compatible "2.28"; then PIP_PLATFORM_FLAG="${PIP_PLATFORM_FLAG} --platform manylinux_2_28_x86_64" fi if is_glibc_compatible "2.34"; then PIP_PLATFORM_FLAG="${PIP_PLATFORM_FLAG} --platform manylinux_2_34_x86_64" fi if is_glibc_compatible "2.39"; then PIP_PLATFORM_FLAG="${PIP_PLATFORM_FLAG} --platform manylinux_2_39_x86_64" fi echo "Using pip platform flags: $PIP_PLATFORM_FLAG" # Convert to absolute paths REQUIREMENTS_FILE=$(realpath "$REQUIREMENTS_FILE") FINAL_WHEEL_OUTPUT_DIRECTORY=$(realpath "$FINAL_WHEEL_OUTPUT_DIRECTORY") TEMP_WORKING_DIR=$(mktemp -d) VENV_DIR="${TEMP_WORKING_DIR}/.build_venv" WHEEL_OUTPUT_DIRECTORY="${TEMP_WORKING_DIR}/wheelhouse" # Cleanup function cleanup() { echo "Cleaning up temporary files..." rm -rf "$TEMP_WORKING_DIR" } trap cleanup EXIT echo "=========================================" echo "Building wheel for $PACKAGE_NAME with all dependencies from $REQUIREMENTS_FILE" echo "=========================================" # Determine Python executable to use consistently PYTHON_EXEC=$(which python3 2>/dev/null || which python 2>/dev/null) if [ -z "$PYTHON_EXEC" ]; then echo "Error: No Python executable found" exit 1 fi echo "Using Python: $PYTHON_EXEC" echo "" # Install build requirements echo "Step 1/5: Installing build tools..." echo "----------------------------------------" "$PYTHON_EXEC" -m pip install --upgrade pip build wheel setuptools echo "✓ Build tools installed successfully" echo "" # Create a virtual environment for building echo "Step 2/5: Creating build environment..." echo "----------------------------------------" "$PYTHON_EXEC" -m venv "$VENV_DIR" # Check if virtual environment was created successfully if [ ! -f "$VENV_DIR/bin/activate" ]; then echo "Error: Failed to create virtual environment" exit 1 fi source "$VENV_DIR/bin/activate" # Install pip-tools for dependency resolution "$VENV_DIR/bin/pip" install pip-tools echo "✓ Build environment created successfully" echo "" # Compile requirements to get all transitive dependencies GLUE_PIP_ARGS="$PIP_PLATFORM_FLAG --python-version $PYTHON_VERSION --only-binary=:all:" echo "Step 3/5: Resolving all dependencies..." echo "----------------------------------------" if ! "$VENV_DIR/bin/pip-compile" --pip-args "$GLUE_PIP_ARGS" --no-emit-index-url --output-file "$TEMP_WORKING_DIR/.compiled_requirements.txt" "$REQUIREMENTS_FILE"; then echo "Error: Failed to resolve dependencies. Check for conflicts in $REQUIREMENTS_FILE" exit 1 fi echo "✓ Dependencies resolved successfully" echo "" # Download all wheels for dependencies echo "Step 4/5: Downloading all dependency wheels..." echo "----------------------------------------" "$VENV_DIR/bin/pip" download -r "$TEMP_WORKING_DIR/.compiled_requirements.txt" -d "$WHEEL_OUTPUT_DIRECTORY" $GLUE_PIP_ARGS # Check if any wheels were downloaded if [ ! "$(ls -A "$WHEEL_OUTPUT_DIRECTORY")" ]; then echo "Error: No wheels were downloaded. Check your requirements file." exit 1 fi # Count downloaded wheels (using find instead of ls for better handling) WHEEL_COUNT=$(find "$WHEEL_OUTPUT_DIRECTORY" -name "*.whl" -type f | wc -l | tr -d ' ') echo "✓ Downloaded $WHEEL_COUNT dependency wheels successfully" echo "" # Create a single uber wheel with all dependencies echo "Step 5/5: Creating uber wheel with all dependencies included..." echo "----------------------------------------" # Create a temporary directory for the uber wheel UBER_WHEEL_DIR="$TEMP_WORKING_DIR/uber" mkdir -p "$UBER_WHEEL_DIR" # Create the setup.py file with custom install command cat >"$UBER_WHEEL_DIR/setup.py" <<EOF from setuptools import setup, find_packages import setuptools.command.install import os import glob import subprocess import sys setup( name='${PACKAGE_NAME}', version='${PACKAGE_VERSION}', description='Bundle containing dependencies for ${PACKAGE_NAME}', author='Package Builder', author_email='builder@example.com', packages=['${PACKAGE_NAME}'], # Include the package directory to hold wheels include_package_data=True, package_data={ '${PACKAGE_NAME}': ['wheels/*.whl'], # Include wheels in the package directory } ) EOF # Create a MANIFEST.in file to include all wheels cat >"$UBER_WHEEL_DIR/MANIFEST.in" <<EOF recursive-include ${PACKAGE_NAME}/wheels *.whl EOF # Create an __init__.py file that imports all the bundled wheel files (no auto-install logic) mkdir -p "$UBER_WHEEL_DIR/${PACKAGE_NAME}" cat >"$UBER_WHEEL_DIR/${PACKAGE_NAME}/__init__.py" <<EOF """ ${PACKAGE_NAME} - dependencies can be installed at runtime using the $(load_wheels) function """ from pathlib import Path import logging import subprocess import sys __version__ = "${PACKAGE_VERSION}" def load_wheels(log_level=logging.INFO): logger = logging.getLogger(__name__) handler = logging.StreamHandler(sys.stdout) formatter = logging.Formatter("[Glue Python Wheel Installer] %(asctime)s - %(name)s - %(levelname)s - %(message)s") handler.setFormatter(formatter) logger.addHandler(handler) logger.setLevel(log_level) logger.info("Starting wheel installation process") package_dir = Path(__file__).parent.absolute() wheels_dir = package_dir / "wheels" logger.debug(f"Package directory: {package_dir}") logger.debug(f"Looking for wheels in: {wheels_dir}") if not wheels_dir.exists(): logger.error(f"Wheels directory not found: {wheels_dir}") return False wheel_files = list(wheels_dir.glob("*.whl")) if not wheel_files: logger.warning(f"No wheels found in: {wheels_dir}") return False logger.info(f"Found {len(wheel_files)} wheels") wheel_file_paths = [str(wheel_file) for wheel_file in wheel_files] logger.info(f"Installing {wheel_file_paths}...") try: result = subprocess.run( [sys.executable, "-m", "pip", "install", *wheel_file_paths], check=True, capture_output=True, text=True ) logger.info(f"✓ Successfully installed wheel files") logger.debug(f"pip output: {result.stdout}") except subprocess.CalledProcessError as e: error_msg = f"Failed to install wheel files" logger.error(f"✗ {error_msg}: {e}") if e.stderr: logger.error(f"Error details: {e.stderr}") return False logger.info("All wheels installed successfully") return True EOF cat >"$UBER_WHEEL_DIR/${PACKAGE_NAME}/auto.py" <<EOF """ ${PACKAGE_NAME} - utility module that allows users to automatically install modules by adding $(import ${PACKAGE_NAME}.auto) to the top of their script """ from ${PACKAGE_NAME} import load_wheels load_wheels() EOF # Copy all wheels to the uber wheel directory mkdir -p "$UBER_WHEEL_DIR/${PACKAGE_NAME}/wheels" cp "$WHEEL_OUTPUT_DIRECTORY"/*.whl "$UBER_WHEEL_DIR/${PACKAGE_NAME}/wheels/" # Build the uber wheel echo "Building uber wheel package..." # Install build tools in the current environment "$VENV_DIR/bin/pip" install build if ! (cd "$UBER_WHEEL_DIR" && "$VENV_DIR/bin/python" -m build --skip-dependency-check --wheel --outdir .); then echo "Error: Failed to build uber wheel" exit 1 fi # Ensure output directory exists mkdir -p "$FINAL_WHEEL_OUTPUT_DIRECTORY" # Copy the uber wheel to the output directory FINAL_WHEEL_OUTPUT_PATH="$FINAL_WHEEL_OUTPUT_DIRECTORY/$UBER_WHEEL_NAME" # Find the generated wheel (should be only one in the root directory) GENERATED_WHEEL=$(find "$UBER_WHEEL_DIR" -maxdepth 1 -name "*.whl" -type f | head -1) if [ -z "$GENERATED_WHEEL" ]; then echo "Error: No uber wheel was generated" exit 1 fi cp "$GENERATED_WHEEL" "$FINAL_WHEEL_OUTPUT_PATH" # Get final wheel size for user feedback WHEEL_SIZE=$(du -h "$FINAL_WHEEL_OUTPUT_PATH" | cut -f1) echo "✓ Uber wheel created successfully!" echo "" echo "=========================================" echo "BUILD COMPLETED SUCCESSFULLY!" echo "=========================================" echo "Final wheel: $FINAL_WHEEL_OUTPUT_PATH" echo "Wheel size: $WHEEL_SIZE" echo "Dependencies included: $WHEEL_COUNT packages" echo "" echo "To install the bundle, run:" echo " pip install $FINAL_WHEEL_OUTPUT_PATH" echo "" echo "After installation, you can verify that the bundle works by running:" echo " python -c \"import ${PACKAGE_NAME}; ${PACKAGE_NAME}.load_wheels()\"" echo " or " echo " python -c \"import ${PACKAGE_NAME}.auto\"" echo "========================================="
./wheel_packager.sh -r <path to requirements.txt> -g <glue version> -o <wheel output directory> -n <package name> -v <wheel version>
--additional-python-modules s3://your-bucket/path/to/package_with_dependencies-1.0.0-py3-none-any.whl
# Option 1: automatic installation via import import package_with_dependencies.auto # Option 2: manual installation from package_with_dependencies import load_wheels load_wheels()
Inclusão de arquivos Python com recursos nativos do PySpark
O AWS Glue usa PySpark para incluir arquivos Python em trabalhos de ETL do AWS Glue. Recomenda-se usar --additional-python-modules para gerenciar suas dependências quando disponíveis. Você pode usar o parâmetro de trabalho --extra-py-files para incluir arquivos Python. As dependências devem ser hospedadas no Amazon S3, e o valor do argumento deve ser uma lista delimitada por vírgulas de caminhos do Amazon S3 sem espaços. Essa funcionalidade se comporta como o gerenciamento de dependências do Python que você usaria com o Spark. Para obter mais informações sobre o gerenciamento de dependências do Python no Spark, consulte a página Using PySpark Native Features--extra-py-files é útil em casos nos quais seu código adicional não está empacotado ou quando você está migrando um programa Spark com uma cadeia de ferramentas existente para gerenciar dependências. Para que suas ferramentas de dependência sejam passíveis de manutenção, você precisará empacotar suas dependências antes de enviá-las.
Scripts de programação que usam transformações visuais
Ao criar uma tarefa do AWS Glue usando a interface visual do AWS Glue Studio, é possível transformar seus dados com nós de transformação de dados gerenciados e transformações visuais personalizadas. Para obter mais informações sobre nós de transformações de dados gerenciados, consulte Transformar dados com transformações gerenciadas do AWS Glue. Para obter mais informações sobre transformações visuais personalizadas, consulte Transformar dados com transformações visuais personalizadas . Os scripts que usam transformações visuais só poderão ser gerados quando a Linguagem do trabalho estiver configurada para usar Python.
Ao gerar uma tarefa do AWS Glue usando transformações visuais, o AWS Glue Studio incluirá essas transformações no ambiente de runtime usando o parâmetro --extra-py-files na configuração da tarefa. Para obter mais informações sobre parâmetros de trabalho, consulte Usar parâmetros de tarefa em tarefas do AWS Glue. Ao fazer alterações em um script gerado ou em um ambiente de runtime, será necessário preservar essa configuração de trabalho para que seu script seja executado com êxito.
Compactar bibliotecas para inclusão
A menos que uma biblioteca esteja contida em um único arquivo .py, ela precisará ser compactada em uma pasta .zip. O diretório do pacote deve estar na raiz do arquivo e precisa conter um arquivo __init__.py para o pacote. Em seguida, o Python poderá importar o pacote normalmente.
Se a sua biblioteca contém um único módulo Python em um arquivo .py, você não precisará compactá-la em uma pasta .zip.
Carregar bibliotecas do Python em cadernos do AWS Glue Studio
Para especificar bibliotecas do Python nos cadernos do AWS Glue Studio, consulte Instalar módulos Python adicionais.
Carregar bibliotecas Python em um endpoint de desenvolvimento no AWS Glue 0.9/1.0
Se você estiver usando diferentes conjuntos de bibliotecas para diferentes scripts de ETL, poderá configurar um endpoint de desenvolvimento separado para cada conjunto ou substituir os arquivos .zip da biblioteca carregados pelo seu endpoint de desenvolvimento sempre que os scripts são alternados.
Você pode usar o console para especificar um ou mais arquivos .zip da biblioteca para um endpoint de desenvolvimento ao criá-lo. Depois de atribuir um nome e uma função do IAM, escolha Script Libraries and job parameters (optional) (Bibliotecas de script e parâmetros de trabalho [opcional]) e insira o caminho completo do Amazon S3 para o arquivo .zip da sua biblioteca na caixa Python library path (Caminho da biblioteca Python). Por exemplo:
s3://bucket/prefix/site-packages.zipSe quiser, você poderá especificar vários caminhos completos para arquivos, separando-os com vírgulas, mas sem espaços, da seguinte maneira:
s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zipSe você atualizar esses arquivos .zip posteriormente, poderá usar o console para importá-los novamente para o seu endpoint de desenvolvimento. Navegue até o endpoint do desenvolvedor em questão, marque a caixa de seleção ao lado e escolha Update ETL libraries no menu Action.
De forma semelhante, você pode especificar arquivos de biblioteca usando as APIs do AWS Glue. Ao criar um endpoint de desenvolvimento chamando Ação CreateDevEndpoint (Python: create_dev_endpoint), você pode especificar um ou mais caminhos completos para bibliotecas no parâmetro ExtraPythonLibsS3Path. Essa chamada é semelhante à seguinte:
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")Ao atualizar um endpoint de desenvolvimento, você também pode atualizar as bibliotecas que ele carrega usando um objeto DevEndpointCustomLibraries e definindo o parâmetro UpdateEtlLibraries como True ao chamar UpdateDevEndpoint (update_dev_endpoint).
Usar bibliotecas Python em trabalho ou JobRun
Ao criar um novo trabalho no console, você pode especificar um ou mais arquivos .zip de biblioteca escolhendo a opção Script Libraries and job parameters (optional) (Bibliotecas de script e parâmetros de trabalho [opcional]) e inserindo os caminhos completos das bibliotecas do Amazon S3, da mesma maneira como você faria ao criar um endpoint de desenvolvimento:
s3://bucket/prefix/lib_A.zip,s3://bucket_B/prefix/lib_X.zipSe você estiver chamando CreateJob (create_job), poderá especificar um ou mais caminhos completos para bibliotecas padrão usando o parâmetro padrão --extra-py-files, da seguinte maneira:
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'})Assim, quando estiver iniciando um JobRun, você poderá substituir a configuração da biblioteca padrão por uma diferente:
runId = glue.start_job_run(JobName='sampleJob',
Arguments={'--extra-py-files': 's3://bucket/prefix/lib_B.zip'})Analisar proativamente dependências do Python
Para identificar proativamente possíveis problemas de dependência antes de implantar no AWS Glue, é possível usar a ferramenta de análise de dependências para validar seus pacotes Python em relação ao ambiente AWS Glue de destino.
A AWS oferece uma ferramenta de análise de dependências Python de código aberto projetada especificamente para ambientes AWS Glue. Essa ferramenta está disponível no repositório de amostras do AWS Glue e pode ser usada localmente para validar suas dependências antes da implantação.
Essa análise ajuda a garantir que suas dependências sigam a prática recomendada de fixar todas as versões da biblioteca para implantações de produção consistentes. Para obter mais detalhes, consulte o arquivo README
O AWS Glue Python Dependency Analyzer ajuda a identificar dependências não fixadas e conflitos de versão simulando a instalação do pip com restrições específicas da plataforma que correspondem ao seu ambiente AWS Glue de destino.
# 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
A ferramenta sinalizará:
-
Dependências não fixadas que poderiam instalar versões diferentes em todas as execuções de tarefas
-
Conflitos de versão entre pacotes
-
Dependências não disponíveis para seu ambiente AWS Glue de destino
O Amazon Q Developer é um assistente conversacional baseado em inteligência artificial (IA) generativa que pode ajudar você a entender, criar, estender e operar aplicações da AWS. Você pode baixá-lo seguindo as instruções no guia de introdução do Amazon Q.
O Amazon Q Developer pode ser usado para analisar e corrigir falhas de trabalho devido à dependência do Python. Sugerimos o prompt a seguir, onde <Job-Name> deve ser substituídopelo nome do seu trabalho do Glue.
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.
O prompt instrui o Q a:
-
Obter o ID de execução do trabalho com falha mais recente
-
Encontrar logs e detalhes associados
-
Encontrar execuções de trabalho bem-sucedidas para detectar quaisquer pacotes Python alterados
-
Fazer quaisquer correções na configuração e acionar outra execução de teste
Módulos do Python já fornecidos no AWS Glue
Para alterar a versão desses módulos fornecidos, forneça novas versões com o parâmetro de trabalho --additional-python-modules.
