Problembehandlung bei externen Funktionen

Unter diesem Thema wird die Behandlung von Problemen bei externen Funktionen beschrieben.

Beachten Sie, dass es bei einigen Cloudplattformen in den Anweisungen zum Erstellen externer Funktionen auf diesen Cloudplattformen möglicherweise zusätzliche Informationen zur Problembehandlung gibt.

Unter diesem Thema:

Allgemeine Problembehandlung

Stellen Sie sicher, dass die Argumente für die externe Funktion den Argumenten des Remotedienstes entsprechen

Wenn Sie Ihren eigenen Remotedienst schreiben und die Anzahl, die Datentypen oder die Reihenfolge der Argumente für den Remotedienst ändern, müssen Sie die entsprechenden Änderungen auch an der externen Funktion vornehmen. Derzeit verfügt der Befehl ALTER EXTERNAL FUNCTION nicht über eine Option zum Ändern von Parametern. Sie müssen daher die externe Funktion löschen und neu erstellen, um die Argumente zu ändern.

Verarbeitungsleistung

Die folgenden Tipps können Ihnen beim Debuggen von Leistungsproblemen helfen:

Siehe auch den Abschnitt zur Behandlung von Problemen mit der Skalierbarkeit.

Skalierbarkeit

Die folgenden Tipps können Ihnen beim Debuggen von Skalierungsproblemen helfen:

  • 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 zu versuchen. Wenn der Dienst jedoch weiterhin überlastet ist und die Wiederholungsversuche nicht erfolgreich sind, wird die Abfrage schließlich abgebrochen.

Siehe dazu auch den Abschnitt zur Problembehandlung unter Verarbeitungsleistung.

Spezifische Symptome

Plattformunabhängige Symptome

Symptom: Beim Versuch, die externe Funktion aufzurufen, wird die Meldung „Error parsing JSON: Invalid response“ angezeigt.

Mögliche Ursachen

Die wahrscheinlichste Ursache ist, dass die vom Remotedienst zurückgegebenen JSON-Daten (z. B. AWS Lambda-Funktion) nicht korrekt erstellt wurde.

Mögliche Lösungen

Stellen Sie sicher, dass Sie ein Array von Arrays zurückgeben, wobei für jede empfangene Eingabezeile ein inneres Array zurückgegeben wird. Überprüfen Sie die Beschreibung des Ausgabeformats unter Von Snowflake empfangenes Datenformat.

Symptom: Eine Fehlermeldung besagt, dass das Format des zurückgegebenen Werts nicht JSON ist.

Mögliche Ursachen

Eine mögliche Ursache hierfür ist, dass Ihr Rückgabewert doppelte Anführungszeichen enthält.

Mögliche Lösungen

Obwohl JSON-Zeichenfolgen durch doppelte Anführungszeichen getrennt sind, sollte die Zeichenfolge selbst in den meisten Fällen nicht mit einem Anführungszeichen beginnen und enden. Wenn die eingebetteten doppelten Anführungszeichen falsch sind, entfernen Sie diese.

Symptom: Eine Fehlermeldung besagt, dass die Funktion die falsche Anzahl von Zeilen empfängt.

Mögliche Ursachen

Der Remotedienst hat wahrscheinlich versucht, mehr oder weniger Zeilen zurückzugeben, als er empfangen hat. (Denken Sie daran, dass die Funktion, obwohl sie nominell skalar ist, möglicherweise im Feld „body“ des Parameters „event“ mehrere Zeilen empfängt und genau so viele Zeilen zurückgeben sollte, wie sie empfangen hat.)

Mögliche Lösungen

Stellen Sie sicher, dass der Remotedienst für jede empfangene Zeile genau eine Zeile zurückgibt.

AWS

Symptom: Wenn Sie Ihre Funktion mit SQL aufrufen, wird eine Meldung angezeigt, dass die Zeilennummerierung nicht in Ordnung ist.

Mögliche Ursachen

Denken Sie daran, dass die von Ihnen zurückgegebenen Zeilennummern monoton aufsteigende Ganzzahlen sein müssen, die bei 0 beginnen. Die Eingabezeilennummern müssen ebenfalls dieser Regel folgen, und jede Ausgabe sollte mit der entsprechenden Eingabezeile übereinstimmen. So sollte beispielsweise die Ausgabe von Ausgabezeile 0 der Eingabe von Eingabezeile 0 entsprechen.

Mögliche Lösungen
  1. Stellen Sie sicher, dass die von Ihnen zurückgegebenen Zeilennummern mit den erhaltenen Zeilennummern übereinstimmen und dass jeder Ausgabewert die Zeilennummer der entsprechenden Eingabe verwendet. Das sollte funktionieren. Wenn dies nicht der Fall ist, sind möglicherweise die eingegebenen Zeilennummern nicht korrekt oder die Zeilen wurden nicht in der richtigen Reihenfolge zurückgegeben. Fahren Sie daher mit Schritt 2 fort.

  2. Stellen Sie sicher, dass die Ausgabezeilennummern bei 0 beginnen, um 1 erhöht werden und korrekt sind.

Symptom: Ein Amazon API Gateway gibt Fehler 502 zurück, wenn der Endpunkt die Lambda-Proxyintegration verwendet

Mögliche Ursachen

Die Lambda-Funktion könnte folgendes Problem haben:

  • Timeout

  • Ausnahme ausgelöst

  • Auf andere Weise fehlgeschlagen

Mögliche Lösungen

Wenn Ihnen die Lambda- oder API Gateway-Protokolle zur Verfügung stehen, überprüfen Sie diese.

Wenn Ihnen der Quellcode der Lambda-Funktion zur Verfügung steht, dann analysieren und debuggen Sie den Code der Lambda-Funktion. In einigen Fällen können Sie möglicherweise eine Kopie dieses Codes in einem einfacheren Kontext (außerhalb von AWS) ausführen, um das Debuggen zu erleichtern.

Stellen Sie sicher, dass die an die Lambda-Funktion gesendeten Daten das von der Lambda-Funktion erwartete Format haben. Sie können versuchen, ein kleineres, einfacheres Dataset zu senden, um festzustellen, ob dies erfolgreich ist.

Stellen Sie sicher, dass Sie nicht zu viele Daten gleichzeitig senden.

In einigen Fällen kann das Problem durch Erhöhen des Timeouts behoben werden, insbesondere wenn die Lambda-Funktion viele CPU-Ressourcen benötigt oder wenn die Lambda-Funktion selbst andere Remotedienste aufruft und daher mehr Zeit benötigt.

Funktion EXTERNAL_FUNCTIONS_HISTORY

Symptom: EXTERNAL_FUNCTIONS_HISTORY gibt „…invalid identifier…“ zurück.

Mögliche Ursache

Möglicherweise haben Sie die Funktionssignatur nicht in einfache Anführungszeichen gesetzt. Folgendes ist beispielsweise falsch, weil die Anführungszeichen fehlen:

select *
  from table(information_schema.external_functions_history(
    function_signature => mydb.public.myfunction(integer, varchar)));
Mögliche Lösung

Korrigieren Sie dies, indem Sie die Funktionssignatur in Anführungszeichen setzen:

select *
  from table(information_schema.external_functions_history(
    function_signature => 'mydb.public.myfunction(integer, varchar)'));

Symptom: EXTERNAL_FUNCTIONS_HISTORY gibt nur eine Ausgabezeile zurück, und viele der Spalten sind NULL.

Mögliche Ursache

Sie haben wahrscheinlich keine Funktionssignatur eingefügt. Wenn Sie keine Funktionssignatur angeben, gibt EXTERNAL_FUNCTION_HISTORY() für Spalten wie INVOCATIONS, SENT ROWS usw. die Aggregatwerte zurück und für Spalten mit Funktionsname, Argumentliste usw. den Wert NULL.

Mögliche Lösung

Wenn Sie Informationen zu genau einer Funktion abrufen möchten, fügen Sie eine Funktionssignatur hinzu.

Wenn Sie Informationen zu allen Funktionen abrufen möchten, sind die NULL-Werte für einige Spalten korrekt, und Sie müssen die Abfrage nicht korrigieren.