Optimisation des coûts

Cette rubrique aborde les moyens d’optimiser Snowflake pour réduire les coûts et optimiser vos dépenses.

Aperçu des coûts : trouver des possibilités d’économies

Snowflake fournit des informations sur les coûts qui permettent d’identifier les possibilités d’optimiser les coûts de Snowflake au sein d’un compte particulier. Ces insights sont calculés et actualisés chaque semaine.

Chaque insight indique combien de crédits ou de TBs pourraient être économisés en optimisant Snowflake.

Note

Vous devez avoir le rôle ACCOUNTADMIN pour voir les informations sur les coûts.

Pour accéder à la vignette Cost Insights :

  1. Connectez-vous à Snowsight.

  2. Passez au rôle ACCOUNTADMIN.

  3. Dans le menu de navigation, sélectionnez Admin » Cost Management.

  4. Sélectionnez l’onglet Account Overview.

  5. Trouvez la vignette Cost insights.

Chacun des insights suivants comprend des suggestions sur la manière d’optimiser vos dépenses.

Insight : tables rarement utilisées avec clustering automatique

Cet insight identifie les tables avec clustering automatique qui sont interrogées moins de 100 fois par semaine par ce compte.

L’activation du clustering automatique pour une table peut améliorer de manière significative les performances des requêtes portant sur cette table. Cependant, à mesure que la table évolue, Snowflake doit utiliser des ressources de calcul sans serveur pour la maintenir dans un état bien clusterisé. Si le nombre de requêtes exécutées sur la table est minime, le coût encouru pourrait ne pas justifier l’amélioration des performances.

Recommandation : envisagez de désactiver le clustering automatique sur ces tables. Avant de désactiver le clustering automatique, déterminez si la table existe uniquement à des fins de reprise après sinistre ou si elle est utilisée par d’autres comptes Snowflake dans le cadre du partage de données, ce qui pourrait expliquer pourquoi elle n’est pas consultée fréquemment.

Par exemple, pour désactiver le clustering automatique pour une table nommée t1, exécutez la commande suivante :

ALTER TABLE t1 SUSPEND RECLUSTER;
Copy
Insight : vues matérialisées rarement utilisées

Cet insight identifie des vues matérialisées qui sont interrogées moins de 10 fois par semaine par ce compte.

La création d’une vue matérialisée peut améliorer considérablement les performances pour certains modèles de requête. Cependant, les vues matérialisées entraînent des coûts de stockage supplémentaires ainsi que des coûts de calcul sans serveur associés au maintien de la vue matérialisée à jour avec les nouvelles données. Si le nombre de requêtes exécutées sur la vue matérialisée est minime, le coût encouru pourrait ne pas justifier l’amélioration des performances.

Recommandation : envisagez de supprimer ou de suspendre les mises à jour des vues matérialisées. Avant de supprimer une vue matérialisée, déterminez si la table existe uniquement à des fins de reprise après sinistre ou si elle est utilisée par d’autres comptes Snowflake dans le cadre du partage de données, ce qui pourrait expliquer pourquoi on n’y accède pas fréquemment.

Par exemple, pour supprimer une vue matérialisée nommée mv1, exécutez la commande suivante :

DROP MATERIALIZED VIEW mv1;
Copy
Insight : chemins d’optimisation de la recherche rarement utilisés

Cet insight identifie des chemins d’accès d”optimisation de la recherche qui sont utilisés moins de 10 fois par semaine par ce compte.

L’optimisation de la recherche utilise les chemins d’accès à la recherche pour améliorer la performance de certains types de requêtes analytiques et de recherche de points. L’ajout d’une optimisation de la recherche à une table peut améliorer considérablement les performances pour ces requêtes. Cependant, l’optimisation de la recherche entraîne des coûts de stockage supplémentaires ainsi que des coûts de calcul sans serveur associés à la mise à jour de ce stockage. Si le nombre de requêtes qui utilisent le chemin d’accès créé par l’optimisation de la recherche est minime, le coût encouru pourrait ne pas justifier les améliorations de performance.

Recommandation : envisagez de supprimer l’optimisation de la recherche de la table. Avant de supprimer l’optimisation de la recherche, déterminez si la table existe uniquement à des fins de reprise après sinistre ou si elle est utilisée par d’autres comptes Snowflake dans le cadre d’un partage de données, ce qui pourrait expliquer pourquoi elle n’est pas consultée fréquemment.

Par exemple, pour supprimer complètement l’optimisation de la recherche d’une table nommée t1, exécutez la commande suivante :

ALTER TABLE t1 DROP SEARCH OPTIMIZATION;
Copy
Insight : tables volumineuses qui ne font jamais l’objet d’une requête

Cet insight identifie les grandes tables qui n’ont pas fait l’objet d’une requête au cours de la dernière semaine par ce compte.

Recommandation : envisagez de supprimer les tables inutilisées, ce qui peut réduire les coûts de stockage sans avoir d’impact sur les charges de travail. Avant de supprimer les tables, déterminez si la table existe uniquement à des fins de reprise après sinistre ou si elle est utilisée par d’autres comptes Snowflake dans le cadre du partage de données, ce qui pourrait expliquer pourquoi elle n’est pas consultée fréquemment.

Par exemple, pour supprimer un nom de table t1, exécutez la commande suivante :

DROP TABLE t1;
Copy
Insight : tables de plus de 100GB à partir desquelles des données sont écrites mais non lues

Cet insight permet d’identifier les tables dans lesquelles des données sont écrites mais jamais lues par ce compte.

Recommandation : il pourrait être inutile de stocker des données et d’ingérer de nouvelles données dans Snowflake si les données ne sont jamais lues. Envisagez de supprimer ces tables pour économiser sur les coûts de stockage ou arrêtez d’écrire de nouvelles données pour économiser sur les crédits consommés par l’ingestion. Avant de supprimer les tables, déterminez si la table existe uniquement à des fins de reprise après sinistre ou si elle est utilisée par d’autres comptes Snowflake dans le cadre du partage de données, ce qui pourrait expliquer pourquoi elle n’est pas lue.

Par exemple, pour supprimer un nom de table t1, exécutez la commande suivante :

DROP TABLE t1;
Copy
Insight : tables permanentes à courte durée de vie

Cet insight permet d’identifier les tables de plus de 100 GB qui ont été supprimées dans les 24 heures suivant leur création.

Recommandation : si les données ne doivent être conservées que pendant une courte période, envisagez d’utiliser une table temporaire ou une table transitoire pour les tables futures. L’utilisation d’une table temporaire ou d’une table temporaire peut vous aider à économiser sur les coûts de Fail-safe et Time Travel.

Par exemple, pour créer une nouvelle table temporaire t1, exécutez la commande suivante :

CREATE TRANSIENT TABLE t1;
Copy

Optimisation des coûts des services Cloud

Si vous constatez que votre utilisation des services Cloud est plus élevée que prévu, vérifiez si votre utilisation de Snowflake suit l’un des modèles suivants. Chaque modèle comprend une recommandation qui peut vous aider à réduire les coûts associés aux services Cloud.

Modèle : requêtes bloquées en raison de verrous de transactions

Les commandes de mise à jour et de fusion placent un verrou de transaction sur une table, ce qui empêche les autres commandes de s’exécuter sur cette table jusqu’à ce que le verrou soit libéré. Les requêtes consomment des crédits de services Cloud dans l’attente de la libération d’un verrou. Plus les requêtes restent longtemps sur la couche de services Cloud à attendre le verrouillage, plus elles consomment de crédits.

Recommandation : les verrous de transaction se produisent souvent lorsque des utilisateurs exécutent des commandes concurrentes de mise à jour/fusion sur une même table, en particulier lorsque chaque commande ne met à jour que quelques lignes. Vous pouvez réduire ces verrous en utilisant une commande par lot plutôt que des mises à jour individuelles. Dans le cadre de cette stratégie, vous procédez comme suit :

  1. Utilisez une instruction INSERT par lot pour charger de nouvelles données dans une table temporaire. Évitez d’utiliser une insertion à une seule ligne. Même les appels API qui chargent de nouvelles données en continu doivent être conçus de manière à soumettre des insertions par lots plutôt que des insertions à une seule ligne.

  2. Utilisez la table temporaire pour mettre à jour/fusionner la table de destination.

Si la source envoie de nouvelles données en continu tout au long de la journée, envisagez d’utiliser une tâche pour mettre à jour la table de destination de manière périodique.

Modèle : commandes de copie peu sélectives

L’exécution des commandes de copie consiste à répertorier les fichiers d’Amazon Simple Storage Service (S3). Étant donné que répertorier des fichiers n’utilise que le calcul des services Cloud, l’exécution de commandes de copie peu sélectives peut entraîner une utilisation élevée des services Cloud.

Recommandation : envisagez de modifier la structure de votre compartiment S3 pour y inclure une sorte de préfixe de date, afin de ne répertorier que les fichiers ciblés dont vous avez besoin.

Modèle : opérations DDL à haute fréquence et clonage

Les opérations en langage de définition de données (DDL), en particulier le clonage, sont entièrement des opérations de métadonnées, ce qui signifie qu’elles n’utilisent que le calcul des services Cloud. La création ou la suppression fréquente de schémas ou de tables de grande taille, ou le clonage de bases de données à des fins de sauvegarde, peuvent entraîner une utilisation importante des services Cloud.

Recommandation : le clonage n’utilise qu’une fraction des ressources nécessaires pour effectuer des copies profondes, vous devriez donc continuer à cloner. Vérifiez vos modèles de clonage pour vous assurer qu’ils sont aussi granulaires que possible et qu’ils ne sont pas exécutés trop fréquemment. Par exemple, vous pouvez souhaiter cloner uniquement des tables individuelles plutôt qu’un schéma entier.

Modèle : fréquence élevée, requêtes simples

La consommation de services Cloud par une simple requête est négligeable, mais l’exécution de requêtes telles que SELECT 1, SELECT sequence1.NEXTVAL ou SELECT CURRENT_SESSION() à une fréquence extrêmement élevée (des dizaines de milliers de fois par jour) peut entraîner une utilisation importante des services Cloud.

Recommandation : vérifiez la fréquence de vos requêtes et déterminez si elle est adaptée à votre cas d’utilisation. Si vous observez une fréquence élevée de requêtes SELECT CURRENT_SESSION() provenant d’outils partenaires utilisant le pilote JDBC, confirmez que le partenaire a mis à jour son code pour utiliser la méthode getSessionId() dans l’interface SnowflakeConnection. Cela permet de tirer parti de la mise en cache et de réduire l’utilisation des services Cloud.

Modèle : requêtes INFORMATION_SCHEMA à haute fréquence

Les requêtes portant sur Schéma d’information de Snowflake ne consomment que les ressources des services Cloud. La consommation de services Cloud par une seule requête sur les vues INFORMATION_SCHEMA peut être négligeable, mais l’exécution de ces requêtes à une fréquence extrêmement élevée (des dizaines de milliers de fois par jour) peut entraîner une utilisation importante des services Cloud.

Recommandation : vérifiez la fréquence de vos requêtes et déterminez si elle est adaptée à votre cas d’utilisation. Vous pouvez également interroger une vue dans le schéma ACCOUNT_USAGE au lieu d’une vue INFORMATION_SCHEMA. L’interrogation du schéma ACCOUNT_USAGE utilise un entrepôt virtuel plutôt que des services Cloud.

Modèle : commandes SHOW à haute fréquence (par des applications de données et des outils tiers)

Les commandes SHOW sont entièrement des opérations de métadonnées, ce qui signifie qu’elles ne consomment que des ressources de services Cloud. Ce modèle se produit généralement lorsque vous avez créé une application basée sur Snowflake qui exécute des commandes SHOW à une fréquence élevée. Ces commandes peuvent également être lancées par des outils tiers.

Recommandation : vérifiez la fréquence de vos requêtes et déterminez si elle est adaptée à votre cas d’utilisation. Dans le cas d’outils partenaires, contactez votre partenaire pour savoir s’il a l’intention d’adapter son utilisation.

Modèle : insertions d’une seule ligne et schémas fragmentés (par les applications de données)

Snowflake n’étant pas un système OLTP, les insertions d’une seule ligne sont sous-optimales et peuvent consommer d’importantes ressources de services Cloud.

La création d’une application de données qui définit un schéma par client peut entraîner plusieurs charges de données dans un laps de temps donné, ce qui peut se traduire par une forte consommation de services Cloud.

Ce modèle se traduit également par un nombre beaucoup plus important de métadonnées que Snowflake doit maintenir, et les opérations sur les métadonnées consomment des ressources des services Cloud. Chaque opération sur les métadonnées consomme individuellement des ressources minimes, mais la consommation peut être importante dans l’ensemble.

Recommandation : en général, il est préférable d’effectuer des chargements par lots ou en masse plutôt que des insertions d’une seule ligne.

L’utilisation d’un schéma partagé est nettement plus efficace, ce qui permet de réduire les coûts. Vous voudrez probablement regrouper toutes les tables sur customer_ID et utiliser des vues sécurisées.

Modèle : requêtes SQL complexes

Les requêtes peuvent consommer beaucoup de calcul de services Cloud si elles comprennent un grand nombre de jointures/produits cartésiens, si elles utilisent l’opérateur IN avec de grandes listes ou s’il s’agit de requêtes très volumineuses. Ces types de requêtes ont tous des durées de compilation élevées.

Recommandation : passez en revue vos requêtes pour confirmer qu’elles font ce que vous voulez qu’elles fassent. Snowflake prend en charge ces requêtes et ne vous facturera que les ressources consommées.

Langage: Français