Introduction aux tâches¶
Une tâche peut exécuter l’un des types de code SQL suivants :
Instruction SQL unique
Appel d’une procédure stockée
Logique procédurale à l’aide de l’Exécution de scripts Snowflake
Les tâches peuvent être combinées avec des flux de table pour des workflows continus ELT afin de traiter les lignes des tables récemment modifiées. Les flux assurent une sémantique unique pour les données nouvelles ou modifiées dans une table.
Les tâches peuvent également être utilisées indépendamment pour générer des rapports périodiques en insérant ou en fusionnant des lignes dans un tableau de rapports ou en effectuant d’autres travaux périodiques.
Dans ce chapitre :
Ressources de calcul¶
Les tâches nécessitent des ressources de calcul pour exécuter le code SQL. L’un ou l’autre des modèles de calcul suivants peut être choisi pour des tâches en particulier :
Modèle de calcul sans serveur
Entrepôt virtuel géré par l’utilisateur
Tâches sans serveur¶
Les tâches sans serveur vous permettent de vous appuyer sur des ressources de calcul gérées par Snowflake plutôt que sur des entrepôts virtuels gérés par des utilisateurs. Les ressources de calcul sans serveur sont automatiquement redimensionnées et augmentées ou diminuées par Snowflake en fonction des besoins de chaque charge de travail. Snowflake détermine la taille idéale des ressources de calcul sans serveur pour une exécution donnée en se basant sur une analyse dynamique des statistiques des exécutions les plus récentes de la même tâche. La taille de calcul maximale d’une tâche sans serveur est équivalente à un entrepôt virtuel XXLARGE géré par l’utilisateur. Plusieurs charges de travail dans votre compte partagent un ensemble commun de ressources de calcul.
Pour activer le modèle de calcul sans serveur, vous devez omettre le paramètre WAREHOUSE lorsque vous créez une tâche via CREATE TASK. Notez que le rôle qui exécute la commande CREATE TASK doit avoir le privilège global EXECUTE MANAGED TASK. Pour plus d’informations sur les exigences de contrôle d’accès aux tâches, voir Sécurité des tâches.
La facturation des exécutions de tâches sans serveur diffère du modèle de consommation de crédits standard pour les tâches qui s’appuient sur des entrepôts virtuels pour les ressources de calcul. Pour plus d’informations, voir Coûts des tâches.
Note
Les tâches Serverless ne peuvent pas appeler les types d’objets et les fonctions suivants :
Des UDFs (fonctions définies par l’utilisateur) qui contiennent du code Java ou Python.
Des procédures stockées écrites en Scala (en utilisant Snowpark), ou qui appellent des UDFs qui contiennent du code Java ou Python.
Astuce
Les tâches sans serveur prennent en charge l’utilisation de tables hybrides, mais vous risquez de ne pas bénéficier de performances ou d’une efficacité optimales lors de l’utilisation de tables hybrides.
Tâches gérées par l’utilisateur¶
Si vous préférez, vous pouvez également gérer les ressources de calcul pour des tâches individuelles en spécifiant un entrepôt virtuel existant lors de la création de la tâche. Cette option exige que vous choisissiez un entrepôt dont la taille est adaptée aux actions SQL exécutées par la tâche.
Sélection d’une taille d’entrepôt¶
Si vous choisissez d’utiliser les entrepôts existants pour fournir les ressources de calcul pour des tâches en particulier, nous vous recommandons de suivre les meilleures pratiques décrites dans Considérations relatives aux entrepôts. Nous vous suggérons d’analyser le temps d’exécution moyen d’une seule tâche ou d’un graphique de tâches à l’aide d’un entrepôt spécifique en fonction de la taille d’entrepôt et du clustering et du fait que l’entrepôt est partagé par plusieurs processus ou qu’il est dédié à l’exécution de cette seule tâche ou de ce graphique de tâches.
Interrogez la vue TASK_HISTORY Account Usage (dans la base de données partagée de SNOWFLAKE). La différence moyenne entre les heures planifiées et effectuées pour une tâche est la durée d’exécution moyenne attendue de la tâche, y compris toute période au cours de laquelle la tâche a été mise en file d’attente. Une tâche est mise en file d’attente lorsque d’autres processus utilisent actuellement toutes les ressources de calcul de l’entrepôt.
À moins que les instructions SQL définies pour les tâches puissent être optimisées (soit en réécrivant les instructions, soit en utilisant des procédures stockées), cela correspondrait au temps d’exécution moyen prévu pour la tâche ou le graphique de tâches. Sélectionnez la bonne taille pour l’entrepôt en fonction de votre analyse pour vous assurer que la tâche ou le graphique de tâches se termine dans cette fenêtre temporelle.
Le diagramme suivant montre une période de 1 minute au cours de laquelle une seule tâche a été mise en file d’attente pendant 20 secondes, puis exécutée pendant 40 secondes.
Le diagramme suivant montre un graphique de tâches qui nécessite en moyenne 5 minutes pour chaque exécution. Le diagramme montre la fenêtre temporelle pour 2 exécutions du graphique de tâches. Cette fenêtre temporelle est calculée à partir du moment où la tâche racine doit démarrer jusqu’à ce que la dernière tâche enfant du graphique de tâches soit terminée. Dans cet exemple, le graphique de tâches est partagé avec d’autres opérations simultanées qui se mettent en file d’attente pendant l’exécution de chacune des 3 tâches du graphique de tâches. Ces opérations simultanées consomment toutes les ressources disponibles lorsque chaque tâche du graphique de tâches termine son exécution et avant le démarrage de la tâche suivante. Par conséquent, la période de chaque tâche inclut une certaine quantité de files d’attente pendant qu’elle attend que d’autres opérations se terminent et abandonnent les ressources de calcul.
Notez que même si ce graphique de tâches s’exécutait sur un entrepôt dédié, un bref décalage serait attendu après la fin d’une tâche prédécesseuse et l’exécution de toute tâche enfant ; cependant, aucune file d’attente des ressources partagées avec d’autres opérations ne se produirait. La taille de l’entrepôt que vous choisissez doit être suffisamment grande pour accueillir plusieurs tâches enfants déclenchées simultanément par les tâches prédécesseurs.
Recommandations pour la sélection d’un modèle de calcul¶
Le tableau suivant décrit divers facteurs qui peuvent vous aider à décider quand utiliser des tâches sans serveur plutôt que des tâches gérées par l’utilisateur :
Catégorie |
Tâches sans serveur |
Tâches gérées par des utilisateurs |
Remarques |
---|---|---|---|
Nombre, durée et prévisibilité des charges de travail des tâches concurrentes |
Recommandé lorsque vous ne pouvez pas utiliser pleinement un entrepôt parce que trop peu de tâches sont exécutées simultanément ou qu’elles se terminent rapidement (en moins de 1 minute). Comme la taille des ressources de calcul choisies est basée sur l’historique des exécutions précédentes, les tâches dont l’exécution est relativement stable sont de bons candidats pour les tâches sans serveur. |
Recommandé lorsque vous pouvez utiliser pleinement un seul entrepôt en programmant plusieurs tâches simultanées pour tirer parti des ressources de calcul disponibles. Également recommandé pour les charges en dents de scie ou imprévisibles sur les ressources de calcul. Des entrepôts multi-clusters avec suspension et reprise automatiques activées pourraient aider à modérer votre consommation de crédit. |
Pour les tâches sans serveur, Snowflake facture votre compte en fonction de l’utilisation réelle des ressources de calcul. En revanche, la facturation des entrepôts gérés par les utilisateurs est basée sur la taille de l’entrepôt, avec un minimum de 60 secondes à chaque reprise de l’entrepôt, quelles que soient les ressources de calcul utilisées. |
Intervalle d’horaire |
Recommandé lorsque le respect de l’intervalle d’horaire est très important. Si l’exécution d’une tâche autonome ou d’un graphique de tâches planifié dépasse la quasi-totalité de cet intervalle, Snowflake augmente la taille des ressources de calcul (jusqu’à un maximum de l’équivalent d’un entrepôt 2X-Large). |
Recommandé lorsque le respect de l’intervalle d’horaire est moins important. |
L”intervalle d’horaire fait référence à l’intervalle de temps entre les exécutions planifiées successives d’une tâche autonome ou de la tâche racine d’un graphique de tâches. Notez que l’augmentation des ressources de calcul réduit le temps d’exécution de certains codes SQL, mais pas tous, et peut ne pas suffire à garantir l’exécution d’une tâche dans le délai de traitement par lots. |
Notez que la taille maximale d’une exécution de tâche sans serveur est équivalente à un entrepôt XXLARGE. Si la charge de travail d’une tâche nécessite un entrepôt plus grand, créez une tâche gérée par l’utilisateur qui fait référence à un entrepôt de la taille requise.
Planification des tâches¶
Une tâche autonome ou la tâche racine d’un graphique de tâches s’exécute généralement selon une planification. Vous pouvez définir le calendrier lors de la création d’une tâche (en utilisant CREATE TASK) ou plus tard (en utilisant ALTER TASK).
Snowflake garantit qu’une seule instance d’une tâche avec une planification (c’est-à-dire une tâche autonome ou la tâche racine d’un graphique de tâches) est exécutée à un moment donné. Si une tâche est toujours en cours d’exécution lors de la prochaine heure d’exécution planifiée, cette heure planifiée est ignorée.
Snowflake redimensionne et met automatiquement à l’échelle les ressources de calcul pour les tâches sans serveur. Pour les tâches qui dépendent d’un entrepôt pour fournir des ressources de calcul, choisissez une taille d’entrepôt appropriée pour une tâche donnée afin de compléter sa charge de travail dans la planification définie. Pour plus d’informations, voir Choisir une taille d’entrepôt (dans cette rubrique).
Planification des tâches et heure d’été¶
L’expression cron dans une définition de tâche prend en charge la spécification d’un fuseau horaire. Une tâche planifiée s’exécute selon l’expression cron spécifiée à l’heure locale pour un fuseau horaire donné. Un soin particulier doit être apporté aux tâches de planification pour les fuseaux horaires qui reconnaissent l’heure d’été. Les tâches planifiées à des heures précises les jours où la transition de l’heure standard à l’heure d’été (ou l’inverse) se produit peuvent avoir des comportements inattendus.
Par exemple :
En automne, de l’heure d’été à l’heure d’hiver, une tâche dont le démarrage est prévu à 1 AM dans le fuseau horaire Amérique/Los Angeles (c.-à-d.
0 1 * * * America/Los_Angeles
) est exécutée deux fois : une fois à 1 AM puis à nouveau lorsque 1:59:59 AM passe à 1:00:00 AM heure locale. C’est-à-dire qu’il y a deux moments où l’heure locale est 1 AM.Au printemps, lorsqu’on passe de l’heure d’hiver à l’heure d’été, une tâche programmée pour commencer à 2 AM dans le fuseau horaire Amérique/Los Angeles (c.-à-d.
0 2 * * * America/Los_Angeles
) ne s’exécute pas du tout, car l’heure locale passe de 1:59:59 AM à 3:00:00 AM. C’est-à-dire qu’il n’y a pas de moment durant ce jour où l’heure locale est 2 AM.
Pour éviter les exécutions de tâches inattendues dues à l’heure d’été, utilisez l’une des approches suivantes :
Ne planifiez pas l’exécution de tâches à une heure précise comprise entre 1 AM et 3 AM (tous les jours ou les jours de la semaine comprenant le dimanche), ou
Ajustez manuellement l’expression cron pour les tâches planifiées à ces heures deux fois par an afin de compenser le changement d’heure dû à l’heure d’été ou
Utilisez un format d’heure qui n’applique pas l’heure d’été, comme UTC.
Graphiques de tâches¶
Un graphique de tâches, ou graphe orienté acyclique (DAG) est une série de tâches composées d’une seule tâche racine et de tâches supplémentaires, organisées par leurs dépendances. Les DAGs circulent dans une seule direction, ce qui signifie qu’une tâche ultérieure dans la série ne peut pas déclencher l’exécution d’une tâche antérieure. Chaque tâche (à l’exception de la tâche racine) peut avoir plusieurs tâches prédécesseuses (dépendances). Chaque tâche peut également avoir plusieurs tâches ultérieures (enfants) qui dépendent d’elle. Une tâche ne s’exécute que lorsque tous les prédécesseurs ont été exécutés avec succès jusqu’à leur terme.
La tâche racine doit avoir une planification définie qui déclenche une exécution du graphique de tâches. Chacune des autres tâches a au moins un prédécesseur défini pour relier les tâches du graphique de tâches. Une tâche enfant ne s’exécute qu’une fois que toutes les tâches qui l’ont précédée ont été exécutées avec succès.
Vous pouvez spécifier les prédécesseurs lors de la création d’une nouvelle tâche (en utilisant CREATE TASK … AFTER) ou ultérieurement (en utilisant ALTER TASK … ADD AFTER). Un graphique de tâches est limité à un maximum de 1 000 tâches au total (tâche racine incluse). Une tâche unique peut avoir un maximum de 100 tâches prédécesseurs et 100 tâches enfants.
Vous pouvez afficher vos graphiques de tâches via SQL ou Snowsight. Pour afficher des graphiques de tâches dans Snowsight, voir Affichage des graphiques de tâches individuelles.
Dans l’exemple de base suivant, la tâche racine demande aux tâches B et C de s’exécuter simultanément. La tâche D s’exécute lorsque les tâches B et C ont terminé leur exécution.
L’exemple pratique suivant montre comment un graphique de tâches peut être utilisé pour mettre à jour les tables de dimensions dans une base de données commerciale avant d’agréger les données de faits :
Un autre exemple montre que la dernière tâche d’un graphique de tâches appelle une fonction externe pour déclencher un service de messagerie à distance afin d’envoyer une notification indiquant que toutes les tâches précédentes ont été correctement exécutées.
Propriété des tâches¶
Toutes les tâches d’un graphique de tâches doivent avoir le même propriétaire (c’est-à-dire qu’un seul rôle doit disposer du privilège OWNERSHIP sur toutes les tâches) et être stockées dans la même base de données et le même schéma.
Le transfert de propriété d’une tâche rompt la dépendance entre cette tâche et toute tâche prédécesseur et enfant. Pour plus d’informations, voir Lien rompu entre les tâches prédécesseur et enfant (dans cette rubrique).
Lorsque la propriété de toutes les tâches d’un graphique de tâches est transférée en même temps, via l’une des activités suivantes, les relations entre toutes les tâches du graphique de tâches sont conservées :
Le propriétaire actuel de toutes les tâches qui composent le graphique de tâches est supprimé (via DROP ROLE). La propriété des objets appartenant au rôle détruit est transférée au rôle qui exécute la commande DROP ROLE.
La propriété de toutes les tâches qui composent le graphique de tâches est explicitement transférée à un autre rôle (par exemple, via l’exécution de GRANT OWNERSHIP sur toutes les tâches d’un schéma).
Chevauchement d’exécutions de graphiques de tâches¶
Par défaut, Snowflake garantit qu’une seule instance d’un graphique de tâches donné est autorisée à s’exécuter à la fois. L’exécution suivante d’une tâche racine n’est programmée qu’à la fin de l’exécution de toutes les tâches du graphique de tâches. Cela signifie que si le temps cumulé nécessaire à l’exécution de toutes les tâches du graphique de tâches dépasse le temps explicitement planifié dans la définition de la tâche racine, au moins une exécution du graphique de tâche est ignorée. Le comportement est contrôlé par le paramètre ALLOW_OVERLAPPING_EXECUTION de la tâche racine ; la valeur par défaut est FALSE. Le fait de définir la valeur du paramètre sur TRUE permet le chevauchement des exécutions de graphiques de tâches.
En outre, une tâche enfant ne commence son exécution qu’après que toutes les tâches prédécesseurs de la tâche enfant ont terminé avec succès leur propre exécution. Une tâche qui exécute des opérations SQL à forte intensité de temps retarde le début de toute tâche enfant qui identifie la tâche comme prédécesseur.
Dans l’exemple suivant, l’exécution d’un graphique de tâches est planifiée pour démarrer lorsqu’une exécution précédente n’est pas encore terminée. La période de chevauchement, ou de concomitance, est identifiée en rouge. Le diagramme identifie également le laps de temps pendant lequel chaque tâche est mise en file d’attente avant d’être exécutée dans l’entrepôt géré par l’utilisateur. Notez que si vous utilisez des ressources de calcul sans serveur, il n’existe pas de période de mise en file d’attente :
Le chevauchement des exécutions peut être toléré (voire même souhaitable) lorsque les opérations de lecture/écriture SQL exécutées par les exécutions en chevauchement d’un graphique de tâches ne produisent pas de données incorrectes ou dupliquées. Cependant, pour les autres graphiques de tâches, les propriétaires des tâches (c’est-à-dire le rôle ayant le privilège OWNERSHIP sur toutes les tâches du graphique de tâches) doivent définir une planification appropriée sur la tâche racine et sélectionner une taille d’entrepôt appropriée (ou utiliser des ressources de calcul sans serveur) pour garantir qu’une instance du graphique de tâches se termine avant la planification suivante de la tâche racine.
Pour mieux aligner un graphique de tâches sur la planification définie dans la tâche racine :
Si possible, augmentez le temps de planification entre les exécutions de la tâche racine.
Vous pouvez envisager de modifier les tâches intenses en calculs pour utiliser des ressources de calcul sans serveur. Si la tâche repose sur des ressources de calcul gérées par l’utilisateur, augmentez la taille de l’entrepôt qui exécute des instructions SQL ou des procédures stockées volumineuses ou complexes dans le graphique de tâches.
Analysez les instructions SQL ou la procédure stockée exécutées par chaque tâche. Déterminer si du code peut être réécrit pour tirer parti du traitement parallèle.
Si aucune des solutions ci-dessus ne vous aide, voyez s’il est nécessaire d’autoriser des exécutions simultanées du graphique de tâches en définissant ALLOW_OVERLAPPING_EXECUTION = TRUE sur la tâche racine. Ce paramètre peut être défini lors de la création d’une tâche (à l’aide de CREATE TASK … ) ou après (à l’aide de ALTER TASK).
Affichage des tâches dépendantes dans un graphique de tâches¶
Pour afficher soit les tâches enfants directes d’une tâche racine, soit toutes les tâches d’un graphique de tâches :
- SQL:
Interrogez la fonction de table TASK_DEPENDENTS (dans Schéma d’information de Snowflake). Notez que pour récupérer toutes les tâches d’un graphique de tâches, il convient de saisir la tâche racine lors de l’appel de la fonction. Si vous saisissez une tâche enfant, la fonction renvoie les enfants (et les enfants de ces enfants, etc.) de la tâche spécifiée.
Exécutions de graphiques de tâches avec des tâches enfants suspendues¶
Lorsque la tâche racine est suspendue, vous pouvez reprendre ou suspendre toute tâche enfant en utilisant ALTER TASK … RESUME | SUSPEND. Il n’est pas nécessaire de reprendre les tâches enfant suspendues avant de reprendre la tâche racine.
Lorsqu’un graphique de tâches s’exécute avec une ou plusieurs tâches enfants suspendues, l’exécution ignore ces tâches. Une tâche enfant avec plusieurs prédécesseurs s’exécute tant que au moins un des prédécesseurs est dans un état de reprise, et que tous les prédécesseurs repris s’exécutent avec succès jusqu’à la fin.
Reprise des tâches suspendues d’un graphique de tâches¶
Pour reprendre récursivement toutes les tâches d’un graphique de tâches, interrogez la fonction SYSTEM$TASK_DEPENDENTS_ENABLE au lieu de reprendre chaque tâche individuellement (via ALTER TASK … RESUME).
Lien rompu entre des tâches prédécesseuses et enfants¶
Les dépendances entre les tâches d’un graphique de tâches peuvent être rompues à la suite de l’une des actions suivantes :
ALTER TASK … REMOVE AFTER et ALTER TASK … UNSET FINALIZE suppriment le lien entre la tâche cible et les tâches prédécesseuses spécifiées ou la tâche racine finalisée.
DROP TASK et GRANT OWNERSHIP rompent tous les liens de la tâche cible. Par exemple, la tâche racine A a une tâche enfant B, et la tâche B a une tâche enfant C. Si vous supprimez la tâche B, le lien entre les tâches A et B est rompu, de même que le lien entre les tâches B et C.
Si une combinaison des actions ci-dessus rompt la relation entre la tâche enfant et tous les prédécesseurs, l’ancienne tâche enfant devient soit une tâche autonome, soit une tâche racine, selon que les autres tâches identifient ou non la tâche comme leur prédécesseur.
Note
Lorsque vous effectuez l’opération GRANT OWNERSHIP
sur une tâche pour accorder la propriété de la tâche à son propriétaire actuel, les liens de dépendance ne peuvent pas être rompus.
Tâche de finalisation¶
Une tâche de finalisation gère la mise à disposition et le nettoyage des ressources utilisées par un graphique de tâches. L’exécution de la tâche de finalisation est garantie si le graphique de tâches est exécuté et assure un nettoyage correct des ressources et la réalisation des étapes nécessaires dans tous les scénarios. Par exemple, si une exécution de graphique de tâches utilise des tables intermédiaires pour suivre les données à traiter et échoue avant la consommation des lignes de la table, l’exécution suivante rencontrera des lignes en double et retraitera les données, ce qui allongera le temps d’exécution ou gaspillera des ressources de calcul. La tâche de finalisation peut résoudre ce problème en supprimant les lignes ou en tronquant la table, si nécessaire.
La tâche de finalisation fonctionne comme toute autre tâche d’un graphique de tâches, aux différences près suivantes :
Une tâche de finalisation est toujours associée à une tâche racine. Chaque tâche racine ne peut avoir qu’une seule tâche de finalisation, et une tâche de finalisation ne peut être associée qu’à une seule tâche racine.
Une tâche de finalisation n’est planifiée que si aucune autre tâche n’est en cours d’exécution ou en file d’attente dans l’exécution de graphique de tâches en cours, et si au moins une tâche du graphique a commencé à être exécutée. Si un graphe est ignoré (par exemple, la tâche racine est ignorée), la tâche de finalisation ne sera pas exécutée. Si la valeur ALLOW_OVERLAPPING_EXECUTION est définie sur true, la tâche de finalisation se comportera comme les autres tâches et continuera à être programmée, même s’il existe d’autres exécutions de graphiques de tâches en cours.
Une tâche de finalisation ne peut pas avoir de tâches enfants. Toute commande qui tente de faire de la tâche de finalisation un prédécesseur échouera. La création d’une tâche de finalisation doit inclure le mot-clé
FINALIZE
, qui est incompatible avec les mots-clésSCHEDULE
etAFTER
.
Pour créer une tâche de finalisation, créez une tâche à l’aide du mot-clé FINALIZE
et définissez une relation avec la tâche racine :
CREATE TASK <TASK_NAME> ...
... FINALIZE = <ROOT_TASK_NAME>
Pour plus d’informations, voir CREATE TASK.
Note
Dans Snowsight, une tâche de finalisation apparaît comme une tâche distincte avec son propre historique d’exécution et ses propres détails de configuration. La vue graphique d’une tâche ne montre pas la tâche de finalisation ou la relation entre la tâche racine et la tâche de finalisation.
Versionnage des exécutions¶
Lorsqu’une tâche autonome ou la tâche racine d’un graphique de tâches est reprise pour la première fois (ou exécutée manuellement via EXECUTE TASK), une version initiale de la tâche est définie. Si la tâche est une tâche racine, une version de l’ensemble du graphique de tâches, y compris toutes les propriétés de toutes les tâches du graphique de tâches, est définie. La tâche autonome ou le graphique de tâches s’exécute en utilisant cette version. Après la suspension et la modification d’une tâche, une nouvelle version est définie lorsque la tâche autonome ou racine est reprise ou exécutée manuellement.
Pour modifier ou recréer une tâche dans un graphique de tâches, il convient d’abord de suspendre la tâche racine (via ALTER TASK … SUSPEND). Lorsque la tâche racine est suspendue, toutes les futures exécutions planifiées de la tâche racine sont annulées ; cependant, si des tâches sont en cours d’exécution (c’est-à-dire, les tâches sont dans un état EXECUTING), ces tâches et toutes les tâches descendantes continuent de s’exécuter en utilisant la version actuelle.
Note
Si la définition d’une procédure stockée appelée par une tâche change pendant l’exécution du graphique de tâches, la nouvelle planification peut être exécutée lorsque la procédure stockée est appelée par la tâche lors de l’exécution en cours.
Par exemple, supposons que la tâche racine d’un graphique de tâches soit suspendue, mais qu’une exécution planifiée de cette tâche ait déjà commencé. Le propriétaire de toutes les tâches du graphique de tâches modifie le code SQL appelé par une tâche enfant pendant que la tâche racine est encore en cours d’exécution. La tâche enfant s’exécute et exécute le code SQL dans sa définition en utilisant la version du graphique de tâches qui existait lorsque la tâche racine a commencé son exécution. Lorsque la tâche racine est reprise ou est exécutée manuellement, une nouvelle version du graphique de tâches est définie. Cette nouvelle version inclut les modifications apportées à la tâche enfant.
Pour récupérer l’historique des versions de tâches, interrogez la vue TASK_VERSIONS Account Usage (dans la base de données partagée SNOWFLAKE).
Définition des paramètres de session des tâches¶
Vous pouvez définir les paramètres de session pour la session dans laquelle une tâche est exécutée. Pour ce faire, modifiez une tâche existante et définissez les valeurs de paramètres souhaitées (à l’aide de ALTER TASK … SET session_parameter = value[, session_parameter = value ... ]
).
Une tâche prend en charge tous les paramètres de session. Pour obtenir la liste complète, voir Paramètres.
Notez qu’une tâche ne prend pas en charge les paramètres de compte ou d’utilisateur.
Suspension automatique de tâches après des échecs d’exécution¶
Il est possible de suspendre automatiquement des tâches après un nombre spécifié d’exécutions consécutives qui échouent ou dont le délai est dépassé. Cette fonction peut réduire les coûts en suspendant les tâches qui consomment des crédits Snowflake, mais ne s’exécutent pas jusqu’à leur terme. Les exécutions de tâches qui ont échoué comprennent les exécutions dans lesquelles le code SQL dans le corps de la tâche produit une erreur de l’utilisateur ou expire. Les exécutions de tâches qui sont ignorées, annulées ou qui échouent en raison d’une erreur système sont considérées comme indéterminées et ne sont pas incluses dans le compte des exécutions de tâches qui ont échoué.
Définissez le paramètre SUSPEND_TASK_AFTER_NUM_FAILURES = num
sur une tâche autonome ou la tâche racine d’un graphique de tâches. Lorsque le paramètre est défini sur une valeur supérieure à 0
, le comportement suivant s’applique aux exécutions de la tâche autonome ou de la tâche racine d’un graphique de tâches :
Les tâches autonomes sont automatiquement suspendues après que le nombre spécifié d’exécutions consécutives de la tâche ait échoué ou ait expiré.
La tâche racine est automatiquement suspendue après l’échec consécutif ou l’expiration de délai consécutive de n’importe quelle tâche enfant du graphique de tâches le nombre de fois spécifié. La tâche enfant qui échoue ou dont le délai expire n’est pas suspendue.
Ce paramètre peut être défini lors de la création d’une tâche (à l’aide de CREATE TASK) ou après (à l’aide de ALTER TASK).
Le paramètre SUSPEND_TASK_AFTER_NUM_FAILURES peut également être défini au niveau du compte, de la base de données ou du schéma. Le paramètre s’applique à toutes les tâches autonomes ou racines contenues dans l’objet modifié. Notez que la définition explicite du paramètre à un niveau inférieur remplace la valeur de paramètre définie à un niveau supérieur.
Exécution manuelle des tâches¶
La commande EXECUTE TASK déclenche manuellement une seule exécution d’une tâche planifiée (soit une tâche autonome, soit la tâche racine d’un graphique de tâches), indépendamment de la planification définie pour la tâche. L’exécution réussie d’une tâche racine déclenche l’exécution en cascade des tâches enfants du graphique de tâches à mesure que leur tâche précédente se termine, comme si la tâche racine s’était exécutée selon sa planification définie.
Cette commande SQL est utile pour tester des tâches autonomes et des graphiques de tâches, nouveaux ou modifiés, avant de leur permettre d’exécuter du code SQL en production.
Appelez cette commande SQL directement dans les scripts ou dans les procédures stockées. En outre, cette commande prend en charge l’intégration de tâches dans des pipelines de données externes. Tous les services tiers qui peuvent s’authentifier dans votre compte Snowflake et autoriser des actions SQL peuvent exécuter la commande EXECUTE TASK pour exécuter des tâches.
Affichage de l’historique des tâches de votre compte¶
Vous pouvez voir l’historique des tâches de votre compte en utilisant SQL ou Snowsight. Pour voir l’historique des tâches dans Snowsight, référez-vous à Affichage de l’historique des tâches dans Snowsight.
Les rôles suivants (ou les rôles avec les privilèges spécifiés) peuvent utiliser SQL pour afficher l’historique des tâches dans une plage de dates spécifiée :
Administrateur de compte (c’est-à-dire les utilisateurs ayant le rôle ACCOUNTADMIN).
Propriétaire de la tâche (c.-à-d. rôle disposant du privilège OWNERSHIP sur une tâche).
Tout rôle disposant du privilège global MONITOR EXECUTION.
Pour visualiser l’historique d’exécution d’une seule tâche :
- SQL:
Interrogez la fonction de table TASK_HISTORY (dans Schéma d’information de Snowflake).
Pour afficher les détails de l’exécution d’un graphique de tâches qui est actuellement programmée ou en cours :
- SQL:
Interrogez la fonction de table CURRENT_TASK_GRAPHS (dans Schéma d’information de Snowflake).
Pour afficher l’historique des exécutions de graphiques de tâches qui se sont correctement effectuées, qui ont échoué ou qui ont été annulées au cours des 60 dernières minutes :
- SQL:
Interrogez la fonction de table COMPLETE_TASK_GRAPHS (dans Schéma d’information de Snowflake).
Interrogez la vue Vue COMPLETE_TASK_GRAPHS (dans Account Usage).
Coûts des tâches¶
Les coûts associés à l’exécution d’une tâche pour exécuter le code SQL diffèrent selon la source des ressources de calcul pour la tâche :
- Entrepôt géré par les utilisateurs
Snowflake facture votre compte pour l’utilisation du crédit en fonction de l’utilisation de l’entrepôt pendant l’exécution d’une tâche, de la même manière que l’utilisation de l’entrepôt pour l’exécution des mêmes instructions SQL dans un client ou dans l’interface Web de Snowflake. La facturation à la seconde et la suspension automatique du crédit vous permettent de commencer avec des tailles d’entrepôts plus grandes, puis d’ajuster la taille en fonction de vos charges de travail.
- Modèle de calcul sans serveur
Snowflake facture votre compte en fonction de l’utilisation réelle des ressources de calcul ; en revanche, les entrepôts virtuels gérés par le client, qui consomment des crédits lorsqu’ils sont actifs, peuvent rester inactifs ou être surutilisés. Les frais sont calculés sur la base de l’utilisation totale des ressources (y compris l’utilisation du service Cloud) mesurée en heures de calcul d’utilisation du crédit.
Snowflake analyse dynamiquement les exécutions de tâches dans l’historique des tâches afin de déterminer la taille idéale des ressources de calcul sans serveur, et suspend ces ressources de calcul pour économiser des coûts. Snowflake gère la capacité de charge, garantissant des ressources de calcul optimales pour répondre à la demande. Pour récupérer les coûts de gestion des ressources de calcul sans serveur, Snowflake applique un multiplicateur 1.2x à la consommation de ressources. Le modèle de calcul sans serveur peut encore réduire les coûts de calcul par rapport aux entrepôts gérés par l’utilisateur, dans certains cas de manière significative.
Pour savoir combien de crédits sont consommés par des tâches, reportez-vous au « Tableau des crédits de fonctionnalité sans serveur » dans le tableau de consommation des services Snowflake.
La facturation est similaire à d’autres fonctionnalités de Snowflake telles que le clustering automatique des tables, la réplication et le basculement/la restauration en cas d’échec, et Snowpipe.
Pour récupérer l’utilisation actuelle du crédit pour une tâche spécifique, interrogez la fonction de la table SERVERLESS_TASK_HISTORY. Exécutez l’instruction suivante en tant que propriétaire de tâche :
SET num_credits = (SELECT SUM(credits_used) FROM TABLE(<database_name>.information_schema.serverless_task_history( date_range_start=>dateadd(D, -1, current_timestamp()), date_range_end=>dateadd(D, 1, current_timestamp()), task_name => '<task_name>') ) );
Où :
<nom_base_de_données>
Nom de la base de données contenant la tâche.
<nom_tâche>
Nom de la tâche.
Pour récupérer l’utilisation actuelle du crédit pour toutes les tâches sans serveur, interrogez la vue SERVERLESS_TASK_HISTORY. Exécutez l’instruction suivante en tant qu’administrateur de compte :
SELECT start_time,
end_time,
task_id,
task_name,
credits_used,
schema_id,
schema_name,
database_id,
database_name
FROM snowflake.account_usage.serverless_task_history
ORDER BY start_time, task_id;
Comprendre le service système¶
Snowflake exécute des tâches avec les privilèges du propriétaire (c’est-à-dire le rôle disposant du privilège OWNERSHIP sur la tâche), mais les tâches exécutées ne sont pas associées à un utilisateur. Au lieu de cela, chaque exécution est effectuée par un service système. Les tâches sont découplées d’utilisateurs spécifiques pour éviter les complications pouvant survenir lorsque des utilisateurs sont détruits, verrouillés en raison de problèmes d’authentification, ou lorsque des rôles sont supprimés.
Les tâches s’exécutent avec les privilèges du propriétaire de la tâche, qu’elles soient planifiées ou exécutées manuellement par EXECUTE TASK par un autre rôle avec le privilège OPERATE.
Étant donné que les tâches exécutées sont découplées d’un utilisateur, l’historique des requêtes associées à ces tâches est associé au service système. SYSTEM n’est pas un utilisateur du compte ; c’est un service qui fonctionne en arrière-plan. En tant que tel, il n’existe aucune information d’identification d’utilisateur pour ce service, et aucune personne (de Snowflake ou de votre compte) ne peut assumer son identité. L’activité pour le service système est limitée à votre compte. Les mêmes protections de chiffrement et autres protocoles de sécurité sont intégrés à ce service comme c’est le cas pour d’autres opérations.
Tâche DDL¶
Pour faciliter la création et la gestion des tâches, Snowflake fournit l’ensemble suivant de commandes spéciales DDL :
De plus, les fournisseurs peuvent afficher, accorder ou révoquer l’accès aux objets de base de données nécessaires pour ELT en utilisant le DDL de contrôle d’accès standard suivant :
Fonctions des tâches¶
Pour prendre en charge la récupération d’informations sur les tâches, Snowflake fournit l’ensemble de fonctions SQL suivant :
Sécurité des tâches¶
Privilèges de contrôle d’accès¶
Création de tâches¶
La création de tâches nécessite un rôle avec au minimum les privilèges suivants :
Objet |
Privilège |
Remarques |
---|---|---|
Compte |
EXECUTE MANAGED TASK |
Obligatoire uniquement pour les tâches qui dépendent de ressources de calcul sans serveur. |
Base de données |
USAGE |
|
Schéma |
USAGE, CREATE TASK |
|
Entrepôt |
USAGE |
Requis uniquement pour les tâches qui dépendent des entrepôts gérés par l’utilisateur pour les ressources de calcul. |
Possession des tâches¶
Après la création d’une tâche, le propriétaire de la tâche doit disposer des privilèges suivants pour que la tâche puisse être exécutée :
Objet |
Privilège |
Remarques |
---|---|---|
Compte |
EXECUTE TASK |
Requis pour exécuter toutes les tâches du rôle. La révocation du privilège EXECUTE TASK sur un rôle empêche toutes les tâches suivantes de démarrer sous ce rôle. |
Compte |
EXECUTE MANAGED TASK |
Obligatoire uniquement pour les tâches qui dépendent de ressources de calcul sans serveur. |
Base de données |
USAGE |
|
Schéma |
USAGE |
|
Tâche |
OWNERSHIP |
|
Entrepôt |
USAGE |
Requis uniquement pour les tâches qui dépendent des entrepôts gérés par l’utilisateur pour les ressources de calcul. |
En outre, le rôle doit disposer des autorisations requises pour exécuter l’instruction SQL exécutée par la tâche.
Reprise ou suspension de tâches¶
En plus du propriétaire de la tâche, un rôle qui a le privilège OPERATE sur la tâche peut suspendre ou reprendre la tâche. Ce rôle doit avoir le privilège USAGE sur la base de données et le schéma qui contiennent la tâche. Aucun autre privilège n’est requis.
Lorsqu’une tâche est reprise, Snowflake vérifie que le rôle de propriétaire de la tâche a les privilèges énumérés dans Possession de tâches (dans cette rubrique).
Création d’un rôle d’administrateur de tâches¶
Pour faciliter l’utilisation, nous vous recommandons de créer un rôle personnalisé (par exemple, taskadmin
) et d’attribuer le privilège EXECUTE TASK à ce rôle. Tout rôle pouvant octroyer des privilèges (par exemple, SECURITYADMIN ou n’importe quel rôle disposant du privilège MANAGE GRANTS) peut ensuite attribuer ce rôle personnalisé à tout rôle de propriétaire de tâche afin de permettre la modification de ses propres tâches. Pour supprimer la possibilité pour le rôle de propriétaire de la tâche d’exécuter la tâche, il suffit de révoquer ce rôle personnalisé à partir du rôle de propriétaire de la tâche. Notez que si vous choisissez de ne pas créer ce rôle personnalisé, un administrateur de compte doit révoquer le privilège EXECUTE TASK du rôle de propriétaire de la tâche.
Par exemple, créez un nom de rôle personnalisé taskadmin
et accordez-lui le privilège EXECUTE TASK. Attribuez le rôle taskadmin
à un rôle de propriétaire de tâche nommé myrole
:
USE ROLE securityadmin;
CREATE ROLE taskadmin;
-- set the active role to ACCOUNTADMIN before granting the account-level privileges to the new role
USE ROLE accountadmin;
GRANT EXECUTE TASK, EXECUTE MANAGED TASK ON ACCOUNT TO ROLE taskadmin;
-- set the active role to SECURITYADMIN to show that this role can grant a role to another role
USE ROLE securityadmin;
GRANT ROLE taskadmin TO ROLE myrole;
Pour plus d’informations sur la création de rôles personnalisés et de hiérarchies de rôles, voir Configuration du contrôle d’accès.
Suppression d’un rôle de propriétaire de tâche¶
Lorsque le rôle de propriétaire d’une tâche donnée (c’est-à-dire le rôle doté du privilège OWNERSHIP sur la tâche) est supprimé, la tâche est « re-possédée » par le rôle qui a détruit le rôle du propriétaire. Cela garantit que la propriété passe à un rôle plus proche de la racine de la hiérarchie des rôles. Lorsqu’une tâche est ré-possédée, elle est automatiquement suspendue, c’est-à-dire que toutes les exécutions en cours de traitement sont en cours d’achèvement, mais les nouvelles exécutions ne seront pas programmées jusqu’à ce que la tâche soit reprise explicitement par le nouveau propriétaire. La raison est d’empêcher un utilisateur ayant accès à un rôle particulier de laisser des tâches qui s’exécutent soudainement avec des autorisations plus élevées lorsque le rôle est supprimé.
Si le rôle sous lequel une tâche est en cours d’exécution est détruit, alors que la tâche est toujours en cours d’exécution, la tâche termine le traitement sous le rôle détruit.
Workflow¶
Cette section fournit une vue d’ensemble de haut niveau sur le workflow de configuration des tâches.
Suivez les étapes décrites dans Création d’un rôle d’administrateur de tâche (dans cette rubrique) pour créer un rôle pouvant être utilisé pour exécuter les commandes au cours des étapes suivantes.
Créez une tâche en utilisant CREATE TASK. La tâche est suspendue par défaut.
Note
Vérifiez que l’instruction SQL à laquelle vous faites référence dans une tâche s’exécute comme prévu avant de créer la tâche. Les tâches sont destinées à automatiser les instructions SQL ou les procédures stockées qui ont déjà été testées de manière approfondie.
Exécutez ALTER TASK … RESUME pour permettre à la tâche de s’exécuter en fonction des paramètres spécifiés dans la définition de la tâche.