Utilisation optimale de Snowflake Warehouse et Tables

Dans le blog précédent, nous avons discuté de la Êtrest pratiques à suivre lors du chargement des données dans Snowflake à partir de Stages.

Poursuivre la série de blogs sur les flocons de neige nous permet de comprendre comment utiliser Snowflake Warehouse and Tables de manière optimale.

Entrepôts virtuels Snowflakes

Les entrepôts virtuels sont l’un des composants essentiels de l’architecture Snowflake et décider des configurations correctes pour celui-ci peut économiser beaucoup de crédits snowflake.

Vous trouverez ci-dessous certaines des meilleures pratiques à prendre en compte lors de la sélection des configurations de l’entrepôt.

Comment décider quelle taille d’entrepôt est optimale ?

• Pour les requêtes simples, il est préférable d’utiliser des entrepôts x-small ou small.
• Pour les requêtes complexes ou si de grands ensembles de données doivent être analysés, utilisez des entrepôts de grande taille.
• Les performances des requêtes s’améliorent de manière linéaire tout en augmentant la taille de l’entrepôt jusqu’à ce que les performances optimales soient atteintes. Après cela, il n’y aurait pas de différence significative dans les performances.
• Pour déterminer l’entrepôt optimal pour les requêtes complexes, il est recommandé de tester avec différents entrepôts et de noter le temps d’exécution de la requête pour chacun.
• Si vous exécutez une seule requête sur l’entrepôt, il est préférable de choisir un entrepôt qui s’exécute pendant au moins une minute pour optimiser le coût.

Suspension automatique de l’entrepôt

La suspension automatique permet aux entrepôts de se suspendre automatiquement lorsqu’ils ne sont pas utilisés et donc de réduire les coûts.

La propriété Auto Suspend peut être désactivée lorsque :

• S’il y a des charges de travail fréquentes et régulières sur l’entrepôt 24*7.

• Si vous avez besoin que l’entrepôt virtuel soit disponible à tout moment pour obtenir des résultats de requête plus rapides à partir du cache.

Notez que la désactivation de la suspension automatique peut entraîner une facturation importante et donc choisir judicieusement.

La pratique générale consiste à maintenir la suspension automatique activée afin que vous ne payiez que pour le temps actif et non pour le temps idéal.

Par défaut, l’intervalle de temps Auto_Suspend est de 600 secondes.

Cela ne peut pas être optimal si vous exécutez les requêtes une fois toutes les 10 minutes et que le temps d’exécution de la requête est de 1 min.

Dans de tels cas, il est toujours préférable de définir l’intervalle de temps AUTO_SUSPEND en fonction des besoins.

L’intervalle de temps pour la suspension automatique peut être décidé en fonction des facteurs ci-dessous :

1. Intervalle de temps entre deux requêtes consécutives exécutées dans l’entrepôt.
2. Temps moyen d’exécution des requêtes.

Coût par rapport aux performances lors de la définition de la limite AUTO_SUSPEND

Supposons qu’il existe un modèle récurrent d’exécution de requêtes similaires toutes les 75 secondes, avec un temps d’exécution moyen des requêtes de 10 secondes, et que l’entrepôt a été défini sur AUTO_SUSPEND après 60 secondes.

Dans de tels cas, voici ce qui se passerait.

0 ème sec → La requête est lancée et démarre l’entrepôt

10ème sec → La requête est exécutée avec succès

70 ème s → Suspension automatique de l’entrepôt

75 ème sec → La requête est lancée et démarre l’entrepôt

85 ème sec → La requête est exécutée avec succès

145 ème s → Suspension automatique de l’entrepôt

150 ème sec → La requête est lancée et démarre l’entrepôt

160 ème sec → La requête est exécutée avec succès

220e sec → Suspension automatique de l’entrepôt

Et ainsi de suite…

Ici, si vous remarquez que l’AUTO_SUSPEND de 60 secondes ne nous profite pas lorsque nous considérons le facteur coût / performance.

La disponibilité totale de l’entrepôt dans le cas ci-dessus est de 210 secondes.

La disponibilité totale si AUTO_SUSPEND était désactivé aurait été de 220 secondes.

Mais l’avantage de désactiver AUTO_SUSPEND dans ce scénario donné aurait été un temps de traitement des requêtes plus rapide.

Étant donné que chaque fois que l’entrepôt est redémarré, les données sont extraites du disque distant vers le cache local, puis la requête est traitée.

Mais en cas de désactivation de AUTO_SUSPEND, étant donné que les requêtes étaient similaires, il suffisait de les traiter sur le cache du disque local et cela entraînerait des performances de requête plus rapides. Peut-être quelques secondes au lieu de 10 secondes.

Et si la même requête avait été réémise et s’il n’y avait pas eu de changement de données, la sortie aurait été en millisecondes directement à partir du cache de résultats.

Pensez donc toujours au compromis entre économiser des crédits en suspendant un entrepôt et conserver le cache des données des requêtes précédentes pour améliorer les performances.

Maintenant que nous comprenons les coûts associés aux entrepôts dans Snowflake, examinons comment le stockage des données dans Snowflake affecte la facturation globale.

Coûts de stockage de données sur les tables internes Snowflake

Les coûts de stockage des données sont souvent négligés dans Snowflake car ils sont considérés comme peu coûteux. Cependant, il est crucial d’examiner attentivement le type de tables à créer dans Snowflake, en tenant compte des coûts associés aux stratégies de voyage dans le temps, de sécurité intégrée, de partage de données et de clonage.

Cette compréhension aidera à développer des approches efficaces pour gérer les tables internes.

Si vous venez d’un arrière-plan RDBMS, vous pouvez supposer que l’exécution de « créer une table » dans Snowflake créera une table normale. Cependant, ce n’est pas le cas. Au lieu de cela, il créera une table avec le voyage dans le temps activé, ce qui peut entraîner une augmentation des coûts si une telle table n’est pas nécessaire.Toutes les insertions, mises à jour, suppressions sur ces tables sont prises en compte pour le stockage des données et en cas d’opérations DML fréquentes, la taille des tables avec des données de voyage dans le temps peut augmenter en un rien de temps.

Par conséquent, si vous n’avez pas décidé du type de table que vous devez créer, utilisez toujours

CREATE TRANSIENT TABLE au lieu de CREATE TABLE

Cela doit être communiqué aux développeurs car l’habitude générale est de toujours utiliser Créer une table.

Pour une table normale, si elle est de grande taille avec un taux de désabonnement élevé, les coûts peuvent augmenter de façon exponentielle.

Notez que toutes les tables n’ont pas besoin d’avoir des fonctionnalités de voyage dans le temps et donc utilisez CREATE TABLE à bon escient.

Par exemple

Supposons que nous ayons une table d’une taille de 200 Go et que nous recevions des mises à jour fréquentes. Cette table est configurée pour voyager dans le temps, spécifiquement pendant 90 jours, et il est supposé que chaque enregistrement de la table subit une mise à jour au moins 20 fois au cours de cette période. Après la période de 90 jours, la table sera déplacée vers le stockage Fail Safe par Snowflake, où elle sera stockée pendant 7 jours.

Voici donc ci-dessous les statistiques de stockage pour la table :

Bien que la table ait une taille de 0,2 To, le coût encouru est de 32,2 To lorsque le voyage dans le temps est activé.

Et ci-dessous est le cas si la même table aurait été une table transitoire avec un voyage dans le temps de 0 jours :

Bien que vous puissiez activer le voyage dans le temps jusqu’à 90 jours, choisissez le nombre de jours qui vous convient.

Par exemple : en production, si je sais que si des problèmes liés aux données existent et peuvent être résolus et résolus dans les 7 jours, je choisirais les jours de voyage dans le temps comme étant de 7 jours.

Même dans le pire des cas, si le problème persiste plus de 7 jours, vous pouvez contacter le support Snowflake et obtenir la copie des données Fail Safe.

Si vous optez pour l’approche de table transitoire pour les tables critiques, la meilleure pratique consiste à toujours conserver une sauvegarde à intervalles réguliers.

Bien que la table de sauvegarde coûte également le même prix que la table réelle, le coût total des deux combinés serait toujours bien inférieur à celui de la table avec voyage dans le temps.

Utiliser le clonage au lieu de CTAS dans Snowflake

Le clonage dans Snowflake est un concept puissant et permettra d’économiser beaucoup de coûts s’il est utilisé.

Les cas d’utilisation seraient :

• Créez une copie du tableau. Cela pourrait être pour tout débogage de bogue.
• Création d’une copie de sauvegarde de la table existante.

Lorsqu’une table est clonée, les micropartitions sont partagées entre la table principale actuelle et la table clonée à ce moment particulier du clonage.

Les requêtes CTAS qui sont utilisées dans de nombreuses bases de données dupliqueraient les données, mais en cas de clonage, les données sous-jacentes sous forme de micro partitions resteront les mêmes, ce qui économisera les coûts de stockage.

Si un DML est effectué sur la table principale et la table clonée après le clonage, les nouvelles micro partitions ne sont pas partagées.

Par conséquent, la meilleure pratique consiste à cloner la table là où c’est nécessaire et à ne pas utiliser de requêtes CTAS. De même, le clonage peut être effectué au niveau de la base de données et du schéma, ce qui permet également d’économiser beaucoup d’argent.

Partage de données pour partager les données entre les comptes

Le clonage d’un objet n’est pas possible entre les comptes et nous avons tendance à opter pour la réplication des objets entre les comptes.

Certains cas d’utilisation ici pourraient être :

La base de données de production se trouve dans le compte Snowflake A1 sous Org O.

La base de données de développement se trouve dans le compte Snowflake A2 sous la même organisation O.

Et vous devez tester le pipeline d’ingénierie de données Dev avec les mêmes tables source que dans le compte Production.

Maintenant, comme le clonage entre bases de données pour les tables source n’est pas possible, dans de tels cas, nous pouvons opter pour le partage de données entre comptes.

Voyons comment cela fonctionne :

Dans le compte Production, supposons que nous ayons une base de données PAYER_PROD et un schéma PAYER_ANALYTICS_MASTER à l’intérieur duquel nous avons une table source AWSCUR_MAIN qui doit être partagée avec le compte Développement.

Suivez ensuite les étapes ci-dessous :

Dans le compte de production :

– Use AccountAdmin role

use role ACCOUNTADMIN;

– Creates a Share object

create share AWSCUR_MAIN_NON_PROD;

– Grants necessary privileges to the share

grant usage on database PAYER_PROD to share AWSCUR_MAIN_NON_PROD;

grant usage on schema PAYER_PROD.PAYER_ANALYTICS_MASTER to share AWSCUR_MAIN_NON_PROD;

grant select on table PAYER_PROD.PAYER_ANALYTICS_MASTER.AWSCUR_MAIN to share AWSCUR_MAIN_NON_PROD;




​​– Add accountid of the Development snowflake to the share

alter share AWSCUR_MAIN_NON_PROD add accounts=<dev_account_id>;

Dans le compte de développement :

– Use AccountAdmin role

use role ACCOUNTADMIN;

– Create a database out of the shared object

CREATE DATABASE PAYER_PROD FROM SHARE <<orgid>>.<<accountid>>."AWSCUR_MAIN_NON_PROD";

– Grant the database to respective roles in development account

GRANT IMPORTED PRIVILEGES ON DATABASE PAYER_PROD TO ROLE "<<rolename>>";

Étant donné que les données sont partagées entre les comptes et non répliquées, aucun coût de stockage supplémentaire n’y est associé. Seules les métadonnées sont partagées.

Toutes les mises à jour des données de production seront reflétées dans la base de données Dev Snowflake sans frais supplémentaires.

Le coût correspond uniquement à l’interrogation des données dans l’environnement de développement, qui correspond à l’utilisation de l’entrepôt.