Einführung in Streams¶

Offset-Speicher¶

Bei der Erstellung eines Streams wird zuerst ein Snapshot jeder Zeile der Quelltabelle erfasst (z. B. Tabelle, externe Tabelle oder die zugrunde liegenden Tabellen einer Ansicht), indem ein Zeitpunkt (Offset genannt) als aktuelle Transaktionsversion der Tabelle initialisiert wird. Das vom Stream verwendete Änderungsnachverfolgungssystem zeichnet dann Informationen über die DML-Änderungen auf, die nach Erstellung dieses Snapshots ausgeführt wurden. Änderungsdatensätze geben den Status einer Zeile vor und nach der Änderung an. Änderungsinformationen spiegeln die Spaltenstruktur des nachverfolgten Quellobjekts wider und enthalten zusätzliche Metadatenspalten, die jedes Änderungsereignis beschreiben.

Beachten Sie, dass ein Stream selbst keine Tabellendaten enthält. Ein Stream speichert nur den Offset für das Quellobjekt und gibt CDC-Datensätze zurück, indem der Versionsverlauf für das Quellobjekt genutzt wird. Wenn der erste Stream für eine Tabelle erstellt wird, werden einige ausgeblendete Spalten zur Quelltabelle hinzugefügt, und dann beginnt das System mit dem Speichern von Metadaten zur Änderungsverfolgung. Diese Spalten verbrauchen nur wenig Speicherplatz. Die CDC-Datensätze, die beim Abfragen eines Streams zurückgegeben werden, basieren auf einer Kombination aus dem im Stream gespeicherten Offset und den in der Tabelle gespeicherten Änderungsverfolgungsmetadaten. Beachten Sie, dass bei Streams on Views die Änderungsverfolgung explizit für die Ansicht und die zugrunde liegenden Tabellen aktiviert werden muss, um die ausgeblendeten Spalten zu diesen Tabellen hinzuzufügen.

Es kann nützlich sein, sich einen Stream als Lesezeichen vorzustellen, das einen Zeitpunkt auf den Seiten eines Buches (d. h. des Quellobjekts) angibt. Ein Lesezeichen kann weggeworfen werden, und andere Lesezeichen können an anderen Stellen in einem Buch eingefügt werden. Ebenso kann ein Stream gelöscht werden, und andere Streams können zum selben oder zu unterschiedlichen Zeitpunkten erstellt werden (entweder indem die Streams zu unterschiedlichen Zeiten nacheinander erstellt werden oder indem Time Travel verwendet wird), um die Änderungsdatensätze für ein Objekt bei gleichen oder verschiedenen Offsets zu verarbeiten.

Ein Beispiel für einen Verbraucher von CDC-Datensätzen ist eine Datenpipeline, in der von den Daten in Stagingtabellen nur die transformiert und in andere Tabellen kopiert werden, die sich seit der letzten Extraktion geändert haben.

Tabellenversionierung¶

Eine neue Tabellenversion wird immer dann erstellt, wenn für eine Transaktion auf der Tabelle, die eine oder mehrere DML-Anweisungen enthält, ein Commit ausgeführt wird. Dies gilt für die folgenden Tabellentypen:

• Standardtabellen

• Verzeichnistabellen

• Externe Tabellen

• Zugrunde liegende Tabellen für eine Ansicht

In der Transaktionshistorie einer Tabelle befindet sich zwischen zwei Tabellenversionen ein Stream-Offset. Die Abfrage eines Streams gibt die Änderungen zurück, die durch Transaktionen verursacht wurden, die nach dem Offset und zum oder vor dem aktuellen Zeitpunkt mit Commit bestätigt wurden.

Das folgende Beispiel zeigt eine Quelltabelle mit 10 mit Commit bestätigten Versionen in der Zeitachse. Der Offset von Stream s1 liegt derzeit zwischen den Tabellenversionen v3 und v4. Wenn der Stream abgefragt (oder verbraucht) wird, enthalten die zurückgegebenen Datensätze alle Transaktionen zwischen der Tabellenversion v4, der Version unmittelbar nach dem Stream-Offset in der Zeitachse der Tabelle, und einschließlich v10, der neuesten mit Commit bestätigten Tabellenversion in der Zeitachse.

Ein Stream stellt den minimalen Satz von Änderungen von seinem aktuellen Offset bis zur aktuellen Version der Tabelle bereit.

Mehrere Abfragen können unabhängig voneinander dieselben Änderungsdaten aus einem Stream verbrauchen, ohne den Offset zu ändern. Ein Stream erhöht den Offset nur, wenn er in einer DML-Transaktion verwendet wird. Dieses Verhalten gilt sowohl für explizite als auch für autocommit-Transaktionen. (Beim Ausführen einer DML-Anweisung wird standardmäßig implizit eine Autocommit-Transaktion gestartet, und die Transaktion wird nach Abschluss der Anweisung mit COMMIT bestätigt. Dieses Verhalten wird mit dem Parameter AUTOCOMMIT gesteuert.) Das Abfragen eines Streams allein führt nicht zum Erhöhen des Offsets, auch nicht innerhalb einer expliziten Transaktion. Der Inhalt des Streams muss in einer DML-Anweisung verarbeitet werden.

Wenn eine SQL-Anweisung einen Stream innerhalb einer expliziten Transaktion abfragt, erfolgt die Abfrage des Streams an der Streamspitze (d. h. dem Zeitstempel), als die Transaktion begann und nicht als die Anweisung ausgeführt wurde. Dieses Verhalten betrifft sowohl DML-Anweisungen als auch CREATE TABLE … AS SELECT (CTAS)-Anweisungen, die eine neue Tabelle mit Zeilen aus einem vorhandenen Stream füllen.

Eine DML-Anweisung, die ein „Select“ auf einem Stream ausführt, verbraucht alle Änderungsdaten im Stream, vorausgesetzt, die Transaktion wurde erfolgreich mit Commit bestätigt. Um sicherzustellen, dass verschiedene Anweisungen auf dieselben Änderungsdatensätze im Stream zugreifen, müssen Sie sie mit einer expliziten Transaktionsanweisung (BEGIN .. COMMIT) umgeben. Dies sperrt den Stream. DML-Aktualisierungen am Quellobjekt in parallelen Transaktionen werden vom Änderungsverfolgungssystem verfolgt, aktualisieren den Stream jedoch erst, wenn für die explizite Transaktionsanweisung ein Commit ausgeführt wurde und die vorhandenen Änderungsdaten verbraucht wurden.

Wiederholbare Leseisolation¶

Streams unterstützen wiederholbare Leseisolation. Im wiederholbaren Lesemodus sehen verschiedene SQL-Anweisungen innerhalb einer Transaktion die gleichen Datensätze in einem Stream. Dies unterscheidet sich von dem für Tabellen unterstützten Read Committed-Modus, in dem Anweisungen alle Änderungen anzeigen, die von vorherigen Anweisungen vorgenommen wurden, die in derselben Transaktion ausgeführt wurden, obwohl für diese Änderungen noch kein Commit ausgeführt wurde.

Die Delta-Datensätze, die von Streams in einer Transaktion zurückgegeben werden, beinhalten den Bereich von der aktuellen Position des Streams bis zur Startzeit der Transaktion. Die Streamposition rückt zur Transaktionsstartzeit vor, wenn der Transaktions-Commit ausgeführt wird, andernfalls bleibt sie an der gleichen Position.

Betrachten Sie das folgende Beispiel:

In Transaktion 1 werden allen Abfragen an Stream s1 dieselben Datensätze angezeigt. DML-Änderungen an Tabelle t1 werden nur dann im Stream aufgezeichnet, wenn für die Transaktion ein Commit ausgeführt wurde.

In Transaktion 2 werden Abfragen an den Stream die Änderungen angezeigt, die in der Tabelle in Transaktion 1 aufgezeichnet wurden. Beachten Sie aber Folgendes: Wenn Transaktion 2 begonnen hätte, bevor das Commit für Transaktion 1 ausgeführt worden wäre, hätten Abfragen an den Stream einen Snapshot des Streams von der Position des Streams bis zur Startzeit von Transaktion 2 zurückgegeben und keine der für Transaktion 1 committeten Änderungen wäre sichtbar.

Stream-Spalten¶

Ein Stream speichert einen Offset für die Quelltabelle und keine tatsächlichen Tabellenspalten oder Daten. Bei Abfragen auf dem Stream erfolgen der Zugriff auf die historischen Daten und die Datenrückgabe in derselben Form wie bei Abfragen auf dem Quellobjekt (d. h. mit denselben Spaltennamen und derselben Reihenfolge), allerdings mit den folgenden zusätzlichen Spalten:

METADATA$ACTION:

Gibt die erfasste DML-Operation (INSERT, DELETE) an.

METADATA$ISUPDATE:

Gibt an, ob die Operation Teil einer UPDATE-Anweisung war. Aktualisierungen von Zeilen in der Quelltabelle werden als ein Paar von DELETE- und INSERT-Datensätzen im Stream dargestellt, wobei METADATA$ISUPDATE-Werte einer Metadatenspalte auf TRUE gesetzt sind.

Beachten Sie, dass Streams die Unterschiede zwischen zwei Offsets aufzeichnen. Wenn eine Zeile hinzugefügt und dann im aktuellen Offset aktualisiert wird, ist die Deltaänderung eine neue Zeile. Die Zeile METADATA$ISUPDATE zeichnet einen FALSE-Wert auf.

METADATA$ROW_ID:

Gibt die eindeutige und unveränderliche Zeilen-ID an, mit der Änderungen an bestimmten Zeilen über die Zeit verfolgt werden können.

Snowflake bietet die folgenden Garantien in Bezug auf METADATA$ROW_ID:

1. METADATA$ROW_ID hängt vom Quellobjekt des Streams ab.

   Beispielsweise erzeugen ein Stream stream1 auf Tabelle table1 und ein Stream stream2 auf Tabelle table1 dieselben METADATA$ROW_IDs für dieselben Zeilen, aber ein Stream stream_view auf Ansicht view1 erzeugt garantiert nicht dieselben METADATA$ROW_IDs wie stream1, selbst wenn view mit der Anweisung CREATE VIEW view AS SELECT * FROM table1 definiert ist.

2. Ein Stream auf einem Quellobjekt und ein Stream auf dem Klon des Quellobjekts erzeugen die gleichen METADATA$ROW_IDs für die Zeilen, die zum Zeitpunkt des Klonens existieren.

3. Ein Stream auf einem Quellobjekt und ein Stream auf dem Replikat des Quellobjekts erzeugen die gleichen METADATA$ROW_IDs für die replizierten Zeilen.

Typen von Streams¶

Die folgenden Streamtypen sind basierend auf den von jedem Stream aufgezeichneten Metadaten verfügbar:

Standard:

Wird für Streams auf Tabellen, Verzeichnistabellen oder Ansichten unterstützt. Ein Standardstream (d. h. Delta-Stream) verfolgt alle DML-Änderungen am Quellobjekt wie Einfügungen, Aktualisierungen und Löschungen (einschließlich Tabellenverkürzungen). Dieser Streamtyp führt eine Verknüpfung (Join) für eingefügte und gelöschte Zeilen im Änderungsset durch, um das Delta auf Zeilenebene bereitzustellen. Als Gesamteffekt wird beispielsweise eine Zeile, die zwischen zwei Transaktionszeitpunkten in einer Tabelle eingefügt und dann gelöscht wird, im Delta entfernt (d. h. sie wird nicht zurückgegeben, wenn der Stream abgefragt wird).

Bemerkung

Standardstreams können keine Änderungsdaten für Geodaten abrufen. Es wird empfohlen, auf Objekten, die Geodaten enthalten, Nur-Anfügen-Streams zu erstellen.

Nur-Anfügen:

Wird für Streams auf Standardtabellen, Verzeichnistabellen oder Ansichten unterstützt. Ein Nur-Anfügen-Stream verfolgt exklusiv Zeileneinfügungen. Aktualisierungs-, Lösch- und Abschneideoperationen werden von Nur-Anfügen-Streams nicht erfasst. Wenn z. B. zunächst 10 Zeilen in eine Tabelle eingefügt werden und dann 5 dieser Zeilen gelöscht werden, bevor der Offset für einen Nur-Anfügen-Stream erweitert wird, würde der Stream nur die 10 eingefügten Zeilen aufzeichnen.

Ein Nur-Anfügen-Stream gibt speziell die angefügten Zeilen zurück, was ihn deutlich leistungsfähiger macht als einen Standard-Stream für Extrahieren, Laden und Transformieren (ELT) und ähnliche Szenarios, die nur auf Zeileneinfügungen angewiesen sind. Beispiel: Eine Quelltabelle kann unmittelbar nach dem Verarbeiten der Zeilen eines Nur-Anfügen-Streams abgeschnitten werden, und das Löschen von Datensätzen produziert keinen Overhead, wenn der Stream das nächste Mal abgefragt oder verarbeitet wird.

Das Erstellen eines Nur-Anfügen-Streams in einem Zielkonto unter Verwendung eines sekundären Objekts als Quelle wird nicht unterstützt.

Nur Einfügen:

Wird nur bei Streams auf externen Tabellen unterstützt. Bei Nur-Einfügen-Streams werden nur Zeileneinfügungen verfolgt. Es werden keine Löschoperationen erfasst, mit denen Zeilen aus einem eingefügten Dataset entfernt werden (d. h. NoOps). Wenn beispielsweise zwischen zwei beliebigen Offsets „File1“ aus dem Cloudspeicherort entfernt wird, auf den in der externen Tabelle verwiesen wird, und „File2“ hinzugefügt wird, gibt der Stream nur Datensätze für die Zeilen in „File2“ zurück. Im Gegensatz zur Verfolgung von CDC-Daten für Standardtabellen kann Snowflake nicht auf die historischen Datensätze von Dateien im Cloudspeicher zugreifen.

Überschriebene oder angehängte Dateien werden im Wesentlichen wie neue Dateien behandelt: Die alte Version der Datei wird aus dem Cloudspeicher entfernt, aber der Nur-Einfügen-Stream zeichnet die Löschoperation nicht auf. Die neue Version der Datei wird dem Cloudspeicher hinzugefügt, und der Nur-Einfügen-Stream zeichnet die Zeilen als Einfügeoperationen auf. Der Stream zeichnet die Differenz zwischen alter und neuer Dateiversion nicht auf. Beachten Sie, dass Anhänge möglicherweise keine automatische Aktualisierung der Metadaten der externen Tabelle auslösen, wie z. B. bei Verwendung von Azure AppendBlobs.

Datenfluss¶

Die folgende Abbildung zeigt, wie sich der Inhalt eines Standardstreams ändert, wenn Zeilen in der Quelltabelle aktualisiert werden. Immer, wenn eine DML-Anweisung die Inhalte des Streams verarbeitet hat, wechselt die Streamposition zur Nachverfolgung auf den nächsten Satz an DML-Änderungen in der Tabelle (d. h. den Änderungen in einer bestimmten Tabellenversion):

Datenaufbewahrungsfrist und Veraltung¶

Ein Stream veraltet, wenn sein Offset außerhalb der Datenaufbewahrungsfrist seiner Quelltabelle (oder der zugrunde liegenden Tabellen einer Quellansicht) liegt. Wenn ein Stream veraltet ist, kann nicht mehr auf die historischen Daten der Quelltabelle zugegriffen werden, auch nicht auf ungenutzte Änderungsdatensätze. Um neue Änderungsdatensätze für die Tabelle verfolgen zu können, müssen Sie den Stream neu erstellen (mit CREATE STREAM). Verbrauchen Sie die Stream-Datensätze innerhalb einer Transaktion während der Aufbewahrungsfrist für die Tabelle, um zu verhindern, dass der Stream veraltet. Weitere Informationen zur Datenaufbewahrungsfrist finden Sie unter Verstehen und Verwenden von Time Travel.

Wenn die Datenaufbewahrungsfrist für eine Tabelle weniger als 14 Tage beträgt und kein Stream verbraucht wurde, verlängert Snowflake diese Frist vorübergehend, um ein Veralten zu verhindern. Die Frist wird unabhängig von der Snowflake Edition Ihres Kontos standardmäßig auf den Offset des Streams oder maximal 14 Tage verlängert. Die maximale Anzahl von Tagen, für die Snowflake die Datenaufbewahrungsfrist verlängern kann, wird durch den Parameterwert MAX_DATA_EXTENSION_TIME_IN_DAYS bestimmt. Wenn der Stream verarbeitet wurde, wird die verlängerte Datenaufbewahrungsfrist wieder auf die Standardfrist der Tabelle verkürzt.

Die folgende Tabelle zeigt Beispielwerte für DATA_RETENTION_TIME_IN_DAYS und MAX_DATA_EXTENSION_TIME_IN_DAYS und gibt an, wie häufig die Streaminhalte verarbeitet werden sollten, um ein Veralten zu vermeiden:

Um den aktuellen Veraltungsstatus eines Streams anzuzeigen, führen Sie den Befehl DESCRIBE STREAM oder SHOW STREAMS aus. Der Zeitstempel in der Spalte STALE_AFTER gibt an, wann der Stream voraussichtlich veraltet sein wird (oder wann er veraltet ist, wenn der Zeitstempel in der Vergangenheit liegt). Dies ist die erweiterte Datenaufbewahrungsfrist für das Quellobjekt. Dieser Zeitstempel wird berechnet, indem der größere der beiden Parameter DATA_RETENTION_TIME_IN_DAYS oder MAX_DATA_EXTENSION_TIME_IN_DAYS des Quellobjekts zum aktuellen Zeitstempel addiert wird.

Durch den Verbrauch der Änderungsdaten für einen Stream wird der Zeitstempel STALE_AFTER hinausgeschoben. Beachten Sie, dass das Lesen aus dem Stream noch einige Zeit nach dem STALE_AFTER-Zeitstempel erfolgreich sein kann. Der Stream kann jedoch während dieses Zeitraums jederzeit veralten. Die Spalte STALE zeigt an, ob der Stream derzeit voraussichtlich veraltet ist, auch wenn der Stream möglicherweise noch nicht wirklich veraltet ist.

Um das Veralten von Streams zu verhindern, wird dringend empfohlen, die Änderungsdaten regelmäßig vor dem STALE_AFTER-Zeitstempel zu verbrauchen (d. h. innerhalb der erweiterten Datenaufbewahrungsfrist des Quellobjekts).

Nach Ablauf des Zeitstempels STALE_AFTER kann der Stream jederzeit veralten, auch wenn es keine unverbrauchten Datensätze für den Stream gibt. Beachten Sie, dass bei Abfragen eines Streams 0 Datensätze zurückgeben werden können, auch wenn es Änderungsdaten für das Quellobjekt gibt. Ein Nur-Anfügen-Stream verfolgt zum Beispiel nur das Einfügen von Zeilen, aber bei Aktualisierungs- und Löschvorgängen werden ebenfalls Änderungsdatensätze in ein Quellobjekt geschrieben. Ein weniger eindeutiges Beispiel für Tabellenschreibvorgänge, die keine Änderungsdaten erzeugen, ist das Reclustering.

Wenn Sie die Änderungsdaten für einen Datenstream verbrauchen, wird dessen Offset auf die Gegenwart vorverlegt, unabhängig davon, ob die dazwischenliegenden Versionen Änderungsdaten enthalten.

Streams mit mehreren Verbrauchern¶

Wir empfehlen, dass Benutzer für jeden Verbraucher von Änderungsdatensätzen für ein Objekt einen separaten Stream erstellen. „Verbraucher“ bezieht sich dabei auf eine Aufgabe, ein Skript oder einen anderen Mechanismus, bei dem Änderungsdatensätze eines Objekts mithilfe einer DML-Transaktion genutzt („verbraucht“) werden. Wie bereits weiter oben unter diesem Thema erwähnt, erhöht eine Stream seinen Offset nur, wenn dieser in einer DML-Transaktion verwendet wird. Verschiedene Verbraucher von Änderungsdaten in einem einzigen Datenstream rufen unterschiedliche Deltas ab, es sei denn, es wird Time Travel verwendet. Wenn die Änderungsdaten, die vom letzten Offset eines Datenstreams erfasst wurden, mit einer DML-Transaktion verbraucht werden, erhöht der Datenstrom den Offset. Die Änderungsdaten stehen für den nächsten Verbraucher nicht mehr zur Verfügung. Um dieselben Änderungsdaten eines Objekts verbrauchen zu können, erstellen Sie mehrere Streams für das Objekt. Ein Stream speichert nur einen Offset des Quellobjekts und nicht die eigentlichen Daten in den Tabellenspalten. Daher können Sie eine beliebige Anzahl von Streams für ein Objekt erstellen, ohne dass dies signifikante Kosten verursacht.

Streams on Views¶

Streams on Views unterstützen sowohl lokale Ansichten als auch Ansichten, die mit Snowflake Secure Data Sharing freigegeben werden, einschließlich sicherer Ansichten. Beachten Sie, dass Streams Änderungen in materialisierten Ansichten nicht nachverfolgen können.

Streams sind auf Ansichten beschränkt, die die folgenden Anforderungen erfüllen:

Zugrunde liegende Tabellen:

• Alle zugrunde liegenden Tabellen müssen native Tabellen sein.

• Auf dieser Ansicht können nur die folgenden Operationen angewendet werden:

  • Projektionen

  • Filter

  • Innere Verknüpfungen und Kreuzverknüpfungen

  • UNION ALL

Verschachtelte Ansichten und Unterabfragen in der FROM-Klausel werden unterstützt, solange die vollständig erweiterte Abfrage die anderen Anforderungen in dieser Anforderungstabelle erfüllt.

Abfrage auf Ansicht:

Allgemeine Anforderungen:

• Die Abfrage kann eine beliebige Anzahl von Spalten auswählen.

• Die Abfrage kann eine beliebige Anzahl von WHERE-Prädikaten enthalten.

• Ansichten mit den folgenden Operationen werden noch nicht unterstützt:

  • GROUP BY-Klauseln

  • QUALIFY-Klauseln

  • Unterabfragen, die nicht in der FROM-Klausel enthalten sind

  • Korrelierte Unterabfragen

  • LIMIT-Klauseln

Funktionen:

• Die Funktionen in der Auswahlliste müssen systemdefinierte, skalare Funktionen sein.

Änderungsverfolgung:

Die Änderungsverfolgung muss in den zugrunde liegenden Tabellen aktiviert sein.

Bevor Sie einen Stream für eine Ansicht erstellen, müssen Sie die Änderungsverfolgung für die zugrunde liegenden Tabellen der Ansicht aktivieren. Eine Anleitung dazu finden Sie unter Aktivieren der Änderungsverfolgung für Ansichten und zugrunde liegende Tabellen.

create or replace table orders (id int, order_name varchar);
create or replace table customers (id int, customer_name varchar);

create or replace view ordersByCustomer as select * from orders natural join customers;
insert into orders values (1, 'order1');
insert into customers values (1, 'customer1');

create or replace stream ordersByCustomerStream on view ordersBycustomer;

select * from ordersByCustomer;
+----+------------+---------------+
| ID | ORDER_NAME | CUSTOMER_NAME |
|----+------------+---------------|
|  1 | order1     | customer1     |
+----+------------+---------------+

select * exclude metadata$row_id from ordersByCustomerStream;
+----+------------+---------------+-----------------+-------------------+
| ID | ORDER_NAME | CUSTOMER_NAME | METADATA$ACTION | METADATA$ISUPDATE |
|----+------------+---------------+-----------------+-------------------|
+----+------------+---------------+-----------------+-------------------+

insert into orders values (1, 'order2');
select * from ordersByCustomer;
+----+------------+---------------+
| ID | ORDER_NAME | CUSTOMER_NAME |
|----+------------+---------------|
|  1 | order1     | customer1     |
|  1 | order2     | customer1     |
+----+------------+---------------+

select * exclude metadata$row_id from ordersByCustomerStream;
+----+------------+---------------+-----------------+-------------------+
| ID | ORDER_NAME | CUSTOMER_NAME | METADATA$ACTION | METADATA$ISUPDATE |
|----+------------+---------------+-----------------+-------------------|
|  1 | order2     | customer1     | INSERT          | False             |
+----+------------+---------------+-----------------+-------------------+

insert into customers values (1, 'customer2');
select * from ordersByCustomer;
+----+------------+---------------+
| ID | ORDER_NAME | CUSTOMER_NAME |
|----+------------+---------------|
|  1 | order1     | customer1     |
|  1 | order2     | customer1     |
|  1 | order1     | customer2     |
|  1 | order2     | customer2     |
+----+------------+---------------+

select * exclude metadata$row_id from ordersByCustomerStream;
+----+------------+---------------+-----------------+-------------------+
| ID | ORDER_NAME | CUSTOMER_NAME | METADATA$ACTION | METADATA$ISUPDATE |
|----+------------+---------------+-----------------+-------------------|
|  1 | order1     | customer2     | INSERT          | False             |
|  1 | order2     | customer1     | INSERT          | False             |
|  1 | order2     | customer2     | INSERT          | False             |
+----+------------+---------------+-----------------+-------------------+

CHANGES-Klausel: Schreibgeschützte Alternative zu Streams¶

Als Alternative zu Streams unterstützt Snowflake das Abfragen von Änderungsverfolgungsmetadaten für Tabellen mithilfe der CHANGES-Klausel für SELECT-Anweisungen. Die CHANGES-Klausel ermöglicht das Abfragen von Änderungsverfolgungsmetadaten zwischen zwei Zeitpunkten, ohne dass ein Stream mit einem expliziten Transaktionsoffset erstellt werden muss. Wenn Sie die CHANGES-Klausel verwenden, wird der Offset nicht erhöht (d. h. es werden keine Datensätze verarbeitet). Die Änderungsverfolgungsmetadaten zwischen verschiedenen Transaktionsstart- und -endpunkten können von mehreren Abfragen abgerufen werden. Für diese Option muss ein Transaktionsstartpunkt für die Metadaten mithilfe einer AT | BEFORE-Klausel angegeben werden. Der Endpunkt für das Änderungsverfolgungsintervall kann mit der optionalen END-Klausel festgelegt werden.

Ein Stream speichert die aktuelle Tabellenversion der Transaktion und ist in den meisten Szenarien die geeignete Quelle für CDC-Datensätze. Für seltene Szenarien, in denen der Offset für beliebige Zeiträume verwaltet werden muss, steht Ihnen die CHANGES-Klausel zur Verfügung.

Derzeit muss auch Folgendes erfüllt („true“) sein, bevor Änderungsverfolgungsmetadaten erfasst werden:

Tabellen:

Aktivieren Sie entweder die Änderungsverfolgung für die Tabelle (mit ALTER TABLE … CHANGE_TRACKING = TRUE), oder erstellen Sie einen Stream auf der Tabelle (mit CREATE STREAM).

Ansichten:

Aktivieren Sie die Änderungsverfolgung für die Ansicht und die ihr zugrunde liegenden Tabellen. Eine Anleitung dazu finden Sie unter Aktivieren der Änderungsverfolgung für Ansichten und zugrunde liegende Tabellen.

Beim Aktivieren der Änderungsverfolgung werden der Tabelle einige ausgeblendete Spalten hinzugefügt, und dann wird mit dem Speichern von Metadaten zur Änderungsverfolgung begonnen. Die Werte in diesen ausgeblendeten CDC-Datenspalten liefern die Eingabe für die Metadaten-Spalten des Streams. Die Spalten verbrauchen wenig Speicherplatz.

Für den Zeitraum, bevor eine dieser Bedingungen erfüllt ist, sind keine Änderungsverfolgungsmetadaten für das Objekt verfügbar.

Erforderliche Zugriffsrechte¶

Das Abfragen eines Streams erfordert eine Rolle mit mindestens den folgenden Rollenberechtigungen:

Abrechnung für Streams¶

Wie unter Datenaufbewahrungsfrist und Veraltung (unter diesem Thema) beschrieben, verlängert Snowflake vorübergehend die Datenaufbewahrungsfrist für die Quelltabelle bzw. die zugrunde liegenden Tabellen der Quellansicht, wenn ein Stream nicht regelmäßig verarbeitet wird. Wenn die Datenaufbewahrungsfrist der Tabelle weniger als 14 Tage beträgt, wird der Zeitraum unabhängig von der Snowflake-Edition Ihres Kontos automatisch auf den kleineren Transaktionsoffset des Streams oder auf 14 Tage (wenn die Datenaufbewahrungsfrist der Tabelle kleiner als 14 Tage ist) verlängert.

Beachten Sie, dass eine erweiterte Datenaufbewahrungsfrist zusätzlichen Speicherplatz erfordert, was sich in Ihren monatlichen Speicherkosten widerspiegelt.

Die mit einem Stream verbundenen Hauptkosten entstehen durch die Verarbeitungszeit, die ein virtuelles Warehouse für die Abfrage des Streams benötigt. Diese Gebühren sind auf der Rechnung als übliche Snowflake-Credits ausgewiesen.