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 utilisant 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
- Tâches sans serveur
- Tâches gérées par des utilisateurs
  - Choix d’une taille d’entrepôt
Planification des tâches
- Planification des tâches et heure d’été
Arborescence simple de tâches
Versionnage des exécutions
Définition des paramètres de session pour les tâches
Exécution manuelle des tâches
Affichage de l’historique des tâches de votre compte
Facturation des exécutions de tâches
Compréhension du service système
Tâche DDL
Fonctions de tâche
Sécurité des tâches
Workflow

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 :

Géré par Snowflake (c’est-à-dire tâches sans serveur)
Géré par des utilisateurs (c’est-à-dire un entrepôt virtuel)

Tâches sans serveur¶

Note

Les tâches sans serveur sont prises en charge en tant que fonctionnalité en avant-première.

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 sont automatiquement redimensionnées et augmentées ou diminuées par Snowflake en fonction des besoins pour chaque charge de travail. Snowflake détermine la taille idéale des ressources de calcul pour une exécution donnée en se basant sur une analyse dynamique des statistiques des exécutions précédentes les plus récentes de la même tâche.

L’option permettant d’activer les tâches de calcul sans serveur doit être spécifiée lors de la création d’une tâche. La syntaxe CREATE TASK est presque identique aux tâches qui reposent sur des entrepôts virtuels gérés par l’utilisateur. Omettez le paramètre WAREHOUSE pour permettre à Snowflake de gérer les ressources de calcul pour la tâche. 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 quelque peu du modèle standard de consommation de crédits pour les tâches qui s’appuient sur des entrepôts pour les ressources de calcul. Pour plus d’informations, voir Facturation des exécutions de tâches.

Note

Les tâches Serverless ne peuvent pas appeler les types d’objets suivants :

UDFs (fonctions définies par l’utilisateur) qui contiennent du code Java.
Procédures stockées écrites en Scala (en utilisant Snowpark), ou qui appellent des UDFs qui contiennent du code Java.

Tâches gérées par des utilisateurs¶

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.

Choix 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 Remarques sur les entrepôts virtuels. Nous vous suggérons d’analyser le temps d’exécution moyen d’une tâche ou d’une arborescence de tâches donnée à l’aide d’un entrepôt spécifique en fonction de la taille de l’entrepôt et du clustering, ainsi que de savoir si l’entrepôt est partagé par plusieurs processus ou est dédié à l’exécution de cette tâche unique (ou arborescence 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 serait le temps d’exécution moyen attendu pour la tâche (ou l’arborescence des tâches). Choisissez la bonne taille pour l’entrepôt en fonction de votre analyse pour vous assurer que la tâche (ou l’arborescence des tâches) se termine dans cette période.

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 une arborescence de tâches qui nécessite en moyenne 5 minutes pour chaque exécution. Le diagramme montre la période pour 2 exécutions de l’arborescence des tâches à terminer. Cette fenêtre est calculée à partir du moment où la tâche racine doit démarrer jusqu’à ce que la dernière tâche enfant de l’arborescence soit terminée. Dans cet exemple, l’arborescence des tâches est partagée avec d’autres opérations simultanées qui se mettent en file d’attente pendant l’exécution de chacune des 3 tâches de l’arborescence. Ces opérations simultanées consomment toutes les ressources disponibles lorsque chaque tâche de l’arborescence 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 cette arborescence 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écesseur et l’exécution de toute tâche enfant ; cependant, aucune file d’attente pour les 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.

Planification des tâches¶

Aucune source d’événement ne peut déclencher une tâche. En revanche, une tâche s’exécute selon un planning, qui peut être défini lors de la création d’une tâche (avec CREATE TASK) ou d’une version ultérieure (avec 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 dans une arborescence 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é, voici deux possibilités :

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é.

Arborescence simple de tâches¶

Les utilisateurs peuvent définir une structure simple en forme d’arborescence de tâches qui commence par une tâche racine et présente des dépendances de tâches. L’implémentation actuelle prend en charge un seul chemin entre deux nœuds quelconques ; c’est-à-dire qu’une tâche individuelle ne peut avoir qu’un seul prédécesseur (une tâche parent). Cela diffère d’une structure de graphe acyclique dirigé (DAG), dans laquelle un seul nœud peut avoir plusieurs prédécesseurs.

Un prédécesseur peut être défini lors de la création d’une tâche (à l’aide de CREATE TASK … AFTER) ou après (à l’aide de ALTER TASK … ADD AFTER). La tâche racine dans l’arborescence devrait avoir une planification définie, tandis que chacune des autres tâches de l’arborescence a un prédécesseur défini pour les lier ensemble. Lorsqu’une exécution d’un prédécesseur se termine correctement, elle déclenche l’exécution de toutes les tâches enfants qui identifient cette tâche comme prédécesseur dans leur définition.

Une arborescence simple de tâches est limitée à un maximum de 1 000 tâches au total (y compris la tâche racine). Une tâche individuelle dans l’arborescence est limitée à un seul prédécesseur ; cependant, une tâche peut comporter un maximum de 100 tâches enfants (c’est-à-dire d’autres tâches identifiant la tâche en tant que prédécesseur).

Note

Un bref décalage survient après l’exécution d’une tâche prédécesseur et l’exécution de toute tâche enfant.

Pour reprendre de manière récursive toutes les tâches dépendantes liées à une tâche racine, interrogez la fonction SYSTEM$TASK_DEPENDENTS_ENABLE plutôt que de reprendre chaque tâche individuellement (à l’aide de ALTER TASK … RESUME).

Arborescence simple des tâches et propriété des tâches¶

Toutes les tâches d’une arborescence simple 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 de l’arborescence) et être stockées dans les mêmes base de données et schéma.

Lorsque la propriété de toutes les tâches dans une arborescence de tâches est transférée en même temps, via l’une des activités suivantes, les liens entre toutes les tâches de l’arborescence sont conservés :

Le propriétaire actuel de toutes les tâches qui composent l’arborescence des tâches est détruit (à l’aide de 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 l’arborescence des tâches est explicitement transférée vers un autre rôle (par exemple, en exécutant GRANT OWNERSHIP sur toutes les tâches d’un schéma).

Arborescence de chevauchement des exécutions de tâches¶

Par défaut, Snowflake veille à ce qu’une seule instance d’une arborescence de tâches particulière soit autorisée à fonctionner à la fois. La prochaine exécution d’une tâche root n’est programmée qu’après la fin de l’exécution de toutes les tâches enfants de l’arborescence. Cela signifie que si le temps cumulé nécessaire à l’exécution de toutes les tâches de l’arborescence dépasse le temps explicitement prévu dans la définition de la tâche root, au moins une exécution de l’arborescence des tâches est sauté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.

Dans l’exemple suivant, l’exécution d’une arborescence des tâches est programmé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 des ressources de calcul gérées par Snowflake sont utilisées, il n’y a pas de période d’attente :

Le chevauchement des exécutions peut être toléré (ou même souhaitable) lorsque les opérations de lecture/écriture SQL exécutées par des exécutions chevauchantes d’une arborescence de tâches ne produisent pas de données incorrectes ou dupliquées. Cependant, pour les autres arborescences, les propriétaires des tâches (c’est-à-dire le rôle ayant le privilège OWNERSHIP sur toutes les tâches de l’arborescence) doivent définir une planification appropriée sur la tâche racine et choisir une taille d’entrepôt appropriée (ou utiliser des ressources de calcul gérées par Snowflake) pour garantir qu’une instance de l’arborescence de tâches se termine avant la prochaine planification de la tâche racine.

Pour mieux aligner une arborescence de tâches avec le planning défini dans la tâche racine :

Si possible, augmentez le temps de planification entre les exécutions de la tâche racine.
Envisagez de modifier les tâches à forte intensité de calcul pour utiliser des ressources de calcul gérées par Snowflake. 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 importantes ou complexes dans l’arborescence des 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 de l’arborescence 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).

Rupture du lien entre les tâches prédécesseur et enfant¶

Si le prédécesseur d’une tâche enfant est supprimé (à l’aide de ALTER TASK … REMOVE AFTER), l’ancienne tâche enfant devient alors une tâche autonome ou une tâche racine, selon que d’autres tâches identifient cette ancienne tâche enfant comme leur prédécesseur.

Si une tâche prédécesseur est détruite (à l’aide de DROP TASK), ou si la propriété d’une tâche prédécesseur est transférée à un autre rôle (à l’aide de GRANT OWNERSHIP), toutes les anciennes tâches enfants qui ont identifié cette tâche comme prédécesseur deviennent des tâches autonomes ou racines selon que d’autres tâches identifient ces anciennes tâches enfants comme leur prédécesseur.

Versionnage des exécutions¶

Lorsqu’une tâche autonome ou la tâche racine d’une arborescence est reprise pour la première fois (ou exécutée manuellement à l’aide de EXECUTE TASK), une version initiale de la tâche est définie. Si la tâche est une tâche racine, alors une version de l’ensemble de l’arborescence des tâches, y compris toutes les propriétés de toutes les tâches de l’arborescence, est définie. La tâche autonome ou l’arborescence 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 une arborescence de tâches, la tâche racine doit d’abord être suspendue (en utilisant 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 de l’arborescence des tâches, la nouvelle programmation 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 arbre de tâches soit suspendue, mais qu’une exécution planifiée de cette tâche ait déjà commencé. Le propriétaire de l’arborescence modifie le code SQL appelé par une tâche enfant pendant que la tâche racine est toujours 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 de l’arborescence de tâches qui était actuelle 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 de l’arborescence de tâches est définie. Cette nouvelle version inclut les modifications apportées à la tâche enfant.

Définition des paramètres de session pour les 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 paramètre_session = valeur[, paramètre_session = valeur ... ]).

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.

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’une arborescence 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 de l’arborescence à 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 arborescences de tâches, nouvelles ou modifiées, 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.

Note

Les tâches sans serveur sont prises en charge en tant que fonctionnalité en avant-première.

Affichage de l’historique des tâches de votre compte¶

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 afficher l’historique des tâches :

SQL

Interrogez la fonction de table TASK_HISTORY (dans Schéma d’information de Snowflake).

Facturation des exécutions de 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.

Ressources gérées par Snowflake (c’est-à-dire 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, 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 rattraper les coûts de gestion des ressources de calcul fournies par Snowflake, nous appliquons un multiplicateur 1.5x à la consommation des ressources. Il convient toutefois de noter que le modèle de calcul sans serveur pourrait 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.

Les crédits Snowflake sont facturés par heure de calcul :

Ressources de calcul gérées par Snowflake : 1,5
Services Cloud : 1

La facturation est similaire à d’autres fonctionnalités de Snowflake telles que le clustering automatique des tables, la réplication des bases de données 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 la tâche (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur la 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 les instructions suivantes en tant qu’administrateur de compte (c’est-à-dire un utilisateur avec le rôle ACCOUNTADMIN) :

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;

Compréhension du 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.

É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 de tâche¶

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	Requis uniquement pour les tâches qui dépendent des ressources de calcul gérées par Snowflake (tâches 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 de tâches¶

Après la création d’une tâche, le propriétaire de la tâche (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur la tâche) doit avoir les privilèges suivants :

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	Requis uniquement pour les tâches qui dépendent des ressources de calcul gérées par Snowflake.
Base de données	USAGE
Schéma	USAGE
Tâche	OWNERSHIP
Entrepôt	USAGE

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 des 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âche¶

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.

Destruction 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.