Analyse des requêtes à l’aide du profil de requête

Le profil de requête, disponible via l”Classic Console, fournit les détails d’exécution d’une requête. Pour la requête sélectionnée, il fournit une représentation graphique des principaux composants du plan de traitement de la requête, avec des statistiques pour chaque composant, ainsi que des détails et des statistiques pour la requête globale.

Dans ce chapitre :

Introduction

Quand utiliser le profil de requête ?

Le profil de requête est un outil puissant permettant de comprendre la mécanique des requêtes. Il peut être utilisé quand vous avez besoin d’en savoir plus sur les performances ou le comportement d’une requête particulière. Il est conçu pour vous aider à repérer les erreurs classiques dans les expressions de requête SQL afin d’identifier les problèmes de performance et les possibilités d’amélioration.

D’autres informations importantes sur les requêtes individuelles sont disponibles dans les différentes colonnes des pages Worksheets Onglet Feuille de calcul et History Onglet Historique.

Comment accéder au profil de requête ?

Le profil de requête est accessible à partir de la page de détail d’une requête. Ainsi, vous pouvez accéder au profil de requête à partir de n’importe quelle page où la colonne Query ID est affichée et où vous pouvez cliquer sur les IDs de requête. Plus spécifiquement :

  • Worksheets Onglet Feuille de calcul

  • History Onglet Historique

Note

Si la colonne Query ID n’est pas affichée sur ces pages, cliquez sur le menu déroulant à côté de l’un des en-têtes de colonne de la page et, dans la liste des Columns, sélectionnez Query ID.

Pour accéder au profil d’une requête :

  1. Dans la page History Onglet Historique ou Worksheets Onglet Feuille de calcul, cliquez sur un ID de requête.

  2. La page de détail de la requête s’affiche :

    ../_images/ui-profile-detail.png
  3. Cliquez sur l’onglet Profile.

  4. Si la requête a un profil, il s’affiche (voir les captures d’écran ci-dessous).

Interface du profil de requête

Pour les besoins de ce chapitre, nous utilisons une requête d’échantillon de base SQL qui joint deux tables :

select sum(j)
from x join y using (i)
where j > 300
and i < (select avg(j) from x);
Copy

La capture d’écran suivante montre le profil de cette requête :

../_images/ui-profile-step1.png

L’interface se compose des éléments principaux suivants :

Étapes:

Si la requête a été traitée en plusieurs étapes, vous pouvez basculer entre chaque étape.

Arborescence des opérateurs:

Le panneau central affiche une représentation graphique de tous les nœuds d’opérateur pour l’étape sélectionnée, y compris les relations entre chaque nœud d’opérateur.

Liste des nœuds:

Le panneau central comprend une liste repliable des nœuds d’opérateur par temps d’exécution.

Vue d’ensemble:

Le panneau de droite affiche une vue d’ensemble du profil de requête. La page passe aux détails de l’opérateur lorsqu’un nœud d’opérateur est sélectionné.

Étapes

Les requêtes sont souvent traitées en plusieurs étapes. Par exemple, notre exemple de requête a été traité en deux étapes :

  • L’étape 1 a calculé la moyenne de la colonne x.j.

  • L’étape 2 a utilisé ce résultat intermédiaire pour calculer le résultat final de la requête.

Le profil de requête affiche chaque étape de traitement dans un panneau séparé. Vous pouvez passer d’un panneau à l’autre en cliquant sur l’étape correspondante. Pour notre requête d’échantillon, cliquer sur Step 2 modifie la vue en :

../_images/ui-profile-step2.png

Arborescence des opérateurs

L’arborescence fournit une représentation graphique des nœuds d’opérateur qui composent une requête et les liens qui relient chaque opérateur :

  • Les opérateurs sont les éléments constitutifs fonctionnels d’une requête. Ils sont responsables de différents aspects de la gestion et du traitement des données, y compris l’accès aux données, leur transformation et leur mise à jour. Chaque nœud d’opérateur de l’arborescence comporte quelques attributs de base :

    <Type> [#]:

    Type d’opérateur et numéro d’ID. L’ID peut être utilisé pour identifier de manière unique un opérateur dans un profil de requête (par exemple Aggregate [5] et Join [11] dans la capture d’écran ci-dessus).

    Pour obtenir une description de tous les types, voir Types d’opérateur ci-dessous.

    Pourcentage:

    Fraction de temps que cet opérateur a consommé au cours de l’étape de recherche (p. ex. 25 % pour Aggregate [5]). Cette information se reflète également dans la barre orange au bas du nœud de l’opérateur, ce qui permet une identification visuelle facile des opérateurs dont les performances sont critiques.

    Étiquette:

    Informations complémentaires spécifiques à l’opérateur (par exemple SUM(X.J) pour Aggregate [5]).

  • Les liens représentent les données circulant entre chaque nœud d’opérateur. Chaque lien indique le nombre d’enregistrements qui ont été traités (p. ex. 41,95M de Join [11] à Aggregate [5]).

Note

Si vous utilisez un écran tactile et que l’arborescence de l’opérateur n’est pas affichée, l’interface d’événements tactiles de votre écran tactile pourrait provoquer des interférences. Pour obtenir des instructions permettant de désactiver temporairement l’interface, consultez la discussion sur le forum de la communauté Snowflake : Query profile window shows the overview, but does not show the query tree (La fenêtre de profil de requête affiche la vue d’ensemble, mais pas l’arborescence)..

Nœuds opérateur par temps d’exécution

Un panneau repliable dans l’arborescence de l’opérateur liste les nœuds par temps d’exécution par ordre décroissant, ce qui permet aux utilisateurs de localiser rapidement les nœuds les plus coûteux en termes de temps d’exécution. Le panneau liste tous les nœuds qui ont duré 1 % ou plus du temps total d’exécution de la requête (ou le temps d’exécution de l’étape de requête affichée, si la requête a été exécutée en plusieurs étapes de traitement).

En cliquant sur un nœud de la liste, l’arborescence de l’opérateur est centrée sur le nœud sélectionné.

La capture d’écran suivante montre le panneau après avoir cliqué sur l’opérateur Aggregate[5] :

../_images/ui-profile-nodes-by-execution-time.png

Vue d’ensemble du profil/détails sur l’opérateur

Le panneau de vue d’ensemble/de détail à droite fournit des informations sur les composants sélectionnés (opérateurs et liens) dans l’arborescence à gauche. Les informations affichées dépendent de si un nœud dans l’arborescence est sélectionné :

  • Initialement, aucun nœud de l’arborescence n’est sélectionné, de sorte que le panneau affiche un synthèse d’informations sur l’étape en cours.

  • Lorsqu’un composant est sélectionné en cliquant sur le nœud, le panneau affiche les informations relatives à ce composant.

Note

Après avoir cliqué sur un nœud, pour revenir à l’information de vue d’ensemble au niveau des étapes, il suffit de désélectionner le nœud en cliquant sur un espace vide autour de l’arborescence de l’opérateur.

Le volet de vue d’ensemble/de détail est divisé en trois sections :

Temps d’exécution:

Fournit des informations sur les tâches de traitement qui ont consommé du temps de requête (décrites dans Détails sur la requête/l’opérateur ci-dessous). De plus, pour les informations au niveau des étapes, il montre le statut de l’étape donnée et son temps d’exécution.

Statistiques:

Fournit des informations détaillées sur diverses statistiques (décrites dans Détails sur la requête/l’opérateur ci-dessous).

Attributs:

Fournit des informations spécifiques au composant (décrites dans Types d’opérateur ci-dessous).

La capture d’écran suivante montre les détails après avoir cliqué sur l’opérateur Join[11] :

../_images/ui-profile-operator.png

Types d’opérateur

Les sections suivantes fournissent une liste des types d’opérateur les plus courants et de leurs attributs.

Opérateurs d’accès et de production de données

TableScan:

Représente l’accès à une table unique. Attributs :

  • Nom complet de la table — le nom de la table accédée, y compris la base de données et le schéma.

  • Colonnes — liste des colonnes analysées.

  • Alias de table — alias de table utilisé, le cas échéant.

  • Chemins de variante extraits — liste des chemins extraits à partir des colonnes VARIANT.

ValuesClause:

Liste des valeurs fournies avec la clause VALUES. Attributs :

  • Nombre de valeurs — le nombre de valeurs produites.

  • Valeurs — la liste de valeurs produites.

Générateur:

Génère des enregistrements à l’aide de la construction TABLE(GENERATOR(...)). Attributs :

  • rowCount — paramètre rowCount fourni.

  • timeLimit — paramètre timeLimit fourni.

ExternalScan:

Représente l’accès aux données stockées dans les objets de zone de préparation. Peut faire partie des requêtes qui analysent directement les données des zones de préparation, mais aussi pour les requêtes COPY de chargement de données. Attributs :

  • Nom de zone de préparation — le nom de la zone de préparation à partir de laquelle les données sont lues.

  • Type de zone de préparation — le type de la zone de préparation (p. ex. TABLE STAGE).

InternalObject:

Représente l’accès à un objet de données interne (par exemple, une table de schéma d’information ou le résultat d’une requête précédente). Attributs :

  • Nom d’objet — le nom ou le type de l’objet accédé.

Opérateurs de traitement de données

Filtre:

Représente une opération qui filtre les enregistrements. Attributs :

  • Condition de filtre - la condition utilisée pour effectuer le filtrage.

Joindre:

Combine deux entrées sur une condition donnée. Attributs :

  • Type de jointure — Type de jointure (par ex. INNER, LEFT OUTER, etc.).

  • Condition de jointure d’égalité — pour les jointures qui utilisent des conditions basées sur l’égalité, cet attribut répertorie les expressions utilisées pour joindre les éléments.

  • Condition de jonction supplémentaire — certaines jonctions utilisent des conditions contenant des prédicats non basés sur l’égalité. Elles sont répertoriées ici.

Note

Les prédicats de jonction de non-égalité pourraient entraîner des vitesses de traitement beaucoup plus lentes et doivent être évités dans la mesure du possible.

Agrégat:

Regroupe les entrées et calcule les fonctions d’agrégat. Peut représenter des constructions SQL, telles que GROUP BY et SELECT DISTINCT. Attributs :

  • Clés de groupement — si GROUP BY est utilisé, cela répertorie les expressions utilisées pour le groupement.

  • Fonctions d’agrégat – répertorie les fonctions calculées pour chaque groupe d’agrégats, p. ex. SUM.

GroupingSets:

Représente des constructions, telles que GROUPING SETS, ROLLUP et CUBE. Attributs :

  • Ensembles de clés de groupement — liste des ensembles de groupement.

  • Fonctions d’agrégat — liste des fonctions calculées pour chaque groupe, p. ex. SUM.

WindowFunction:

Calcule les fonctions de la fenêtre. Attributs :

  • Fonctions de la fenêtre — liste des fonctions de la fenêtre calculées.

Trier:

Entrée d’ordres sur une expression donnée. Attributs :

  • Clés de tri — expression définissant l’ordre de tri.

SortWithLimit:

Produit une partie de la séquence d’entrée après le tri, généralement le résultat d’une construction ORDER BY ... LIMIT ... OFFSET ... dans SQL. Attributs :

  • Clés de tri — expression définissant l’ordre de tri.

  • Nombre de lignes — nombre de lignes produites.

  • Décalage — position dans la séquence ordonnée à partir de laquelle les tuples produits sont émis.

Aplatir:

Traite les enregistrements VARIANT, en les aplatissant éventuellement sur un chemin spécifié. Attributs :

  • Entrée — l’expression d’entrée utilisée pour aplatir les données.

JoinFilter:

Opération de filtrage spéciale qui enlève les tuples qui peuvent être identifiés comme ne correspondant pas à l’état d’une jonction plus loin dans le plan de requête. Attributs :

  • ID de jonction d’origine — la jonction utilisée pour identifier les tuples qui peuvent être filtrées.

UnionAll:

Procède à la concaténation de deux entrées. Attributs : aucun.

ExternalFunction:

Représente le traitement par une fonction externe.

Opérateurs DML

Insérer:

Ajoute des enregistrements à une table via une opération INSERT ou COPY. Attributs :

  • Expressions d’entrée — les expressions insérées.

  • Nom complet de la table — nom de la table cible unique à laquelle les enregistrements sont ajoutés.

  • Noms de table complets — noms des tables auxquelles les enregistrements sont ajoutés.

Supprimer:

Supprime des enregistrements d’une table. Attributs :

  • Nom de table — nom de la table dont les enregistrements sont supprimés.

Mettre à jour:

Met à jour les enregistrements d’une table. Attributs :

  • Nom de table complet — le nom de la table mise à jour.

Fusionner:

Effectue une opération MERGE sur une table. Attributs :

  • Nom de table complet — le nom de la table mise à jour.

Décharger:

Représente une opération COPY qui exporte les données d’une table vers un fichier dans une zone de préparation. Attributs :

  • Emplacement - le nom de la zone de préparation où les données sont sauvegardées.

Opérateurs de métadonnées

Certaines requêtes comprennent des étapes qui sont de pures opérations de métadonnées/de catalogue plutôt que des opérations de traitement de données. Ces étapes se composent d’un seul opérateur. Quelques exemples :

Commandes DDL et de transactions:

Utilisées pour créer ou modifier des objets, des sessions, des transactions, etc. Généralement, ces requêtes ne sont pas traitées par un entrepôt virtuel et donnent lieu à un profil à une seule étape correspondant à l’instruction SQL correspondante. Par exemple :

CREATE DATABASE | SCHEMA | …

ALTER DATABASE | SCHEMA | TABLE | SESSION | …

DROP DATABASE | SCHEMA | TABLE | …

COMMIT

Commande de création de table:

Commande DDL pour créer une table. Par exemple :

CREATE TABLE

Comme les autres commandes DDL, ces requêtes donnent un profil à une seule étape. Cependant, elles peuvent aussi faire partie d’un profil à plusieurs étapes, comme lorsqu’elles sont utilisées dans une instruction CTAS. Par exemple :

CREATE TABLE … AS SELECT …

Réutilisation de résultats de requête:

Une requête qui réutilise le résultat d’une requête précédente.

Résultat basé sur les métadonnées:

Requête dont le résultat est calculé à partir de métadonnées uniquement, sans accéder à aucune donnée. Ces requêtes ne sont pas traitées par un entrepôt virtuel. Par exemple :

SELECT COUNT(*) FROM …

SELECT CURRENT_DATABASE()

Opérateurs divers

Résultat:

Renvoie le résultat de la requête. Attributs :

  • Liste des expressions - les expressions produites.

Détails sur la requête/l’opérateur

Pour vous aider à analyser les performances des requêtes, le panneau de détail fournit deux classes d’informations de profil :

  • Temps d’exécution, réparti en catégories

  • Statistiques détaillées

De plus, des attributs sont fournis pour chaque opérateur (décrits dans Types d’opérateur dans ce chapitre).

Temps d’exécution

Le temps d’exécution indique le temps attribué à chaque tâche durant le traitement d’une requête. Le temps passé peut être réparti dans les catégories suivantes, affichées dans l’ordre suivant :

  • Processing — le temps consacré au traitement des données par le CPU.

  • Local Disk IO — l’heure à laquelle le traitement a été bloqué par l’accès au disque local.

  • Remote Disk IO — l’heure à laquelle le traitement a été bloqué par l’accès au disque distant.

  • Network Communication — l’heure à laquelle le traitement attendait le transfert des données réseau.

  • Synchronization — diverses activités de synchronisation entre les processus participants.

  • Initialization — le temps passé à configurer le traitement de la requête.

Statistiques

Les diverses statistiques, regroupées dans les sections suivantes, constituent une source importante d’informations dans le panneau de détails :

  • IO — informations sur les opérations d’entrée-de sortie effectuées pendant la requête :

    • Progression de l’analyse — le pourcentage de données analysées pour une table donnée jusqu’à présent.

    • Octets analysés — le nombre d’octets analysés jusqu’à présent.

    • Pourcentage de données analysées à partir du cache — le pourcentage de données analysées à partir du cache du disque local.

    • Octets écrits — octets écrits (par exemple lors du chargement dans une table).

    • Octets écrits dans le résultat — octets écrits dans l’objet de résultat. Par exemple, select * from . . . produirait un jeu de résultats sous forme de tableau représentant chaque champ de la sélection. En général, l’objet de résultats représente tout ce qui est produit comme résultat de la requête, et Octets écrits dans le résultat représente la taille du résultat retourné.

    • Octets lus à partir d’un résultat — octets lus à partir de l’objet de résultat.

    • Octets externes analysés — octets lus à partir d’un objet externe, par exemple une zone de préparation.

  • DML — Statistiques des requêtes Data Manipulation Language (DML) :

    • Nombre de lignes insérées — nombre de lignes insérées dans une ou plusieurs tables.

    • Nombre de lignes mises à jour — nombre de lignes mises à jour dans une table.

    • Nombre de lignes supprimées — nombre de lignes supprimées dans une table.

    • Nombre de lignes déchargées — nombre de lignes déchargées lors de l’exportation des données.

  • Pruning — informations sur les effets de l’élagage de table :

    • Partitions analysées — nombre de partitions analysées jusqu’à présent.

    • Nombre total de partitions — nombre total de partitions dans une table donnée.

  • Spilling — informations sur l’utilisation du disque pour les opérations où les résultats intermédiaires ne rentrent pas dans la mémoire :

    • Octets déversés sur le stockage local — volume de données déversées sur le disque local (« spill to disk »).

    • Octets déversés sur le stockage distant — volume de données déversées sur le disque distant (« spill to disk »).

  • Network — communication réseau :

    • Octets envoyés sur le réseau — quantité de données envoyées sur le réseau.

  • External Functions — informations sur les appels à des fonctions externes :

    Les statistiques suivantes sont affichées pour chaque fonction externe appelée par l’instruction SQL. Si la même fonction a été appelée plusieurs fois à partir de la même instruction SQL, les statistiques sont agrégées.

    • Nombre total d’appels — nombre de fois qu’une fonction externe a été appelée. (Cela peut être différent du nombre d’appels de fonctions externes dans le texte de l’instruction SQL en raison du nombre de lots dans lesquels les lignes sont divisées, du nombre de tentatives (en cas de problèmes de réseau transitoires), etc.)

    • Lignes envoyées — nombre de lignes envoyées aux fonctions externes.

    • Lignes reçues — nombre de lignes reçues en retour de fonctions externes.

    • Octets envoyés (entre régions) — nombre d’octets envoyés aux fonctions externes. Si le libellé inclut « (entre régions) », les données ont été envoyées entre plusieurs régions (ce qui peut avoir un impact sur la facturation).

    • Octets reçus (entre régions) — nombre d’octets reçus depuis des fonctions externes. Si le libellé inclut « (entre régions) », les données ont été envoyées entre plusieurs régions (ce qui peut avoir un impact sur la facturation).

    • Tentatives en raison d’erreurs transitoires — nombre de tentatives en raison d’erreurs transitoires.

    • Latence moyenne par appel — La durée moyenne par appel entre le moment où Snowflake a envoyé les données et reçu les données renvoyées.

    • Erreurs HTTP 4xx — nombre total de requêtes HTTP ayant renvoyé un code de statut 4xx.

    • Erreurs HTTP 5xx — nombre total de requêtes HTTP ayant renvoyé un code de statut 5xx.

    • Latence par appel réussi (moy) — latence moyenne pour les requêtes HTTP réussies.

    • Frais généraux moyens de latence dus à la limitation — frais généraux moyens par requête réussie en raison d’un ralentissement causé par la limitation (HTTP 429).

    • Tentatives de lots en raison de la limitation — nombre de lots qui ont fait l’objet de nouvelles tentatives en raison d’erreurs HTTP 429.

    • Temps de latence par appel réussi (P50) — temps de latence du 50e centile pour les requêtes HTTP réussies. 50 pour cent de toutes les requêtes acceptées ont été traitées en moins de temps.

    • Temps de latence par appel réussi (P90) — 90e centile de latence pour les requêtes HTTP réussies. 90 pour cent de toutes les requêtes acceptées ont été traitées en moins de temps.

    • Temps de latence par appel réussi (P95) — 95e centile de latence pour les requêtes HTTP réussies. 95 pour cent de toutes les requêtes réussies ont été traitées en moins de temps.

    • Temps de latence par appel réussi (P99) — 99e centile de latence pour les requêtes HTTP réussies. 99 pour cent de toutes les requêtes réussies ont été traitées en moins de temps.

  • Extension Functions — informations sur les appels aux fonctions d’extension :

    • Temps de chargement du gestionnaire d’UDF Java — temps de chargement du gestionnaire d’UDF Java.

    • Total des appels au gestionnaire d’UDF Java — nombre d’appels au gestionnaire d’UDF Java.

    • Durée maximale d’exécution du gestionnaire d’UDF Java — durée maximale d’exécution du gestionnaire d’UDF Java.

    • Temps moyen d’exécution du gestionnaire d’UDF Java — temps moyen d’exécution du gestionnaire d’UDF Java.

    • Appels process() d’UDTF Java — nombre de fois où la méthode de traitement d’UDTF Java a été appelée.

    • Temps d’exécution process() d’UDTF Java— temps nécessaire à l’exécution du traitement des UDTF Java.

    • Temps d’exécution moyen process() d’UDTF Java— temps moyen nécessaire à l’exécution du traitement des UDTF Java.

    • Appels au constructeur d’UDTF Java — nombre de fois où le constructeur d’UDTF Java a été appelé.

    • Temps d’exécution du constructeur d’UDTF Java — temps d’exécution du constructeur d’UDTF Java.

    • Temps d’exécution moyen du constructeur d’UDTF Java — temps d’exécution moyen du constructeur d’UDTF Java.

    • Appels endPartition() d’UDTF Java — nombre de fois où la méthode endPartition d’UDTF Java a été appelée.

    • Temps d’exécution endPartition() d’UDTF Java — temps nécessaire à l’exécution de la méthode endPartition d’UDTF Java.

    • Temps d’exécution moyen endPartition() d’UDTF Java — temps moyen nécessaire à l’exécution de la méthode endPartition d’UDTF Java.

    • Temps de téléchargement de dépendance d’UDF Java maximum — durée maximale de téléchargement des dépendances d’UDF Java.

    • Utilisation de mémoire JVM max — pic d’utilisation de la mémoire tel que rapporté par le JVM.

    • Temps de compilation du code en ligne d’UDF Java en ms — temps de compilation du code en ligne d’UDF Java.

    • Total des appels au gestionnaire d’UDF Python — nombre de fois où le gestionnaire d’UDF Python a été appelé.

    • Temps total d’exécution du gestionnaire d’UDF Python — temps total d’exécution du gestionnaire d’UDF Python.

    • Temps moyen d’exécution du gestionnaire d’UDF Python — temps moyen d’exécution du gestionnaire d’UDF Python.

    • Utilisation maximale de mémoire sandbox Python — utilisation maximale de la mémoire par l’environnement sandbox de Python.

    • Temps moyen de création de l’environnement Python : téléchargement et installation des paquets — temps moyen de création de l’environnement Python, y compris le téléchargement et l’installation des paquets.

    • Temps du solveur Conda — temps nécessaire à l’exécution du solveur Conda pour résoudre les paquets Python.

    • Temps de création de l’environnement Conda — temps nécessaire à la création de l’environnement Python.

    • Temps d’initialisation d’UDF Python — temps d’initialisation d’UDF Python.

    • Nombre d’octets de fichiers externes lus pour les UDFs — nombre d’octets de fichiers externes lus pour des UDFs.

    • Nombre de fichiers externes accédés pour des UDFs — nombre de fichiers externes accédés pour des UDFs.

    Si la valeur d’un champ, par exemple « Tentatives en raison d’erreurs transitoires » est nulle, le champ n’est pas affiché.

Informations expurgées de profils de requête dans une Snowflake Native App

Snowflake Native App Framework expurge les informations du profil de requête dans les contextes suivants :

  • Requêtes exécutées lors de l’installation ou de la mise à niveau de l’application.

  • Requêtes provenant d’une procédure stockée appartenant à l’application.

  • Requêtes contenant une vue ou une fonction non sécurisée appartenant à l’application.

Pour chacun de ces types de requêtes, Snowsight réduit les données du profil de la requête en un seul nœud vide au lieu d’afficher l’arbre complet du profil de la requête.

Problèmes de requête courants identifiés par le profil de requête

Cette section décrit les problèmes que vous pouvez identifier et résoudre à l’aide du profil de requête.

« Explosion » de jonctions

L’une des erreurs courantes des utilisateurs de SQL est de joindre des tables sans fournir de condition de jonction (résultant en un « produit cartésien »), ou de fournir une condition où les enregistrements d’une table correspondent à plusieurs enregistrements d’une autre table. Pour de telles requêtes, l’opérateur Join produit significativement plus de tuples qu’il n’en consomme (souvent par ordre de grandeur).

Ceci peut être observé en regardant le nombre d’enregistrements produits par un opérateur Join, et se reflète généralement aussi dans un opérateur Join chronophage.

L’exemple suivant montre une entrée dans des centaines d’enregistrements, mais une sortie dans les centaines de milliers :

SELECT tt1.c1, tt1.c2
FROM tt1
JOIN tt2 ON tt1.c1 = tt2.c1
 AND tt1.c2 = tt2.c2;
Copy
../_images/ui-profile-issues-exploding-joins.png

UNION sans ALL

Dans SQL, il est possible de combiner deux ensembles de données avec les constructions UNION ou UNION ALL. La différence est que UNION ALL concatène simplement les entrées, tandis que UNION fait la même chose, mais supprime également les doublons.

Une erreur classique est d’utiliser UNION alors que la sémantique UNION ALL est suffisante. Ces requêtes apparaissent dans le profil de requête en tant qu’opérateur UnionAll avec un opérateur Aggregate supplémentaire (qui effectue l’élimination des doublons).

Requêtes trop volumineuses pour la mémoire

Pour certaines opérations (par exemple, l’élimination des doublons dans un grand ensemble de données), la quantité de mémoire disponible pour les ressources de calcul utilisée pour exécuter l’opération peut ne pas être suffisante pour contenir les résultats intermédiaires. En conséquence, le moteur de traitement des requêtes commencera à déverser les données sur le disque local. Si l’espace disque local n’est pas suffisant, les données déversées sont alors enregistrées sur des disques distants.

Ce déversement peut avoir un effet important sur les performances de la requête (surtout si le disque distant est utilisé pour le déversement). Pour remédier à cette situation, nous recommandons les choses suivantes :

  • Utilisez un entrepôt plus grand (ce qui a pour effet d’augmenter l’espace mémoire/espace disque local disponible pour l’opération), et/ou

  • Traitez les données par lots de plus petite taille.

Élagage inefficace

Snowflake collecte des statistiques complètes sur les données lui permettant de ne pas lire les parties inutiles d’une table selon les filtres de requête. Toutefois, pour que cela ait un effet, l’ordre de stockage des données doit être corrélé avec les attributs du filtre de requête.

L’efficacité de l’élagage s’observe en comparant les statistiques Partitions analysées et Nombre total de partitions dans les opérateurs TableScan. Si la première est une petite fraction de la seconde, alors l’élagage est efficace. Dans le cas contraire, l’élagage n’a eu aucun effet.

Bien entendu, l’élagage ne peut aider que pour les requêtes qui filtrent réellement une quantité importante de données. Si les statistiques d’élagage n’indiquent pas de réduction de données, mais qu’il y a un opérateur Filter au-dessus de TableScan qui filtre un certain nombre d’enregistrements, cela peut indiquer qu’une autre organisation des données pourrait être utile pour cette requête.

Pour plus d’informations sur l’élagage, voir Fonctionnement des structures de table dans Snowflake.

Données de profils de requête expurgées d’une Snowflake Native App

Snowflake Native App Framework expurge les informations du profil de requête dans les contextes suivants :

  • Requêtes exécutées lors de l’installation ou de la mise à niveau de l’application.

  • Requêtes provenant d’une procédure stockée appartenant à l’application.

  • Requêtes contenant une vue ou une fonction non sécurisée appartenant à l’application.

Pour chacun de ces types de requêtes, Snowsight réduit les données du profil de la requête en un seul nœud vide au lieu d’afficher l’arbre complet du profil de la requête.