Surveiller les performances des tables dynamiques¶

La surveillance des performances vous permet d’effectuer les tâches suivantes :

Identifier les actualisations de table dynamique lentes ou coûteuses.
Diagnostiquer les goulots d’étranglement.
Mesurer l’impact des optimisations.

Cette rubrique explique ce qu’il faut rechercher pour surveiller les performances des tables dynamiques et comment diagnostiquer les problèmes. Pour plus d’informations sur les outils de surveillance, voir Surveiller les tables dynamiques.

Astuce

Pour un exemple pratique, voir Tutoriel : Optimiser les performances des tables dynamiques pour les workflows SCD de type 1.

Indicateurs de performance clés¶

Pour surveiller les performances des tables dynamiques, concentrez-vous sur les métriques décrites dans cette section.

Durée de l’actualisation¶

La durée d’actualisation mesure le temps nécessaire à chaque actualisation. Pour repérer la dégradation des performances, suivez la durée d’actualisation dans le temps.

Signaux d’avertissement :

La durée augmente avec le temps : L’augmentation des volumes de données ou la dégradation de la localité des données peuvent entraîner une augmentation constante des durées d’actualisation.
La durée approche la latence cible : Lorsque les actualisations prennent presque autant de temps que votre latence cible, vous risquez de ne pas répondre aux exigences de niveau d’actualisation des données.
Variation élevée de la durée : De grandes modifications de la durée d’actualisation peuvent indiquer des pics de charge de travail ou des conflits de ressources.

Pour visualiser la durée d’actualisation, voir Surveillez le statut de actualisation de vos tables dynamiques.

Métriques de latence¶

Les métriques de latence montrent dans quelle mesure votre table dynamique atteint son objectif de niveau d’actualisation. Pour plus d’informations sur le fonctionnement de la latence cible, voir Comprendre la latence cible des tables dynamiques.

Métriques clés :

Latence réelle : Le temps entre le moment où les données sources ont changé et le moment où la table dynamique a reflété ces changements.
Ratio de temps dans la latence cible : Pourcentage de temps pendant lequel une table est restée dans sa latence cible. Un ratio inférieur à un indique que le pipeline ne respecte pas son objectif de niveau d’actualisation.
Latence maximale : La latence réelle la plus longue au cours d’une période donnée.

Pour afficher les métriques de latence, voir Surveillez le statut de actualisation de vos tables dynamiques.

Statistiques de partition¶

Pour les actualisations incrémentielles, le nombre de partitions analysées doit être proportionnel aux données qui ont changé, et non à la taille totale de la table. Des analyses de partition élevées indiquent une faible localité des données.

Signaux d’avertissement :

Analyse d’un pourcentage élevé de partitions totales lors de l’actualisation incrémentielle.
Analyses de partition augmentant avec le temps sans croissance correspondante des données.

Pour afficher les statistiques de partitions, voir Analyser les profils de requête.

Pour obtenir des conseils sur l’amélioration de la localité des données, voir Améliorer la localité des données.

Actualiser le mode¶

Le mode d’actualisation affecte directement les performances. Vérifiez que votre table dynamique utilise le mode attendu.

Pour vérifier le mode d’actualisation, utilisez SHOW DYNAMIC TABLES et examinez les colonnes refresh_mode et refresh_mode_reason. Dans Snowsight, affichez le mode d’actualisation dans l’en-tête de l’objet.

Pour obtenir des conseils sur le choix du mode d’actualisation approprié, voir Sélectionner un mode d’actualisation.

Diagnostic des actualisations lentes¶

Lorsque les actualisations prennent plus de temps que prévu, procédez comme suit pour identifier la cause :

Vérifiez l’historique d’actualisation pour détecter les tendances en matière de durée d’actualisation, telles que les augmentations graduelles ou les hausses soudaines (Surveillez le statut de actualisation de vos tables dynamiques).
Examinez le profil de requête pour identifier les goulots d’étranglement (Analyser les profils de requête) :
- Les analyses de partition élevées suggère une mauvaise localité des données.
- Les octets déversés indiquent que l’entrepôt est trop petit.
- Des opérateurs spécifiques qui prennent beaucoup de temps peuvent indiquer une opportunité d’optimiser votre requête de table dynamique.
Vérifiez si la latence est systématiquement supérieure à votre cible, ce qui indique que les actualisations peuvent ne pas suivre votre volume de données (Surveillez le statut de actualisation de vos tables dynamiques).
Examinez les dépendances en amont pour vérifier si les tables en amont provoquent des retards ou produisent un volume élevé de modifications.

Dans la vue Graph dans Snowsight, recherchez les conditions suivantes :
- Tables en amont exécutant une actualisation (affichées avec le statut executing).
- Tables en amont en échec ou suspendues.
- Actualisation des tables en amont plus longue que d’habitude.
Pour accéder à la vue Graph, voir Voir le graphique des tables connectées à vos tables dynamiques.
Vérifiez le volume des modifications traitées par la table dynamique, car des volumes élevés de modifications des dépendances en amont peuvent ralentir les actualisations.

Utilisez la fonction DYNAMIC_TABLE_REFRESH_HISTORY pour voir combien de lignes ont été modifiées dans les actualisations récentes :
```
SELECT
  name,
  data_timestamp,
  statistics:numInsertedRows::INT AS rows_inserted,
  statistics:numDeletedRows::INT AS rows_deleted,
  refresh_action
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
ORDER BY data_timestamp DESC
LIMIT 10;
```
Copy
Lorsque le volume de modification est élevé par rapport à la taille totale de la table (plus de 5 % des lignes de la table), envisagez plutôt d’utiliser le mode d’actualisation complet.

Modèles communs et actions recommandées¶

La durée d’actualisation est stable, mais la latence est élevée : Votre latence cible est probablement trop ambitieuse compte tenu de la taille actuelle de l’entrepôt et du volume de données. Les actualisations s’effectuent correctement, mais ne parviennent pas à suivre les modifications entrantes. Vérifiez si votre latence cible et les ressources de l’entrepôt correspondent à votre volume de données.
Les pics de durée d’actualisation et les octets déversés sont élevés : L’entrepôt ne dispose pas de la mémoire suffisante pour traiter l’actualisation, soit parce que l’entrepôt est trop petit, soit parce que d’autres requêtes s’exécutent en même temps. Augmentez la taille de l’entrepôt ou déplacez les actualisations de tables dynamiques vers un entrepôt dédié.
Les analyses de partition augmentent avec le temps, mais le volume de données reste le même : La localité des données est faible, ce qui oblige Snowflake à analyser plus de partitions que nécessaire. Vérifiez vos clés de clustering et la localité des données. Vérifiez également si les modifications en amont affectent de nombreuses partitions dispersées plutôt que quelques partitions contiguës.
Chaque actualisation traite une grande partie de la table (plus de 5 % des lignes ou partitions) : L’actualisation incrémentielle offre peu d’avantages lorsque la plupart des tables changent fréquemment. Passez en mode d’actualisation complet ou concevez à nouveau votre pipeline pour réduire la quantité de données modifiées à chaque actualisation.

En fonction de vos résultats, appliquez les correctifs appropriés à partir de Optimiser les performances des tables dynamiques.

Note

Les actualisations ignorées ou échouées sont généralement dues à des problèmes de configuration et non à des problèmes de performances. Voir Troubleshooting skipped or failed dynamic table refreshes.

Analyser les profils de requête¶

Le profil de requête affiche des statistiques d’exécution détaillées pour chaque actualisation. Lorsqu’une actualisation est lente, le profil de requête vous aide à identifier les opportunités d’optimisation.

Pour accéder au profil de requête :

Accédez à Transformation » Dynamic Tables.
Sélectionnez la table dynamique et allez dans l’onglet Refresh History.
Sélectionnez Show query profile à côté de l’actualisation que vous souhaitez analyser.

Tout d’abord, obtenez l’ID de requête de l’historique d’actualisation :

SELECT
  name,
  refresh_start_time,
  query_id
FROM TABLE(INFORMATION_SCHEMA.DYNAMIC_TABLE_REFRESH_HISTORY(
  NAME => 'my_dynamic_table'
))
WHERE state = 'SUCCEEDED'
ORDER BY refresh_start_time DESC
LIMIT 5;

Copy

Analysez ensuite le profil de la requête avec la fonction GET_QUERY_OPERATOR_STATS :

SELECT *
FROM TABLE(GET_QUERY_OPERATOR_STATS('<query_id>'));

Copy

Que rechercher ?¶

Partitions analysées vs. supprimées : Lorsque les analyses de partition sont élevées par rapport au nombre total de partitions, la cause est généralement une localité des données faible ou un clustering manquant.
Distribution temporelle : Vérifiez quels opérateurs consomment le plus de temps. Les opérateurs qui prennent un temps disproportionné peuvent indiquer une opportunité d’optimiser votre requête. Voir Optimiser les requêtes pour l’actualisation incrémentielle pour des conseils spécifiques à l’opérateur.
Octets déversés sur le stockage local ou le stockage distant : Les octets élevés déversés indiquent souvent que l’entrepôt est trop petit pour la charge de travail d’actualisation ou que les autres requêtes exécutées sur le même entrepôt réduisent la mémoire disponible pour les actualisations. Envisagez d’augmenter la taille de l’entrepôt ou d’exécuter les actualisations de tables dynamiques sur un entrepôt dédié pour réduire les conflits.

Pour plus de conseils sur la manière de résoudre les problèmes trouvés dans le profil de la requête, voir Optimiser les performances des tables dynamiques.

Surveillance de l’utilisation de l’entrepôt¶

Pour vérifier si votre entrepôt peut gérer la charge de travail de vos tables dynamiques et trouver des moyens de réduire les coûts, surveillez l’utilisation de l’entrepôt.

Métriques clés à surveiller¶

Octets déversés : Les octets déversés sur le stockage local ou le stockage distant signifient que l’entrepôt est peut-être trop petit. Envisagez d’augmenter la taille de l’entrepôt. Pour plus de détails sur l’identification et le dépannage des octets déversés, voir Recherche de requêtes qui se déversent sur le stockage.
**Utilisation de l’entrepôt* : Vérifiez si l’entrepôt dispose de suffisamment de ressources pour actualiser les charges de travail. Une faible utilisation signifie que vous avez peut-être un entrepôt surdimensionné. Des temps de file d’attente élevés signifient que votre entrepôt est trop petit ou qu’il exécute trop de requêtes simultanées.
Mise en file d’attente des requêtes : Les requêtes en file d’attente retardent l’actualisation. Si la file d’attente est fréquemment actualisée, augmentez la taille de l’entrepôt, utilisez un entrepôt dédié pour les actualisations des tables dynamiques ou envisagez un entrepôt multi-clusters pour gérer des charges de travail variables.
Utilisation du crédit : Suivez les crédits pour équilibrer les performances et les coûts. Effectuez une surveillance régulière pour trouver des possibilités de modifier la taille des entrepôts ou d’ajuster les calendriers d’actualisation.

Pour visualiser l’utilisation de l’entrepôt et les temps de file d’attente, voir Réduction des files d’attente. Optimisez la configuration de l’entrepôt pour les tables dynamiques avec Optimiser les performances des tables dynamiques.

Surveiller les dépendances¶

Les dépendances entre les tables dynamiques peuvent affecter les performances. Les problèmes de performance dans les tables en amont se répercutent sur les tables en aval, car une table en aval doit attendre que les tables en amont finalisent leur actualisation avant de pouvoir démarrer sa propre actualisation.

Pour diagnostiquer les problèmes de performance liés aux dépendances en amont, voir Diagnostic des actualisations lentes.

Pour voir le graphique des dépendances, voir Voir le graphique des tables connectées à vos tables dynamiques.

Configurer des alertes en cas de problèmes de performance¶

Vous pouvez configurer des alertes pour vous informer lorsque les performances se dégradent. Nous vous recommandons de créer des alertes pour les conditions suivantes :

La durée d’actualisation dépasse un certain seuil.
La latence manque systématiquement la cible.

Les alertes utilisent des tables d’événements pour suivre les événements d’actualisation. Pour les instructions de configuration, voir Surveillance des tables d’événements et alertes pour les tables dynamiques.