Überwachen der Aktivität¶

Details zu Abfragen¶

Die Registerkarte Query Details liefert die Ergebnisse der Abfrage zusammen mit zusätzlichen Informationen. Die Registerkarte Query Details ist die Standard-Registerkarte für die Abfrageseite. Die Registerkarte Query Details enthält die folgenden Bereiche:

• Details

• SQL Text

• Results

Der Abschnitt Details enthält zusätzliche Informationen zur Ausführung der Abfrage, einschließlich:

• Status der Abfrage

• Startzeitpunkt der Abfrage

• Beendigungszeitpunkt der Abfrage

• Dauer der Abfrage

• Abfrage-ID

• Sitzung-ID

• Treiberstatus

• Clienttreiber

Der Abschnitt SQL Text enthält den eigentlichen Text der Abfrage. Bewegen Sie den Mauszeiger über den SQL-Text, um den Text in einem Arbeitsblatt zu öffnen oder den Text zu kopieren.

Der Abschnitt Results enthält die Ergebnisse der Abfrage. Wählen Sie Export Query aus, um die Ergebnisse als CSV-Datei zu exportieren.

Query Profile¶

Auf der Registerkarte Query Profile können Sie den Ausführungsplan der Abfrage untersuchen und detaillierte Informationen zu den einzelnen Ausführungsschritten abrufen.

Query Profile ist ein leistungsfähiges Tool zum Verständnis der Mechanismen von Abfragen. Es kann verwendet werden, wenn Sie mehr über die Leistung oder das Verhalten einer bestimmten Abfrage erfahren müssen. Das Tool soll Ihnen helfen, typische Fehler in SQL-Abfrageausdrücken zu erkennen, um potenzielle Leistungsengpässe und Verbesserungsmöglichkeiten zu identifizieren.

Dieser Abschnitt gibt einen kurzen Überblick über die Navigation und Verwendung von Query Profile.

• Ausführungsplan von Abfragen

• Operatorknoten

• Query Profile-Navigation

• Informationsbereiche

Schnittstelle	Beschreibung
Ausführungsplan von Abfragen	Der Ausführungsplan von Abfragen wird in der Mitte von Query Profile angezeigt. Der Ausführungsplan von Abfragen besteht aus Operatorknoten, die Rowset-Operatoren repräsentieren. Pfeile zwischen den Operatoren zeigen die Rowsets an, die von einem Operator zu einem anderen weitergegeben werden.
Operatorknoten	Jeder Operatorknoten enthält folgende Informationen: Operatortyp und Operator-ID Die für das Ausführen dieses Operators benötigte Zeit in Prozent der Abfragedauer Vorschau der Operatordetails. Beispielsweise der Name einer Tabelle oder einer Liste von Ausdrücken.
Query Profile-Navigation	Verwenden Sie die Schaltflächen in der linken oberen Ecke von Query Profile für folgende Aktionen: Zwischen Ausführungsschritten wechseln Abfrageausführungsplan in das Fenster einpassen Abfrageausführungsplan vergrößern/verkleinern Bemerkung Schritte werden nur angezeigt, wenn die Abfrage in Schritten ausgeführt wurde.
Informationsbereiche	Query Profile bietet verschiedene Informationsbereiche. Die Bereiche werden im Abfrageausführungsplan angezeigt. Welche Bereiche angezeigt werden, hängt vom Fokus des Abfrageausführungsplans ab. Query Profile enthält die folgenden Informationsbereiche: Profile Overview Statistics Most Expensive Nodes Attributes Weitere Informationen zu den Informationen, die in den Bereichen bereitgestellt werden, finden Sie unter Referenz zum Abfrageverlauf.

Profilübersicht¶

Der Bereich enthält Informationen dazu, welche Verarbeitungsaufgaben Abfragezeit verbraucht haben. Die Ausführungszeit enthält Informationen darüber, wofür die Zeit während der Verarbeitung einer Abfrage verbraucht wurde. Die aufgewendete Zeit kann in folgende Kategorien unterteilt werden:

• Processing – Zeit, die von der CPU für die Datenverarbeitung verbraucht wurde.

• Local Disk IO – Zeit, in der die Verarbeitung durch den Zugriff auf die lokale Festplatte blockiert wurde.

• Remote Disk IO – Zeit, in der die Verarbeitung durch Remote-Festplattenzugriff blockiert wurde.

• Network Communication – Zeit, in der die Verarbeitung auf die Netzwerkdatenübertragung wartete.

• Synchronization – Verschiedene Synchronisationsaktivitäten zwischen den beteiligten Prozessen.

• Initialization – Zeit, die für das Einrichten der Abfrageverarbeitung verbraucht wurde.

Statistiken¶

Eine wichtige Informationsquelle im Detailbereich sind die verschiedenen Statistiken, die in folgende Abschnitte unterteilt sind:

• IO – Informationen zu den während der Abfrage ausgeführten Eingabe/Ausgabe-Operationen:

  • Scan progress – Prozentsatz der Daten, die bislang für eine bestimmte Tabelle gescannt wurden.

  • Bytes scanned – Anzahl der bislang gescannten Bytes.

  • Percentage scanned from cache – Prozentsatz der Daten, die vom lokalen Festplattencache gescannt wurden.

  • Bytes written – Geschriebene Bytes (z. B. beim Laden in eine Tabelle).

  • Bytes written to result – Bytes, die in das Ergebnisobjekt geschrieben wurden. So würde beispielsweise select * from . . . eine Menge von Ergebnissen im tabellarischen Format für jedes Feld in der Auswahl liefern. Im Allgemeinen repräsentiert das Ergebnisobjekt das, was als Ergebnis der Abfrage erzeugt wird, und Bytes written to result steht für die Größe des zurückgegebenen Ergebnisses.

  • Bytes read to result – Bytes, die aus dem Ergebnisobjekt gelesen wurden.

  • External Bytes scanned – Bytes, die von einem externen Objekt, z. B. einem Stagingbereich, gelesen wurden.

• DML – Statistiken zu DML–Abfragen (Datenbearbeitungssprache):

  • Number of rows inserted – Anzahl der in eine Tabelle (oder Tabellen) eingefügten Zeilen.

  • Number of rows updated – Anzahl der in einer Tabelle aktualisierten Zeilen.

  • Number of rows deleted – Anzahl der aus einer Tabelle gelöschten Zeilen.

  • Number of rows unloaded – Anzahl der während des Datenexports entladenen Zeilen.

• Pruning – Informationen zu den Auswirkungen der Tabellenverkürzung:

  • Partitions scanned – Anzahl der bisher gescannten Partitionen.

  • Partitions total – Gesamtanzahl der Partitionen einer Tabelle.

• Spilling – Informationen zur Festplattennutzung für Operationen, bei denen Zwischenergebnisse nicht in den Arbeitsspeicher passen:

  • Bytes spilled to local storage – Datenmenge, die auf die lokale Festplatte übertragen wurde.

  • Bytes spilled to remote storage – Datenmenge, die auf die externe Festplatte übertragen wurde.

• Network – Netzwerk-Kommunikation:

  • Bytes sent over the network – Über das Netzwerk gesendete Datenmenge.

• External Functions – Informationen zu Aufrufen externer Funktionen:

  Die folgenden Statistiken werden für jede externe Funktion angezeigt, die von der SQL-Anweisung aufgerufen wird. Wenn dieselbe Funktion mehrmals von derselben SQL-Anweisung aufgerufen wurde, werden die Statistiken aggregiert.

  • Total invocations – Häufigkeit, mit der eine externe Funktion aufgerufen wurde. Der Wert kann sich von der Anzahl der externen Funktionsaufrufe im Text der SQL-Anweisung unterscheiden und zwar aufgrund der Anzahl der Batches, in die Zeilen unterteilt sind, der Anzahl der Wiederholungsversuche (bei vorübergehenden Netzwerkproblemen) usw.

  • Rows sent – Anzahl der an externe Funktionen gesendeten Zeilen.

  • Rows received – Anzahl der von externen Funktionen empfangenen Zeilen.

  • Bytes sent (x-region) – Anzahl der an externe Funktionen gesendeten Bytes. Wenn das Etikett „(x-region)“ enthält, wurden die Daten über Regionen hinweg gesendet (was sich auf die Abrechnung auswirken kann).

  • Bytes received (x-region) – Anzahl der von externen Funktionen empfangenen Bytes. Wenn das Etikett „(x-region)“ enthält, wurden die Daten über Regionen hinweg gesendet (was sich auf die Abrechnung auswirken kann).

  • Retries due to transient errors – Anzahl der Wiederholungen aufgrund vorübergehender Fehler.

  • Average latency per call – Durchschnittliche Zeit pro Aufruf zwischen dem Zeitpunkt, zu dem Snowflake die Daten gesendet hat, und dem Zeitpunkt, zu dem Snowflake die zurückgegebenen Daten empfangen hat.

  • HTTP 4xx errors – Gesamtzahl der HTTP-Anforderungen, die einen 4xx-Statuscode zurückgegeben haben.

  • HTTP 5xx errors – Gesamtzahl der HTTP-Anforderungen, die einen 5xx-Statuscode zurückgegeben haben.

  • Latency per successful call (avg) – Durchschnittliche Latenz von erfolgreichen HTTP-Anforderungen.

  • Avg throttle latency overhead – Durchschnittlicher Overhead pro erfolgreicher Anforderung aufgrund einer durch Drosselung verursachten Verlangsamung (HTTP 429).

  • Batches retried due to throttling – Anzahl der Batches, deren Ausführung aufgrund von HTTP-Fehler 429 erneut versucht wurden.

  • Latency per successful call (P50) – 50. Perzentil-Latenz von erfolgreichen HTTP-Anforderungen. 50 Prozent aller erfolgreichen Anforderungen wurden in weniger als dieser Zeit abgeschlossen.

  • Latency per successful call (P90) – 90. Perzentil-Latenz von erfolgreichen HTTP-Anforderungen. 90 Prozent aller erfolgreichen Anforderungen wurden in weniger als dieser Zeit abgeschlossen.

  • Latency per successful call (P95) – 95. Perzentil-Latenz von erfolgreichen HTTP-Anforderungen. 95 Prozent aller erfolgreichen Anforderungen wurden in weniger als dieser Zeit abgeschlossen.

  • Latency per successful call (P99) – 99. Perzentil-Latenz von erfolgreichen HTTP-Anforderungen. 99 Prozent aller erfolgreichen Anforderungen wurden in weniger als dieser Zeit abgeschlossen.

• Extension Functions – Informationen zu Aufrufen von Erweiterungsfunktionen:

  • Java UDF handler load time – Zeit, die der Java-UDF-Handler zum Laden benötigt.

  • Total Java UDF handler invocations – Anzahl der Aufrufe des Java-UDF-Handlers.

  • Max Java UDF handler execution time – Maximaler Zeitaufwand für die Ausführung des Java-UDF-Handlers.

  • Avg Java UDF handler execution time – Durchschnittlicher Zeitaufwand für die Ausführung des Java-UDF-Handlers.

  • Java UDTF process() invocations – Anzahl der Aufrufe der Java-UDTF-Methode process.

  • Java UDTF process() execution time – Zeitaufwand für die Ausführung des Java-UDTF-Prozesses.

  • Avg Java UDTF process() execution time – Durchschnittlicher Zeitaufwand für die Ausführung des Java-UDTF-Prozesses.

  • Java UDTF’s constructor invocations – Anzahl der Aufrufe des Java-UDTF-Konstruktors.

  • Java UDTF’s constructor execution time – Zeitaufwand für die Ausführung des Java-UDTF-Konstruktors.

  • Avg Java UDTF’s constructor execution time – Durchschnittlicher Zeitaufwand für die Ausführung des Java-UDTF-Konstruktors.

  • Java UDTF endPartition() invocations – Anzahl der Aufrufe der Java-UDTF-Methode endPartition.

  • Java UDTF endPartition() execution time – Zeitaufwand für die Ausführung der Java-UDTF-Methode endPartition.

  • Avg Java UDTF endPartition() execution time – Durchschnittlicher Zeitaufwand für die Ausführung der Java-UDTF-Methode endPartition.

  • Max Java UDF dependency download time – Maximaler Zeitaufwand für das Herunterladen der Java-UDF-Abhängigkeiten.

  • Max JVM memory usage – Spitzenauslastung des Arbeitsspeichers, wie von JVM gemeldet.

  • Java UDF inline code compile time in ms – Kompilierungszeit für den Java-UDF-Inline-Code.

  • Total Python UDF handler invocations – Anzahl der Aufrufe des Python-UDF-Handlers.

  • Total Python UDF handler execution time – Gesamtausführungszeit für den Python-UDF-Handler.

  • Avg Python UDF handler execution time – Durchschnittlicher Zeitaufwand für die Ausführung des Python-UDF-Handlers.

  • Python sandbox max memory usage – Spitzenauslastung des Arbeitsspeichers durch die Python-Sandbox-Umgebung.

  • Avg Python env creation time: Download and install packages – Durchschnittlicher Zeitaufwand für das Erstellen der Python-Umgebung, einschließlich des Herunterladens und Installierens von Paketen.

  • Conda solver time – Zeitaufwand für die Ausführung des Conda-Solvers zur Auflösung von Python-Paketen.

  • Conda env creation time – Zeitaufwand für das Erstellen der Python-Umgebung.

  • Python UDF initialization time – Zeitaufwand für das Initialisieren der Python-UDF.

  • Number of external file bytes read for UDFs – Anzahl der für UDFs gelesenen Bytes für externe Dateien.

  • Number of external files accessed for UDFs – Anzahl der Zugriffe auf externe Dateien für UDFs.

  Wenn der Wert eines Feldes, z. B. „Retries due to transient errors“, null ist, wird das Feld nicht angezeigt.

Die teuersten Knoten¶

Im Bereich werden alle Knoten aufgelistet, die 1 % oder mehr der gesamten Ausführungszeit der Abfrage (oder die Ausführungszeit für den angezeigten Abfrageschritt, wenn die Abfrage in mehreren Verarbeitungsschritten ausgeführt wurde) in Anspruch genommen haben. Der Bereich listet die Knoten nach Ausführungszeit in absteigender Reihenfolge auf, sodass Benutzer die teuersten Operatorknoten in Bezug auf die Ausführungszeit schnell finden können.

Attribute¶

In den folgenden Abschnitten finden Sie eine Liste der häufigsten Operatortypen und ihrer Attribute.

„Explodierende“ Joins¶

Einer der häufigsten Fehler von SQL-Benutzern besteht darin, Tabellen zu verknüpfen, ohne eine Join-Bedingung anzugeben (was zu einem „Kartesischen Produkt“ führt), oder eine Bedingung bereitzustellen, bei der Datensätze einer Tabelle mit mehreren Datensätzen einer anderen Tabelle übereinstimmen. Für solche Abfragen produziert der Operator Join signifikant (oft um Größenordnungen) mehr Tupel, als er verbraucht.

Dies kann beobachtet werden, indem die Anzahl der Datensätze betrachtet wird, die von einem Join-Operator erzeugt wurden. Dies spiegelt sich normalerweise auch in Join-Operatoren wider, die viel Zeit in Anspruch nehmen.

UNION ohne ALL¶

In SQL können zwei Datasets mit UNION- oder UNION ALL-Konstrukten kombiniert werden. Der Unterschied zwischen beiden besteht darin, dass mit UNION ALL die Eingaben einfach verkettet werden, während UNION dasselbe tut, aber auch eine doppelte Löschung durchführt.

Ein häufiger Fehler ist die Verwendung von UNION, wenn die UNION ALL-Semantik ausreicht. Diese Abfragen werden in Query Profile als UnionAll-Operator mit einem zusätzlichen Aggregate-Operator darüber angezeigt (der eine doppelte Löschung vornimmt).

Abfragen, die zu groß für den Arbeitsspeicher sind¶

Bei einigen Operationen (z. B. doppelte Löschung bei einem großen Dataset) reicht die für die Server zur Ausführung der Operation zur Verfügung stehende Speicherkapazität möglicherweise nicht aus, um Zwischenergebnisse zu speichern. Als Ergebnis beginnt das Abfrageverarbeitungsmodul, die Daten auf die lokale Festplatte zu übertragen. Wenn der lokale Speicherplatz nicht ausreicht, werden die Überlaufdaten auf Remote-Festplatten gespeichert.

Dieser Überlauf kann sich erheblich auf die Abfrageleistung auswirken (insbesondere, wenn für den Überlauf ein Remote-Datenträger verwendet wird). Um die Auswirkungen zu reduzieren, empfehlen wir Folgendes:

• Verwenden eines größeren Warehouse (effektives Erhöhen des verfügbaren Arbeitsspeichers bzw. des lokalen Festplattenspeichers für die Operation) und/oder

• Verarbeiten der Daten in kleineren Batches.

Ineffizientes Verkürzen¶

Snowflake sammelt umfangreiche Statistiken zu Daten, sodass basierend auf den Abfragefiltern keine unnötigen Teile einer Tabelle gelesen werden. Um diesen Effekt zu erzielen, muss die Reihenfolge der Datenspeicherung mit den Abfragefilterattributen korreliert werden.

Die Effizienz des Verkürzungsprozesses kann durch Vergleichen der Statistiken Partitions scanned und Partitions total in den TableScan-Operatoren überwacht werden. Wenn ersterer Wert ein kleiner Bruchteil des letzteren Werts ist, dann ist das Verkürzen effizient. Wenn nicht, hatte das Verkürzen keine Wirkung.

Das Verkürzen kann natürlich nur für Abfragen hilfreich sein, bei denen tatsächlich eine erhebliche Datenmenge herausgefiltert wird. Wenn in den Verkürzungsstatistiken keine Datenreduktion angezeigt wird, über TableScan jedoch ein Filter-Operator steht, der eine Anzahl von Datensätzen herausfiltert, könnte dies darauf hindeuten, dass für diese Abfrage eine andere Organisation der Daten von Vorteil ist.

Weitere Informationen zum Verkürzen finden Sie unter Grundlegendes zu Tabellenstrukturen in Snowflake.