Verwaltung von Snowpipe¶

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¶

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.

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

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

   • Löschen Sie die Pipe (mit DROP PIPE), und erstellen Sie sie (mit CREATE PIPE).

   • Erstellen Sie die Pipe neu (mithilfe der Syntax CREATE OR REPLACE PIPE). Intern wird die Pipe gelöscht und erstellt.

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:

   • Automatisieren von Snowpipe für Amazon S3

   • Automatisieren von Snowpipe für Google Cloud Storage

   • Automatisieren von Snowpipe für Microsoft Azure Blob-Speicher

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.

Fortsetzen von veralteten Pipes¶

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.