Verwaltung von Snowpipe

Dieses Thema beschreibt die administrativen Aufgaben, die mit der Verwaltung von Snowpipe verbunden sind.

Unter diesem Thema:

Löschen von Stagingdateien, nachdem Snowpipe die Daten geladen hat

Pipeobjekte unterstützen die Kopieroption PURGE nicht. Snowpipe kann Stagingdateien nicht automatisch löschen, wenn die Daten erfolgreich in Tabellen geladen wurden.

Um nicht mehr benötigte Stagingdateien zu entfernen, empfiehlt es sich, in regelmäßigen Abständen den Befehl REMOVE auszuführen, um die Dateien zu löschen.

Alternativ können Sie auch die von Ihrem Cloudspeicheranbieter bereitgestellten Funktionen für die Lebenszyklusverwaltung konfigurieren.

Laden historischer Daten

Bemerkung

Die Informationen in diesem Abschnitt beziehen sich auf das automatische Laden von Daten mithilfe von Ereignisbenachrichtigungen. Durch Aufrufe über die Snowpipe REST-API können historische Daten geladen werden, ohne dass zusätzliche Schritte erforderlich sind.

Mithilfe der ALTER PIPE … REFRESH-Anweisung können Sie einen Satz von Staging-Datendateien der letzten 7 Tage in die Erfassungswarteschlange von Snowpipe kopieren, um sie in die Zieltabelle zu laden. Wenn Sie Daten aus älteren Stagingdateien laden möchten, empfehlen wir die folgenden Schritte:

  1. Laden Sie die historischen Daten in die Zieltabelle, indem Sie eine COPY INTO <Tabelle>-Anweisung ausführen.

  2. Konfigurieren Sie das automatische Laden von Daten unter Verwendung von Snowpipe mit Ereignisbenachrichtigungen. Neue Stagingdateien lösen Ereignisbenachrichtigungen für die Aufnahme in die Zieltabelle aus. Da die historischen Datendateien keine Ereignisbenachrichtigungen auslösen, werden sie nicht zweimal geladen.

    Eine Anleitung dazu finden Sie unter:

    Amazon S3

    Automatisieren von Snowpipe für Amazon S3

    Google Cloud Storage

    Automatisieren von Snowpipe für Google Cloud Storage

    Microsoft Azure

    Automatisieren von Snowpipe für Microsoft Azure Blob-Speicher

  3. Führen Sie die ALTER PIPE … REFRESH-Anweisung aus, um alle Dateien, die zwischen Schritt 1 und 2 bereitgestellt wurden, in die Warteschlange aufzunehmen. Die Anweisung überprüft den Ladeverlauf sowohl für die Zieltabelle als auch für die Pipe, um sicherzustellen, dass dieselben Dateien nicht zweimal geladen werden.

Neuerstellen von Pipes

Um die meisten Pipe-Eigenschaften zu ändern, muss eine Pipe neu erstellt werden (mit einer CREATE OR REPLACE PIPE-Anweisung).

In diesem Abschnitt werden Voraussetzungen und bewährte Verfahren beschrieben, die bei der Neuerstellung von Pipes Rohren zu beachten sind.

Neuerstellen von Pipes für das automatische Laden von Daten

Wenn Sie eine Pipe neu erstellen, die das Laden von Daten mithilfe von Ereignisbenachrichtigungen automatisiert, empfehlen wir die Ausführung der folgenden Schritte:

  1. Halten Sie die Pipe an (mit ALTER PIPE … SET PIPE_EXECUTION_PAUSED = true). Warten Sie, bis alle derzeit in der Warteschlange befindlichen Dateien in die Zieltabelle geladen wurden.

  2. Fragen Sie die Funktion SYSTEM$PIPE_STATUS ab, und vergewissern Sie sich, dass der Ausführungsstatus der Pipe PAUSED und die Anzahl der ausstehenden Dateien 0 ist.

  3. Erstellen Sie die Pipe neu (mithilfe der Syntax CREATE OR REPLACE PIPE).

  4. Halten Sie die Pipe erneut an.

  5. Überprüfen Sie die Konfigurationsschritte für Ihren Cloudmessagingdienst, um sicherzustellen, dass die Einstellungen weiterhin korrekt sind:

  6. Setzen Sie die Pipe fort (mit ALTER PIPE … SET PIPE_EXECUTION_PAUSED = false).

  7. Fragen Sie die Funktion SYSTEM$PIPE_STATUS erneut ab, und vergewissern Sie sich, dass der Ausführungsstatus der Pipe RUNNING ist.

Ladeverlauf

Der Ladeverlauf für Snowpipe-Operationen wird in den Metadaten des Pipeobjekts gespeichert. Wenn eine Pipe neu erstellt wird, wird der Ladeverlauf gelöscht. Im Allgemeinen wirkt sich diese Bedingung nur auf Benutzer aus, die anschließend eine ALTER PIPE … REFRESH-Anweisung auf der Pipe ausführen. Dadurch könnten doppelte Daten aus Stagingdateien in den Speicherort der Pipe geladen werden, wenn die Daten bereits zuvor erfolgreich geladen, anschließend aber nicht gelöscht wurden.

Ändern der Cloudparameter des referenzierten Stagingbereichs

Die Cloudparameter eines externen Stagingbereichs umfassen Folgendes:

  • URL

  • STORAGE_INTEGRATION

  • ENCRYPTION

Nach der erfolgreichen Konfiguration von Snowpipe können Sie die folgenden Schritte auszuführen, um einen der Cloudparameter des referenzierten Stagingbereichs zu ändern:

  1. Halten Sie die Pipe an (mit ALTER PIPE … SET PIPE_EXECUTION_PAUSED = true). Warten Sie, bis alle derzeit in der Warteschlange befindlichen Dateien in die Zieltabelle geladen wurden.

  2. Ändern Sie die Stagingbereichsparameter wie erforderlich (mit ALTER STAGE).

  3. Setzen Sie die Pipe fort (mit ALTER PIPE ... SET PIPE_EXECUTION_PAUSED = false).

Da Pipes nicht transaktional sind, stellen diese Schritte sicher, dass Snowpipe Dateien mit den neuesten Parameterwerten des Stagingbereichs in die Warteschlange stellt.

Warnung

Das Ändern des Parameters URL eines Stagingbereichs kann dazu führen, dass abhängige Pipes, die Cloudmessaging zum Auslösen von Datenladevorgängen nutzen (d. h. durch AUTO_INGEST = TRUE), nicht mehr funktionieren.

Übertragen der Pipe-Eigentümerschaft

Führen Sie die folgenden Schritte aus, um die Eigentümerschaft einer Pipe zu übertragen:

  1. Setzen Sie den Parameter PIPE_EXECUTION_PAUSED auf TRUE.

    Dieser Parameter ermöglicht das Anhalten oder Fortsetzen einer Pipe. Der Parameter wird auf folgenden Ebenen unterstützt:

    • Konto

    • Schema

    • Pipe

    Auf Pipeebene kann der Objekteigentümer (oder eine übergeordnete Rolle in einer Rollenhierarchie) den Parameter so einstellen, dass eine einzelne Pipe angehalten oder fortgesetzt wird.

    Ein Kontoadministrator (Benutzer mit der Rolle ACCOUNTADMIN) kann diesen Parameter auf Kontoebene so einstellen, dass alle Pipes im Konto angehalten oder fortgesetzt werden. Ebenso kann ein Benutzer mit der Berechtigung MODIFY im Schema die Pipes auf Schemaebene anhalten oder fortsetzen. Beachten Sie, dass dieses größere Domainsteuerelement nur Pipes betrifft, bei denen der Parameter nicht bereits auf einer niedrigeren Ebene gesetzt wurde, z. B. durch den Eigentümer auf Objektebene.

  2. Übertragen Sie die Eigentümerschaft der Pipe mithilfe von GRANT OWNERSHIP.

  3. Erzwingen Sie die Fortsetzung der Pipe (mit SYSTEM$PIPE_FORCE_RESUME).

    Dies ermöglicht es dem neuen Eigentümer, den Pipestatus zu bewerten und festzustellen, wie viele Dateien darauf warten, mit SYSTEM$PIPE_STATUS geladen zu werden. Es wird empfohlen, sicherzustellen, dass nur Dateien in die Warteschlange gestellt werden, die zum Laden in die Zieltabelle zugelassen sind.

Ändern der COPY-Anweisung in einer Pipedefinition

Führen Sie folgende Schritte aus, um die COPY-Anweisung in einer Pipedefinition zu ändern; zum Beispiel, wenn der Zieltabelle Spalten hinzugefügt werden.

Um die Befehle in diesem Abschnitt ausführen zu können, muss die aktuelle Rolle des Benutzers über die Berechtigung OWNERSHIP für die Pipe verfügen.

  1. Halten Sie die Pipe an (mit ALTER PIPE … SET PIPE_EXECUTION_PAUSED = true).

  2. Fragen Sie die Funktion SYSTEM$PIPE_STATUS ab, und vergewissern Sie sich, dass der Ausführungsstatus der Pipe PAUSED und die Anzahl der ausstehenden Dateien 0 ist.

  3. Erstellen Sie die Pipe neu, um die COPY-Anweisung in der Definition zu ändern. Wählen Sie eine der folgenden Optionen:

  4. Halten Sie die Pipe erneut an.

  5. Überprüfen Sie die Konfigurationsschritte für Ihren Cloudmessagingdienst, um sicherzustellen, dass die Einstellungen weiterhin korrekt sind:

  6. Setzen Sie die Pipe fort (mit ALTER PIPE … SET PIPE_EXECUTION_PAUSED = false).

  7. Fragen Sie die Funktion SYSTEM$PIPE_STATUS erneut ab, und vergewissern Sie sich, dass der Ausführungsstatus der Pipe RUNNING ist.

Bemerkung

Die Metadaten zum Laden von Dateien sind dem Pipeobjekt zugeordnet und nicht der Tabelle. Durch Neuerstellung der Pipe wird der Verlauf der geladenen Dateien gelöscht. Stellen Sie sicher, dass Dateien, die bereits von Snowpipe geladen wurden, nicht versehentlich erneut an die Pipe gesendet und ein weiteres Mal in die Zieltabelle geladen werden. Um den Abfrageverlauf für eine Tabelle anzuzeigen, fragen Sie die Funktion COPY_HISTORY ab.

Fortsetzen von veralteten Pipes

Bemerkung

Dieser Abschnitt betrifft nur Pipeobjekte, die Cloudmessaging nutzen, um das Laden von Daten auszulösen (d. h. mit AUTO_INGEST = TRUE in der Pipedefinition).

Wenn eine Pipe angehalten wird, besteht für neue von der Pipe empfangene Ereignismeldungen eine begrenzte Aufbewahrungsfrist. Der Zeitraum beträgt standardmäßig 14 Tage. Wenn eine Pipe länger als 14 Tage angehalten wird, wird sie als veraltet angesehen.

Um eine veraltete Pipe fortzusetzen, muss eine qualifizierte Rolle die Funktion SYSTEM$PIPE_FORCE_RESUME aufrufen und das Argument STALENESS_CHECK_OVERRIDE eingeben. Dieses Argument weist darauf hin, dass die Rolle eine veraltete Pipe fortsetzt.

Setzen Sie z. B. die veraltete Pipe stalepipe1 in Datenbank/Schema mydb.myschema fort:

SELECT SYSTEM$PIPE_FORCE_RESUME('mydb.myschema.stalepipe1’,’staleness_check_override`);

Wenn die Eigentümerschaft der Pipe an eine andere Rolle übertragen wurde, während die veraltete Pipe angehalten war, ist für das Fortsetzen der Pipe das zusätzliche Argument OWNERSHIP_TRANSFER_CHECK_OVERRIDE erforderlich. Setzen Sie z. B. die veraltete Pipe stalepipe2 in Datenbank/Schema mydb.myschema fort, die an eine neue Rolle übertragen wurde:

SELECT SYSTEM$PIPE_FORCE_RESUME('mydb.myschema.stalepipe1’,’staleness_check_override, ownership_transfer_check_override`);

Wenn eine Ereignisbenachrichtigung, die empfangen wird, während eine Pipe pausiert, das Ende der begrenzten Aufbewahrungsfrist erreicht, plant Snowflake, dass sie aus den internen Metadaten gelöscht wird. Wenn die Pipe später fortgesetzt wird, kann Snowpipe die älteren Benachrichtigungen nur nach dem Best-Effort-Prinzip verarbeiten. Snowflake kann nicht garantieren, dass sie verarbeitet werden.

Wenn beispielsweise eine Pipe 15 Tage nach ihrer Unterbrechung fortgesetzt wird, überspringt Snowpipe im Allgemeinen alle Ereignisbenachrichtigungen, die am ersten Tag der Unterbrechung der Pipe empfangen wurden (d. h. die jetzt älter als 14 Tage sind). Wenn die Pipe 16 Tage nach ihrer Unterbrechung fortgesetzt wird, überspringt Snowpipe generell alle Ereignisbenachrichtigungen, die am ersten und zweiten Tag nach dem Anhalten der Pipe empfangen wurden. Und so weiter.