Leistungsstarke externe Funktionen entwerfen¶

Synchroner Remotedienst¶

Bevor ein Benutzer eine externe Funktion aufrufen kann, müssen Entwickler und Snowflake-Kontoadministratoren Snowflake für den Zugriff auf den Proxydienst konfigurieren. Normalerweise werden die Schritte in ungefähr der unten gezeigten Reihenfolge ausgeführt (beginnend von der rechten Seite des obigen Diagramms nach links in Richtung Snowflake).

1. Ein Entwickler muss den Remotedienst schreiben, und dieser Remotedienst muss über den HTTPS-Proxydienst verfügbar gemacht werden. Der Remotedienst kann beispielsweise eine Python-Funktion sein, die auf AWS Lambda ausgeführt und über eine Ressource im Amazon API Gateway verfügbar gemacht wird.

2. In Snowflake muss ein ACCOUNTADMIN oder eine Rolle mit der Berechtigung CREATE INTEGRATION ein Objekt „API-Integration“ erstellen, das Authentifizierungsinformationen enthält, die Snowflake eine Kommunikation mit dem Proxydienst ermöglichen. Die API-Integration wird mit dem SQL-Befehl CREATE API INTEGRATION erstellt.

3. Ein Snowflake-Benutzer muss den SQL-Befehl CREATE EXTERNAL FUNCTION ausführen. Der Benutzer muss eine Rolle verwenden, die über die Berechtigung USAGE für die API-Integration verfügt und über ausreichende Berechtigungen zum Erstellen von Funktionen.

   Bemerkung

   Der Befehl CREATE EXTERNAL FUNCTION erstellt keine externe Funktion im Sinne des Ladens von Code, der außerhalb von Snowflake ausgeführt wird. Stattdessen erstellt der Befehl CREATE EXTERNAL FUNCTION ein Datenbankobjekt, das indirekt auf den Code verweist, der außerhalb von Snowflake ausgeführt wird. Genauer gesagt erstellt der Befehl CREATE EXTERNAL FUNCTION ein Objekt, das Folgendes enthält:

   • Die URL der Ressource im HTTPS-Proxydienst, die als Vermittlungsfunktion fungiert.

   • Der Name der API-Integration, die zur Authentifizierung beim Proxydienst verwendet werden soll.

   • Ein Name, der effektiv ein Alias für den Remotedienst ist. Dieser Alias wird in SQL-Befehlen verwendet, z. B. SELECT MyAliasForRemoteServiceXYZ(col1) ...;

Der Alias in Snowflake, der Name der HTTPS-Proxydienstressource und der Name des Remotedienstes können unterschiedlich sein. (Die Verwendung des gleichen Namens für alle drei kann jedoch die Verwaltung vereinfachen.)

Obwohl die oben beschriebenen Schritte die häufigste Methode zum Ausführen einer externen Funktion sind, sind einige Variationen zulässig. Beispiel:

• Der Remotedienst ist möglicherweise nicht der letzte Schritt im Ablauf. Der Remotedienst könnte einen weiteren Remotedienst aufrufen, um einen Teil der Arbeit zu erledigen.

• Wenn der Remotedienst keine JSON-formatierten Daten akzeptiert und zurückgibt, kann die Ressource des HTTPS-Proxydienstes (die Vermittlungsfunktion) die Daten vom JSON-Format in ein anderes Format konvertieren (und die zurückgegebenen Daten zurück in JSON konvertieren).

• Obwohl Snowflake empfiehlt, dass sich der Remotedienst wie eine echte Funktion verhält (d. h. als Code, der 0 oder mehr Eingabeparameter akzeptiert und einen Ausgabewert zurückgibt), der keine Nebeneffekte hat und keine Statusinformationen enthält, ist dies nicht unbedingt erforderlich. Der Remotedienst kann andere Aufgaben ausführen, z. B. das Senden von Warnungen, wenn ein Wert (z. B. ein Temperaturwert in den Daten) gefährlich hoch ist. In seltenen Fällen speichert der Remotedienst möglicherweise Statusinformationen, z. B. die Gesamtzahl der ausgegebenen Warnungen.

Asynchroner Remotedienst¶

Ein asynchroner Remotedienst ist nützlich, wenn ein Remotedienst die in Komponenten wie dem Proxydienst integrierten Timeouts überschreitet.

Ein asynchroner Remotedienst umfasst die gleichen Komponenten (Client, Snowflake, Proxydienst und Remotedienst) und die gleichen allgemeinen Schritte wie oben beschrieben. Die Einzelheiten der HTTP-Anforderung und deren Antworten sind jedoch unterschiedlich.

Asynchrones Verhalten wird von der Person, die den Remotedienst schreibt, (und von Snowflake) implementiert. SQL-Anweisungen sind für asynchrone Remotedienste die gleichen wie für synchrone Remotedienste.

Wenn Sie Ihren eigenen Remotedienst schreiben und dieser für die asynchronen Verarbeitung in Snowflake kompatibel sein soll, muss dieser sich wie folgt verhalten:

• Wenn er anfangs einen HTTP-POST-Befehl für einen bestimmten Batch von Zeilen empfängt, gibt der Remotedienst den HTTP-Code 202 zurück („Processing…“).

• Wenn der Remotedienst nach dem POST, aber bevor die Ausgabe fertig ist, irgendwelche HTTP-GET-Anforderungen empfängt, gibt der Remotedienst den HTTP-Code 202 zurück.

• Nachdem der Remotedienst alle Ausgabezeilen generiert hat, wartet er auf den nächsten HTTP-GET-Befehl mit derselben Batch-ID und gibt dann die empfangenen Zeilen zusammen mit dem HTTP-Code 200 zurück („Successful completion…“).

Kurz gesagt, für jeden empfangenen Batch gibt der Remotedienst „202“ zurück, bis die Ergebnisse bereit sind, woraufhin der nächste GET-Befehl die Ergebnisse und einen HTTP-Code 200 erhält.

Für jeden Batch verwendet Snowflake den asynchronen Remotedienst wie folgt:

1. Snowflake sendet einen HTTP-POST-Befehl, der die zu verarbeitenden Daten enthält, zusammen mit einer eindeutigen Batch-ID.

2. Wenn Snowflake einen HTTP-Code 202 als Antwort erhält, führt Snowflake so lange eine Schleife aus, bis einer der folgenden Punkte zutrifft:

   • Snowflake empfängt die Daten und einen HTTP-Code 200.

   • Das interne Timeout von Snowflake ist erreicht.

   • Snowflake erhält einen Fehler (z. B. HTTP-Antwortcode 5XX).

   In jeder Iteration der Schleife führt Snowflake eine Verzögerung aus und gibt dann einen HTTP-GET-Befehl aus, der die gleiche Batch-ID enthält wie die Batch-ID des entsprechenden HTTP-POST-Befehls, sodass der Remotedienst Informationen für den richtigen Batch zurückgeben kann.

   Die Verzögerung innerhalb der Schleife beginnt kurz, wird aber mit jeder empfangenen HTTP 202-Antwort länger, bis das Timeout von Snowflake erreicht ist.

3. Wenn das Timeout von Snowflake erreicht wird, bevor HTTP 200 zurückgegeben wird, bricht Snowflake die SQL-Abfrage ab.

   Gegenwärtig beträgt das Timeout von Snowflake 10 Minuten (600 Sekunden) und ist nicht vom Benutzer konfigurierbar. Dieser Timeout-Wert könnte sich in Zukunft ändern.

Skalierbarkeit des Remotedienstes¶

Entwickler, die Remotedienste schreiben, sollten Folgendes berücksichtigen:

• Die Häufigkeit, mit der der Remotedienst aufgerufen wird

• Die Anzahl der pro Aufruf gesendeten Zeilen

• Die Ressourcen, die zum Verarbeiten jeder Zeile erforderlich sind

• Die zeitliche Verteilung der Aufrufe (Peak vs. Durchschnitt)

Die Kapazität muss möglicherweise im Laufe der Zeit erhöht werden, da die Funktion zunächst nur einigen Entwicklern und Testern aufgerufen wird, dann aber von der gesamten Organisation genutzt wird. Wenn der Remotedienst von mehreren Organisationen verwendet wird, muss die Kapazität möglicherweise mit zunehmender Anzahl von Organisationen erhöht werden. Darüber hinaus wird es mit zunehmender Anzahl und Vielfalt von Organisationen möglicherweise schwieriger, die Größe und den Zeitpunkt der Workloads vorherzusagen.

Der Anbieter des Remotedienstes ist dafür verantwortlich, genügend Kapazität bereitzustellen, um Spitzenlasten zu bewältigen. Zur Skalierung des Dienstes können verschiedene Techniken verwendet werden. Wenn der Remotedienst vom Autor des Remotedienstes verwaltet wird, muss der Autor den Dienst möglicherweise explizit mit genügend Kapazität bereitstellen, um Spitzenlasten zu verarbeiten. Alternativ kann der Autor entscheiden, einen gehosteten, automatisch skalierten oder elastischen Dienst wie AWS Lambda zu verwenden.

Remotedienste sollten bei Überlastung den HTTP-Antwortcode 429 zurückgeben. Wenn Snowflake HTTP 429 erkennt, reduziert Snowflake die Rate, mit der Zeilen gesendet werden, und versucht Batches von Zeilen, die nicht erfolgreich verarbeitet wurden, erneut zu senden.

Weitere Informationen zur Behandlung von Skalierbarkeitsproblemen finden Sie unter Problembehandlung bei Skalierbarkeits- und Leistungsproblemen.

Wenn Remotedienstaufrufe zu einem Timeout führen, weil jeder einzelne Aufruf zu lange dauert, und nicht, weil das System generell überlastet ist, dann lesen Sie die Beschreibung, wie ein Asynchroner Remotedienst erstellt wird.

Skalierbarkeit des Proxydienstes¶

Auch der Proxydienst sollte skalierbar sein. Glücklicherweise sind Proxydienste, die von großen Cloudanbietern bereitgestellt werden, generell skalierbar.

Allerdings sind bei einigen Proxydiensten, darunter Amazon API Gateway und Azure API Management, standardmäßige Nutzungsgrenzen definiert. Wenn die Anforderungsrate das Limit überschreitet, drosseln diese Proxydienste die Anforderungen. Gegebenenfalls müssen Sie AWS oder Azure bitten, die Quote für Ihren Proxydienst zu erhöhen.

Benutzer, die externe Funktionen entwickeln oder verwalten, sollten jedoch die folgenden plattformspezifischen Informationen berücksichtigen:

Amazon API Gateway:

Amazon API Gateway ist selbst ein verwalteter AWS-Dienst, der automatisch an den Workload des Benutzers angepasst wird. Benutzer sollten mit den verschiedenen Einschränkungen von API Gateway vertraut sein.

Amazon API Gateway kann so konfiguriert werden, dass der Remotedienst skaliert wird. Insbesondere kann das API Gateway so konfiguriert werden, dass das Zwischenspeichern (Caching) und/oder Drosseln von Anforderungen aktiviert wird, um die Belastung des Remotedienstes bei Bedarf zu verringern:

• Caching aktivieren

• Drosselung aktivieren

Da das Drosseln Timeouts und Wiederholungsversuche beeinflussen kann, sollten Benutzer auch Kenntnis darüber haben, wie Snowflake mit Timeouts und Wiederholungsversuchen umgeht:

• Konto für Timeout-Fehler

• Berücksichtigen, dass Remotedienst mehr als eine Zeile übergeben kann

Microsoft Azure API Management-Dienst:

Für Azure API Management hängen die Limits von der für den Dienst gewählten SKU ab. Die Grenzen sind unter Limits des Azure-Abonnementdienstes im Abschnitt API Management-Limits dokumentiert.

Da das Drosseln Timeouts und Wiederholungsversuche beeinflussen kann, sollten Benutzer auch Kenntnis darüber haben, wie Snowflake mit Timeouts und Wiederholungsversuchen umgeht:

• Konto für Timeout-Fehler

• Berücksichtigen, dass Remotedienst mehr als eine Zeile übergeben kann

Problembehandlung bei Skalierbarkeits- und Leistungsproblemen¶

• Verwenden Sie die Funktion QUERY_HISTORY , QUERY_HISTORY_BY_*, um Leistungsmerkmale zu überwachen und Leistungsprobleme zu beheben.

• Verwenden Sie die Seite Query Profile, um die durchschnittliche Latenz pro Anforderung anzuzeigen.

• Auf der Seite Query Profile können Sie sehen, wie oft Anforderungen aufgrund vorübergehender Fehler wiederholt wurden, einschließlich der im Abschnitt Berücksichtigen, dass Remotedienst mehr als eine Zeile übergeben kann aufgeführten.

• Überwachen Sie die Ressourcennutzung Ihres Remotedienstes, um festzustellen, wie diese an die Last angepasst wird, und stellen Sie sicher, dass der Remotedienst über genügend Kapazität verfügt, um Spitzenlasten zu bedienen.

• Verwenden Sie die Protokollierung im Amazon API Gateway oder im Remotedienst, um Details pro Anforderung abzurufen.

• Steuern Sie die Parallelität, mit der Snowflake Anforderungen an den Remotedienst sendet. Weitere Details dazu finden Sie unter Parallelität.

• Geben Sie den HTTP-Antwortcode 429 vom Remotedienst zurück, wenn dieser überlastet ist. Geben Sie diesen so früh wie möglich zurück, anstatt auf eine Erhöhung der Latenz zu warten.

• Berücksichtigen Sie das Timeout für den Proxyservice. Ab Juli 2020 beträgt das Timeout für Amazon API Gateway beispielsweise 30 Sekunden. Timeouts können durch verschiedene Faktoren verursacht werden, einschließlich Überlastung des Remotedienstes.

Snowflake versucht, Abfragen bei vorübergehenden Fehlern/Timeouts innerhalb einer angemessenen Zeit erneut auszuführen. Wenn der Dienst jedoch weiterhin überlastet ist und die Wiederholungsversuche nicht erfolgreich sind, wird die Abfrage schließlich abgebrochen.