Comprendre l’utilisation du flocon de neige Partie 3

Comprendre l’utilisation du flocon de neige Partie 3


Cet article sur le profilage des requêtes est le troisième d’une série en trois parties pour vous aider à utiliser les fonctionnalités et les données de Snowflake. Schéma d’informations pour mieux comprendre et efficacement Snowflake.

En tant que Customer Success Engineer, mon travail quotidien consiste à aider nos clients à tirer le meilleur parti de notre service. Dans mon premier poste, j’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 mon deuxième messageje vous ai montré comment maîtriser votre utilisation de l’espace de stockage.

Dans ce dernier article, j’approfondirai la compréhension du profilage des requêtes. Pour ce faire, je vais vous montrer des exemples utilisant la famille de fonctions QUERY_HISTORY. Je vais également vous montrer une page pratique dans l’interface utilisateur qui fournit une vue graphique de chaque requête. N’oubliez pas que vous aurez besoin des privilèges Warehouse MONITOR pour effectuer les tâches décrites dans cet article. En règle générale, le rôle SYSADMIN dispose des privilèges MONITOR d’entrepôt nécessaires sur l’ensemble de votre compte ; cependant, d’autres rôles de niveau inférieur peuvent également disposer des privilèges nécessaires.

Prêt à commencer? Nous y voilà!

Profilage de l’historique des requêtes

Le profilage des requêtes est peut-être l’un des sujets les plus populaires sur lesquels je réponds aux questions. De nombreux clients souhaitent améliorer les performances de leurs requêtes. Bien que chaque équipe de développement doive s’efforcer de refactoriser périodiquement son code, beaucoup ont du mal à déterminer par où commencer. Passer par cette analyse devrait aider à identifier un bon point de départ.

Regardons une syntaxe, selon notre documentation pour QUERY_HISTORY:

select *
from table(information_schema.query_history(dateadd('hours',-1, current_timestamp()),current_timestamp()))
order by start_time;

Cette requête fournit une vue de toutes les requêtes exécutées par l’utilisateur actuel au cours de l’heure écoulée :

Profilage des requêtes - Historique

Nous pouvons également tirer parti des fonctions associées QUERY_HISTORY pour affiner votre objectif :

  • QUERY_HISTORY_BY_SESSION
  • QUERY_HISTORY_BY_USER
  • QUERY_HISTORY_BY_WAREHOUSE

Celles-ci sont particulièrement utiles si vous avez identifié des problèmes de flux de travail spécifiques que vous devez résoudre.

Astuce de profilage n° 1 : Utiliser HASH()

Maintenant, un conseil particulièrement utile : l’utilisation de HASH sur la colonne QUERY_TEXT peut vous aider à consolider et à regrouper des requêtes similaires (la fonction HASH renverra le même résultat si des requêtes sont exactement identiques). En règle générale, l’identification des groupes de requêtes et la recherche de la durée d’exécution maximale et minimale des requêtes devraient vous aider à trier des flux de travail spécifiques. Dans l’exemple ci-dessous, je fais une analyse sur le temps moyen de compilation et d’exécution. De plus, je collecte un nombre de requêtes avec la même syntaxe :

select hash(query_text), query_text, count(*), avg(compilation_time), avg(execution_time)
from table(information_schema.query_history(dateadd('hours',-1,current_timestamp()),current_timestamp()))
group by hash(query_text), query_text
order by count(*) desc;

Production:

Profilage de requête - Groupes de requêtes

L’utilisation de la fonction HASH permet en outre à un utilisateur d’interroger facilement une instance particulière de cette requête à partir de la fonction QUERY_HISTORY. Dans l’exemple ci-dessus, je pourrais rechercher des requêtes spécifiques où le HASH du texte de la requête est converti en valeur -102792116783286838. Par exemple:

select *
from table(information_schema.query_history())
where hash(query_text) = -102792116783286838
order by start_time;

Production:

Profilage de requête - Requête unique (SQL)

Le résultat ci-dessus vous montre toutes les fois où vous avez émis cette requête particulière (remontant à 7 jours). Portez une attention particulière aux colonnes suivantes :

  • COMPILATION_TIME
  • TEMPS D’EXÉCUTION
  • FILE D’ATTENTE (fois)

Si une requête passe plus de temps à compiler (COMPILATION_TIME) qu’à exécuter (EXECUTION_TIME), il est peut-être temps de revoir la complexité de la requête. Le compilateur de requêtes de Snowflake optimisera votre requête et identifiera toutes les ressources nécessaires pour effectuer la requête de la manière la plus efficace. Si une requête est trop complexe, le compilateur doit passer plus de temps à trier la logique de la requête. Examinez votre requête et voyez s’il existe de nombreuses sous-requêtes imbriquées ou des jointures inutiles. De plus, s’il y a plus de colonnes sélectionnées que nécessaire, alors soyez peut-être plus précis dans votre instruction SELECT en spécifiant certaines colonnes.

Le temps QUEUED est intéressant car il peut être un indicateur de la taille de votre entrepôt et de la charge de travail que vous avez placée sur l’entrepôt. Snowflake est capable d’exécuter des requêtes simultanées et fait un très bon travail en le faisant. Cependant, il y aura des moments où une requête particulièrement volumineuse nécessitera plus de ressources et, par conséquent, entraînera la mise en file d’attente d’autres requêtes en attendant que les ressources de calcul soient libérées. Si vous constatez que de nombreuses requêtes passent beaucoup de temps dans la file d’attente, vous pouvez :

  • Dédiez un entrepôt à ces grandes requêtes complexes en cours d’exécution, ou
  • Utilisez la fonctionnalité d’entrepôt multi-clustering de Snowflake pour permettre une exécution plus parallèle des requêtes. Pour plus d’informations sur les entrepôts multi-clusters, consultez le Documentation sur les flocons de neige.

Dans les récentes mises à jour de nos fonctions QUERY_HISTORY_* Information Schema, nous avons ajouté plus de références de métadonnées aux résultats et vous devriez maintenant avoir une gamme de métadonnées à votre disposition :

  • ID DE SESSION
  • USER_NAME, ROLE_NAME
  • DATABASE_NAME, SCHEMA_NAME
  • WAREHOUSE_NAME , WAREHOUSE_SIZE , WAREHOUSE_TYPE

Ces colonnes vous aideront à identifier l’origine des requêtes et à affiner votre workflow. Un exemple simple serait de trouver l’entrepôt avec les requêtes les plus longues. Ou recherchez l’utilisateur qui émet généralement ces requêtes.

Astuce de profilage n° 2 : Utiliser l’interface utilisateur

Une fois que vous avez identifié une requête particulière que vous souhaitez examiner, vous pouvez copier sa valeur QUERY_ID et utiliser cette valeur pour afficher son plan de requête dans le profil de requête de Snowflake. Pour cela, cliquez sur le Histoire , ajoutez un filtre QUERY ID et collez le QUERY_ID en question. Par exemple:

Profil de requête - Utilisation de l'interface utilisateur

Indice: Si vous ne voyez pas de résultat, assurez-vous que vous utilisez un rôle avec le privilège MONITOR d’entrepôt nécessaire (par exemple, SYSADMIN ou ACCOUNTADMIN) et que vous avez sélectionné le bon QUERY ID.

Une fois la recherche terminée, vous devriez pouvoir cliquer sur le lien fourni sous le ID de requête pour accéder à la page de détail de la requête :

Profilage de requête - Page de profil dans l'interface utilisateur

Cliquez maintenant sur le Profil languette.

Vous devriez voir une visualisation du profil de requête. Dans mon exemple, Snowflake montre que cette requête particulière s’est exécutée en deux étapes :

Étape 1:

Profilage de requête - Étape 1 du profil dans l'interface utilisateur

Étape 2:

Profilage de requête - Étape 2 du profil dans l'interface utilisateur

La documents en ligne fournit des détails détaillés sur la façon d’interpréter cette vue. Portez une attention particulière à la orange barre dans cette vue. Il indique le pourcentage de temps de requête global consacré à ce processus particulier. Dans ce cas, nous pouvons voir que notre requête a passé la plupart du temps à lire les données de la table. Si nous exécutons cette requête assez souvent, nous devrions voir ce temps diminuer car nous lirons les données du cache au lieu du disque.

Conclusion

En utilisant l’interface utilisateur et les fonctions et vues du schéma d’informations décrites dans cet article, vous pouvez utiliser le profilage des requêtes pour vous aider à comprendre votre flux de travail actuel et identifier les requêtes qui peuvent être mieux optimisées. Cela vous aidera à économiser de l’argent à long terme et à améliorer votre expérience utilisateur. Snowflake continuera à investir dans des outils comme ceux-ci pour aider nos utilisateurs à mieux comprendre et utiliser notre plateforme.

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

J’espère que cet article et cette série vous ont inspiré la manière dont vous souhaitez gérer votre instance Snowflake. Il existe de nombreuses options avec lesquelles jouer et elles sont toutes destinées à vous fournir 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! Nous serions ravis de vous aider dans votre voyage vers le cloud.

Pour plus d’informations, n’hésitez pas à nous contacter au [email protected]. 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.