Profiling für benutzerdefinierte Snowpark Python-Funktions-Handler¶
Mit dem integrierten Code-Profiler können Sie herausfinden, wie viel Zeit oder Speicher für die Ausführung Ihres Handler-Codes aufgewendet wurde. Der Profiler generiert Informationen, die beschreiben, wie viel Zeit oder Speicher für die Ausführung jeder Zeile Python-Code aufgewendet wurde.
Mit dem Profiler können Sie Berichte erstellen, die sich jeweils auf einen der folgenden Punkte konzentrieren:
Amount of time per line zeigt die Anzahl der Ausführungen einer Zeile, die Ausführungsdauer usw. an.
Amount of memory usage per line zeigt den pro Zeile verbrauchten Speicher an.
Der Profiler speichert den erstellten Bericht in einer internen:doc:Ereignistabelle</developer-guide/logging-tracing/event-table-columns>. Sie können die Ergebnisse mithilfe einer Funktion abrufen, die für den Zugriff auf die Tabelle vorgesehen ist.
Bemerkung
Profiling führt zu einem Performance-Overhead bei der Python-Ausführung und kann die Leistung der Abfrage beeinträchtigen. Sie ist für Entwicklung und Tests gedacht und sollte nicht für kontinuierliche Produktions-Workloads aktiviert werden.
Erforderliche Berechtigungen¶
Zum Verwalten und Verwenden der Profiler-Ergebnisdaten, die in der SNOWFLAKE.LOCAL.PROFILER_EVENTS_RAW-Ereignistabelle gespeichert werden, müssen Sie die folgenden Rollen verwenden:
Anwendungsrolle |
Anmerkungen |
|---|---|
PROFILER_EVENTS_ADMIN |
Erforderlich für die Verwaltung von Daten in der Ereignistabelle, in der Profilerdaten gespeichert sind, einschließlich des Auswählens, Kürzens oder Löschens von Datensätzen. |
PROFILER_USER |
Erforderlich, um Profiler-Ergebnisse aus der Ereignistabelle zu lesen. |
Weitere Informationen zum Zuweisen einer Anwendungsrolle finden Sie unter:doc:/sql-reference/sql/grant-application-role. Im folgenden Beispiel wird die Rolle ACCOUNTADMIN verwendet, um einem Benutzenden die Anwendungsrolle PROFILER_USER zuzuweisen.
Einschränkungen¶
Nach der Ausführung der Abfrage kann es 15–20 Sekunden dauern, bis die Ergebnisse des Profilers bereit sind.
Die Profiler-Ausgabe wird nicht gespeichert, wenn die Ausführung der UDF fehlschlägt.
Rekursive Profilerstellung wird nicht unterstützt. Nur die Top-Level-Funktionen der angegebenen Module werden profiliert. Bei Funktionen, die innerhalb von Funktionen definiert sind, ist dies nicht der Fall.
Das Profiling von Modulen von Drittanbietern wird nicht unterstützt.
Unterstützung für die Profiling-UDFs, die clientseitig mit der ` snowflake.snowpark`-API erstellt wurden, ist nicht verfügbar.
Python-Funktionen, die parallel über
jobliblaufen, werden nicht profiliert.UDTFs werden nicht unterstützt.
Die Zeit wird in Echtzeit (Wall Clock Time) und nicht in CPU-Zeit gemessen.
Verwendung¶
Sobald Sie den Profiler eingerichtet haben, können Sie ihn verwenden, indem Sie einfach die UDF ausführen, um die Profiler-Ausgabe zu generieren. Sobald die Ausführung der UDF beendet ist, wird die Profiler-Ausgabe in eine interne Ereignistabelle geschrieben. Sie können die Profiler-Ausgabe mit einer Systemfunktion abrufen.
Folgen Sie diesen Schritten in Ihrem Code, um den Profiler einzurichten und zu verwenden:
Aktivieren Sie den Profiler und legen Sie fest, worauf sich der Profilbericht konzentrieren soll.
Führen Sie die UDF aus.
Profiling-Ausgabe ansehen.
Aktivieren Sie den Profiler, indem Sie seinen Fokus festlegen¶
Um den Profiler zu aktivieren, legen Sie einen der folgenden Sitzungsparameter fest:
Bemerkung
Profiling führt zu einem Performance-Overhead bei der Python-Ausführung. Sie sollten das Profiling für Ihren Code während der Entwicklung und des Testens vornehmen. Aktivieren Sie Profiling nicht für kontinuierliche Produktions-Workloads.
Angabe des zu Codes für das Profiling¶
Standardmäßig erstellt der Profiler ein Profil von Methoden, die inline mit der UDF-Deklaration definiert wurden. Mit anderen Worten: Der Profiler profiliert alle im Handler definierten Methoden.
Beim folgendenUDF-Beispiel erstellt der Profiler beispielsweise ein Profil der handler-Methode und der helper-Methode.
Angeben des externen Codes für das Profiling¶
Sie können angeben, dass der Profiler ein Profil für Handler-Code erstellen soll, der außerhalb der UDF-Deklaration definiert wurde, wie z. B. aus einem Stagingbereich importierter Code.
Um externen Code für das Profiling anzugeben, legen Sie den Wert des Sitzungsparameters PYTHON_UDF_PROFILER_MODULES auf eine durch Kommas getrennte Liste der Module fest, die den Code enthalten.
Der Profiler fügt die angegebenen Module in seine Profiling-Ausgabe ein, wenn Sie eine UDF ausführen, die sie importiert.
Der Code im folgenden Beispiel zeigt eine UDF, die Code aus den angegebenen Modulen importiert:
Ausführen der benutzerdefinierten Funktion¶
Nachdem Sie den Profiler aktiviert haben, führen Sie die benutzerdefinierte Funktion (UDF) aus, um mit dem Profiling zu beginnen.
Standardmäßig profiliert der Profiler Methoden, die in Ihrem Modul definiert sind. Weitere Informationen zum Registrieren anderer Module aus importierten Dateien im Profil finden Sie unter:ref:label-snowpark_python_udf_profiler_additional.
Profiling-Ausgabe ansehen¶
Um die Ausgabe des Profilings anzuzeigen, fragen Sie eine interne Ereignistabelle ab.
Die Ergebnisse des Profilings sind normalerweise 15–20 Sekunden, nachdem die UDF die Ausführung beendet hat, in der Ereignistabelle verfügbar. Sie können auf die Ausgabe zugreifen, indem Sie die Tabellensystemfunktion GET_PYTHON_UDF_PROFILER_OUTPUT verwenden.
Der Code im folgenden Beispiel zeigt eine Abfrage der Ereignistabelle nach Profiler-Ergebnissen an. Die als Argument angegebene query_id ist die Abfrage-ID derUDF-Abfrage, für die das Profiling aktiviert wurde.
Profiling-Ergebnisse¶
Wenn Sie die Profiler-Ergebnisse anzeigen, sehen Sie einen Bericht, der sich je nachdem, ob Sie das Profiling für einen Zeilenbericht oder einen Speicherbericht angegeben haben, unterscheidet.
Die Ausgabe des Speicher-Profilers sieht wie folgt aus:
Die Ausgabe des Zeilen-Profilers sieht wie folgt aus: