Snowpipe-Fehlerbehebung

Unter diesem Thema wird ein methodischer Ansatz zur Fehlerbehebung beim Laden von Daten mit Snowpipe beschrieben.

Unter diesem Thema:

Die Schritte zur Behebung von Problemen mit Snowpipe unterscheiden sich je nach dem zum Laden von Datendateien verwendeten Workflow.

Automatisches Laden von Daten mit Cloud Storage-Ereignisbenachrichtigungen

Schritt 1: Pipestatus überprüfen

Rufen Sie den aktuellen Status der Pipe ab. Die Ergebnisse werden im JSON-Format angezeigt. Weitere Informationen dazu finden Sie unter SYSTEM$PIPE_STATUS.

Überprüfen Sie die folgenden Werte:

lastReceivedMessageTimestamp

Gibt den Zeitstempel der letzten Ereignismeldung an, die aus der Meldungswarteschlange empfangen wurde. Beachten Sie, dass diese Nachricht möglicherweise nicht für die bestimmte Pipe gilt, z. B. wenn der mit der Nachricht verknüpfte Pfad nicht mit dem Pfad in der Pipedefinition übereinstimmt. Darüber hinaus werden von Pipes zur automatischen Erfassung nur solche Meldungen verarbeitet, die von erstellten Datenobjekten ausgelöste wurden.

Wenn der Zeitstempel früher als erwartet ist, deutet dies auf ein Problem mit der Dienstkonfiguration (d. h. Amazon SQS, Amazon SNS oder Azure Event Grid) oder mit dem Dienst selbst hin. Wenn das Feld leer ist, überprüfen Sie Ihre Dienstkonfigurationseinstellungen. Wenn das Feld einen Zeitstempel enthält, dieser jedoch früher als erwartet ist, überprüfen Sie, ob Einstellungen in Ihrer Dienstkonfiguration geändert wurden.

lastForwardedMessageTimestamp

Gibt den Zeitstempel der letzten Ereignismeldung vom Typ „Objekt erstellen“ mit einem übereinstimmenden Pfad an, der an die Pipe weitergeleitet wurde.

Wenn aus der Meldungswarteschlange Ereignismeldungen empfangen, aber nicht an die Pipe weitergeleitet werden, stimmen wahrscheinlich der Blob-Speicherpfad, in dem die neuen Datendateien erstellt werden, und der kombinierten Pfad, der in den Stagingbereichs- und Pipedefinitionen in Snowflake angegeben ist, nicht überein. Überprüfen Sie alle in den Stagingbereichs- und Pipedefinitionen angegebenen Pfade. Beachten Sie, dass ein in der Pipedefinition angegebener Pfad an einen beliebigen Pfad in der Stagingbereichsdefinition angehängt wird.

Schritt 2: Anzeigen des COPY-Verlaufs für die Tabelle

Wenn Ereignismeldungen empfangen und weitergeleitet werden, fragen Sie den Ladeaktivitätsverlauf für die Zieltabelle ab. Weitere Informationen dazu finden Sie unter COPY_HISTORY.

In der Spalte STATUS wird gezeigt, ob ein bestimmter Satz von Dateien geladen, teilweise geladen oder nicht geladen wurde. Die Spalte FIRST_ERROR_MESSAGE bietet einen Hinweis auf die Ursache, warum ein Ladeversuch nur teilweise erfolgreich war oder fehlgeschlagen ist.

Beachten Sie, dass bei mehreren Problemen mit einem Satz von Dateien die Spalte FIRST_ERROR_MESSAGE nur den ersten aufgetretenen Fehler anzeigt. Um alle in den Dateien aufgetretenen Fehler anzuzeigen, führen Sie eine COPY INTO <Tabelle>-Anweisung aus, wobei die Kopieroption VALIDATION_MODE auf RETURN_ALL_ERRORS gesetzt ist. Die Kopieroption VALIDATION_MODE weist eine COPY-Anweisung an, die zu ladenden Daten zu validieren und Ergebnisse auf Basis der angegebenen Validierungsoption zurückzugeben. Bei Angabe dieser Kopieroption werden keine Daten geladen. Verweisen Sie in der Anweisung auf die Dateien, die Sie mit Snowpipe zu laden versucht haben. Weitere Informationen zur Kopieroption finden Sie unter COPY INTO <Tabelle>.

Wenn die COPY_HISTORY-Ausgabe keine erwarteten Dateien enthält, fragen Sie einen früheren Zeitraum ab. Wenn die Dateien Duplikate früherer Dateien waren, wurde die Aktivität möglicherweise im Ladeverlauf aufgezeichnet, als versucht wurde, die ursprünglichen Dateien zu laden.

Schritt 3: Datendateien validieren

Wenn bei der Ladeoperation Fehler in den Datendateien auftreten, gibt die Tabellenfunktion COPY_HISTORY den ersten Fehler aus, der in jeder Datei aufgetreten ist. Fragen Sie zum Überprüfen der Datendateien die Funktion VALIDATE_PIPE_LOAD ab.

Aufrufen von Snowpipe-REST-Endpunkten zum Laden von Daten

Schritt 1: Überprüfen von Authentifizierungsproblemen

Die Snowpipe-REST-Endpunkte verwenden eine Schlüsselpaarauthentifizierung mit JSON Web Token (JWT).

Die Python/Java-Erfassungs-SDKs generieren das JWT für Sie. Wenn Sie die REST-API direkt aufrufen, müssen Sie es generieren. Wenn in der Anforderung kein JWT-Token angegeben ist, wird der Fehler 400 vom REST-Endpunkt zurückgegeben. Wenn das bereitgestellte Token ungültig ist, wird ein Fehler ähnlich dem folgenden zurückgegeben:

snowflake.ingest.error.IngestResponseError: Http Error: 401, Vender Code: 390144, Message: JWT token is invalid.

Schritt 2: Anzeigen des COPY-Verlaufs für die Tabelle

Fragen Sie den Verlauf der Ladeaktivitäten für eine Tabelle ab, einschließlich aller Versuche, Daten mit Snowpipe zu laden. Weitere Informationen dazu finden Sie unter COPY_HISTORY. In der Spalte STATUS wird gezeigt, ob ein bestimmter Satz von Dateien geladen, teilweise geladen oder nicht geladen wurde. Die Spalte FIRST_ERROR_MESSAGE bietet einen Hinweis auf die Ursache, warum ein Ladeversuch nur teilweise erfolgreich war oder fehlgeschlagen ist.

Beachten Sie, dass bei mehreren Problemen mit einem Satz von Dateien die Spalte FIRST_ERROR_MESSAGE nur den ersten aufgetretenen Fehler anzeigt. Um alle in den Dateien aufgetretenen Fehler anzuzeigen, führen Sie eine COPY INTO <Tabelle>-Anweisung aus, wobei die Kopieroption VALIDATION_MODE auf RETURN_ALL_ERRORS gesetzt ist. Die Kopieroption VALIDATION_MODE weist eine COPY-Anweisung an, die zu ladenden Daten zu validieren und Ergebnisse auf Basis der angegebenen Validierungsoption zurückzugeben. Bei Angabe dieser Kopieroption werden keine Daten geladen. Verweisen Sie in der Anweisung auf die Dateien, die Sie mit Snowpipe zu laden versucht haben. Weitere Informationen zur Kopieroption finden Sie unter COPY INTO <Tabelle>.

Schritt 3: Überprüfen des Pipestatus

Wenn die Tabellenfunktion COPY_HISTORY 0 Ergebnisse für den Datenladevorgang zurückgibt, den Sie untersuchen, rufen Sie den aktuellen Status der Pipe ab. Die Ergebnisse werden im JSON-Format angezeigt. Weitere Informationen dazu finden Sie unter SYSTEM$PIPE_STATUS.

Der executionState-Schlüssel gibt den Ausführungsstatus der Pipe an. So zeigt beispielsweise PAUSED an, dass die Pipe derzeit angehalten ist. Der Pipeeigentümer könnte das Ausführen der Pipe mit ALTER PIPE fortsetzen.

Wenn der executionState-Wert auf ein Problem beim Starten der Pipe hinweist, prüfen Sie den error-Schlüssel bzgl. weiterer Informationen.

Schritt 4: Datendateien validieren

Wenn bei der Ladeoperation Fehler in den Datendateien auftreten, gibt die Tabellenfunktion COPY_HISTORY den ersten Fehler aus, der in jeder Datei aufgetreten ist. Fragen Sie zum Überprüfen der Datendateien die Funktion VALIDATE_PIPE_LOAD ab.

Andere Probleme

Entladene Dateien

Wenn die Funktionsausgabe COPY_HISTORY anzeigt, dass eine Teilmenge von Dateien nicht geladen wurde, können Sie versuchen, die Pipe zu „aktualisieren“.

Diese Situation kann in einer der folgenden Situationen auftreten:

  • Der externe Stagingbereich wurde zuvor mit dem Befehl COPY INTO table für das Massenladen von Daten verwendet.

  • REST API:

    • Für den Aufruf der REST-APIs wird eine externe, ereignisgesteuerte Funktionalität verwendet, und im externen Stagingbereich bestand bereits vor der Konfiguration der Ereignisse ein Backlog mit Datendateien.

  • Automatische Erfassung:

    • Im externen Stagingbereich war bereits ein Backlog der Datendateien vorhanden, bevor Ereignisbenachrichtigungen konfiguriert wurden.

    • Ein Ereignisbenachrichtigungsfehler verhinderte, dass eine Reihe von Dateien in die Warteschlange gestellt wurde.

Um die Datendateien mit der konfigurierten Pipe in Ihren externen Stagingbereich zu laden, führen Sie eine ALTER PIPE … REFRESH-Anweisung aus.

Geänderte Daten konnten nicht neu geladen werden, geänderte Daten wurden unbeabsichtigt geladen

Snowflake verwendet Metadaten zum Laden von Dateien, um das erneute Laden derselben Dateien (und das Duplizieren von Daten) in einer Tabelle zu verhindern. Snowpipe verhindert das Laden von Dateien mit dem gleichen Namen, auch wenn sie später geändert wurden (d. h. ein anderes eTag haben).

Die Metadaten zum Laden von Dateien sind dem Pipeobjekt zugeordnet und nicht der Tabelle. Infolgedessen:

  • Stagingdateien mit dem gleichen Namen wie bereits geladene Dateien werden ignoriert, auch wenn sie geändert wurden, z. B. wenn neue Zeilen hinzugefügt oder Fehler in der Datei korrigiert wurden.

  • Das Kürzen der Tabelle mit dem Befehl TRUNCATE TABLE löscht nicht die Snowpipe-Datei, die die Metadaten lädt.

Beachten Sie jedoch, dass Pipes die Metadaten des Ladeverlaufs nur für 14 Tage beibehalten. Daher:

Dateien wurden innerhalb von 14 Tagen geändert und erneut bereitgestellt

Snowpipe ignoriert geänderte Dateien, die erneut bereitgestellt werden. Um die gleichen Datendateien neu zu laden, ist es derzeit notwendig, das Pipeobjekt mit der CREATE OR REPLACE PIPE-Syntax neu zu erstellen.

Im folgenden Beispiel wird die mypipe-Pipe basierend auf dem Beispiel in Schritt 1 von Vorbereiten des Ladens von Daten über die Snowpipe REST-API neu erstellt:

create or replace pipe mypipe as copy into mytable from @mystage;
Dateien wurden nach 14 Tagen geändert und erneut bereitgestellt

Snowpipe lädt die Daten erneut und führt möglicherweise zu doppelten Datensätzen in der Zieltabelle.

Darüber hinaus können doppelte Datensätze in die Zieltabelle geladen werden, wenn COPY INTO <Tabelle>-Anweisungen ausgeführt werden, die auf denselben Bucket/Container, Pfad und dieselbe Zieltabelle verweisen wie beim Laden Ihrer aktiven Snowpipe. Die Ladeverläufe für den COPY-Befehl und Snowpipe werden in Snowflake separat gespeichert. Wenn Sie nach dem Laden historischer Stagingdaten die Daten manuell über die Pipekonfiguration laden müssen, führen Sie eine ALTER PIPE … REFRESH-Anweisung aus. Weitere Informationen dazu finden Sie unter Entladene Dateien unter diesem Thema.

Fehler: Die dem Stagingbereich {1} zugeordnete Integration {0} wurde nicht gefunden

Das Laden von Daten von einem externen Stagingbereich kann einen Fehler ähnlich dem folgenden hervorrufen:

003139=SQL compilation error:\nIntegration ''{0}'' associated with the stage ''{1}'' cannot be found.

Dieser Fehler kann auftreten, wenn die Zuordnung zwischen dem externen Stagingbereich und der mit dem Stagingbereich verknüpften Speicherintegration unterbrochen wurde. Dies geschieht, wenn das Speicherintegrationsobjekt neu erstellt wurde (mithilfe von CREATE OR REPLACE STORAGE INTEGRATION). Ein Stagingbereich ist mit einer Speicherintegration verknüpft, wobei anstelle des Namens der Speicherintegration eine ausgeblendete ID verwendet wird. Im Hintergrund löscht die CREATE OR REPLACE-Syntax das Objekt und erstellt es mit einer anderen verborgenen ID neu.

Wenn Sie eine Speicherintegration neu erstellen müssen, nachdem diese mit einer oder mehreren Stagingbereichen verknüpft wurde, müssen Sie die Zuordnung zwischen einem Stagingbereich und der Speicherintegration neu einrichten, indem Sie ALTER STAGE Stagingbereichsname SET STORAGE_INTEGRATION = Speicherintegrationsname ausführen, wobei:

  • Stagingbereichsname ist der Name des Stagingbereichs.

  • Speicherintegrationsname ist der Name der neuen Speicherintegration.