Aktualisierungsgrenze für dynamische Tabellen¶

Verwenden Sie eine Aktualisierungsgrenze für dynamische Tabellen, um die Pipelines dynamischer Tabellen zu entkoppeln und gleichzeitig die Upstream-Ergebnisse zu lesen.

Wenn eine dynamische Tabelle auf eine andere verweist, werden die beiden zusammen als eine einzige Pipeline aktualisiert. Während dies in den meisten Szenarien funktioniert, gibt es bestimmte Anwendungsfälle, z. B. die Datenfreigabe über Teamgrenzen hinweg, bei denen die Anforderungen an die Datenaktualisierung variieren können. Sie können die beiden dynamischen Tabellen als unabhängig (und somit zu verschiedenen Pipelines gehörend) deklarieren, indem Sie die Upstream-Referenz in DYNAMIC_TABLE_REFRESH_BOUNDARY() einschließen. Die Snapshot-Isolation wird nur innerhalb einer einzigen Pipeline garantiert, sodass dynamische Tabellen über eine Aktualisierungsgrenze hinweg keine Snapshot-Isolation untereinander bieten.

Übersicht¶

Wenn eine dynamische Tabelle aus einer anderen dynamischen Tabelle liest, führt Snowflake standardmäßig Folgendes aus:

Aktualisiert beide Tabellen zusammen als Teil einer einzigen Pipeline.
Koordiniert die Aktualisierungen, sodass die Snapshot-Isolation für nachgelagerte dynamische Tabellen für alle vorgelagerten dynamischen Tabellen in der Pipeline gelten.
Setzt Regeln auf Pipeline-Ebene durch, wie z. B. Zielverzögerungsprüfungen.

In einigen Pipelines soll nicht jede Beziehung dazu führen, dass beide dynamischen Tabellen zusammen aktualisiert werden. Einige allgemeine Beispiele umfassen:

Teamübergreifende Pipelines, bei denen ein Team eine dynamische Tabelle veröffentlicht, die ein anderes Team nutzt, die nachgelagerte dynamische Tabelle aber die vorgelagerte Pipeline nicht beeinflussen oder erben sollte.
Inkrementelle Migrationen, bei denen Sie einen vorgelagerten Pipeline-Schritt in eine dynamische Tabelle konvertieren, aber nicht möchten, dass nachgelagerte Verbrauchende damit beginnen, Aktualisierungen zu koordinieren.
Dynamische-Tabelle-für-Ansicht-für-dynamische-Tabelle-Muster, bei dem eine dynamische Tabelle aus einer Ansicht liest, die eine andere dynamische Tabelle abfragt. Dieses Muster wird nicht unterstützt, es sei denn, die Ansicht ist in DYNAMIC_TABLE_REFRESH_BOUNDARY() eingeschlossen.

Eine Aktualisierungsgrenze macht diese Trennung explizit: Eingaben innerhalb der Grenze werden als zu einer separaten Pipeline gehörend behandelt und wie reguläre Tabellen gelesen.

Syntax¶

DYNAMIC_TABLE_REFRESH_BOUNDARY( <object_name> )

Wobei:

object_name: Der Name einer Tabelle, Ansicht, dynamischen Tabelle oder eines allgemeinen Tabellenausdrucks (CTE).

Verwenden Sie dieses Schlüsselwort in der FROM /JOIN-Klausel (einschließlich innerhalb von CTEs und UNION-Zweige) einer dynamischen Tabellendefinition.

Beispiele¶

Das folgende Beispiel liest aus einer Ansicht, die eine andere dynamische Tabelle abfragt. Ohne eine Aktualisierungsgrenze wird das Erstellen einer dynamischen Tabelle, die aus einer Ansicht einer anderen dynamischen Tabelle liest, nicht unterstützt. Das Einschließen der Ansicht in DYNAMIC_TABLE_REFRESH_BOUNDARY() ermöglicht dieses Muster:

CREATE DYNAMIC TABLE analytics.click_analytics_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '5 minutes'
AS
SELECT *
FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(analytics.enriched_clicks_view);

Im folgenden Beispiel wird eine direkt referenzierte dynamische Tabelle mit einer Ansicht verknüpft, deren vorgelagerte dynamische Tabelle nach einem längeren Zeitplan aktualisiert wird. Das Einschließen der Ansicht in DYNAMIC_TABLE_REFRESH_BOUNDARY() verhindert, dass die nachgelagerte dynamische Tabelle alle 5 Minuten die teure Upstream-Aktualisierung auslöst, während sie trotzdem die neueste verfügbare Version lesen kann. Die Snapshot-Isolation wird über die Aktualisierungsgrenze hinweg nicht garantiert:

CREATE DYNAMIC TABLE data_eng.enriched_clicks_dt
  WAREHOUSE = de_wh
  TARGET_LAG = '5 minutes'
AS
SELECT
  c.*,
  p.product_name
FROM data_eng.clickstream_dt AS c
LEFT JOIN DYNAMIC_TABLE_REFRESH_BOUNDARY(product_db.active_products_view) AS p
  ON c.product_id = p.product_id;

Verhalten¶

Wie Aktualisierungsgrenzen Abhängigkeiten verändern¶

Wenn Sie eine Eingabe in DYNAMIC_TABLE_REFRESH_BOUNDARY() innerhalb einer dynamischen Tabellendefinition einschließen:

Diese Eingabe wird für diese Definition als Eingabe einer Aktualisierungsgrenze behandelt.
Alle dynamischen Tabellen, die von dieser Eingabe aus erreichbar sind, sind für diese Definition nicht in der Pipeline enthalten.
Bei der Aktualisierung liest die dynamische Tabelle diese Objekte in ihrer aktuellen Version und nicht mit dem in der Pipeline koordinierten Datenzeitstempel.

Infolgedessen:

Keine kaskadierende Aktualisierung über die Grenze hinweg: Die Aktualisierung der nachgelagerten dynamischen Tabelle löst keine Aktualisierungen von dynamischen Tabellen aus, die nur über eine Aktualisierungsgrenze erreichbar sind.
Unabhängige Zeitplanung: Die Zielverzögerung und die Aktualisierungsplanung für die nachgelagerte dynamische Tabelle ignorieren dynamische Tabellen, die nur über die Grenze erreichbar sind.
Keine Snapshot-Isolation über die Grenze hinweg: Die nachgelagerte dynamische Tabelle liest jede Version der vorgelagerten Daten, die zum Aktualisierungszeitpunkt verfügbar ist. Es ist nicht garantiert, dass die Daten jenseits der Grenze mit der Snapshot-Isolation abgeglichen werden, die für andere vorgelagerte Abhängigkeiten gilt.

Snapshot-Isolation und Aktualisierungsgrenzen¶

Innerhalb einer einzelnen Pipeline (ohne Grenze) garantiert Snowflake die Snapshot-Isolation für alle vorgelagerten dynamischen Tabellen, die an dieser Pipeline beteiligt sind.

Aktualisierungsgrenzen schwächen absichtlich diese Garantie für die Abhängigkeit, die die Grenze überschreitet, ab:

Innerhalb der Grenze: Objekte werden entsprechend ihrer eigenen Pipelines aktualisiert und koordiniert.
Außerhalb der Grenze: Die nachgelagerte dynamische Tabelle liest jede Version, die zum Zeitpunkt der Aktualisierung verfügbar ist.

Eine einzige Definition einer dynamischen Tabelle kann daher auf beide Arten von Eingaben verweisen:

Direkte Verweise auf vorgelagerte dynamische Tabellen, die an der Snapshot-Isolation und koordinierten Aktualisierungen innerhalb der Pipeline beteiligt sind.
Verweise auf Aktualisierungsgrenzen, die die neueste verfügbare Version der vorgelagerten Daten unabhängig voneinander und ohne Snapshot-Isolation lesen.

Verwenden Sie Aktualisierungsgrenzen nur für Abhängigkeiten, bei denen Sie keine Snapshot-Isolation zwischen den vor- und nachgelagerten dynamischen Tabellen benötigen.

Anwendungsfälle¶

Entkoppeln von teamübergreifenden Pipelines¶

Verschiedene Teams können verschiedene Teile einer logischen Pipeline besitzen:

Team A: Veröffentlicht eine dynamische Kerntabelle, die in der gesamten Organisation verwendet wird.
Team B: Definiert eine nachgelagerte dynamische Tabelle, die die dynamische Kerntabelle mit teamspezifischen Daten verknüpft.

Team B kann die Ausgabe von Team A in eine Aktualisierungsgrenze einschließen, um:

zu vermeiden, dass die dynamischen Tabellen von Team A in die eigene Pipeline gezogen werden.
den eigenen Aktualisierungszeitplan unabhängig zu halten.
Behandeln Sie die dynamische Tabelle von Team A ähnlich wie eine externe, regelmäßig aktualisierte Tabelle.

Aktivieren der dynamischen Tabelle in der Ansicht der dynamischen Tabelle¶

Ohne eine Aktualisierungsgrenze wird das Erstellen einer dynamischen Tabelle, die aus einer Ansicht einer anderen dynamischen Tabelle liest, nicht unterstützt. Mit einer Aktualisierungsgrenze können Sie die Abhängigkeit der Ansicht explizit als Grenze markieren:

CREATE VIEW v_orders AS
SELECT *
FROM orders_dt;

CREATE DYNAMIC TABLE order_summary_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '15 minutes'
AS
SELECT
  customer_id,
  COUNT(*) AS num_orders
FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(v_orders)
GROUP BY customer_id;

Hier gilt für order_summary_dt Folgendes:

Liest aus orders_dt über eine Aktualisierungsgrenze.
Gehört nicht zur gleichen Pipeline wie orders_dt.
Liest bei einer Aktualisierung jede verfügbare Version von orders_dt.

Beispiel: Ansicht einer teameigenen Grenze¶

Ein allgemeines Muster besteht darin, dass ein Team sowohl über eine dynamische Tabelle als auch über eine Ansicht verfügt und die Aktualisierungsgrenze innerhalb der Ansichtsdefinition anwendet. Andere Teams verbrauchen dann diese Ansicht, ohne neue Abhängigkeiten für die dynamische Tabelle des besitzenden Teams einzuführen.

-- Team A: owns product_catalog_dt and publishes a boundary view
CREATE DYNAMIC TABLE product.product_catalog_dt
  WAREHOUSE = product_wh
  TARGET_LAG = '1 hour'
AS
SELECT *
FROM product.raw_products;

CREATE VIEW product.active_products_public_v AS
SELECT * FROM DYNAMIC_TABLE_REFRESH_BOUNDARY(product.product_catalog_dt)
WHERE is_active = TRUE;

-- Team B: consumes Team A's view in their own dynamic table
CREATE DYNAMIC TABLE analytics.active_product_clicks_dt
  WAREHOUSE = analytics_wh
  TARGET_LAG = '5 minutes'
AS
SELECT
  c.*,
  p.product_name
FROM analytics.clickstream_dt AS c
JOIN product.active_products_public_v AS p
  ON c.product_id = p.product_id;

Bei diesem Muster:

Team A steuert die Aktualisierungsgrenze durch Einschließen von product_catalog_dt in``product.active_products_public_v``.
Team B und andere Teams definieren ihre eigenen dynamischen Tabellen, die nur auf die veröffentlichte Ansicht verweisen.
Diese nachgelagerten dynamischen Tabellen fügen product_catalog_dt nicht zu ihrer eigenen Pipeline hinzu;``product_catalog_dt`` bleibt außerhalb ihrer Pipelines, obwohl die Daten über die Ansicht sichtbar sind.

Inkrementelle Migration zu dynamischen Tabellen¶

Wenn Sie einen bestehenden Pipeline-Schritt in eine dynamische Tabelle migrieren, möchten Sie möglicherweise nicht, dass nachgelagerte Verbrauchende Folgendes tun:

Damit beginnen, Aktualisierungen der neuen dynamischen Tabelle auszulösen.
Übernehmen neuer Anforderungen an die Zielverzögerung.

Wenn Sie die neue dynamische Tabelle (oder eine Ansicht darüber) in eine Aktualisierungsgrenze einschließen, können nachgelagerte dynamische Tabellen diese nutzen, ohne derselben Pipeline hinzugefügt zu werden.

Zielverzögerung¶

Aktualisierungsgrenzen beeinflussen auch, wie die Zielverzögerung durchgesetzt wird.

Die Zielverzögerung einer vorgelagerten dynamischen Tabelle muss gleich sein oder kürzer als die jeder nachgelagerten dynamischen Tabelle innerhalb derselben Pipeline. Dynamische Tabellen, auf die über DYNAMIC_TABLE_REFRESH_BOUNDARY() verwiesen wird, gehören nicht zur gleichen Pipeline, sodass diese Regel nicht über die Grenze hinweg gilt.

Vorgelagerte dynamische Tabellen innerhalb einer Aktualisierungsgrenze behalten ihre eigene Zielverzögerung und Planungsverhalten; sie werden nicht durch nachgelagerte Entscheidungen über die Grenze hinweg verschärft oder gelockert.

Einschränkungen¶

Aktualisierungsgrenzen unterliegen einigen wichtigen Regeln:

** Dieselbe dynamische Tabelle sowohl innerhalb als auch außerhalb einer Aktualisierungsgrenze ist nicht zulässig**

Alle Verweise auf dieselbe vorgelagerte dynamische Tabelle innerhalb einer einzelnen Definition müssen entweder direkt in der Definition enthalten oder in DYNAMIC_TABLE_REFRESH_BOUNDARY() eingeschlossen sein. Das Mischen beider würde es ermöglichen, dieselbe dynamische Tabelle mit verschiedenen Versionen zu lesen. Snowflake blockiert diese Definitionen und gibt einen beschreibenden Fehler zurück.

Nicht unterstützte Grenzziele

DYNAMIC_TABLE_REFRESH_BOUNDARY() muss ein benanntes Objekt (Tabelle, Ansicht, dynamische Tabelle oder CTE) umschließen. Folgendes kann nicht umschlossen werden:

Inline-Unterabfragen
Tabellenfunktionen oder UDTFs.
Beliebig TABLE(...)-Aufrufe

Auswirkung außerhalb dynamischer Tabellen

Sie können DYNAMIC_TABLE_REFRESH_BOUNDARY() in regulären SELECT-Abfragen aufrufen, aber außerhalb einer dynamischen Tabellendefinition ist dies eine „NoOps“-Anweisung (keine Operation).

Best Practices¶

Bei Verwendung von Aktualisierungsgrenzen in Pipelines dynamischer Tabellen:

Verwenden Sie eine Aktualisierungsgrenze in folgenden Situationen:

Sie möchten die dynamische Tabelle eines anderen Teams nutzen, ohne dessen Pipeline beizutreten.
Sie benötigen keine Snapshot-Isolation von einer bestimmten vorgelagerten Abhängigkeit.
Eine dynamische Tabelle hängt von einer Ansicht ab, die auf eine andere dynamische Tabelle verweist. Dieses Muster wird nur unterstützt, wenn entweder die Ansicht oder die vorgelagerte dynamische Tabelle in DYNAMIC_TABLE_REFRESH_BOUNDARY() eingeschlossen ist.

Vermeiden Sie eine Aktualisierungsgrenze in folgenden Situationen:

Sie benötigen eine Snapshot-Isolation über diese Abhängigkeit hinweg.
Sie möchten, dass nachgelagerte Aktualisierungen mit vorgelagerten dynamischen Tabellen koordiniert werden und dass Aktualisierungen bei Bedarf kaskadieren.
Sie verlassen sich auf globale Zielverzögerungsbeziehungen über die gesamte Pipeline hinweg.