Konzepte für externe Funktionen

Dieses Thema enthält eine allgemeine Beschreibung der Funktionsweise externer Funktionen.

Unter diesem Thema:

Funktionsweise externer Funktionen

Snowflake ruft Remotedienst nicht direkt auf. Stattdessen ruft Snowflake den Remotedienst über den nativen HTTPS-Proxydienst eines Cloudanbieters auf, z. B. API Gateway auf AWS.

Hauptschritte zum Aufrufen einer externen Funktion:

  1. Das Clientprogramm eines Benutzers übergibt Snowflake eine SQL-Anweisung, die eine externe Funktion aufruft.

  2. Bei der Auswertung der externen Funktion als Teil der Abfrageausführung liest Snowflake die Definition der externen Funktion, die die URL des Proxydienstes und den Namen der API-Integration enthält, der wiederum Authentifizierungsinformationen für diesen Proxydienst enthält.

  3. Snowflake liest Informationen aus der API-Integration und erstellt eine HTTP-POST-Anforderung, die Folgendes enthält:

    • HTTP-Header-Informationen. (Details sind unter CREATE EXTERNAL FUNCTION dokumentiert.)

    • Die zu verarbeitenden Daten. Diese Daten sind im JSON-Format.

    • Die zu verwendende „Ressource“ des Proxydienstes. Die Ressource enthält Informationen zum Remotedienst, z. B. den Standort dieses Dienstes.

    • Die Authentifizierungsinformationen für diese Proxydienst-Ressource.

    Die POST-Anforderung wird an den Proxydienst gesendet.

  4. Der Proxydienst empfängt die POST-Anforderung, verarbeitet diese und leitet sie an den eigentlichen Remotedienst weiter. Sie können sich Proxydienst und Proxyressource vereinfacht als Relais- oder Vermittlungsfunktion vorstellen, die den Remotedienst aufruft.

  5. Der Remotedienst verarbeitet die Daten und gibt das Ergebnis zurück, das über die Verarbeitungsfolge an die ursprüngliche SQL-Anweisung zurückgegeben wird.

Die folgende Abbildung zeigt die oben beschriebenen Schritte:

Illustration of the flow of data from external function call to remote service.

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 AWS 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.

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.

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 in Betracht ziehen, bei Überlastung 429 zurückzugeben. Wenn Snowflake den HTTP-Antwortcode 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 Skalierbarkeit.

Skalierbarkeit des Proxydienstes

Auch der Proxydienst sollte skalierbar sein. Glücklicherweise sind Proxydienste, die von großen Cloudanbietern bereitgestellt werden, generell skalierbar. Benutzer, die externe Funktionen entwickeln oder verwalten, sollten jedoch die folgenden Informationen berücksichtigen:

AWS API Gateway

AWS 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: https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html.

AWS 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:

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

  • Anzahl der Server im virtuellen Warehouse (d. h. die Warehouse-Größe)

  • Anzahl der Warehouse-Cluster.

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.