Dynamische Tabellen in Snowflake erklärt: Moderne Datenpipelines

Die dynamischen Tabellen von Snowflake sind ein echtes Power-Tool für jeden Dateningenieur. Im Grunde sind das automatische Aktualisierungsprozesse, die Transformation-Abfragen auf Basistabellen anwenden, um neue Tabellen zu erstellen. 

Dynamische Tabellen machen die Daten-Orchestrierungs-Pipelines einfacher, wenn es auf aktuelle Daten ankommt und komplizierte SQL-basierte Transformationen nötig sind. Sie verwenden eine verzögerte Zeitsteuerung, um Tabellen basierend auf Änderungen in den Basistabellen zu aktualisieren.

Die neuesten Verbesserungen haben ihre Funktionen erweitert und ermöglichen nun eine Datenübertragung nahezu in Echtzeit sowie eine tiefere Integration in das Ökosystem von Snowflake (frisch aufgefrischt mit diesem Einführungskurs).

In diesem Leitfaden erfährst du, wie dynamische Tabellen funktionieren, wie du sie effektiv einsetzt und wie du die Leistung überwachst und optimierst. Am Ende wirst du in der Lage sein, diese Implementierungen zu bewerten und zu testen, um zu sehen, ob sie zu den Datenanforderungen deines Unternehmens passen.

Was sind dynamische Tabellen in Snowflake?

Dynamische Tabellen sind eine vollständig verwaltete Klasse von Snowflake-Datenbankobjekten, die dabei helfen, Datenpipelines zu optimieren und zu automatisieren. 

Anstatt externe Orchestrierungstools zu verwenden oder manuelle Aktualisierungen mit den Aktualisierungen der Quelltabellen abzustimmen, werden dynamische Tabellen automatisch auf Basis von Änderungen an den Quelldaten und definierten Aktualisierungszielen aktualisiert. So können Datenexperten flexible Datenumwandlungen erstellen, die bei Änderungen der Daten nach Bedarf aktualisiert werden können.

Im Gegensatz zu Ansichten, bei denen der Benutzer die Tabelle bei der Abfrage berechnen muss, bleiben dynamische Tabellen berechnet, was die Abfragegeschwindigkeit erhöht. Ähnlich wie materialisierte Ansichten, die auch zwischengespeicherte Daten bieten, können dynamische Tabellen Dinge wie Verknüpfungen, Vereinigungen und verschachtelte Ansichten nutzen, was mit materialisierten Ansichten nicht geht.

Ursprünglich eingeführt, um die Lücke zwischen traditionellen ELT-Pipelines und ereignisgesteuerte Architekturen einzubauen, sind dynamische Tabellen ein Beispiel dafür, wie Snowflake die Datenverarbeitung deklarativ und abhängigkeitsbewusst weiterentwickelt.

Du musst nur die SQL-Abfrage „ SELECT “ schreiben, die deine dynamische Tabelle mit einem definierten „ TARGET_LAG “ festlegt, der die Aktualisierungshäufigkeit bestimmt. 

Beispielsweise bedeutet eine „ TARGET_LAG “ von fünf Minuten, dass die dynamische Tabelle nicht mehr als fünf Minuten hinter der Basistabelle zurückliegt. Das Beste daran ist, dass das alles von Snowflakes eigener interner Aktualisierungs-Engine gemanagt wird und wir uns das Entwerfen komplizierter Pipelines sparen können!

Dynamische Tabellen in Snowflake verstehen

Um dynamische Tabellen effektiv zu nutzen, schauen wir uns ein paar der technischen Details von Snowflake an, um ihre Stärken und Schwächen zu verstehen.

Grundlegende Architektur und Funktionsweise

Ähnlich wie materialisierte Ansichten bieten dynamische Tabellen ein dauerhaftes und automatisches Datenaktualisierungsverhalten. Im Gegensatz zu materialisierten Ansichten kann man hier aber komplexere Transformationen machen, weil man Sachen wie Vereinigungen und Verknüpfungen machen kann. 

So kannst du mehrere kleinere dynamische Tabellen erstellen, die dann in größere dynamische Tabellen eingefügt werden können.

Eine wichtige Neuerung ist, dass Snowflake einen automatisierten Abhängigkeitsgraphen nutzt. Du kannst entweder eine dynamische Aggregattabelle erstellen, die bei Aktualisierung der Basistabellen aktualisiert wird, oder du kannst mithilfe gerichteter azyklischer Graphen Ebenen dynamischer Tabellen erstellen. Das funktioniert so, dass eine Basis-Staging-Tabelle aktualisiert wird, was dann die Aktualisierung einer nachgelagerten dynamischen Tabelle auslöst. 

Sobald diese dynamischen Zwischentabellen aktualisiert sind, wird die endgültige aggregierte dynamische Tabelle aktualisiert. All das läuft über die Aktualisierungs-Worker von Snowflake, die nach Datenaktualisierungen suchen und dafür sorgen, dass die Quelltabellen mit den neuesten Daten aktualisiert werden.

Aus der Snowflake-Dokumentation zum Erstellen dynamischer Tabellen

Dynamik des Aktualisierungsmechanismus

Die wichtigsten Mechanismen, die du beim Erstellen dynamischer Tabellen steuern kannst, sind Aktualisierungsmodi, Verzögerungen und Lagerparameter während der Erstellung. Dynamische Tabellen können auf zwei Arten aktualisiert werden:

• Inkrementeller Modus: Snowflake schaut, was sich seit dem letzten Aktualisieren geändert hat, und fügt die Änderungen in die Tabelle ein.
• Vollmodus: Berechnet die ganze Tabelle bei jeder Aktualisierung neu und ersetzt sie komplett.

Du kannst den Aktualisierungsmodus entweder manuell festlegen oder bei der ersten Erstellung der dynamischen Tabelle die Option „ REFRESH_MODE = AUTO “ verwenden. Pass nur auf, wenn du „ AUTO “ benutzt, dass der Aktualisierungsmodus beim Erstellen festgelegt wird und nicht mehr geändert werden kann. Wenn Snowflake feststellt, dass eine inkrementelle Aktualisierung nicht gut funktioniert, wird eine vollständige Aktualisierung durchgeführt.

Die Einstellung „ WAREHOUSE “ entscheidet, welches Warehouse für die Rechenressourcen genutzt wird. Achte darauf, dass du das richtige Modell für deine Rechenleistung und Datenspeicheranforderungen auswählst.

Das vielleicht wichtigste Konzept ist die Verzögerung. Die gängigste Methode zur Bestimmung der Verzögerung ist die Verwendung von „ TARGET_LAG “, die die akzeptable Verzögerung zwischen Quelldaten und dynamischen Tabellen definiert. Wenn du mit einer etwas komplexeren Pipeline arbeitest, in der andere dynamische Tabellen auf anderen dynamischen Tabellen basieren, kannst du „ TARGET_LAG = DOWNSTREAM “ (Dynamische Tabellen verknüpfen) auswählen. 

Wenn du „ TARGET_LAG “ auf „ DOWNSTREAM “ setzt, werden die nachgelagerten dynamischen Tabellen überprüft, die für das Timing auf die aktuelle dynamische Tabelle angewiesen sind.

Tabelle mit den Unterschieden zwischen dynamischen Tabellen und normalen Tabellen, Ansichten und materialisierten Ansichten

Abhängigkeitsverwaltung

Jede dynamische Tabelle ist Teil eines DAG, sodass Snowflake die Aktualisierung mehrerer Tabellen koordinieren kann. Das sorgt für Genauigkeit und Effizienz, vor allem in Pipelines mit mehreren Stufen.

Snowsight hat eine coole Oberfläche, um diesen DAG zu checken, und zeigt Abhängigkeiten, Aktualisierungszeiten und Verzögerungswerte an. Das ist echt praktisch beim Debuggen und bei der Auswirkungsanalyse. Lies dir unbedingt diesen Artikel über Snowflake-Datenpipelines, um mehr darüber zu erfahren, wie die Architektur von Snowflake funktioniert.

Wichtigste Merkmale und Vorteile im Vergleich

Schauen wir uns ein paar andere wichtige Funktionen von dynamischen Tabellen und ihre Vorteile an. 

Vorteile gegenüber herkömmlichen Architekturen

Dynamische Tabellen machen externe Orchestrierung (z. B. Airflow oder dbt Cloud) überflüssig, da sie die Abhängigkeitsverfolgung und Aktualisierungslogik direkt in Snowflake erledigen.

Das hat echt viele Vorteile, zum Beispiel:

• Einfacheres Orchestrierungs: Keine Cron-Jobs oder manuelle Aktualisierungslogik nötig.
• Integrierte Unterstützung für die Erfassung geänderter Daten (CDC): Inkrementelle Verarbeitung wird von Haus aus unterstützt.
• Einheitliche Überwachungs: Status, Verzögerung und Abstammung kannst du in Snowsight checken.
• Unterstützung für das Umschreiben von Abfragen: Snowflake kann Abfragen mithilfe der dynamischen Tabellenherkunft optimieren.

All das macht dynamische Tabellen super für Situationen, in denen aktuelle Daten in Echtzeit gebraucht werden. Denk dabei an Sachen wie Echtzeit-Dashboards und CDC-Workflows. Außerdem kannst du mehrere dynamische Tabellen für mehrstufige Transformationen hintereinander verketten.

Echtzeit-Datenverarbeitung und Änderungsdatenerfassung (CDC)

Anstatt manuelle Aktualisierungszeitpläne mit CRON-Jobs festzulegen, verwenden dynamische Tabellen die Funktion „ TARGET_LAG “, um die Quelltabellen zu überprüfen. Für das Streamen von Echtzeit-Datentabellen heißt das, dass die dynamische Tabelle automatisch aktualisiert wird, sobald sie um die festgelegte Verzögerung nicht mehr synchron ist.

Obwohl sie sich sehr ähnlich sind, werden dynamische Tabellen oft als Alternative zu Streams und materialisierten Ansichten verwendet. Materialisierte Ansichten sind super, wenn du immer aktuelle Daten brauchst und eine einfache Logik auf einer einzelnen Basistabelle anwendest. 

Streams sind super, um CDC manuell zu machen und zu verstehen, wie sich Daten mit der Zeit ändern. Dynamische Tabellen sind super, wenn du regelmäßig geplante Updates für komplexe Datenumwandlungsabfragen auf einfache Weise machen willst.

Weitere Überlegungen zur Strukturierung von Daten in Snowflake findest du in diesem Kurs zur Datenmodellierung in Snowflake ist eine super Quelle.

Implementierung dynamischer Tabellen in Snowflake

Schauen wir uns mal an, wie man dynamische Tabellen mit Syntaxmustern und Best Practices einrichtet. Das ist eigentlich ganz einfach, aber wenn du die Parameter richtig verstehst, kannst du deine dynamischen Tabellen optimal nutzen.

Rahmenbedingungen und Syntax für die Umsetzung

Hier ist ein Beispielcode, wie wir eine dynamische Tabelle mit unserer Tabelle „ raw_sales “ als Basis erstellen könnten. Schau es dir an, dann erklären wir es dir gleich genauer.

# Your Dynamic Table parameters
CREATE OR REPLACE Dynamic Table sales_agg
  TARGET_LAG = '5 minutes'
  WAREHOUSE = 'prod_wh'
  REFRESH_MODE = auto
  INITIALIZE = on_create
  AS

# Your SQL query for the table itself
SELECT
  store_id,
  SUM(amount) AS total_sales,
  COUNT(*) AS sale_count
FROM raw_sales
GROUP BY store_id;

Die zweite Hälfte sollte ziemlich klar sein: Das ist unsere Anweisung „ SELECT “, die die Daten in der Tabelle definiert. Die erste Hälfte vor der Anweisung „ SELECT “ sind alle unsere Erstellungsparameter: 

• TARGET_LAG: Gibt die Frischeanforderungen wie oben erklärt an. Du kannst hier entweder einen Zeitrahmen festlegen oder „DOWNSTREAM“ schreiben, wenn es eine andere dynamische Tabelle gibt, die diese Daten nutzt.
• WAREHOUSE: Legt die Rechenressourcen fest. Stell sicher, dass du das richtige Snowflake-Warehouse auswählst, damit du genug Ressourcen hast, um die Tabelle kostengünstig zu erstellen.
• REFRESH_MODE: Kann explizit auf „ INCREMENTAL “ oder „ FULL “ gesetzt werden. Ich hab „ AUTO ” ausgewählt, damit Snowflake die beste Methode findet.
• INITIALIZE: Legt fest, wann die Tabelle initialisiert wird. „ ON_CREATE “ bedeutet, dass die Tabelle sofort initialisiert wird. Wenn du es auf „ ON_SCHEDULE “ setzt, wird die Tabelle initialisiert, sobald die erste Verzögerungsperiode erreicht ist.

Beachte, dass Snowflake eine Änderungsverfolgung braucht, um inkrementelle Aktualisierungen richtig zu unterstützen. Das heißt, dass sie für inkrementelle dynamische Tabellen automatisch aktiviert sind! 

Wenn du das manuell überprüfen willst, kannst du den Befehl „ ALTER TABLE “ verwenden. Wenn die Änderungsverfolgung aktiviert ist, kannst du auch in der Zeit zurückgehen, falls du alte Versionen von Tabellen wiederherstellen musst.

CLONE und ICEBERG

Zwei Besonderheiten bei dynamischen Tabellen sind das Klonen und das Verbinden mit Snowflake Iceberg-Tabellen, die auf externen Apache Iceberg-Tabellen Tabellen.

Bei Iceberg-Tabellen ändert sich bei der Einrichtung nichts. Der Hauptvorteil von dynamischen Tabellen, die auf Snowflake Iceberg-Tabellen basieren, besteht darin, dass Sie die externen Daten ohne kontinuierliche Erfassung oder Duplizierung weiterverarbeiten können.

Das Klonen ist dank der Zeitreise-Funktion von Snowflake möglich, und wir können eine ältere Version unserer dynamischen Tabelle kopieren, indem wir den Befehl „ CLONE “ wie folgt verwenden:

CREATE Dynamic Table clone_sales_agg
CLONE sales_agg
AT (OFFSET => -24*60*60) –-24 hours ago
TARGET_LAG = DOWNSTREAM
WAREHOUSE = sales_wh

Der Nachteil dabei ist, dass geklonte Tabellen möglicherweise nicht alle Metadaten der Quelltabelle enthalten und zusätzlichen Speicherplatz beanspruchen. Sei vorsichtig beim Klonen und überleg dir, ob es wirklich nötig ist.

Beispiel für die Datenkonfiguration

Es ist eine gute Idee, das Einrichten dynamischer Tabellen zu üben, um die Funktionalität zu testen. Hier ist eine allgemeine Anleitung zum Testen dynamischer Tabellen:

• Erstell eine einfache Tabelle „ raw_sales ” mit Zeitstempeln.
• Füge regelmäßig neue Zeilen ein.
• Klicke auf „ TARGET_LAG = '1 minute' “, um die Aktualisierungen in Aktion zu sehen.

Du kannst zum Beispiel einen Stream erstellen, der einen S3-Bucket überwacht, in den du regelmäßig Daten hochladen kannst. Wenn sich diese Daten ändern, kannst du sehen, wie deine dynamische Tabelle aktualisiert wird. In diesem Tutorial findest du einfache Möglichkeiten zum Einrichten von Snowflake-Datenaufnahme und dann in diesem Tutorial mehr Infos zum Erstellen von Tabellen in Snowflake.

Überwachen und Verwalten dynamischer Tabellen

Snowflake hat ein paar Tools, mit denen du dynamische Tabellen gut im Auge behalten und verwalten kannst, zum Beispiel Snowsight oder Abfragen. Stell sicher, dass du in deinem Konto die Berechtigung zum Überwachen hast, um diese Infos zu sehen!

Überwachungsmethoden und -instrumente

Die Überwachung dynamischer Tabellen mit Snowsight ist ganz einfach:

• Geh zu „Daten“ und wähl „Datenbanken“ aus.
• Wähle die Datenbank und das Schema aus, die deine dynamische Tabelle enthalten.
• Wähle die Option „ Dynamische Tabellen aus.
• Hier findest du eine Liste der Tabellen, die du auswählen und mit weiteren Infos anschauen kannst.

Snowsight hat coole Infos, z. B. wie die dynamische Tabelle erstellt wurde, die DAG, den Aktualisierungsverlauf und Metriken.

Um das Gleiche mit SQL zu machen, würden wir den Befehl „ SHOW DYNAMIC TABLES “ verwenden. 

Wenn ich zum Beispiel alle dynamischen Tabellen sehen will, die mit meinen Verkäufen zu tun haben:

SHOW Dynamic Tables LIKE ‘sales_%' IN SCHEMA mydb.myschema;

Hier findest du Infos wie wann die Tabelle erstellt wurde, wie groß sie ist, wie viel Zielverzögerung sie hat und wie ihr Status gerade ist.

Dynamische Tabellen verwalten und ändern

Irgendwann wirst du wahrscheinlich deine dynamische Tabelle ändern oder pausieren wollen. Zum Glück macht Snowflake das ganz einfach.

Um deine Tabelle auszulassen, benutzen wir „ ALTER DYNAMIC TABLE “ und „ SUSPEND “:

ALTER Dynamic Table sales_agg SUSPEND;

Um es später fortzusetzen, machen wir dasselbe, aber mit „ RESUME “:

ALTER Dynamic Table sales_agg RESUME;

Um die Einstellungen zu ändern, kannst du auch die Zeile „ ALTER DYNAMIC TABLE “ und „ SET “ für den Parameter, den du ändern willst, verwenden:

ALTER Dynamic Table sales_agg SET TARGET_LAG = '10 minutes';

Der beste Weg, Abhängigkeiten zu verwalten und Betriebsunterbrechungen zu minimieren, ist sicherzustellen, dass du keine kritischen Tabellen aussetzt. Wenn du vorhast, die Verzögerung zu ändern, solltest du dir überlegen, wie sich das auf den Zeitpunkt der nachgelagerten Tabellen auswirken könnte. 

Betriebliche Einschränkungen überwinden

Wir haben gelernt, dass dynamische Tabellen echt praktisch sind, aber es gibt noch ein paar Einschränkungen und Dinge, die man beachten muss.

Architektonische Einschränkungen und Grenzen

Es gibt ein paar Einschränkungen bei den Konten und Quelltypen. Aktuelle Einschränkungen sind:

• Auf 50.000 dynamische Tabellen pro Konto begrenzt (Stand: Mitte 2025).
• Nicht alle Snowflake-Objekttypen werden als Quellen unterstützt (z. B. Streams).
• Dynamische Tabellenabfragen werden nicht in der Überwachungsansicht „ ACCESS_HISTORY “ verfolgt.

Andere Sachen, die man bedenken sollte, sind Klonen, Zeitreisen und Zugriffskontrolle. Zeitreisen sind vielleicht am einfachsten, weil man dafür mindestens einen Tag braucht. Du kannst die Zeitreise nicht ausschalten, indem du die Option „ DATA_RETENTION_TIME_IN_DAYS “ auf 0 setzt. 

Wenn du eine dynamische Tabelle klonst, denk dran, dass nicht alle Metadaten gespeichert werden. Außerdem kannst du dynamische Tabellen von Iceberg nicht klonen. Wenn du eine dynamische Tabelle klonst, die auf einer dynamischen Iceberg-Tabelle basiert, wird diese dynamische Iceberg-Tabelle nicht an den neuen Speicherort verschoben.

Zum Erstellen und Verwenden dynamischer Tabellen brauchst du die Zugriffsrollen „ CREATE DYNAMIC TABLE “, „ SELECT “ und „ USAGE “ für die übergeordnete Datenbank und das Schema. 

Wenn du dir diese Einschränkungen merkst, solltest du weniger Probleme mit dynamischen Tabellen haben!

Techniken zur Leistungsoptimierung

Durch die einfache Implementierung kann das System schnell überlastet sein. Ein häufiger Fehler ist, dynamische Tabellen wie eine Echtzeit-Datenpipeline zu behandeln. Sie sollen keine Echtzeit-Datenquellen ersetzen; stattdessen sollten wir uns überlegen, wann wir die Daten brauchen und wie aktuell sie sein müssen. Zum Beispiel können wir diese bewährten Vorgehensweisen befolgen:

• Verwende nach Möglichkeit „ REFRESH_MODE = incremental “, damit wir nicht bei jedem Laden die ganze dynamische Tabelle neu erstellen müssen.
• Passe die „ TARGET_LAG “ an, um die Kosten und die Anforderungen der Stakeholder an die Aktualität der Daten in Einklang zu bringen.
• Wähle die richtige Größe für „ WAREHOUSE “, um die verwendeten Rechenressourcen zu optimieren.
• Teile große Transformationen in kleinere Tabellen auf.
• Schreib schlaues und effizientes SQL, das nicht auf massiven Joins und verschachtelten „ SELECT “-Anweisungen angewiesen ist.

Wenn du diese einfachen Tipps befolgst, solltest du keine Probleme mit deinen dynamischen Tabellen haben. Wenn du sie richtig einsetzt, kannst du deine wichtigen Datenpipelines mit minimalen Kosten vereinfachen, aber wenn du sie einfach so verwendest, kann das später zu Problemen führen!

Preise und Kosten

Wie bereits erwähnt, fallen bei der Verwendung dynamischer Tabellen Speicher- und Rechenkosten an. Wir zeigen dir ein paar Strategien, wie du diese Kosten in Snowflake besser verstehen und verwalten kannst.

Kostenelemente

Die Kosten für die Verwendung dynamischer Tabellen setzen sich aus zwei großen Teilen zusammen: Speicherplatz und Rechenleistung. Jedes davon besteht aus mehreren Teilen, also schauen wir uns das mal genauer an.

Speicherkosten mit dynamischen Tabellen

Für die Speicherkosten werden dir die materialisierten Ergebnisse jeder dynamischen Tabelle berechnet. Es gibt auch zusätzliche Kosten für Sachen wie Zeitreisen, sichere Speicherung und Klonen. 

Die einzige Ausnahme sind dynamische Iceberg-Tabellen, für die keine Snowflake-Speicherkosten anfallen, da sie extern gespeichert werden. Du kannst diese Kosten begrenzen, indem du deine dynamische Tabelle so schlank wie möglich hältst oder das Klonen und Zurückblättern auf ein Minimum reduzierst.

Berechne Kosten mit dynamischen Tabellen

Die Rechenkosten bestehen aus zwei großen Teilen: virtuelles Lager und Cloud Services-Rechenleistung. Virtuelle Lagerhäuser sind die Ressourcen, die du zum Initialisieren und Aktualisieren deiner Tabellen verwendest; denk dabei an die Kosten, die mit der Ausführung der Abfrage verbunden sind. 

Bei den Cloud Services geht es mehr um die Automatisierung, die Snowflake bietet. Dazu gehören das Erkennen von Änderungen an zugrunde liegenden Basisobjekten und die Pflege der DAGs. Denk mal an all die Arbeit, die Snowflake im Hintergrund macht, damit deine dynamischen Tabellen funktionieren. 

Das hängt von der von dir festgelegten Tabellenverzögerung ab, und die Kosten hängen direkt von der festgelegten Häufigkeit ab.

Um zu sehen, wie sich diese Kosten zusammensetzen, check einfach mal Kostenübersicht von Snowflake, wo alles genau aufgeschlüsselt ist.

Kostenüberwachung und Einsparungen

Mit Snowsight von Snowflake ist es super einfach, diese Kosten im Auge zu behalten. Du kannst wie gewohnt zu „Überwachung“ und dann zu „Dynamische Tabellen“ gehen. Auf der Seite der dynamischen Tabelle gibt es eine Registerkarte „ Refresh History “, auf der die verwendeten Warehouse-Credits angezeigt werden.

Wenn du die allgemeine Nutzung deines Kontos sehen möchtest, kannst du auch die folgende Abfrage verwenden:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY;

Dadurch werden die Kosten der verschiedenen Dienste auf dem Konto angezeigt und können mit deinen dynamischen Tabellen verknüpft werden. 

Außerdem empfehle ich, das Ganze in einem speziellen Lager zu testen, damit du die Lagerkosten für die dynamische Tabelle richtig verstehst. Sobald du ein Gefühl für die Kosten hast, kannst du sie in deine gemeinsamen Lagerhäuser verschieben.

Wenn du Kosten sparen willst, solltest du Funktionen wie die automatische Aussetzung in Betracht ziehen. Ausgeblendete dynamische Tabellen werden nur für die Speicherung berechnet, nicht für Aktualisierungsressourcen. 

Du kannst auch temporäre dynamische Tabellen verwenden, die keine ausfallsicheren Speicherkosten haben. Außerdem kannst du eine Menge Rechenkosten sparen, wenn du deine „ TARGET_LAG “ auf die richtige Frequenz optimierst und, wo möglich, eine inkrementelle Aktualisierung nutzt. 

Wie immer sind gut geschriebene SQL-Anweisungen und optimierte Transformationen auch eine super Möglichkeit, den Verbrauch von Rechenressourcen zu reduzieren.

Anwendungsfälle für dynamische Tabellen in Snowflake

Dynamische Tabellen kannst du überall dort einsetzen, wo du eine komplizierte, knifflige zeitbasierte ETL-Pipeline durch eine vereinfachte, verzögerungsbasierte und selbstverwaltete Pipeline ersetzen möchtest.

Muster für die Bereitstellung in Unternehmen

Hier sind ein paar Anwendungsfälle, die für deine Branche nützlich sein könnten.

Für Finanzunternehmen kann es sinnvoll sein, Transaktionsdaten regelmäßig zu aktualisieren, zum Beispiel bei Betrugserkennung oder Rückbuchungen. 

Da wir keine Daten in Echtzeit brauchen, könnte für allgemeine Systemstatus-Dashboards ein „ TARGET_LAG “ von 10 Minuten sinnvoll sein. Vielleicht hast du ein Data-Science-Modell, das alle Betrugswarnungen in einer Tabelle speichert, und ein Rückbuchungsüberwachungssystem von einem anderen Anbieter, das die Daten in einer anderen Tabelle speichert. 

Du kannst diese beiden ganz einfach in einer aggregierten Tabelle zusammenfassen, ohne dass du komplizierte Airflow-DAGs brauchst. Das sollte die Abfrage-Performance vereinfachen und verbessern.

Für die Einzelhandelsanalyse interessiert uns vielleicht, wie verschiedene Regionen abschneiden. Es kann sein, dass jede Region ihre eigene zentrale Datenbank hat, die die Daten regelmäßig weiterleitet, aber vielleicht nicht ganz synchron. Anstatt ETL-Pipelines zu erstellen, deren Timings auf jede Datenbank abgestimmt sein müssen, können wir eine dynamische Tabelle erstellen, die alle Daten nach Bedarf auf Basis der Verzögerungen aus jeder Tabelle zusammenfasst. Das macht die Pipeline einfacher und man muss nicht ständig was reparieren.

Andere Szenarien könnten sein:

• Echtzeit-Verhaltensanalyse: Sammelt Infos zum Kundenverhalten in Echtzeit, um neue Trends zu erkennen.
• CDC-Workflows: Halte Daten für betriebliche Änderungen fast in Echtzeit bereit, um einen Lernpfad für geschäftliche Probleme zu erstellen.
• Daten-Vault-Modellierung: Neue Daten werden nach und nach hinzugefügt, sobald sie eintreffen, und dienen als einzige Quelle dafür, wie die Daten erfasst wurden.

Fazit

Dynamische Tabellen von Snowflake sind ein super Tool, um komplexe zeitbasierte ETL-Pipelines zu vereinfachen. Sie bieten eine coole Balance zwischen Automatisierung, Flexibilität und Leistung. Denk einfach an ein paar bewährte Vorgehensweisen, wie das Testen mit nicht kritischen Pipelines, um das Verhalten der Datenaktualisierung zu verstehen, die Überwachung deiner Verzögerungs- und Kostenkennzahlen und die Bewertung der visuellen DAGs, um Abhängigkeiten zu verstehen.

Dynamische Tabellen sind nicht in jedem Fall ein kompletter Ersatz für Streams und Tasks, aber sie bieten eine coole neue Option, die Code reduziert und die Effizienz erhöht. Wenn du sie richtig einsetzt, kannst du dir das Leben echt erleichtern. Weitere Infos zu Snowflake und ein paar SQL-Auffrischungen findest du in den folgenden Ressourcen:

• SQL-Grundlagen-Spickzettel
• Snowflake-Grundlagen
• Snowflake-Architektur im Detail
• Beste Snowflake-Zertifizierung 2025
• Die 32 häufigsten Fragen in Vorstellungsgesprächen bei Snowflake