Contrôle des coûts dans Snowflake

Cette rubrique traite des contrôles que vous pouvez utiliser pour limiter les dépenses liées à l’utilisation d’un entrepôt virtuel. Ces contrôles permettent de s’assurer que le coût réel de l’utilisation des entrepôts virtuels ne dépasse pas le coût prévu.

Ces contrôles ne s’appliquent pas aux services Cloud et aux fonctions sans serveur.

Dans ce chapitre :

Contrôler l’accès aux entrepôts virtuels

Le fait de définir soigneusement qui peut travailler avec des entrepôts virtuels et ce qu’ils peuvent faire avec ces entrepôts permet de contrôler les coûts en limitant l’utilisation des ressources de calcul aux entrepôts connus dont la configuration est rentable. Le contrôle d’accès granulaire de Snowflake vous permet d’accorder les privilèges suivants pour les entrepôts :

  • CREATE WAREHOUSE — Privilège global (c’est-à-dire accordé sur le compte) qui limite les rôles pouvant créer un nouvel entrepôt, ce qui vous permet de forcer les individus à utiliser des entrepôts existants qui ont des contrôles de coûts en place.

  • MODIFY — Privilège sur un entrepôt spécifique qui permet de modifier les paramètres qui affectent le coût, y compris le redimensionnement d’un entrepôt et la désactivation du paramètre de suspension automatique. Il arrive souvent que les utilisateurs augmentent la taille d’un entrepôt pour une charge de travail particulière, puis oublient de le ramener à sa taille initiale, ce qui peut avoir un effet important sur les coûts.

  • USAGE — Privilège sur un entrepôt spécifique qui permet d’activer l’entrepôt pour fournir des ressources de calcul pour les requêtes et autres actions SQL. En attribuant soigneusement ce privilège, on s’assure que les utilisateurs ne peuvent utiliser que des entrepôts dont la taille et la configuration sont adaptées à leurs charges de travail.

Centraliser la responsabilité de la création et de la mise à l’échelle des entrepôts à quelques membres de votre équipe est considéré comme une bonne pratique. Vous pouvez créer un rôle dédié avec des autorisations pour créer et modifier tous les entrepôts, puis accorder ce rôle à un nombre limité d’utilisateurs. Cela vous permet de contrôler vos politiques relatives aux entrepôts et d’éviter les dépassements de coûts accidentels résultant de la création ou de l’agrandissement inopiné d’entrepôts.

Astuce

Si vous souhaitez pouvoir faire évoluer un entrepôt pour gérer des charges de travail plus exigeantes, mais que vous ne voulez pas donner aux utilisateurs la possibilité d’augmenter la taille d’un entrepôt parce qu’ils pourraient oublier de le redimensionner plus tard, envisagez d’utiliser un entrepôt multi-clusters. Un entrepôt multi-clusters évolue automatiquement en fonction des fluctuations de la charge de travail.

Pour une liste de tous les privilèges qui peuvent être définis pour un entrepôt, voir Privilèges de l’entrepôt virtuel.

Choix de la meilleure taille d’entrepôt

La taille d’un entrepôt détermine le nombre maximum de crédits qui peuvent être dépensés en une heure. Par exemple, un petit entrepôt ne peut consommer plus de 2 crédits par heure. Pour une liste complète des tailles d’entrepôts ainsi que le nombre maximum de crédits qu’ils consomment, voir Aperçu des entrepôts.

Une bonne pratique de contrôle des coûts consiste à utiliser différents entrepôts pour différentes charges de travail, ce qui vous permet de choisir une taille adaptée à chaque charge de travail. Si vous n’êtes pas sûr de la taille optimale de l’entrepôt, commencez par une taille plus petite et augmentez-la progressivement en fonction des performances de la charge de travail et de son SLA.

Pour plus d’informations sur le choix de l’entrepôt approprié pour une charge de travail, voir Gestion des ressources de calcul Snowflake (article de blog Snowflake).

Limiter les délais d’interrogation

Les requêtes suspendues consomment des crédits excessifs parce qu’elles sont plus longues que prévu. Pour éviter les coûts excessifs associés à une requête qui s’emballe, vous pouvez définir le paramètre STATEMENT_TIMEOUT_IN_SECONDS pour déterminer la durée maximale d’exécution d’une instruction SQL avant son annulation.

Le paramètre STATEMENT_TIMEOUT_IN_SECONDS peut être défini pour un compte entier, un utilisateur, une session ou un entrepôt spécifique. Ainsi, vous pouvez définir avec soin des limites de temps qui correspondent aux durées d’exécution prévues pour diverses charges de travail. Ce paramètre est défini par défaut au niveau du compte. Lorsque le paramètre est défini pour un entrepôt en plus de la session, la valeur non nulle la plus basse est appliquée.

Utilisez les commandes suivantes pour afficher les limites de temps actuelles des requêtes :

SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN ACCOUNT;
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN USER <username>;
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN SESSION;
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN WAREHOUSE <warehouse_name>;

Si vous devez ajuster les limites de temps, utilisez l’une des commandes suivantes :

ALTER ACCOUNT SET STATEMENT_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER USER <username> SET STATEMENT_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER WAREHOUSE <warehouse_name> SET STATEMENT_TIMEOUT_IN_SECONDS = <number_of_seconds>;

Limiter les temps d’attente des instructions

Les instructions SQL qui sont dans une file d’attente pour utiliser un entrepôt ne consomment pas de crédits. Toutefois, si une requête reste trop longtemps dans la file d’attente, elle peut ne plus être pertinente au moment de son exécution. L’exécution d’une requête qui n’est plus pertinente gaspille des crédits. Vous pouvez donc mettre en place un contrôle des coûts en fixant une durée maximale pendant laquelle une instruction SQL peut être mise en attente avant d’être annulée.

Le paramètre qui contrôle la durée pendant laquelle une instruction SQL reste dans la file d’attente est STATEMENT_QUEUED_TIMEOUT_IN_SECONDS. Ce paramètre peut être défini pour un compte, un utilisateur, une session ou un entrepôt spécifique dans son intégralité. Ce paramètre est défini par défaut au niveau du compte. Lorsque le paramètre est défini pour un entrepôt en plus de la session, la valeur non nulle la plus basse est appliquée.

Utilisez les commandes suivantes pour afficher les limites de temps actuelles des files d’attente :

SHOW PARAMETERS LIKE 'STATEMENT_QUEUED_TIMEOUT_IN_SECONDS' IN ACCOUNT;
SHOW PARAMETERS LIKE 'STATEMENT_QUEUED_TIMEOUT_IN_SECONDS' IN USER <username>;
SHOW PARAMETERS LIKE 'STATEMENT_QUEUED_TIMEOUT_IN_SECONDS' IN SESSION;
SHOW PARAMETERS LIKE 'STATEMENT_QUEUED_TIMEOUT_IN_SECONDS' IN WAREHOUSE <warehouse_name>;

Si vous devez ajuster les limites de temps, utilisez l’une des commandes suivantes :

ALTER ACCOUNT SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER USER <username> SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER SESSION SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;
ALTER WAREHOUSE <warehouse_name> SET STATEMENT_QUEUED_TIMEOUT_IN_SECONDS = <number_of_seconds>;

Utiliser la suspension automatique

Par défaut, tous les entrepôts ont le paramètre de suspension automatique activé, ce qui signifie qu’un entrepôt s’arrête automatiquement lorsqu’il est inactif pendant une période définie. Un entrepôt suspendu ne consomme pas de crédits, de sorte que l’entrepôt ne subit des coûts que lorsqu’il traite une charge de travail.

En empêchant les utilisateurs de désactiver le paramètre de suspension automatique, on évite qu’un entrepôt non utilisé ne gaspille des crédits. Vous pouvez utiliser le contrôle d’accès pour permettre à quelqu’un d’utiliser un entrepôt mais aussi pour l’empêcher de modifier son paramètre de suspension automatique.

Requête : trouver des entrepôts sans suspension automatique

Utilisez la requête suivante pour vérifier périodiquement si le paramètre de suspension automatique a été désactivé pour tout entrepôt.

SHOW WAREHOUSES
;
SELECT "name" AS WAREHOUSE_NAME
      ,"size" AS WAREHOUSE_SIZE
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE IFNULL("auto_suspend",0) = 0
;

Pour activer la suspension automatique pour les entrepôts qui l’ont désactivée, ouvrez Snowsight, the Snowflake web interface, et naviguez vers Admin » Warehouses. Vous pouvez également utiliser le paramètre AUTO_SUSPEND de la commande ALTER WAREHOUSE.

Utilisation de la reprise automatique avec la suspension automatique

En général, chaque entrepôt dont la suspension automatique est activée doit également avoir la reprise automatique activée. La combinaison de ces deux paramètres permet d’arrêter et de démarrer un entrepôt automatiquement en fonction des fluctuations de la charge de travail de l’entrepôt.

Requête : trouver des entrepôts sans reprise automatique

La requête suivante liste les entrepôts qui n’ont pas activé la reprise automatique, ce qui vous permet de savoir lesquels doivent être modifiés.

SHOW WAREHOUSES
;
SELECT "name" AS WAREHOUSE_NAME
      ,"size" AS WAREHOUSE_SIZE
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE "auto_resume" = 'false'
;

Pour activer la reprise automatique pour les entrepôts qui l’ont désactivée, ouvrez Snowsight, the Snowflake web interface, et naviguez vers Admin » Warehouses. Vous pouvez également utiliser le paramètre AUTO_RESUME de la commande ALTER WAREHOUSE.

Appliquer les limites de dépenses

Les moniteurs de ressources permettent de fixer des limites aux crédits consommés par un entrepôt pendant un intervalle de temps ou une plage de dates spécifiques. Cela peut contribuer à éviter que les entrepôts ne consomment involontairement plus de crédits que prévu.

Parfois, un moniteur de ressources notifie simplement un administrateur lorsqu’une limite de crédit est atteinte, mais vous pouvez également forcer une limite en configurant un moniteur de ressources pour qu’il suspende un entrepôt dès que la limite est atteinte. Il existe deux options pour appliquer une limite : suspendre l’entrepôt une fois que les instructions en attente sont exécutées ou suspendre immédiatement sans attendre la fin des instructions.

Comme un seul moniteur de ressources peut être défini pour plusieurs entrepôts ou pour un compte entier, vous pouvez effectivement suspendre plusieurs entrepôts lorsqu’une limite de dépenses globale est atteinte. Un entrepôt peut être affecté à son propre moniteur de ressources et à un moniteur de ressources spécifique au compte en même temps ; l’entrepôt est suspendu lorsque l’une ou l’autre des limites de crédit est atteinte.

Pour plus de détails sur la suspension des entrepôts lorsque les limites de dépenses sont atteintes, voir Travailler avec des moniteurs de ressources.

Requête : trouver des entrepôts sans moniteurs de ressources

La requête suivante liste les entrepôts qui n’ont pas été affectés à un moniteur de ressources spécifique à l’entrepôt, ce qui les rend vulnérables à l’emballement des coûts. Notez que même s’il existe un moniteur de ressources au niveau du compte, cette requête renvoie toujours les entrepôts qui n’ont pas de moniteur spécifique à l’entrepôt dans ce compte.

SHOW WAREHOUSES
;
SELECT "name" AS WAREHOUSE_NAME
      ,"size" AS WAREHOUSE_SIZE
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE "resource_monitor" = 'null'
;

Note

La couche de services Cloud de l’architecture Snowflake peut encore encourir de faibles frais si des requêtes sont exécutées sur un entrepôt qui a été suspendu par un moniteur de ressources.