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

Fehlerbenachrichtigungen

Konfigurieren Sie Fehlerbenachrichtigungen für Snowpipe. Wenn Snowpipe während eines Ladevorgangs auf Fehler stößt, sendet das Feature eine Benachrichtigung an einen konfigurierten Cloudmessagingdienst und ermöglicht so die Analyse Ihrer Datendateien. Weitere Informationen dazu finden Sie unter Snowpipe-Fehlerbenachrichtigungen.

Allgemeine Problembehandlung

Führen Sie die folgenden Schritte aus, um die Ursache für typische Probleme zu ermitteln, die das automatische Laden von Dateien verhindern.

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: COPY-Verlauf für die Tabelle anzeigen

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.

In Microsoft Azure Data Lake Storage Gen2-Speicher generierte Dateien werden nicht geladen

Derzeit rufen einige Clients von Drittanbietern FlushWithClose nicht in der ADLS Gen 2 REST-API auf. Dieser Schritt ist notwendig, um Ereignisse auszulösen, die Snowpipe benachrichtigen, die Dateien zu laden. Versuchen Sie, die REST-API manuell aufzurufen, um das Laden der Daten in Snowpipe auszulösen.

Weitere Informationen zur Flush-Methode mit dem Argument close finden Sie unter https://docs.microsoft.com/en-us/dotnet/api/azure.storage.files.datalake.datalakefileclient.flush. Zusätzliche REST-API-Referenzinformationen zum Laden mit dem Parameter close finden Sie unter https://docs.microsoft.com/en-us/rest/api/storageservices/datalakestoragegen2/path/update.

Snowpipe stoppt das Laden von Dateien nach dem Löschen eines Amazon SNS-Themenabonnements

Wenn ein Benutzer zum ersten Mal ein Pipeobjekt erstellt, das ein bestimmtes Thema des Amazon Simple Notification Service (SNS) referenziert, abonniert Snowflake eine Snowflake-eigene Warteschlange des Amazon Simple Queue Service (SQS) zu diesem Thema. Wenn ein AWS-Administrator das SQS-Abonnement für das SNS-Thema löscht, erhält jede Pipe, die das Thema referenziert, keine Ereignismeldung mehr von Amazon S3.

So beheben Sie das Problem:

  1. Warten Sie 72 Stunden ab dem Zeitpunkt, an dem das SNS-Themenabonnement gelöscht wurde.

    Nach 72 Stunden löscht Amazon SNS das gelöschte Abonnement. Weitere Informationen finden Sie in der Amazon SNS-Dokumentation.

  2. Erstellen Sie alle Pipes neu, die auf das Thema verweisen (mit CREATE OR REPLACE PIPE). Verweisen Sie in der Pipedefinition auf dasselbe SNS-Thema. Eine Anleitung dazu finden Sie unter Schritt 3: Pipe mit aktivierter automatischer Erfassung erstellen.

Alle Pipes, die vor der Löschung des SNS-Themenabonnements funktionierten, sollten nun wieder Ereignismeldungen von S3 empfangen können.

Um die 72-stündige Verzögerung zu umgehen, können Sie ein SNS-Thema mit einem anderen Namen erstellen. Erstellen Sie mit dem Befehl CREATE OR REPLACE PIPE alle Pipes neu, die auf das Thema verweisen, und geben Sie den neuen Themennamen an.

Ladevorgänge aus Google Cloud Storage verzögern sich oder es fehlen Dateien

Wenn das automatische Laden von Daten aus Google Cloud Storage (GCS) unter Verwendung von Pub/Sub-Meldungen konfiguriert ist, konnte die Ereignismeldung möglicherweise nur für eine einzelne Stagingdatei gelesen werden. Alternativ können sich die Datenladungen von GCS zwischen einigen Minuten und einem Tag oder länger verzögern. Im Allgemeinen werden beide Probleme verursacht, wenn ein GCS-Administrator dem Snowflake-Dienstkonto nicht die Rolle Monitoring Viewer zugewiesen hat.

Eine Anleitung dazu finden Sie unter Konfigurieren des sicheren Zugriffs auf Cloudspeicher im Abschnitt „Schritt 2: Snowflake Zugriff auf die Speicherorte gewähren“.

Aufrufen von Snowpipe-REST-Endpunkten zum Laden von Daten

Fehlerbenachrichtigungen

Die Unterstützung für Snowpipe-Fehlerbenachrichtigungen ist für Snowflake-Konten verfügbar, die auf Amazon Web Services (AWS) gehostet werden. Fehler, die beim Laden von Daten auftreten, lösen Benachrichtigungen aus, die eine Analyse Ihrer Datendateien ermöglichen. Weitere Informationen dazu finden Sie unter Snowpipe-Fehlerbenachrichtigungen.

Allgemeine Problembehandlung

Führen Sie die folgenden Schritte aus, um die Ursache für typische Probleme zu ermitteln, die das Laden von Dateien verhindern:

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

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

Menge von Dateien nicht geladenen

Fehlender COPY_HISTORY-Datensatz für das Laden

Prüfen Sie, ob die COPY INTO <Tabelle>-Anweisung in der Pipe die PATTERN-Klausel enthält. Wenn ja, überprüfen Sie, ob der als PATTERN-Wert angegebene reguläre Ausdruck alle zu ladenden Stagingdateien herausfiltert.

Um den PATTERN-Wert ändern zu können, muss die Pipe mit der Syntax CREATE OR REPLACE PIPE neu erstellt werden.

Weitere Informationen dazu finden Sie unter CREATE PIPE.

COPY_HISTORY-Datensatz zeigt entladene Teilmenge von Dateien an

Wenn die Ausgabe der COPY_HISTORY-Funktion 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.

Doppelte Daten in Zieltabellen

Vergleichen Sie die COPY INTO <Tabelle>-Anweisungen in den Definitionen aller Pipes des Kontos durch Ausführen von SHOW PIPES oder durch Abfragen der Ansicht PIPES in Account Usage oder der Ansicht PIPES in Information Schema. Wenn in den COPY INTO <Tabelle>-Anweisungen mehrere Pipes auf denselben Cloudspeicherort verweisen, stellen Sie sicher, dass sich die Verzeichnispfade nicht überschneiden. Andernfalls könnten mehrere Pipes denselben Satz von Datendateien in die Zieltabellen laden. Diese Situation kann beispielsweise eintreten, wenn mehrere Pipe-Definitionen auf denselben Speicherort mit unterschiedlicher Granularität verweisen, wie <Speicherort>/path1/ und <Speicherort>/path1/path2/. Wenn in diesem Beispiel Dateien in <Speicherort>/path1/path2/ bereitgestellt werden, würden beide Pipes eine Kopie der Dateien laden.

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;
Copy
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 Menge von nicht geladenen Dateien unter diesem Thema.

Mit CURRENT_TIMESTAMP eingefügte Ladezeiten liegen vor LOAD_TIME-Werten der COPY_HISTORY-Ansicht

Tabellendesigner können eine Zeitstempelspalte hinzufügen, die den aktuellen Zeitstempel als Standardwert einfügt, wenn Datensätze in eine Tabelle geladen werden. Dadurch kann die Zeit erfasst werden, zu der jeder Datensatz in die Tabelle geladen wurde, jedoch liegen die Zeitstempel vor den LOAD_TIME-Spaltenwerten, die von der COPY_HISTORY-Funktion (Information Schema) oder der COPY_HISTORY-Ansicht (Account Usage) zurückgegeben werden. Der Grund dafür ist, dass CURRENT_TIMESTAMP ausgewertet wird, wenn der Ladevorgang in den Clouddiensten kompiliert wird, und nicht, wenn der Datensatz in die Tabelle eingefügt wird (d. h., wenn die Transaktion für die Ladeoperation mit Commit bestätigt wird).

Bemerkung

Wir raten derzeit davon ab, die folgenden Funktionen in copy_statement für Snowpipe zu verwenden:

  • CURRENT_DATE

  • CURRENT_TIME

  • CURRENT_TIMESTAMP

  • GETDATE

  • LOCALTIME

  • LOCALTIMESTAMP

  • SYSDATE

  • SYSTIMESTAMP

Es ist ein bekanntes Problem, dass die mit diesen Funktionen eingefügten Zeitwerte einige Stunden vor den LOAD_TIME-Werten liegen können, die von der COPY_HISTORY-Funktion oder der COPY_HISTORY-Ansicht zurückgegeben werden.

Es wird empfohlen, stattdessen METADATA$START_SCAN_TIME abzufragen, was eine genauere Darstellung der zu ladenden Menge an Datensätzen bietet.

Error: Integration {0} associated with the stage {1} cannot be found

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

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 stage_name SET STORAGE_INTEGRATION = storage_integration_name ausführen, wobei:

  • stage_name ist der Name des Stagingbereichs.

  • storage_integration_name ist der Name der Speicherintegration.

Fehler bei Snowpipe, das auf Regionen für Regierungsbehörden verweist

Sie können einen Fehler erhalten, wenn Snowpipe auf einen Bucket in einer Regionen für Regierungsbehörden verweist, während sich das Konto in einer kommerziellen Region befindet. Beachten Sie, dass in den von den Cloudanbietern bereitgestellten Regionen für Regierungsbehörden das Senden und Empfangen von Ereignisbenachrichtigungen an oder aus anderen kommerziellen Regionen nicht zulässig ist. Weitere Informationen dazu finden Sie unter AWS GovCloud (US) und Azure Government.