Vue d’ensemble 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. En plus d’être défini par son type en Standard ou Optimisé pour Snowpark, 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.

Taille d’entrepôt

La taille spécifie la quantité de ressources de calcul disponibles par cluster dans un entrepôt. Snowflake prend en charge les tailles d’entrepôt suivantes :

Taille d’entrepôt

Crédits / heure (entrepôts Gen1)

Crédits / seconde (entrepôts Gen1)

Remarques

X-Small

1

0,0003

Taille par défaut des entrepôts créés dans Snowsight et utilisant CREATE WAREHOUSE.

Small

2

0,0006

Medium

4

0,0011

Large

8

0,0022

X-Large

16

0,0044

Taille par défaut des entrepôts créés à l’aide de l”Classic Console.

2X-Large

32

0,0089

3X-Large

64

0,0178

4X-Large

128

0,0356

5X-Large

256

0,0711

Généralement disponible dans les régions Amazon Web Services (AWS) et Microsoft Azure et en avant-première dans les régions gouvernementales US.

6X-Large

512

0,1422

Généralement disponible dans les régions Amazon Web Services (AWS) et Microsoft Azure et en avant-première dans les régions gouvernementales US.

Les nombres figurant dans le tableau précédent se rapportent à la première génération (Gen1) des entrepôts standard de Snowflake. Pour obtenir des informations sur l’utilisation des nouveaux entrepôts Gen2, voir Entrepôts standard de génération 2 de Snowflake. Pour obtenir des informations sur la consommation de crédits pour les entrepôts standard de deuxième génération, consultez Snowflake Service Consumption Table. Les entrepôts Gen2 ne sont pas encore disponibles pour tous les fournisseurs de services Cloud ou pour toutes les régions, et ne sont pas actuellement la valeur par défaut lorsque vous créez un entrepôt standard.

Une autre façon de mettre à l’échelle la capacité des entrepôts Snowflake sans modifier la taille de l’entrepôt consiste à utiliser des entrepôts à clusters multiples. Pour plus d’informations sur cette fonction, voir Entrepôts multi-clusters.

Entrepôts de tailles supérieures

Les entrepôts de tailles supérieures 5X-Large et 6X-Large sont généralement disponibles dans toutes les régions Amazon Web Services (AWS) et Microsoft Azure.

Des entrepôts de tailles supérieures sont disponibles en avant-première dans les régions US (nécessite la prise en charge FIPS sur ARM).

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

Comme l’illustre le tableau ci-dessus, l’utilisation du crédit double lorsque vous passez à la taille d’entrepôt supérieure 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 suivant présente les totaux de facturation de trois entrepôts standard Gen1 de taille différente en fonction de leur temps de fonctionnement (totaux arrondis au millième de crédit le plus proche) :

Délai d’exécution

Crédits . (X-Small)

Crédits . (X-Large)

Crédits . (5X-Large)

0-60 secondes

0,017

0,267

4,268

61 secondes

0,017

0,271

4,336

2 minutes

0,033

0,533

8,532

10 minutes

0,167

2,667

42,668

1 heure

1,000

16,000

256,000

Note

  • Pour un entrepôt multi-clusters, le nombre de crédits facturés est calculé en fonction de la taille de l’entrepôt 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.

Conséquences sur le chargement de 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 Considérations relatives au chargement de 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 varient en fonction de la taille de l’entrepôt, car les entrepôts plus grands disposent de plus de ressources de calcul pour traiter les requêtes.

Si les requêtes traitées par un entrepôt fonctionnent lentement, vous pouvez toujours redimensionner l’entrepôt pour alimenter davantage de ressources. Les ressources supplémentaires n’ont aucune conséquence sur les requêtes déjà en cours d’exécution, mais une fois qu’elles sont entièrement provisionnées, elles deviennent 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 Considérations relatives aux entrepôts.

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 Applications et outils pour se connecter à Snowflake.

Entrepôt par défaut pour les notebooks

Pour améliorer le rapport coût-efficacité des charges de travail de notebook, un entrepôt X-Small multicluster, SYSTEM$STREAMLIT_NOTEBOOK_WH, est automatiquement mis en place dans chaque compte. Cet entrepôt, qui fonctionne avec un maximum de 10 clusters et un délai d’expiration par défaut de 60 secondes, utilise un mécanisme de « bin packing » amélioré. Le rôle ACCOUNTADMIN dispose du privilège OWNERSHIP.

Recommandations pour la gestion des coûts

  • Snowflake recommande de réserver l’utilisation de l’entrepôt SYSTEM$STREAMLIT_NOTEBOOK_WH aux charges de travail de notebook.

  • Pour améliorer l’efficacité du bin-packing et réduire la fragmentation des clusters, dirigez les requêtes SQL des applications de notebook vers un entrepôt de requêtes distinct géré par le client. L’utilisation d’un seul entrepôt partagé pour toutes les applications de notebook d’un compte améliore encore l’efficacité du bin-packing.

  • Le fait de séparer les charges de travail de notebook Python et les requêtes SQL minimise la fragmentation des clusters. Cette approche permet d’optimiser les coûts globaux en veillant à ce que les charges de travail de notebook Python ne soient pas hébergées dans des entrepôts plus importants, qui sont généralement utilisés pour l’exécution des requêtes.

Exigences en matière de contrôle d’accès

Privilège

Objet

Remarques

USAGE

SYSTEM$STREAMLIT_NOTEBOOK_WH

Par défaut, le rôle PUBLIC dispose des privilèges USAGE. ACCOUNTADMIN peut accorder et révoquer des privilèges USAGE.

MONITOR, OPERATE, APPLYBUDGET

SYSTEM$STREAMLIT_NOTEBOOK_WH

Disponible pour l’ACCOUNTADMIN et peut être accordé par l’ACCOUNTADMIN à d’autres rôles.

Priorité des paramètres d’entrepôt par défaut

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.