PipelineStep Classe
Représente une étape d’exécution dans un pipeline Azure Machine Learning.
Les pipelines sont construits à partir de plusieurs étapes de pipelines, qui sont des unités de calcul distinctes dans le pipeline. Chaque étape peut s’exécuter indépendamment et utiliser des ressources de calcul isolées. Chaque étape dispose généralement de ses propres entrées, sorties et paramètres nommés.
La classe PipelineStep est la classe de base dont héritent d’autres classes d’étape intégrées conçues pour des scénarios courants, comme PythonScriptStep, DataTransferStep et HyperDriveStep.
Pour obtenir une vue d’ensemble de la façon dont les Pipelines et PipelineSteps sont liés, consultez Présentation des pipelines ML.
Initialiser PipelineStep.
- Héritage
-
builtins.objectPipelineStep
Constructeur
PipelineStep(name, inputs, outputs, arguments=None, fix_port_name_collisions=False, resource_inputs=None)Paramètres
- arguments
- list
Liste facultative d’arguments à transmettre à un script utilisé à l’étape.
- fix_port_name_collisions
- bool
Spécifie si les collisions de noms doivent être corrigées. Si True est défini et qu’une entrée et une sortie portent le même nom, un préfixe « INPUT » est ajouté à l’entrée. La valeur par défaut est False.
- resource_inputs
- list
Liste facultative des entrées à utiliser comme ressources. Les ressources sont téléchargées dans le dossier de script et offrent un moyen de modifier le comportement du script au moment de l’exécution.
- arguments
- list
Liste facultative d’arguments à transmettre à un script utilisé à l’étape.
- fix_port_name_collisions
- bool
Spécifie si les collisions de noms doivent être corrigées. Si True est défini et qu’une entrée et une sortie portent le même nom, un préfixe « INPUT » est ajouté à l’entrée. La valeur par défaut est False.
- resource_inputs
- list
Liste facultative des entrées à utiliser comme ressources. Les ressources sont téléchargées dans le dossier de script et offrent un moyen de modifier le comportement du script au moment de l’exécution.
Remarques
Un PipelineStep est une unité d’exécution qui nécessite généralement une cible d’exécution (cible de calcul), un script à exécuter avec des entrées et des arguments de script facultatifs, et qui peut générer des sorties. L’étape peut également utiliser un certain nombre d’autres paramètres spécifiques à l’étape.
Les étapes de pipeline peuvent être configurées ensemble pour construire un Pipeline, qui représente un flux de travail Azure Machine Learning pouvant être partagé et réutilisé. Chaque étape d’un pipeline peut être configurée pour permettre la réutilisation de ses résultats d’exécution précédents si le contenu de l’étape (scripts/dépendances), ainsi que les entrées et les paramètres, restent inchangés. Lors de la réutilisation de l’étape, au lieu de soumettre le travail au calcul, les résultats de l’exécution précédente sont immédiatement mis à la disposition des étapes suivantes.
Azure Machine Learning Pipelines fournit des étapes intégrées pour les scénarios courants. Pour obtenir des exemples, consultez le package steps et la classe AutoMLStep. Pour obtenir une vue d’ensemble de la construction d’un pipeline basé sur des étapes prédéfinies, consultez https://aka.ms/pl-first-pipeline.
Les étapes prédéfinies dérivées de PipelineStep sont des étapes utilisées dans un pipeline. Si vous utilisez des appels de flux de travail Machine Learning pour créer des étapes qui peuvent être versionnées et utilisées sur différents pipelines, utilisez la classe Module.
Gardez à l’esprit les points suivants quand vous utilisez des étapes de pipeline, des données d’entrée/de sortie et la réutilisation d’étape.
Il est recommandé d’utiliser des emplacements source_directory distincts pour les différentes étapes. Si tous les scripts de vos étapes de pipeline se trouvent dans un répertoire unique, le hachage de ce répertoire change chaque fois que vous modifiez un script en forçant toutes les étapes à être réexécutées. Pour obtenir un exemple d’utilisation de répertoires distincts pour différentes étapes, consultez https://aka.ms/pl-get-started.
Conserver des dossiers distincts pour les scripts et les fichiers dépendants pour chaque étape permet de réduire la taille de l’instantané créé pour chaque étape, car un instantané est effectué uniquement pour le dossier spécifique. Étant donné que chaque modification apportée à l’un des fichiers dans le source_directory de l’étape déclenche le rechargement de l’instantané, conserver des dossiers distincts pour chaque étape permet la réutilisation des étapes du pipeline. En effet, si aucune modification n’est effectuée dans le source_directory d’une étape, l’exécution précédente de l’étape est réutilisée.
Si les données utilisées dans une étape se trouvent dans un magasin de données et que allow_reuse est défini sur True, les modifications des données ne sont pas détectées. Si les données sont chargées dans le cadre de l’instantané (sous le source_directory de l’étape), bien que cela ne soit pas recommandé, le hachage est modifié et déclenche une réexécution.
Méthodes
| create_input_output_bindings |
Crée des liaisons d’entrée et de sortie à partir des entrées et sorties de l’étape. |
| create_module_def |
Crée l’objet de définition de module qui décrit l’étape. |
| create_node |
Crée un nœud pour le graphe de pipeline en fonction de cette étape. |
| get_source_directory |
Obtient le répertoire source de l’étape et vérifie que le script existe. |
| resolve_input_arguments |
Fait correspondre les entrées et les sorties aux arguments pour produire une chaîne d’arguments. |
| run_after |
Exécute cette étape après l’étape spécifiée. |
| validate_arguments |
Vérifie que les entrées et les sorties d’étape fournies dans les arguments se trouvent dans les listes d’entrées et de sorties. |
create_input_output_bindings
Crée des liaisons d’entrée et de sortie à partir des entrées et sorties de l’étape.
create_input_output_bindings(inputs, outputs, default_datastore, resource_inputs=None)Paramètres
- default_datastore
- AbstractAzureStorageDatastore ou AzureDataLakeDatastore
Magasin de données par défaut.
- resource_inputs
- list
Liste des entrées à utiliser comme ressources. Les ressources sont téléchargées dans le dossier de script et offrent un moyen de modifier le comportement du script au moment de l’exécution.
Retours
Tuple des liaisons d’entrée et des liaisons de sortie.
Type de retour
create_module_def
Crée l’objet de définition de module qui décrit l’étape.
create_module_def(execution_type, input_bindings, output_bindings, param_defs=None, create_sequencing_ports=True, allow_reuse=True, version=None, module_type=None, arguments=None, runconfig=None, cloud_settings=None)Paramètres
- create_sequencing_ports
- bool
Spécifie si des ports de séquencement sont créés pour le module.
- allow_reuse
- bool
Spécifie si le module doit être disponible pour être réutilisé dans des pipelines futurs.
- module_type
- str
Type de module à créer pour le service de création de module. Actuellement, seuls deux types sont pris en charge : « None » et « BatchInferencing ». module_type est différent de execution_type qui spécifie le type de service back-end à utiliser pour exécuter ce module.
- arguments
- list
Liste d’arguments annotés à utiliser au moment de l’appel de ce module
- cloud_settings
- <xref:azureml.pipeline.core._restclients.aeva.models.CloudSettings>
Paramètres à utiliser pour les clouds
Retours
Objet de définition de module.
Type de retour
create_node
Crée un nœud pour le graphe de pipeline en fonction de cette étape.
abstract create_node(graph, default_datastore, context)Paramètres
- default_datastore
- AbstractAzureStorageDatastore ou AzureDataLakeDatastore
Magasin de données à utiliser par défaut pour cette étape.
- context
- <xref:azureml.pipeline.core._GraphContext>
Objet de contexte du graphe.
Retours
Nœud créé.
Type de retour
get_source_directory
Obtient le répertoire source de l’étape et vérifie que le script existe.
get_source_directory(context, source_directory, script_name)Paramètres
- context
- <xref:azureml.pipeline.core._GraphContext>
Objet de contexte du graphe.
- hash_paths
- list
Chemins de hachage à utiliser pour déterminer l’empreinte digitale du module.
Retours
Répertoire source et chemins de hachage.
Type de retour
resolve_input_arguments
Fait correspondre les entrées et les sorties aux arguments pour produire une chaîne d’arguments.
static resolve_input_arguments(arguments, inputs, outputs, params)Paramètres
Retours
Retourne un tuple de deux éléments. Le premier est une liste plate d’éléments pour les arguments résolus. La deuxième est une liste d’arguments structurés (_InputArgument, _OutputArgument, _ParameterArgument et _StringArgument)
Type de retour
run_after
Exécute cette étape après l’étape spécifiée.
run_after(step)Paramètres
Remarques
Si vous souhaitez exécuter une étape, par exemple step3 une fois que step1 et step2 sont terminés, vous pouvez utiliser :
step3.run_after(step1)
step3.run_after(step2)
validate_arguments
Vérifie que les entrées et les sorties d’étape fournies dans les arguments se trouvent dans les listes d’entrées et de sorties.
static validate_arguments(arguments, inputs, outputs)Paramètres
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour