Introduction aux tâches¶

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 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 unique ou d’un DAG de tâches à 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 DAG).

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 le DAG). Choisissez la bonne taille pour l’entrepôt en fonction de votre analyse pour vous assurer que la tâche (ou le DAG) 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 un DAG qui nécessite en moyenne 5 minutes pour chaque exécution. Le diagramme montre la période pour 2 exécutions du DAG à 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 du DAG soit terminée. Dans cet exemple, le DAG 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 DAG. Ces opérations simultanées consomment toutes les ressources disponibles lorsque chaque tâche du DAG 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 DAG 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¶

Une tâche autonome ou la tâche racine d’un DAG 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 dans un DAG) 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).

DAG de tâches¶

Un 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 (c’est-à-dire une boucle). Chaque tâche (à l’exception de la tâche racine) peut avoir plusieurs tâches prédécesseurs (dépendances) ; de même, chaque tâche peut avoir plusieurs tâches suivantes (enfants) qui en dépendent. 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 un calendrier défini qui déclenche une exécution du DAG. Chacune des autres tâches a au moins un prédécesseur défini pour relier les tâches dans le DAG. 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 DAG est limité à un maximum de 1 000 tâches au total (y compris la tâche racine). Une tâche unique peut avoir un maximum de 100 tâches prédécesseurs et 100 tâches enfants.

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 DAG peut être utilisé pour mettre à jour les tables de dimensions dans une base de données de ventes avant d’agréger les données de faits :

Un autre exemple montre que la dernière tâche d’un DAG 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é exécutées avec succès.

DAG de chevauchement des exécutions¶

Par défaut, Snowflake garantit qu’une seule instance d’un DAG particulier est 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 du DAG. Cela signifie que si le temps cumulé nécessaire à l’exécution de toutes les tâches du DAG dépasse le temps explicitement prévu dans la définition de la tâche racine, au moins une exécution du DAG 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. Le fait de définir la valeur du paramètre sur TRUE permet aux exécutions de DAG de se chevaucher.

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 DAG 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’un DAG ne produisent pas de données incorrectes ou dupliquées. Cependant, pour les autres DAGs, les propriétaires des tâches (c’est-à-dire le rôle ayant le privilège OWNERSHIP sur toutes les tâches du DAG) 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 du DAG se termine avant la prochaine planification de la tâche racine.

Pour mieux aligner un DAG avec la planification définie dans la tâche racine :

1. Si possible, augmentez le temps de planification entre les exécutions de la tâche racine.

2. 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 le DAG.

3. 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 DAG 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).

CREATE TASK <TASK_NAME> ...
... FINALIZE = <ROOT_TASK_NAME>

Versionnage des exécutions¶

Lorsqu’une tâche autonome ou la tâche racine d’un DAG 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 du DAG, y compris toutes les propriétés de toutes les tâches du DAG, est définie. La tâche autonome ou le DAG 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 DAG, 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.

Par exemple, supposons que la tâche racine d’un DAG 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 dans le DAG 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 du DAG 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 du DAG 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 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 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.

Suspendre automatiquement les 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 dans un DAG. 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 dans le DAG :

• 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 de toute tâche unique dans un DAG ou après le nombre spécifié d’exécutions consécutives.

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). Ce paramètre s’applique aux tâches qui s’appuient sur des ressources informatiques gérées par Snowflake (c’est-à-dire le modèle de calcul sans serveur) ou sur des ressources informatiques gérées par l’utilisateur (c’est-à-dire un entrepôt virtuel).

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 (c’est-à-dire plus granulaire) remplace la valeur du 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 DAG) 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 DAG à 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 DAGs, 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 visualiser les détails de l’exécution d’un DAG qui est actuellement programmée ou en cours d’exécution :

SQL

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

Pour visualiser l’historique des exécutions de DAG qui se sont correctement exécutés, qui ont échoué ou qui ont été annulés 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.

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.

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 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>')
    )
  );

Copy

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.

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 :

• CREATE TASK

• ALTER TASK

• DROP TASK

• DESCRIBE TASK

• SHOW TASKS

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 :

• GRANT <privilèges>

• REVOKE <privilèges>

• SHOW GRANTS

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 :

• SYSTEM$CURRENT_USER_TASK_NAME

• TASK_HISTORY

• TASK_DEPENDENTS

Sécurité des tâches¶

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;

Workflow¶

Cette section fournit une vue d’ensemble de haut niveau sur le workflow de configuration des tâches.

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

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

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