Profilage de stockage : Comprendre votre utilisation de Snowflake

Profilage de stockage : Comprendre votre utilisation de Snowflake


Cet article est le deuxième d’une série en trois parties pour vous aider à utiliser le schéma d’information de Snowflake pour mieux comprendre et utiliser efficacement Snowflake.

En tant que Customer Success Engineer, mon travail quotidien consiste à aider nos clients à tirer le meilleur parti de notre service. Et je transmets maintenant une partie de ce que j’ai appris pour vous aider à devenir plus autonome. Dans mon premier postej’ai discuté de la maîtrise de votre utilisation des ressources de calcul en utilisant diverses vues et fonctions de schéma d’informations pour profiler l’utilisation de votre entrepôt virtuel.

Dans cet article, je vous explique en profondeur comment vous utilisez le stockage de données dans Snowflake au niveau de la base de données, de l’étape et de la table. Pour ce faire, je vais vous montrer des exemples de deux fonctions et une vue fournies dans le schéma d’informations pour surveiller l’utilisation du stockage. Je vais également vous montrer une page pratique dans l’interface utilisateur qui fournit une vue au niveau du compte de votre stockage. N’oubliez pas que vous avez besoin d’un accès ACCOUNTADMIN pour effectuer l’une des tâches décrites dans cet article.

Commençons.

Profilage de stockage récapitulatif dans l’interface utilisateur

Avant de plonger dans notre analyse détaillée du stockage des données, jetons un coup d’œil à la vue récapitulative du stockage au niveau du compte fournie par Snowflake. En tant qu’utilisateur avec le rôle ACCOUNTADMIN, vous pouvez accéder au Compte dans l’interface utilisateur Snowflake pour obtenir un aperçu visuel du stockage de données pour votre compte.

profiling storage ui screenshot
Cette page fournit une vue, par mois, de l’utilisation moyenne et quotidienne du stockage sur l’ensemble de votre compte. Vous pouvez utiliser les filtres de la page pour filtrer par base de données, étape Snowflake et données conservées dans Fail-safe (pour la reprise après sinistre).

Profilage de stockage détaillé à l’aide du schéma d’informations

Le schéma d’informations Snowflake fournit deux fonctions et une vue pour surveiller le stockage des données détaillées au niveau de la base de données, de l’étape et de la table :

  • DATABASE_STORAGE_USAGE_HISTORY (fonction)
  • STAGE_STORAGE_USAGE_HISTORY (fonction)
  • TABLE_STORAGE_METRICS (affichage)

La fonction de table DATABASE_STORAGE_USAGE_HISTORY affiche l’état et l’utilisation de votre base de données pour toutes les bases de données de votre compte ou une base de données spécifiée. Voici un exemple d’utilisation au cours des 10 derniers jours pour une base de données nommée sales:

use warehouse mywarehouse;

select * from
table(sales.information_schema.database_storage_usage_history(dateadd('days',-10,current_date()),current_date(), ‘SALES’));

profiling storage query1

Notez que la capture d’écran ci-dessus n’affiche que certaines des colonnes de sortie. Pour plus de détails sur la sortie, consultez le documents en ligne. En outre, selon la documentation Snowflake :

Si une base de données a été supprimée et que sa période de conservation des données est passée (c’est-à-dire que la base de données ne peut pas être récupérée à l’aide de Time Travel), le nom de la base de données est signalé comme DROPPED_identifiant.

À la base, l’information la plus utile de cette fonction est la croissance moyenne de votre base de données. Gardez à l’esprit que la sortie inclut à la fois AVERAGE_DATABASE_BYTES et AVERAGE_FAILSAFE_BYTES. Tirer parti de ces points de données pour dériver un pourcentage de Sécurité intégrée sur la taille réelle de la base de données devrait vous donner une idée du montant que vous devriez investir dans votre stockage à sécurité intégrée. Si certaines données ne sont pas critiques et ne nécessitent pas de sécurité intégrée, essayez de définir ces tables sur transitoire. Des informations plus détaillées sur les données de sécurité intégrée sont fournies dans TABLE_STORAGE_METRICS, que nous examinerons plus en détail plus tard dans cet article.

Examinons ensuite STAGE_STORAGE_USAGE_HSTORY. Cette fonction vous indique la quantité de stockage utilisée pour les fichiers préparés à travers tout vos emplacements de staging Snowflake, y compris nommés, internes étapes. Notez que cette fonction ne permet pas d’interroger le stockage sur des étapes individuelles.

Voici un exemple d’utilisation d’un fichier intermédiaire au cours des 10 derniers jours (en utilisant la même base de données, salesde l’exemple précédent) :

select * from
table(sales.information_schema.stage_storage_usage_history(dateadd('days',-10,current_date()),current_date()));

profiling storage query2

Notez que la capture d’écran ci-dessus n’affiche que certaines des colonnes de sortie. Pour plus de détails sur la sortie, consultez le documents en ligne.

Notez également que vous ne pouvez interroger que jusqu’à 6 mois de données à l’aide de cette fonction. Certains de nos utilisateurs aiment utiliser les stages Snowflake pour stocker leurs données brutes. Par exemple, un utilisateur exploite les emplacements de transfert de table pour son stockage de données brutes au cas où il aurait besoin d’accéder aux données à l’avenir. Il n’y a rien de mal à cette approche, et puisque Snowflake compresse vos fichiers de données mis en scène, cela a certainement du sens ; cependant, seuls les 6 derniers mois de stockage de données par étapes sont disponibles.

Enfin, la vue TABLE_STORAGE_METRICS affiche votre stockage au niveau de la table au moment de l’exécution. Il s’agit d’un instantané de votre stockage de table qui inclut votre stockage actif et à sécurité intégrée. De plus, vous pouvez également dériver le stockage cloné en utilisant la colonne CLONE_GROUP_ID. À ce jour, il s’agit du niveau de stockage le plus granulaire disponible pour les utilisateurs.

Voici un exemple d’utilisation générale (utilisant le sales base de données):

select *
from sales.information_schema.table_storage_metrics
where table_catalog = 'SALES';

profiling storage query3

Notez que la capture d’écran ci-dessus ne montre qu’une partie des colonnes de sortie. Pour plus de détails sur la sortie, consultez le documents en ligne.

Une analyse intéressante avec laquelle j’ai aidé nos clients est de déterminer quelle part de leur stockage de table est basée sur des données clonées. Dans Snowflake, le clonage des données n’a aucun coût supplémentaire (jusqu’à ce que les données soient modifiées ou supprimées) et cela se fait très rapidement. Tous les utilisateurs bénéficient du « clonage sans copie », mais certains sont curieux de savoir exactement quel pourcentage de leur stockage de table provient réellement de données clonées. Pour le déterminer, nous allons tirer parti de la colonne CLONE_GROUP_ID dans TABLE_STORAGE_METRICS.

Par exemple (en utilisant une base de données nommée concurrency_wh):

with storage_sum as (
  select clone_group_id,
         sum(owned_active_and_time_travel_bytes) as owned_bytes,
         sum(active_bytes) + sum(time_travel_bytes) as referred_bytes
  from concurrency_wh.information_schema.table_storage_metrics
  where active_bytes > 0
  group by 1)
select * , referred_bytes / owned_bytes as ratio
from storage_sum
where referred_bytes > 0 and ratio > 1
order by owned_bytes desc;

profiling storage query4

Le ratio dans la requête ci-dessus vous donne une idée de la quantité de données d’origine à laquelle le clone fait référence. En général, lorsque vous créez un clone d’une table, le CLONE_GROUP_ID de la table d’origine est affecté à la nouvelle table clonée. Lorsque vous exécutez DML sur la nouvelle table, votre valeur REFERRED_BYTES est mise à jour. Si vous rejoignez CLONE_GROUP_ID dans la vue d’origine, vous obtenez la sortie de la table d’origine avec la table clonée. Un ratio de 1 dans l’exemple ci-dessus signifie que les données de la table ne sont pas clonées.

Si vous avez besoin de trouver le nom exact de la table à partir de la requête ci-dessus, joignez simplement le CTE à la vue TABLE_STORAGE_METRICS et demandez la colonne TABLE_NAME.

Par exemple (en utilisant la même base de données, concurrency_whde l’exemple précédent) :

with storage_sum as (
  select clone_group_id,
         sum(owned_active_and_time_travel_bytes) as owned_bytes,
         sum(active_bytes) + sum(time_travel_bytes) as referred_bytes
  from concurrency_wh.information_schema.table_storage_metrics
  where active_bytes > 0
  group by 1)
select b.table_name, a.* , referred_bytes / owned_bytes as ratio
from storage_sum a
join concurrency_wh.information_schema.table_storage_metrics b
on a.clone_group_id = b.clone_group_id
where referred_bytes > 0 and ratio > 1
order by owned_bytes desc;

Profilage de stockage - Exemple

Conclusion

En utilisant l’interface utilisateur et les fonctions et vues du schéma d’informations décrites dans cet article, vous pouvez profiler votre stockage de données pour vous aider à contrôler vos coûts de stockage et à comprendre comment votre entreprise se développe au fil du temps. C’est une bonne idée de prendre régulièrement des instantanés de votre stockage afin de pouvoir analyser votre croissance d’un mois à l’autre. Cela vous aidera à la fois à formuler des informations sur l’utilisation et à prendre des mesures.

Pour en savoir plus sur ce sujet, consultez notre documentation en ligne :

J’espère que cet article vous a donné de bonnes idées sur la façon de gérer votre instance Snowflake. Recherchez la partie 3 de cette série dans les semaines à venir où je vous montrerai comment analyser les performances de vos requêtes. Comme déjà indiqué dans les parties 1 et 2, il existe de nombreuses options avec lesquelles jouer dans Snowflake et elles sont toutes destinées à vous donner la flexibilité et le contrôle dont vous avez besoin pour utiliser au mieux Snowflake. S’il vous plaît partagez vos pensées avec nous!

Aussi, pour plus d’informations, n’hésitez pas à nous contacter au [email protected]. Nous serions ravis de vous aider dans votre voyage vers le cloud. Et gardez un œil sur ce blog ou suivez-nous sur Twitter (@flocondeneige) pour suivre toutes les nouvelles et les événements ici à Snowflake Computing.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.