Utilizzo del codice modulare con il decoratore @remote - Amazon SageMaker

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo del codice modulare con il decoratore @remote

È possibile organizzare il codice in moduli per facilitare la gestione dell'area di lavoro durante lo sviluppo e continuare a utilizzare la funzione @remote per richiamare una funzione. È inoltre possibile replicare i moduli locali dall'ambiente di sviluppo all'ambiente di lavoro remoto. A tal fine, imposta il parametro include_local_workdir su True, come visualizzato nell'esempio di codice seguente.

@remote( include_local_workdir=True, )
Nota

Il decoratore e il parametro @remote devono apparire nel file principale, anziché in uno qualsiasi dei file dipendenti.

Quando include_local_workdir è impostato suTrue, SageMaker impacchetta tutti gli script Python mantenendo la struttura di directory nella directory corrente del processo. Inoltre, rende disponibili le dipendenze nella directory di lavoro del lavoro.

Ad esempio, supponiamo che lo script Python che elabora MNIST il set di dati sia diviso in uno script e main.py uno script dipendente. pytorch_mnist.py main.pychiama lo script dipendente. Inoltre, lo main.py script contiene il codice per importare la dipendenza come mostrato.

from mnist_impl.pytorch_mnist import ...

Il main.py file deve contenere anche il @remote decoratore e deve impostare il include_local_workdir parametro su. True

Il include_local_workdir parametro di default include tutti gli script Python nella directory. È possibile personalizzare i file che si desidera caricare nel lavoro utilizzando questo parametro insieme al parametro. custom_file_filter Puoi passare una funzione che filtra le dipendenze dei lavori da caricare su S3 o un CustomFileFilter oggetto che specifica le directory e i file locali da ignorare nella funzione remota. Puoi usare custom_file_filter solo se include_local_workdir è impostato su True —altrimenti il parametro viene ignorato.

L'esempio seguente CustomFileFilter ignora tutti i file e le cartelle del taccuino o i file denominati data durante il caricamento di file su S3.

@remote( include_local_workdir=True, custom_file_filter=CustomFileFilter( ignore_pattern_names=[ # files or directories to ignore "*.ipynb", # all notebook files "data", # folter or file named data ] ) )

L'esempio seguente dimostra come è possibile impacchettare un intero spazio di lavoro.

@remote( include_local_workdir=True, custom_file_filter=CustomFileFilter( ignore_pattern_names=[] # package whole workspace ) )

L'esempio seguente mostra come utilizzare una funzione per filtrare i file.

import os def my_filter(path: str, files: List[str]) -> List[str]: to_ignore = [] for file in files: if file.endswith(".txt") or file.endswith(".ipynb"): to_ignore.append(file) return to_ignore @remote( include_local_workdir=True, custom_file_filter=my_filter )

Migliori pratiche per strutturare la directory di lavoro

Le seguenti best practice suggeriscono come organizzare la struttura delle cartelle utilizzando il @remote decoratore nel codice modulare.

  • Colloca il decoratore @remote in un file che si trova nella directory di livello principale dell'area di lavoro.

  • Struttura i moduli locali a livello principale.

L'immagine di esempio seguente mostra la struttura di directory consigliata. In questa struttura di esempio, lo script main.py si trova nella directory di livello principale.

. ├── config.yaml ├── data/ ├── main.py <----------------- @remote used here ├── mnist_impl │ ├── __pycache__/ │ │ └── pytorch_mnist.cpython-310.pyc │ ├── pytorch_mnist.py <-------- dependency of main.py ├── requirements.txt

L'immagine di esempio seguente mostra una struttura di directory che si tradurrà in un comportamento incoerente quando viene utilizzata per annotare il codice con un decoratore @remote.

In questa struttura di esempio, lo script main.py che contiene il decoratore @remote non si trova nella directory di livello principale. È NOTconsigliata la seguente struttura.

. ├── config.yaml ├── entrypoint │ ├── data │ └── main.py <----------------- @remote used here ├── mnist_impl │ ├── __pycache__ │ │ └── pytorch_mnist.cpython-310.pyc │ └── pytorch_mnist.py <-------- dependency of main.py ├── requirements.txt