Leistungsstarke externe Funktionen entwerfen

Unter diesem Thema finden Sie Informationen zu Parallelität, Zuverlässigkeit und Skalierbarkeit von externen Funktionen, einschließlich Informationen zur Verwendung asynchroner externer Funktionen.

Unter diesem Thema:

Asynchrone vs. synchrone Remotedienste

Ein Remotedienst kann synchron oder asynchron sein.

synchron:

Der Aufruf eines synchronen Remotedienstes ist ein blockierender Aufruf. Der Remotedienst sendet erst dann eine Antwort, wenn die Ergebnisse vorliegen. Der Dienst kann nicht abgefragt werden.

Synchroner Code ist einfacher zu implementieren als asynchroner Code.

asynchron:

Ein asynchroner Remotedienst kann abgefragt werden, während der Aufrufer auf Ergebnisse wartet.

Die asynchrone Verwendung reduziert die Empfindlichkeit gegenüber Timeouts.

Weitere Informationen zu asynchronen Diensten finden Sie in der von Microsoft bereitgestellten Beschreibung der Antwortmuster von asynchronen Anforderungen. (Die Informationen sind nicht auf Microsoft Azure beschränkt.)

Ein synchroner Remotedienst empfängt eine HTTP-POST-Anforderung, verarbeitet die Anforderung und gibt das Ergebnis zurück. Je nachdem, wie lange es dauert, die Daten zu verarbeiten, kann es zu einer erheblichen Verzögerung zwischen dem Zeitpunkt des Eingangs der Anforderung und der Rückgabe der Ergebnisse kommen.

Ein asynchroner Remotedienst empfängt eine HTTP-POST-Anforderung und gibt eine (in der Regel fast sofortige) Bestätigung zurück, dass die Anforderung empfangen wurde. Der Aufrufer (Snowflake) führt dann eine Abrufschleife (Polling) aus, in der er eine oder mehrere HTTP-GET-Anforderungen ausgibt (normalerweise mit einer erheblichen Verzögerung zwischen den einzelnen Anforderungen), um den Status der asynchronen Verarbeitung zu überprüfen. Ein GET sendet keine Daten im Hauptteil der Anforderung, sondern enthält den gleichen Header wie das ursprüngliche POST.

Asynchrone Remotedienste sind nützlich, wenn ein Remotedienst die in Komponenten wie dem Proxydienst (z. B. Amazon API Gateway) integrierten Timeouts überschreitet.

Ein Remotedienst ist nicht unbedingt rein synchron oder rein asynchron. Ein Remotedienst kann zu verschiedenen Zeiten synchron und asynchron arbeiten, abhängig von Faktoren wie der Datenmenge in der Anforderung, der Anzahl anderer Anfragen, die verarbeitet werden, usw.

Die Snowflake-Implementierung von externen Funktionen ist im Allgemeinen sowohl mit synchronen als auch asynchronen Funktionsbibliotheken von Drittanbietern kompatibel.

Das folgende Diagramm veranschaulicht die synchrone und asynchrone Verarbeitung. Der obere Pfad ist synchron. Der untere Pfad (der eine oder mehrere HTTP-GET-Anforderungen enthält) ist asynchron.

Veranschaulichung der HTTP-POST- und HTTP-GET-Anforderungen für asynchrone externe Funktionen.

Beispiele für synchrone und asynchrone externe Funktionen finden Sie unter Snowflake-Beispielfunktionen.

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.

Bemerkung

Die Häufigkeit, mit der Abfragen zu Timeouts führen, hängt teilweise auch von der Skalierbarkeit des Remotedienstes ab. Wenn Ihr Remotedienst häufig Timeouts produziert, finden Sie unter Skalierbarkeit eine Diskussion zu diesem Thema.

Skalierbarkeit

Der Remotedienst, der Proxydienst und alle anderen Schritte zwischen Snowflake und dem Remotedienst müssen in der Lage sein, die an sie gesendeten Workloads zu verarbeiten.

Einige Anbieter von Cloudplattformen haben standardmäßige Nutzungsgrenzen oder andere Quoten für Proxydienste und Remotedienste, die den Durchsatz externer Funktionsaufrufe begrenzen können.

Größere Snowflake Warehouse-Größen können die Gleichzeitigkeit erhöhen, mit der Anforderungen gesendet werden, was die Quote des Proxydienstes überschreiten könnte.

Benutzer können sehen, wie oft Snowflake das Senden von Anforderungsstapeln (aufgrund von Drosselung oder anderen Fehlern) für eine Abfrage wiederholen musste, indem sie den Wert von Retries due to transient errors im Abfrageprofil anzeigen.

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:

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

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:

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.

Parallelität

Die Ressourcenanforderungen hängen von der Art und Weise ab, wie Zeilen auf Aufrufe verteilt sind (viele parallele Aufrufe mit jeweils wenigen Zeilen oder ein Aufruf mit der Gesamtzahl von Zeilen). Ein System, das eine hohe Kapazität unterstützt, unterstützt nicht unbedingt eine hohe Parallelität und umgekehrt. Sie sollten die erforderliche Peak-Parallelität sowie die größten angemessenen individuellen Workloads abschätzen und genügend Ressourcen bereitstellen, um beide Arten von Peaks zu verarbeiten.

Darüber hinaus sollte bei der Parallelitätsschätzung berücksichtigt werden, dass Snowflake Aufrufe externer Funktionen parallelisieren kann. Eine einzelne Abfrage eines einzelnen Benutzers kann dazu führen, dass mehrere Aufrufe gleichzeitig an den Remotedienst gesendet werden. Verschiedene Faktoren beeinflussen die Anzahl der gleichzeitigen Aufrufe von Snowflake an einen Proxy- oder Remotedienst, darunter:

  • Anzahl der gleichzeitigen Benutzer, die Abfragen mit externen Funktionen ausführen

  • Größe der Abfrage jedes Benutzers

  • Die Menge der Computeressourcen im virtuellen Warehouse (d. h. die Warehouse-Größe).

  • Anzahl der Warehouses.

Die korrekte Verwendung der Parallelität kann besonders komplex sein, wenn externe Funktionen Nebeneffekte haben. Die Ergebnisse können in Abhängigkeit von der Reihenfolge, in der die Zeilen des Benutzers verarbeitet werden, variieren. (Snowflake empfiehlt, dass Sie das Schreiben oder Verwenden von Remotediensten mit Nebeneffekten vermeiden.)

Zuverlässigkeit

Je nachdem, wo der Remotedienst ausgeführt wird, müssen Sie möglicherweise Folgendes berücksichtigen:

  • Zuverlässigkeit

  • Fehlerbehandlung

  • Debugging

  • Aktualisierung (wenn der Remotedienst möglicherweise neue Funktionen hinzufügt oder Fehlerkorrekturen benötigt)

Wenn der Remotedienst nicht zustandslos ist, müssen Sie möglicherweise auch die Wiederherstellung nach einem Fehler in Betracht ziehen. (Snowflake empfiehlt dringend, dass Remotedienste zustandslos sind.)

Informationen zu Timeouts und Wiederholungsversuchen finden Sie unter Konto für Timeout-Fehler und Berücksichtigen, dass Remotedienst mehr als eine Zeile übergeben kann.