Schedule Classe
Définit une planification de soumission d’un pipeline.
Une fois qu’un pipeline est publié, vous pouvez utiliser une planification pour soumettre le pipeline à un intervalle spécifique, ou quand des changements liés à un emplacement du service Stockage Blob sont détectés.
Initialisez la planification.
- Héritage
-
builtins.objectSchedule
Constructeur
Schedule(workspace, id, name, description, pipeline_id, status, recurrence, datastore_name, polling_interval, data_path_parameter_name, continue_on_step_failure, path_on_datastore, _schedule_provider=None, pipeline_endpoint_id=None)Paramètres
- datastore_name
- str
Nom du magasin de données pour lequel un monitoring doit être effectué sur les objets blob modifiés/ajoutés. Remarque : 1) Les magasins de données de réseau virtuel ne sont pas pris en charge. 2) Le type d’authentification du magasin de données doit être défini sur « Clé de compte ».
- polling_interval
- int
Durée (en minutes) entre l’interrogation des blobs modifiés/ajoutés.
- data_path_parameter_name
- str
Nom du paramètre de pipeline relatif au chemin d’accès des données à définir avec le chemin d’accès des blobs modifiés.
- continue_on_step_failure
- bool
Indique s’il faut poursuivre l’exécution des autres étapes du PipelineRun envoyé si une étape échoue. Si ce paramètre est fourni, il remplace le paramètre continue_on_step_failure du pipeline.
- path_on_datastore
- str
facultatif. Chemin d’accès sur le magasin de données à surveiller pour les blobs modifiés/ajoutés. Remarque : Dans la mesure où path_on_datastore se trouve sous le conteneur du magasin de données, le chemin réel faisant l’objet d’un monitoring par la planification est container/path_on_datastore. S’il n’y en a aucun, le conteneur du magasin de données est surveillé. Les ajouts/modifications effectués dans un sous-dossier de path_on_datastore ne font pas l’objet d’un monitoring. Prise en charge limitée aux planifications de magasin de données.
- _schedule_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaScheduleProvider>
Fournisseur de planification.
- datastore_name
- str
Nom du magasin de données pour lequel un monitoring doit être effectué sur les objets blob modifiés/ajoutés. Remarque : Les magasins de données VNet ne sont pas pris en charge.
- polling_interval
- int
Durée (en minutes) entre l’interrogation des blobs modifiés/ajoutés.
- data_path_parameter_name
- str
Nom du paramètre de pipeline relatif au chemin d’accès des données à définir avec le chemin d’accès des blobs modifiés.
- continue_on_step_failure
- bool
Indique s’il faut poursuivre l’exécution des autres étapes du PipelineRun envoyé si une étape échoue. Si ce paramètre est fourni, il remplace le paramètre continue_on_step_failure du pipeline.
- path_on_datastore
- str
facultatif. Chemin d’accès sur le magasin de données à surveiller pour les blobs modifiés/ajoutés. Remarque : Dans la mesure où path_on_datastore se trouve sous le conteneur du magasin de données, le chemin réel faisant l’objet d’un monitoring par la planification est container/path_on_datastore. S’il n’y en a aucun, le conteneur du magasin de données est surveillé. Les ajouts/modifications effectués dans un sous-dossier de path_on_datastore ne font pas l’objet d’un monitoring. Prise en charge limitée aux planifications de magasin de données.
- _schedule_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaScheduleProvider>
Fournisseur de planification.
- pipeline_endpoint_id
- str
ID du point de terminaison de pipeline à soumettre par la planification.
Remarques
Deux types de planification sont pris en charge. Le premier utilise la périodicité pour soumettre un pipeline selon une planification donnée. Le deuxième effectue un monitoring de AzureBlobDatastore à la recherche d’objets blob ajoutés ou modifiés, puis soumet un pipeline quand des changements sont détectés.
Pour créer une planification qui soumet un pipeline selon une périodicité, utilisez ScheduleRecurrence au moment de la création de la planification.
ScheduleRecurrence est utilisé au moment de la création d’une planification pour un pipeline de la manière suivante :
from azureml.pipeline.core import Schedule, ScheduleRecurrence
recurrence = ScheduleRecurrence(frequency="Hour", interval=12)
schedule = Schedule.create(workspace, name="TestSchedule", pipeline_id="pipeline_id",
experiment_name="helloworld", recurrence=recurrence)
Cette planification soumet le PublishedPipeline fourni toutes les 12 heures. Le pipeline soumis est créé dans l’expérience avec le nom « helloworld ».
Pour créer une planification qui déclenche PipelineRuns en cas de modification d’un emplacement du service Stockage Blob, spécifiez un magasin de données ainsi que les informations de données associées au moment de la création de la planification.
from azureml.pipeline.core import Schedule
from azureml.core.datastore import Datastore
datastore = Datastore(workspace=ws, name="workspaceblobstore")
schedule = Schedule.create(workspace, name="TestSchedule", pipeline_id="pipeline_id"
experiment_name="helloworld", datastore=datastore,
polling_interval=5, path_on_datastore="file/path")
Notez que les paramètres polling_interval et path_on_datastore sont facultatifs. Le paramètre polling_interval spécifie la fréquence d’interrogation des modifications apportées au magasin de données. La valeur par défaut est de 5 minutes. path_on_datastore permet de spécifier le dossier de magasin de données sur lequel un monitoring doit être effectué pour détecter les changements apportés. Si None est spécifié, le conteneur du magasin de données fait l’objet d’un monitoring. Remarque : Les ajouts/modifications d’objets blob dans les sous-dossiers de path_on_datastore ou du conteneur de magasin de données (si path_on_datastore n’est pas spécifié) ne sont pas détectés.
De plus, si le pipeline a été construit pour utiliser DataPathPipelineParameter afin de décrire une entrée d’étape, utilisez le paramètre data_path_parameter_name au moment de la création d’une planification déclenchée par le magasin de données. Cela permet de définir l’entrée en fonction du fichier ayant fait l’objet de changements quand PipelineRun est soumis par la planification.
Dans l’exemple suivant, quand la planification déclenche PipelineRun, la valeur de PipelineParameter pour « input_data » correspond au fichier modifié/ajouté :
from azureml.pipeline.core import Schedule
from azureml.core.datastore import Datastore
datastore = Datastore(workspace=ws, name="workspaceblobstore")
schedule = Schedule.create(workspace, name="TestSchedule", pipeline_id="pipeline_id",
experiment_name="helloworld", datastore=datastore,
data_path_parameter_name="input_data")
Pour plus d’informations sur les planifications, consultez : https://aka.ms/pl-schedule.
Méthodes
| create |
Permet de créer une planification pour un pipeline. Spécifiez la périodicité d’une planification sur une base temporelle, ou spécifiez un magasin de données, polling_interval (facultatif), data_path_parameter_name (facultatif) pour créer une planification qui effectue le monitoring de l’emplacement du magasin de données à la recherche de modifications/d’ajouts. |
| create_for_pipeline_endpoint |
Crée une planification pour un point de terminaison de pipeline. Spécifiez la périodicité d’une planification sur une base temporelle, ou spécifiez un magasin de données, polling_interval (facultatif), data_path_parameter_name (facultatif) pour créer une planification qui effectue le monitoring de l’emplacement du magasin de données à la recherche de modifications/d’ajouts. |
| disable |
Permet de définir la planification à l’état « Désactivé » pour l’empêcher de s’exécuter. |
| enable |
Permet de définir la planification à l’état « Actif » pour lui permettre de s’exécuter. |
| get |
Permet d’obtenir la planification ayant l’ID donné. |
| get_all |
Permet d’obtenir toutes les planifications de l’espace de travail actuel. DÉPRÉCIÉE : Cette méthode est dépréciée en faveur de la méthode list. |
| get_last_pipeline_run |
Permet de récupérer la dernière exécution de pipeline soumise par la planification. Retourne None si aucune exécution n’a été soumise. |
| get_pipeline_runs |
Permet de récupérer les exécutions de pipeline générées à partir de la planification. |
| get_schedules_for_pipeline_endpoint_id |
Permet d’obtenir toutes les planifications correspondant à l’ID de point de terminaison de pipeline donné. |
| get_schedules_for_pipeline_id |
Permet d’obtenir toutes les planifications correspondant à l’ID de pipeline donné. |
| list |
Permet d’obtenir toutes les planifications de l’espace de travail actuel. |
| load_yaml |
Permet de charger et de lire le fichier YAML pour obtenir les paramètres de planification. Le fichier YAML est un moyen supplémentaire de passer les paramètres de Schedule pour créer une planification. |
| update |
Permet de mettre à jour la planification. |
create
Permet de créer une planification pour un pipeline.
Spécifiez la périodicité d’une planification sur une base temporelle, ou spécifiez un magasin de données, polling_interval (facultatif), data_path_parameter_name (facultatif) pour créer une planification qui effectue le monitoring de l’emplacement du magasin de données à la recherche de modifications/d’ajouts.
static create(workspace, name, pipeline_id, experiment_name, recurrence=None, description=None, pipeline_parameters=None, wait_for_provisioning=False, wait_timeout=3600, datastore=None, polling_interval=5, data_path_parameter_name=None, continue_on_step_failure=None, path_on_datastore=None, _workflow_provider=None, _service_endpoint=None)Paramètres
- experiment_name
- str
Nom de l’expérience à laquelle la planification va soumettre les tests.
- pipeline_parameters
- dict
Dictionnaire de paramètres pour affecter de nouvelles valeurs {nom du paramètre, valeur du paramètre}
- wait_for_provisioning
- bool
Indique s’il faut attendre la fin de l’approvisionnement de la planification.
- datastore
- AzureBlobDatastore
Magasin de données pour lequel un monitoring doit être effectué sur les objets blob modifiés/ajoutés. Remarque : Les magasins de données VNet ne sont pas pris en charge. Non utilisable avec une périodicité.
- polling_interval
- int
Durée (en minutes) entre l’interrogation des blobs modifiés/ajoutés. La valeur par défaut est de 5 minutes. Prise en charge limitée aux planifications de magasin de données.
- data_path_parameter_name
- str
Nom du paramètre de pipeline relatif au chemin d’accès des données à définir avec le chemin d’accès des blobs modifiés. Prise en charge limitée aux planifications de magasin de données.
- continue_on_step_failure
- bool
Indique s’il faut poursuivre l’exécution des autres étapes du PipelineRun envoyé si une étape échoue. Si ce paramètre est fourni, il remplace le paramètre continue_on_step_failure du pipeline.
- path_on_datastore
- str
facultatif. Chemin d’accès sur le magasin de données à surveiller pour les blobs modifiés/ajoutés. Remarque : Dans la mesure où path_on_datastore se trouve sous le conteneur du magasin de données, le chemin réel faisant l’objet d’un monitoring par la planification est container/path_on_datastore. S’il n’y en a aucun, le conteneur du magasin de données est surveillé. Les ajouts/modifications effectués dans un sous-dossier de path_on_datastore ne font pas l’objet d’un monitoring. Prise en charge limitée aux planifications de magasin de données.
- _workflow_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaWorkflowProvider>
Fournisseur de workflow.
Retours
Planification créée.
Type de retour
create_for_pipeline_endpoint
Crée une planification pour un point de terminaison de pipeline.
Spécifiez la périodicité d’une planification sur une base temporelle, ou spécifiez un magasin de données, polling_interval (facultatif), data_path_parameter_name (facultatif) pour créer une planification qui effectue le monitoring de l’emplacement du magasin de données à la recherche de modifications/d’ajouts.
static create_for_pipeline_endpoint(workspace, name, pipeline_endpoint_id, experiment_name, recurrence=None, description=None, pipeline_parameters=None, wait_for_provisioning=False, wait_timeout=3600, datastore=None, polling_interval=5, data_path_parameter_name=None, continue_on_step_failure=None, path_on_datastore=None, _workflow_provider=None, _service_endpoint=None)Paramètres
- pipeline_endpoint_id
- str
ID du point de terminaison de pipeline à soumettre par la planification.
- experiment_name
- str
Nom de l’expérience à laquelle la planification va soumettre les tests.
- pipeline_parameters
- dict
Dictionnaire de paramètres pour affecter de nouvelles valeurs {nom du paramètre, valeur du paramètre}
- wait_for_provisioning
- bool
Indique s’il faut attendre la fin de l’approvisionnement de la planification.
- datastore
- AzureBlobDatastore
Magasin de données pour lequel un monitoring doit être effectué sur les objets blob modifiés/ajoutés. Remarque : Les magasins de données VNet ne sont pas pris en charge. Non utilisable avec une périodicité.
- polling_interval
- int
Durée (en minutes) entre l’interrogation des blobs modifiés/ajoutés. La valeur par défaut est de 5 minutes. Prise en charge limitée aux planifications de magasin de données.
- data_path_parameter_name
- str
Nom du paramètre de pipeline relatif au chemin d’accès des données à définir avec le chemin d’accès des blobs modifiés. Prise en charge limitée aux planifications de magasin de données.
- continue_on_step_failure
- bool
Indique s’il faut poursuivre l’exécution des autres étapes du PipelineRun envoyé si une étape échoue. Si ce paramètre est fourni, il remplace le paramètre continue_on_step_failure du pipeline.
- path_on_datastore
- str
facultatif. Chemin d’accès sur le magasin de données à surveiller pour les blobs modifiés/ajoutés. Remarque : Dans la mesure où path_on_datastore se trouve sous le conteneur du magasin de données, le chemin réel faisant l’objet d’un monitoring par la planification est container/path_on_datastore. S’il n’y en a aucun, le conteneur du magasin de données est surveillé. Les ajouts/modifications effectués dans un sous-dossier de path_on_datastore ne font pas l’objet d’un monitoring. Prise en charge limitée aux planifications de magasin de données.
- _workflow_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaWorkflowProvider>
Fournisseur de workflow.
Retours
Planification créée.
Type de retour
disable
Permet de définir la planification à l’état « Désactivé » pour l’empêcher de s’exécuter.
disable(wait_for_provisioning=False, wait_timeout=3600)Paramètres
- wait_for_provisioning
- bool
Indique s’il faut attendre la fin de l’approvisionnement de la planification.
- wait_timeout
- int
Nombre de secondes à attendre avant l’expiration du délai d’attente.
enable
Permet de définir la planification à l’état « Actif » pour lui permettre de s’exécuter.
enable(wait_for_provisioning=False, wait_timeout=3600)Paramètres
- wait_for_provisioning
- bool
Indique s’il faut attendre la fin de l’approvisionnement de la planification.
- wait_timeout
- int
Nombre de secondes à attendre avant l’expiration du délai d’attente.
get
Permet d’obtenir la planification ayant l’ID donné.
static get(workspace, id, _workflow_provider=None, _service_endpoint=None)Paramètres
- _workflow_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaWorkflowProvider>
Fournisseur de workflow.
Retours
Objet de planification
Type de retour
get_all
Permet d’obtenir toutes les planifications de l’espace de travail actuel.
DÉPRÉCIÉE : Cette méthode est dépréciée en faveur de la méthode list.
static get_all(workspace, active_only=True, pipeline_id=None, pipeline_endpoint_id=None, _workflow_provider=None, _service_endpoint=None)Paramètres
- active_only
- bool
Si la valeur est true, retourne uniquement les planifications actives. S’applique uniquement si aucun ID de pipeline n’est fourni.
- pipeline_id
- str
Si ce paramètre est fourni, seules les planifications du pipeline ayant l’ID donné sont retournées.
- pipeline_endpoint_id
- str
Si ce paramètre est fourni, seules les planifications du point de terminaison de pipeline ayant l’ID donné sont retournées.
- _workflow_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaWorkflowProvider>
Fournisseur de workflow.
Retours
Liste de Schedule.
Type de retour
get_last_pipeline_run
Permet de récupérer la dernière exécution de pipeline soumise par la planification. Retourne None si aucune exécution n’a été soumise.
get_last_pipeline_run()Retours
Dernière exécution de pipeline.
Type de retour
get_pipeline_runs
Permet de récupérer les exécutions de pipeline générées à partir de la planification.
get_pipeline_runs()Retours
Liste de PipelineRun.
Type de retour
get_schedules_for_pipeline_endpoint_id
Permet d’obtenir toutes les planifications correspondant à l’ID de point de terminaison de pipeline donné.
static get_schedules_for_pipeline_endpoint_id(workspace, pipeline_endpoint_id, _workflow_provider=None, _service_endpoint=None)Paramètres
- _workflow_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaWorkflowProvider>
Fournisseur de workflow.
Retours
Liste de Schedule.
Type de retour
get_schedules_for_pipeline_id
Permet d’obtenir toutes les planifications correspondant à l’ID de pipeline donné.
static get_schedules_for_pipeline_id(workspace, pipeline_id, _workflow_provider=None, _service_endpoint=None)Paramètres
- _workflow_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaWorkflowProvider>
Fournisseur de workflow.
Retours
Liste de Schedule.
Type de retour
list
Permet d’obtenir toutes les planifications de l’espace de travail actuel.
static list(workspace, active_only=True, pipeline_id=None, pipeline_endpoint_id=None, _workflow_provider=None, _service_endpoint=None)Paramètres
- active_only
- bool
Si la valeur est true, retourne uniquement les planifications actives. S’applique uniquement si aucun ID de pipeline n’est fourni.
- pipeline_id
- str
Si ce paramètre est fourni, seules les planifications du pipeline ayant l’ID donné sont retournées.
- pipeline_endpoint_id
- str
Si ce paramètre est fourni, seules les planifications du point de terminaison de pipeline ayant l’ID donné sont retournées.
- _workflow_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaWorkflowProvider>
Fournisseur de workflow.
Retours
Liste de Schedule.
Type de retour
load_yaml
Permet de charger et de lire le fichier YAML pour obtenir les paramètres de planification.
Le fichier YAML est un moyen supplémentaire de passer les paramètres de Schedule pour créer une planification.
static load_yaml(workspace, filename, _workflow_provider=None, _service_endpoint=None)Paramètres
- _workflow_provider
- <xref:azureml.pipeline.core._aeva_provider._AevaWorkflowProvider>
Fournisseur de workflow.
Retours
Dictionnaire de paramètres et de valeurs de Schedule.
Type de retour
Remarques
Deux types de fichier YAML sont pris en charge pour les planifications. Le premier lit et charge les informations de périodicité pour permettre la création de la planification et le déclenchement du pipeline. Le deuxième lit et charge les informations du magasin de données pour permettre la création de la planification et le déclenchement du pipeline.
Exemple de création d’une planification qui soumet un pipeline en fonction d’une périodicité :
from azureml.pipeline.core import Schedule
schedule_info = Schedule.load_yaml(workspace=workspace,
filename='./yaml/test_schedule_with_recurrence.yaml')
schedule = Schedule.create(workspace, name="TestSchedule", pipeline_id="pipeline_id",
experiment_name="helloworld", recurrence=schedule_info.get("recurrence"),
description=schedule_info.get("description"))
Exemple de fichier YAML test_schedule_with_recurrence.yaml :
Schedule:
description: "Test create with recurrence"
recurrence:
frequency: Week # Can be "Minute", "Hour", "Day", "Week", or "Month".
interval: 1 # how often fires
start_time: 2019-06-07T10:50:00
time_zone: UTC
hours:
- 1
minutes:
- 0
time_of_day: null
week_days:
- Friday
pipeline_parameters: {'a':1}
wait_for_provisioning: True
wait_timeout: 3600
datastore_name: ~
polling_interval: ~
data_path_parameter_name: ~
continue_on_step_failure: None
path_on_datastore: ~
Exemple de création d’une planification qui soumet un pipeline en fonction d’un magasin de données :
from azureml.pipeline.core import Schedule
schedule_info = Schedule.load_yaml(workspace=workspace,
filename='./yaml/test_schedule_with_datastore.yaml')
schedule = Schedule.create(workspace, name="TestSchedule", pipeline_id="pipeline_id",
experiment_name="helloworld",datastore=schedule_info.get("datastore_name"),
polling_interval=schedule_info.get("polling_interval"),
data_path_parameter_name=schedule_info.get("data_path_parameter_name"),
continue_on_step_failure=schedule_info.get("continue_on_step_failure"),
path_on_datastore=schedule_info.get("path_on_datastore"))
update
Permet de mettre à jour la planification.
update(name=None, description=None, recurrence=None, pipeline_parameters=None, status=None, wait_for_provisioning=False, wait_timeout=3600, datastore=None, polling_interval=None, data_path_parameter_name=None, continue_on_step_failure=None, path_on_datastore=None)Paramètres
- recurrence
- ScheduleRecurrence
Nouvelle périodicité de planification du pipeline.
- pipeline_parameters
- dict
Dictionnaire de paramètres pour affecter de nouvelles valeurs {nom du paramètre, valeur du paramètre}.
- wait_for_provisioning
- bool
Indique s’il faut attendre la fin de l’approvisionnement de la planification.
- datastore
- AzureBlobDatastore
Magasin de données pour lequel un monitoring doit être effectué sur les objets blob modifiés/ajoutés. Remarque : Les magasins de données VNet ne sont pas pris en charge.
- polling_interval
- int
Durée (en minutes) entre l’interrogation des blobs modifiés/ajoutés. La valeur par défaut est de 5 minutes.
- data_path_parameter_name
- str
Nom du paramètre de pipeline relatif au chemin d’accès des données à définir avec le chemin d’accès des blobs modifiés.
- continue_on_step_failure
- bool
Indique s’il faut poursuivre l’exécution des autres étapes du PipelineRun envoyé si une étape échoue. Si ce paramètre est fourni, il remplace le paramètre continue_on_step_failure du pipeline.
- path_on_datastore
- str
facultatif. Chemin d’accès sur le magasin de données à surveiller pour les blobs modifiés/ajoutés. Remarque : Dans la mesure où path_on_datastore se trouve sous le conteneur du magasin de données, le chemin réel faisant l’objet d’un monitoring par la planification est container/path_on_datastore. S’il n’y en a aucun, le conteneur du magasin de données est surveillé. Les ajouts/modifications effectués dans un sous-dossier de path_on_datastore ne font pas l’objet d’un monitoring. Prise en charge limitée aux planifications de magasin de données.
Attributs
continue_on_step_failure
Permet d’obtenir la valeur du paramètre continue_on_step_failure.
Retours
Valeur du paramètre continue_on_step_failure
Type de retour
data_path_parameter_name
Permet d’obtenir le nom du paramètre de pipeline relatif au chemin de données à définir avec le chemin d’objet blob changé.
Retours
Nom du paramètre de chemin des données.
Type de retour
datastore_name
Permet d’obtenir le nom du magasin de données utilisé pour la planification.
Retours
Nom du magasin de données.
Type de retour
description
Permet d’obtenir la description de la planification.
Retours
Description de la planification.
Type de retour
id
name
path_on_datastore
Permet d’obtenir le chemin au sein du magasin de données faisant l’objet d’un monitoring par la planification.
Retours
Chemin dans le magasin de données.
Type de retour
pipeline_endpoint_id
Obtient l’ID du point de terminaison de pipeline soumis par la planification.
Retours
ID.
Type de retour
pipeline_id
polling_interval
Permet d’obtenir le délai, en minutes, qui s’écoule entre les interrogations des objets blob modifiés/ajoutés.
Retours
Intervalle d’interrogation.
Type de retour
recurrence
Permet d’obtenir la périodicité de la planification.
Retours
Périodicité de la planification.
Type de retour
status
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