Remarques sur les entrepôts virtuels

Ce chapitre fournit des lignes directrices générales et des bonnes pratiques pour utiliser les entrepôts virtuels dans Snowflake dans le cadre du traitement de requêtes. Il ne fournit pas de nombres, de valeurs ou de recommandations spécifiques ou absolus, car chaque scénario de requête est différent et est affecté par de nombreux facteurs, y compris le nombre d’utilisateurs/de requêtes simultanés, le nombre de tables interrogées, la taille et la composition des données, ainsi que vos exigences spécifiques concernant la disponibilité, la latence et le coût de l’entrepôt.

Il n’inclut également pas de remarques sur les entrepôts concernant le chargement de données. Ces remarques sont disponibles dans un autre chapitre (voir la barre latérale).

Pour utiliser les entrepôts efficacement :

  1. Testez les différents types de requête et les différentes tailles d’entrepôt pour déterminer les combinaisons qui répondent le mieux à vos besoins et à votre charge de travail spécifiques.

  2. Ne vous focalisez pas sur la taille de l’entrepôt. Snowflake utilise la facturation à la seconde, ce qui vous permet d’exploiter de plus grands entrepôts (Large, X-Large, 2X-Large, etc), et de les suspendre simplement lorsqu’ils ne sont pas utilisés.

Note

Ces lignes directrices et bonnes pratiques s’appliquent à la fois aux entrepôts à cluster unique qui sont la norme pour tous les comptes, et aux entrepôts multi-clusters qui sont disponibles dans Snowflake Enterprise Edition (et versions supérieures).

Dans ce chapitre :

Comment les crédits sont-ils facturés pour les entrepôts ?

Les frais de crédit sont calculés sur la base suivante :

  • Nombre de serveurs par cluster (déterminé par la taille de l’entrepôt).

  • Nombre de clusters (si vous utilisez des entrepôts multi-clusters).

  • Durée d’exécution de chaque serveur de chaque cluster.

Par exemple :

X-Small

Utilise 1 serveur par cluster et facture 1 crédit par heure complète et continue d’exécution de chaque cluster. Chaque taille successive double le nombre de serveurs par cluster.

4X-Large

Utilise 128 serveurs par cluster et facture 128 crédits par heure complète et continue d’exécution de chaque cluster.

Remarques :

  • Chaque serveur d’un cluster d’entrepôts possède :

    • Une minuterie interne qui enregistre quand le serveur a été démarré. Cette minuterie interne est utilisée pour calculer les frais de facturation de crédit individuels pour le serveur selon un intervalle de l’ordre de la seconde.

    • Une position dans l’entrepôt qui est conservée, même lorsque l’entrepôt est suspendu ou redimensionné. Cette position a une conséquence sur la façon dont les serveurs sont ajoutés et supprimés, car les serveurs sont toujours supprimés dans l’ordre inverse de la date à laquelle ils ont été ajoutés (principe connu sous le nom de LIFO, « Last In, First Out »).

  • Lorsqu’un serveur est mis en service :

    • Les frais de facturation minimum pour la mise en service d’un serveur sont de 1 minute (soit 60 secondes).

    • Il n’y a aucun avantage à arrêter un entrepôt avant la fin de la première période de 60 secondes, car les crédits ont déjà été facturés pour cette période.

    • Après les 60 premières secondes, toute facturation ultérieure pour un serveur en cours d’exécution est facturée à la seconde (jusqu’à l’arrêt du serveur). En d’autres termes :

      • Si un serveur fonctionne pendant 30 à 60 secondes, il est facturé pour 60 secondes.

      • Si un serveur fonctionne pendant 61 secondes, il n’est facturé que pour 61 secondes.

      • Si un serveur fonctionne pendant 61 secondes, s’arrête, puis redémarre et fonctionne pendant moins de 60 secondes, il est facturé 121 secondes (60 + 1 + 60).

  • Redimensionner un entrepôt crée des serveurs supplémentaires pour chaque cluster dans l’entrepôt :

    • Il en résulte une augmentation du nombre de crédits facturés pour l’entrepôt (pendant l’exécution des serveurs supplémentaires).

    • La minuterie interne pour les serveurs supplémentaires démarre dès qu’ils sont mis en service, c’est-à-dire que les crédits pour les serveurs supplémentaires sont facturés par rapport au moment où l’entrepôt a été redimensionné.

  • La consommation de crédit est affichée par incréments d’une heure. Avec la facturation à la seconde, vous verrez des montants fractionnaires pour l’utilisation du crédit et la facturation.

Quelle est la conséquence de la composition des requêtes sur le traitement des entrepôts ?

Le nombre de serveurs requis pour traiter une requête dépend de la taille et de la complexité de la requête. Dans la plupart des cas, les requêtes évoluent linéairement en fonction de la taille de l’entrepôt, en particulier pour les requêtes plus grandes et plus complexes. Lors de la prise en compte de facteurs ayant une incidence sur le traitement de la requête, tenez compte des éléments suivants :

  • La taille globale des données des tables interrogées a une influence plus forte que le nombre de lignes.

  • Le filtrage de requête utilisant des prédicats a également une conséquence sur le traitement, tout comme le nombre de jointures/tables dans la requête.

Astuce

Pour obtenir les meilleurs résultats, essayez d’exécuter des requêtes relativement homogènes (taille, complexité, ensembles de données, etc.) sur le même entrepôt. L’exécution de requêtes de taille et/ou de complexité très variables sur le même entrepôt rend plus difficile l’analyse de la charge de l’entrepôt. Il est alors plus difficile de choisir la taille la plus adaptée pour correspondre à la taille, à la composition et au nombre de requêtes dans votre charge de travail.

Comment la mise en cache d’entrepôt influence-t-elle les requêtes ?

Chaque entrepôt, lorsqu’il est en cours d’exécution, conserve une mémoire cache des données de table consultées au fur et à mesure que les requêtes sont traitées par l’entrepôt. Cela permet d’améliorer les performances des requêtes ultérieures si elles sont capables de lire à partir de la mémoire cache au lieu de la ou des tables de la requête. La taille de la mémoire cache est déterminée par le nombre de serveurs dans l’entrepôt, c’est-à-dire que plus l’entrepôt est grand (et donc plus le nombre de serveurs dans l’entrepôt est élevé), plus le cache est grand.

Cette mémoire cache est supprimée lorsque l’entrepôt est suspendu, ce qui peut entraîner un ralentissement des performances initiales pour certaines requêtes après la reprise de l’entrepôt. Lorsque l’entrepôt relancé recommence à traiter davantage de requêtes, la mémoire cache se reconstruit et les requêtes capables d’exploiter le cache voient leurs performances accroître.

Gardez cela à l’esprit lorsque vous décidez de suspendre un entrepôt ou de le laisser en service. En d’autres termes, pesez le pour et le contre entre économie de crédits en suspendant un entrepôt et maintien de la mémoire cache des données des requêtes précédentes pour renforcer les performances.

Création d’un entrepôt

Lors de la création d’un entrepôt, les deux facteurs les plus importants à prendre en compte, du point de vue des coûts et des performances, sont les suivants :

  • La taille de l’entrepôt (c-à-d. le nombre de serveurs par cluster).

  • La gestion manuelle ou automatique (pour lancer/relancer et suspendre un entrepôt).

Le nombre de clusters dans l’entrepôt est également important si vous utilisez Snowflake Enterprise Edition (ou supérieur) et des entrepôts multi-clusters. Pour plus de détails, voir Scale Up vs Scale out (dans ce chapitre).

Sélection d’une taille d’entrepôt initiale

La taille initiale que vous sélectionnez pour un entrepôt dépend de la tâche qu’il effectue et de la charge de travail qu’il traite. Par exemple :

  • Pour le chargement des données, la taille de l’entrepôt doit correspondre au nombre de fichiers en cours de chargement et à la quantité de données dans chaque fichier. Pour plus de détails, voir Remarques relatives au chargement des données.

  • Pour les requêtes dans des environnements de test à petite échelle, des tailles d’entrepôts plus petites (X-Small, Small, Medium) peuvent suffire.

  • Pour les requêtes dans des environnements de production à grande échelle, des tailles d’entrepôt plus grandes (Large, X-Large, 2X-Large, etc.) peuvent s’avérer plus rentables.

Toutefois, notez que la facturation à la seconde et la suspension automatique du crédit vous permettent de commencer avec des tailles plus grandes, puis d’ajuster la taille en fonction de vos charges de travail. Vous pouvez toujours réduire la taille d’un entrepôt à tout moment.

Par ailleurs, un entrepôt plus grand n’est pas nécessairement plus rapide pour les requêtes plus petites et plus basiques. Les petites/simples requêtes n’ont généralement pas besoin d’un entrepôt X-Large (ou plus grand) car elles ne profiteront pas nécessairement des ressources supplémentaires, quel que soit le nombre de requêtes traitées simultanément. En général, essayez d’adapter la taille de l’entrepôt à la taille et à la complexité prévues des requêtes à traiter par l’entrepôt.

Astuce

Faites des essais en exécutant les mêmes requêtes sur des entrepôts de tailles différentes (par ex. X-Large, Large, Medium). Les requêtes que vous testez doivent être d’une taille et d’une complexité permettant un traitement entre 5 à 10 minutes (ou moins).

Automatisation de la suspension de l’entrepôt

Les entrepôts peuvent être configurés de sorte à s’arrêter automatiquement lorsqu’aucune activité n’est effectuée après une certaine période. La suspension automatique s’active en spécifiant la période d’inactivité (minutes, heures, etc.) pour l’entrepôt.

Nous vous recommandons de paramétrer la suspension automatique en fonction de votre charge de travail et de vos besoins en matière de disponibilité de l’entrepôt :

  • Si vous activez la suspension automatique, nous vous recommandons de la régler sur une valeur faible (p. ex. 5 ou 10 minutes, ou moins), car Snowflake utilise la facturation à la seconde. Cela aidera à empêcher vos entrepôts de rester exécutés (et de consommer des crédits) lorsqu’ils ne sont pas utilisés.

    Toutefois, la valeur que vous définissez doit correspondre aux temps morts, le cas échéant, dans votre charge de travail de requête. Par exemple, si vous avez des temps morts réguliers de 2 ou 3 minutes entre chaque requête entrante, il n’est pas conseillé de régler la suspension automatique sur 1 ou 2 minutes, car votre entrepôt sera continuellement dans un état de suspension et de reprise (si la reprise automatique est également activée) et à chaque reprise, la consommation minimale de crédit vous sera facturée (c’est-à-dire 60 secondes).

  • Pensez à désactiver la suspension automatique d’un entrepôt si :

    • Vous avez une charge de travail élevé et constante pour l’entrepôt.

    • Vous avez besoin que l’entrepôt soit disponible sans délai ni décalage. La mise en service d’un entrepôt est généralement très rapide (p. ex. 1 ou 2 secondes). Cependant, la mise en service peut être plus longue en fonction de la taille de l’entrepôt et de la disponibilité des serveurs à mettre en marche.

Important

Si vous choisissez de désactiver la suspension automatique, veuillez bien considérer les coûts associés à la gestion continue d’un entrepôt, même lorsque celui-ci ne traite pas de requêtes. Les coûts peuvent être considérables, en particulier pour les grands entrepôts (X-Large, 2X-Large, etc.).

Pour désactiver la suspension automatique, vous devez explicitement sélectionner Never dans l’interface Web ou spécifier NULL dans SQL.

Automatisation de la reprise de l’entrepôt

Les entrepôts peuvent être configurés de sorte à redémarrer lorsque de nouvelles requêtes sont soumises.

Nous vous recommandons d’activer/de désactiver la reprise automatique en fonction du degré de contrôle que vous souhaitez exercer sur l’utilisation d’un entrepôt particulier :

  • Si le coût et l’accès ne sont pas un problème, activez la reprise automatique pour vous assurer que l’entrepôt démarre chaque fois que nécessaire. Gardez à l’esprit que la reprise de l’entrepôt peut subir un court décalage en raison de la mise en route des serveurs.

  • Si vous souhaitez contrôler les coûts et/ou l’accès des utilisateurs, laissez la fonction de reprise automatique désactivée, et effectuez plutôt une reprise manuelle de l’entrepôt lorsque cela est nécessaire.

Scale Up vs Scale Out

Snowflake propose deux façons de mettre les entrepôts à l’échelle :

  • L’approche « Scale Up » en redimensionnant un entrepôt.

  • Dimensionnez en fonction de vos besoins, en ajoutant des clusters à un entrepôt (nécessite Snowflake Enterprise Edition ou une version supérieure).

Le redimensionnement de l’entrepôt améliore les performances.

Le redimensionnement d’un entrepôt améliore généralement les performances des requêtes, en particulier celles des requêtes plus importantes et plus complexes. Cela peut également contribuer à réduire les files d’attente si un entrepôt ne dispose pas d’un nombre suffisant de serveurs pour traiter toutes les requêtes qui sont soumises simultanément. Notez que redimensionner un entrepôt n’a pas pour but de résoudre les problèmes de simultanéité. Pour résoudre ce problème, utilisez des entrepôts supplémentaires afin de faire face à la charge de travail ou utilisez un entrepôt multi-clusters (si cette fonction est disponible pour votre compte).

Snowflake permet de redimensionner un entrepôt à tout moment, même lorsqu’il est en cours d’exécution. Si une requête s’exécute lentement et que vous avez des requêtes supplémentaires de taille et de complexité similaires que vous souhaitez exécuter sur le même entrepôt, vous pouvez choisir de redimensionner l’entrepôt en cours d’exécution. Cependant, prenez compte des remarques suivantes :

  • Comme nous l’avons déjà dit à propos de la taille de l’entrepôt, « plus grand » ne signifie pas nécessairement « plus rapide ». Pour les requêtes de base plus petites, qui s’exécutent déjà rapidement, vous ne verrez peut-être pas d’améliorations significatives après le redimensionnement.

  • Le redimensionnement d’un entrepôt en cours d’exécution n’a aucune conséquence sur les requêtes qui sont déjà en cours de traitement par l’entrepôt. Les serveurs supplémentaires ne sont utilisés que pour les requêtes en attente et les nouvelles requêtes.

Astuce

Diminuer la taille d’un entrepôt en cours d’exécution supprime des serveurs de l’entrepôt. Lorsque les serveurs sont supprimés, la mémoire cache associée aux serveurs est détruite, ce qui peut avoir des conséquences sur les performances similaires aux conséquences de la suspension de l’entrepôt sur les performances après sa reprise.

Gardez cela à l’esprit lorsque vous choisissez de réduire la taille d’un entrepôt en cours d’exploitation ou de le maintenir à la taille actuelle. En d’autres termes, il faut peser le pour et le contre entre économie de crédits et maintien de la mémoire cache du serveur.

Les entrepôts multi-clusters améliorent la simultanéité

Les entrepôts multi-clusters sont conçus spécifiquement pour traiter les problèmes de file d’attente et de performance liés à un grand nombre d’utilisateurs et/ou de requêtes simultanés. De plus, les entrepôts multi-clusters peuvent vous aider à automatiser ce processus si votre nombre d’utilisateurs/demandes a tendance à fluctuer.

Lorsque vous décidez d’utiliser ou non des entrepôts multi-clusters et du nombre de clusters à utiliser par entrepôt, tenez compte de des éléments suivants :

  • Si vous utilisez Snowflake Enterprise Edition (ou une édition supérieure), tous vos entrepôts doivent être configurés comme des entrepôts multi-clusters.

  • À moins que vous n’ayez une raison particulière d’utiliser le mode « Maximisé », les entrepôts multi-clusters doivent être configurés de sorte à être exécutés en mode « Mise à l’échelle automatique », ce qui permet à Snowflake de démarrer et de s’arrêter automatiquement.

  • Lors du choix du nombre minimum et maximum de clusters pour un entrepôt multi-clusters :

    Minimum

    Conservez la valeur par défaut de 1, ce qui garantit que les clusters supplémentaires ne sont lancés qu’en cas de besoin. Toutefois, si la haute disponibilité de l’entrepôt est importante, réglez la valeur sur une valeur supérieure à 1. Cela permet d’assurer la disponibilité et la continuité de l’entrepôt dans l’éventualité peu probable d’une défaillance de cluster.

    Maximum

    Réglez cette valeur sur une valeur aussi grande que possible, tout en tenant compte de la taille de l’entrepôt et des coûts de crédit correspondants. Par exemple, un entrepôt X-Large (16 serveurs) avec un maximum de clusters = 10 consommera 160 crédits en une heure si les 10 clusters fonctionnent en continu pendant une heure.