Aperçu des entrepôts

Des entrepôts sont requis pour les requêtes, ainsi que pour toutes les opérations DML, y compris le chargement de données dans des tables. Un entrepôt est défini par sa taille, ainsi que par les autres propriétés qui peuvent être définies pour aider à contrôler et automatiser l’activité de l’entrepôt.

Les entrepôts peuvent être démarrés et arrêtés à tout moment. Ils peuvent également être redimensionnés à tout moment, même en cours d’exécution, pour s’adapter aux besoins en ressources de calcul en fonction de la nature des opérations effectuées par l’entrepôt.

Dans ce chapitre :

Taille d’entrepôt

La taille spécifie le nombre de serveurs qui composent chaque cluster dans un entrepôt. Snowflake prend en charge les tailles d’entrepôt suivantes :

Taille d’entrepôt

Serveurs / clusters

Crédits / Heure

Crédits / Seconde

Remarques

X-Small

1

1

0,0003

Taille par défaut des entrepôts créés à l’aide de CREATE WAREHOUSE.

Small

2

2

0,0006

Medium

4

4

0,0011

Large

8

8

0,0022

X-Large

16

16

0,0044

Valeur par défaut pour les entrepôts créés dans l’interface Web.

2X-Large

32

32

0,0089

3X-Large

64

64

0,0178

4X-Large

128

128

0,0356

Conséquences sur l’utilisation du crédit et la facturation

Comme l’illustre la table ci-dessus, il existe une correspondance une à une entre le nombre de serveurs dans un cluster d’entrepôt et le nombre de crédits consommés par le cluster (et qui sont donc facturés) pour chaque heure complète de fonctionnement de l’entrepôt. Cependant, notez que Snowflake emploie une facturation à la seconde (avec un minimum de 60 secondes à chaque fois que l’entrepôt démarre). Ainsi, les entrepôts sont uniquement facturés pour les crédits réellement consommés.

Le nombre total de crédits facturés dépend de la durée de fonctionnement continu de l’entrepôt. À des fins de comparaison, le tableau ci-dessous présente les totaux de facturation de trois entrepôts de tailles différentes en fonction de leur durée d’exécution (arrondis au millième le plus proche) :

Délai d’exécution

Crédits . (X-Small)

Crédits . (X-Large)

Crédits . (3X-Large)

0-60 secondes

0,017

0,267

1,067

61 secondes

0,017

0,271

1,084

2 minutes

0,033

0,533

2,133

10 minutes

0,167

2,667

10,667

1 heure

1,000

16,000

64,000

Note

Pour un entrepôt multi-clusters, le nombre de crédits facturés est calculé en fonction du nombre de serveurs par cluster et du nombre de clusters exécutés sur la période.

Par exemple, si un entrepôt multi-clusters 3X-Large exécute 1 cluster pendant une heure complète et exécute ensuite 2 clusters durant l’heure suivante complète, le nombre total de crédits facturés serait de 192 (c-à-d. 64 + 128).

Les entrepôts multi-clusters constituent une fonctionnalité Enterprise Edition.

Impact sur le chargement des données

L’augmentation de la taille d’un entrepôt n’améliore pas toujours les performances de chargement des données. Les performances de chargement des données sont davantage influencées par le nombre de fichiers chargés (et la taille de chaque fichier) que par la taille de l’entrepôt.

Astuce

À moins que vous ne chargiez en bloc un grand nombre de fichiers simultanément (c.-à-d. des centaines ou des milliers de fichiers), un entrepôt plus petit (petit, moyen, grand) suffit généralement. L’utilisation d’un entrepôt plus grand (X-Large, 2X-Large, etc.) consomme plus de crédits et n’entraîne pas systématiquement une augmentation des performances.

Pour plus de conseils et d’instructions sur le chargement des données, voir Remarques relatives au chargement des données.

Conséquences sur le traitement des requêtes

La taille d’un entrepôt peut avoir des conséquences sur le temps nécessaire pour exécuter les requêtes soumises à l’entrepôt, en particulier pour les requêtes plus grandes et plus complexes. En général, les performances des requêtes évoluent linéairement en fonction de la taille de l’entrepôt, car des ressources de calcul supplémentaires sont mises à disposition à chaque augmentation de la taille.

Si les requêtes traitées par un entrepôt fonctionnent lentement, vous pouvez toujours redimensionner l’entrepôt pour alimenter davantage de serveurs. Les serveurs supplémentaires n’ont aucune conséquence sur les requêtes déjà en cours d’exécution, mais ils sont disponibles pour les requêtes qui sont en file d’attente ou venant d’être soumises.

Astuce

Un entrepôt plus grand n’est pas nécessairement plus rapide pour les petites requêtes basiques.

Pour obtenir d’autres conseils et lignes directrices sur les entrepôts, consultez Remarques sur les entrepôts virtuels.

Suspension et reprise automatiques

Un entrepôt peut être configuré de sorte à reprendre ou s’arrêter automatiquement en fonction de l’activité :

  • Par défaut, la suspension automatique est activée. Snowflake suspend automatiquement l’entrepôt s’il est inactif pendant la période spécifiée.

  • Par défaut, la reprise automatique est activée. Snowflake reprend automatiquement l’entrepôt lorsqu’une instruction nécessitant un entrepôt est soumise et que l’entrepôt est l’entrepôt actuel pour la session.

Ces propriétés peuvent être utilisées pour simplifier et automatiser la surveillance et l’utilisation de vos entrepôts afin de les adapter à votre charge de travail. La suspension automatique garantit que vous ne laissez pas un entrepôt en fonctionnement (et ne consommez pas de crédits) lorsqu’il n’y a pas de requêtes entrantes. De même, la reprise automatique assure que l’entrepôt redémarre dès que cela est nécessaire.

Note

La suspension automatique et la reprise automatique ne s’appliquent qu’à l’ensemble de l’entrepôt, et non aux clusters individuels de l’entrepôt. Pour un entrepôt multi-clusters :

  • La suspension automatique ne se produit que lorsque le nombre minimum de clusters est en cours d’exécution et qu’il n’y a aucune activité pendant la période spécifiée. Le minimum est généralement de 1 (cluster), mais peut être supérieur à 1.

  • La reprise automatique ne s’applique que lorsque l’ensemble de l’entrepôt est suspendu (c’est-à-dire qu’aucun cluster n’est en cours d’exécution).

Traitement et simultanéité des requêtes

Le nombre de requêtes qu’un entrepôt peut traiter simultanément est déterminé par la taille et la complexité de chaque requête. Au fur et à mesure que les requêtes sont soumises, l’entrepôt calcule et réserve les ressources de calcul nécessaires au traitement de chaque requête. Si l’entrepôt n’a pas suffisamment de ressources restantes pour traiter une requête, celle-ci est mise en file d’attente en attendant que les ressources disponibles soient disponibles au fur et à mesure que les autres requêtes en cours aboutissent.

Snowflake fournit quelques paramètres au niveau de l’objet qui peuvent être réglés pour aider à contrôler le traitement et la simultanéité des requêtes :

Note

Si un trop grand nombre de requêtes sont mises en file d’attente, un autre entrepôt peut être créé et les requêtes peuvent être redirigées manuellement vers le nouvel entrepôt. En outre, le redimensionnement d’un entrepôt peut permettre une mise à l’échelle limitée pour la simultanéité et la mise en file d’attente des requêtes. Toutefois, le redimensionnement de l’entrepôt est principalement destiné à améliorer les performances des requêtes.

Pour permettre une mise à l’échelle entièrement automatisée pour la simultanéité, Snowflake recommande les entrepôts multi-clusters qui offrent essentiellement les mêmes avantages que la création d’entrepôts supplémentaires et la redirection des requêtes, mais sans nécessiter une intervention manuelle.

Les entrepôts multi-clusters constituent une fonctionnalité Enterprise Edition.

Utilisation d’entrepôts dans les sessions

Lorsqu’une session est lancée dans Snowflake, elle n’est pas, par défaut, associée à un entrepôt. Tant qu’un entrepôt n’est pas associé à une session, les requêtes ne peuvent pas être soumises au cours de la session.

Entrepôt par défaut pour les utilisateurs

Pour faciliter l’exécution de requêtes immédiatement après le lancement d’une session, Snowflake prend en charge la spécification d’un entrepôt par défaut pour chaque utilisateur individuel. L’entrepôt par défaut d’un utilisateur est utilisé comme entrepôt pour toutes les sessions lancées par l’utilisateur.

Un entrepôt par défaut peut être spécifié lors de la création ou de la modification de l’utilisateur, soit via l’interface Web soit à l’aide de la commande CREATE USER/ALTER USER.

Entrepôt par défaut pour les utilitaires, pilotes et connecteurs client

Outre les entrepôts par défaut pour les utilisateurs, tous les autres clients Snowflake (SnowSQL, pilote JDBC, pilote ODBC, connecteur Python, etc.) peuvent avoir un entrepôt par défaut :

  • SnowSQL prend à la fois en charge un fichier de configuration et une option de ligne de commande pour spécifier un entrepôt par défaut.

  • Les pilotes et les connecteurs prennent en charge la spécification d’un entrepôt par défaut comme paramètre de connexion lors du lancement d’une session.

Pour plus d’informations, voir Connexion à Snowflake.

Priorité des entrepôts

Lorsqu’un utilisateur se connecte à Snowflake et démarre une session, Snowflake détermine l’entrepôt par défaut pour la session dans l’ordre suivant :

  1. Entrepôt par défaut pour l’utilisateur.

    » écrasé par…

  2. Entrepôt par défaut dans le fichier de configuration de l’utilitaire client (SnowSQL, pilote JDBC, etc.) utilisé pour se connecter à Snowflake (si le client prend en charge les fichiers de configuration).

    » écrasé par…

  3. Entrepôt par défaut spécifié sur la ligne de commande du client ou par les paramètres du pilote/connecteur transmis à Snowflake.

Note

De plus, l’entrepôt par défaut d’une session peut être modifié à tout moment en exécutant la commande USE WAREHOUSE dans la session.