Snowflake Dynamic Tables uitgelegd: moderne datapijplijnen

De Dynamic Tables van Snowflake zijn een krachtig hulpmiddel in de gereedschapskist van elke data engineer. Het zijn in feite geautomatiseerde verversingsprocessen die transformatiequeries op basistabellen gebruiken om nieuwe tabellen te genereren. 

Dynamic Tables vereenvoudigen data-orchestratiepijplijnen waar dataversheid belangrijk is en complexe SQL-transformaties nodig zijn. Ze gebruiken op lag gebaseerde timing om tabellen te verversen op basis van wijzigingen in basistabellen.

Recente verbeteringen hebben hun mogelijkheden versterkt, met near-real-time datapropagatie en diepere integratie binnen Snowflakes ecosysteem (ververs je kennis met deze introductiecursus). 

Deze gids legt uit hoe Dynamic Tables werken, hoe je ze effectief implementeert, en hoe je prestaties monitort en optimaliseert. Aan het einde kun je beoordelen en testen of deze implementaties passen bij de databehoeften van jouw organisatie.

Wat zijn Snowflake Dynamic Tables?

Dynamic Tables zijn een volledig beheerde klasse Snowflake-databaseobjecten die helpen om datapijplijnen te stroomlijnen en te automatiseren. 

In plaats van externe orchestratietools te gebruiken of handmatige verversingen met updates van brontabellen te timen, werken Dynamic Tables automatisch bij op basis van wijzigingen in brondata en gedefinieerde versheidstargets. Zo kunnen dataprofessionals transformaties bouwen die flexibel zijn en bijwerken wanneer de data verandert.

In tegenstelling tot views, die de gebruiker de tabel laten berekenen bij het opvragen, blijven Dynamic Tables berekend, wat de querysnelheid verbetert. En hoewel materialized views vergelijkbare gecachte data bieden, kunnen Dynamic Tables zaken gebruiken als joins, unions en geneste views, wat bij materialized views niet kan.

Oorspronkelijk geïntroduceerd om de kloof te overbruggen tussen traditionele ELT-pijplijnen en event-driven architecturen, vertegenwoordigen Dynamic Tables Snowflakes voortdurende ontwikkeling richting declaratieve en afhankelijkheidsbewuste dataverwerking. 

Alles wat je hoeft te doen, is de SQL-SELECT-query schrijven die je Dynamic Table definieert met een gedefinieerde TARGET_LAG, die de verversingsfrequentie bepaalt. 

Een TARGET_LAG van vijf minuten betekent bijvoorbeeld dat de Dynamic Table niet meer dan vijf minuten achterloopt op de basistabel. Het mooiste is dat dit allemaal wordt beheerd door Snowflakes eigen interne verversingsengine, waardoor we geen complexe pijplijnen hoeven te ontwerpen!

Snowflake Dynamic Tables begrijpen

Om Dynamic Tables effectief te implementeren, duiken we in enkele onderliggende technische implementaties van Snowflake om hun sterke en zwakke punten te begrijpen.

Fundamentele architectuur en werking

Net als materialized views bieden Dynamic Tables persistent en geautomatiseerd verversingsgedrag. Maar in tegenstelling tot materialized views staan ze complexere transformaties toe, zoals unions en joins. 

Dit maakt het mogelijk om meerdere kleinere Dynamic Tables te creëren die vervolgens grotere dynamic tables voeden.

Een belangrijke innovatie is Snowflakes gebruik van een geautomatiseerde afhankelijkheidsgrafiek. Je kunt ofwel een dynamische aggregatietabel maken die bijwerkt wanneer basistabellen bijwerken, of lagen van Dynamic Tables bouwen met gerichte acyclische grafieken (DAG’s). Dit werkt door een basis stagingtabel bij te werken, wat de update van een downstreame dynamic table triggert. 

Zodra die intermediaire Dynamic Tables zijn bijgewerkt, werkt de uiteindelijke aggregatie-Dynamic Table bij. Dit alles werkt met Snowflakes refresh workers die zoeken naar data-updates en ervoor zorgen dat brontabellen met actuele data verversen.

Uit de Snowflake-documentatie over het maken van Dynamic Tables

Dynamiek van het verversingsmechanisme

De belangrijkste mechanismen die je kunt sturen bij het maken van Dynamic Tables zijn verversingsmodi, lag en warehouse-parameters tijdens de creatie. Dynamic Tables ondersteunen twee verversingsmodi:

• Incremental mode: Snowflake analyseert wijzigingen sinds de laatste verversing en voegt de wijzigingen samen in de tabel
• Full mode: Berekent de hele tabel bij elke verversing opnieuw en vervangt de tabel volledig

Je kunt de verversingsmodus handmatig bepalen, of je kunt REFRESH_MODE = AUTO gebruiken bij de initiële creatie van de dynamic table. Wees je er bij AUTO van bewust dat de modus bij creatie wordt vastgesteld en niet wordt bijgewerkt. Als Snowflake bepaalt dat een incrementele verversing inefficiënt is, kiest het voor een volledige verversing.

De WAREHOUSE-instelling bepaalt welk warehouse voor compute-resources wordt gebruikt. Zorg dat je de juiste kiest die past bij je reken- en opslagbehoeften.

Misschien wel het belangrijkste concept is de lag. De meest gebruikelijke manier om lag te bepalen is TARGET_LAG, dat de acceptabele vertraging tussen brondata en dynamic tables definieert. Werk je met een wat complexere pijplijn waarin andere Dynamic Tables afhankelijk zijn van weer andere dynamic tables, dan kun je TARGET_LAG = DOWNSTREAM instellen. 

Door TARGET_LAG op DOWNSTREAM te zetten, wordt gekeken naar de downstream Dynamic Tables die voor timing afhankelijk zijn van de huidige Dynamic Table.

Tabel met verschillen tussen Dynamic Tables en traditionele tabellen, views en materialized views

Afhankelijkheidsbeheer

Elke Dynamic Table draagt bij aan een DAG, waardoor Snowflake verversingen over meerdere tabellen kan coördineren. Dit waarborgt correctheid en efficiëntie, vooral in meertraps pijplijnen.

Snowsight biedt een visuele interface om deze DAG te verkennen, met afhankelijkheden, verversingstijden en lag-metrics. Dit is een groot voordeel voor debugging en impactanalyse. Lees zeker dit artikel over Snowflake-datapijplijnen voor meer info over hoe de architectuur van Snowflake werkt.

Belangrijkste functies en vergelijkende voordelen

Laten we ingaan op enkele andere kernfuncties van Dynamic Tables en hun voordelen. 

Vergelijkende voordelen ten opzichte van traditionele architecturen

Dynamic Tables maken externe orchestratie (zoals Airflow of dbt Cloud) overbodig door afhankelijkheidstracking en verversingslogica native in Snowflake af te handelen.

Dit heeft diverse voordelen, waaronder:

• Vereenvoudigde orkestratie: geen cronjobs of handmatige verversingslogica nodig.
• Ingebouwde change data capture (CDC)-ondersteuning: incrementele verwerking wordt native ondersteund.
• Geünificeerde monitoring: verversingsstatus, lag en lineage zijn zichtbaar in Snowsight.
• Query rewrite-ondersteuning: Snowflake kan queries optimaliseren met behulp van de lineage van de Dynamic Table.

Dit alles maakt Dynamic Tables bijzonder geschikt in situaties waar actuele en near-real-time data nodig is. Denk aan real-time dashboards en CDC-workflows. Bovendien kun je meerdere Dynamic Tables achter elkaar schakelen voor transformaties in meerdere stappen.

Realtime dataverwerking en change data capture (CDC)

In plaats van handmatige verversingstijdlijnen met CRON-jobs te definiëren, gebruiken Dynamic Tables TARGET_LAG om te vergelijken met brontabellen. Voor streamende realtime datatabellen betekent dit dat zodra de Dynamic Table uit sync is met de ingestelde lag, deze automatisch wordt bijgewerkt.

Hoewel ze erg op elkaar lijken, worden Dynamic Tables vaak gebruikt als alternatief voor Streams en materialized views. Materialized views zijn geweldig als je data altijd actueel moet zijn en je eenvoudige logica op één enkele basistabel gebruikt. 

Streams zijn ideaal om CDC handmatig te implementeren en te begrijpen hoe data in de tijd verandert. Dynamic Tables zijn perfect wanneer je op een eenvoudige manier regelmatig geplande updates wilt toepassen op complexe datatransformatiequeries.

Voor meer overwegingen over hoe je data structureert in Snowflake is deze cursus over datamodellering in Snowflake een uitstekende bron.

Snowflake Dynamic Tables implementeren

Laten we stap voor stap bekijken hoe je Dynamic Tables opzet met syntaxpatronen en best practices. Dit opzetten is relatief eenvoudig, maar een grondig begrip van de parameters zorgt dat je het maximale uit je dynamic tables haalt.

Implementatiekader en syntax

Hier is voorbeeldcode voor hoe we een Dynamic Table kunnen maken met onze tabel raw_sales als basis. Bekijk het even; daarna lichten we het toe.

# 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;Mogelijk gemaakt door

Het tweede deel is vrij rechttoe rechtaan; dat is onze SELECT-instructie, die de data in de tabel definieert. Het eerste deel, vóór de SELECT-instructie, zijn onze creatieparameters: 

• TARGET_LAG: specificeert de versheidseis zoals hierboven uitgelegd. Je kunt hier een tijdsbestek instellen of “DOWNSTREAM” gebruiken als er een andere Dynamic Table is die deze data gebruikt.
• WAREHOUSE: bepaalt de compute-resources. Kies het juiste Snowflake-warehouse om voldoende resources te hebben om de tabel kostenefficiënt te genereren
• REFRESH_MODE: kan expliciet worden ingesteld op INCREMENTAL of FULL. Ik heb AUTO gekozen om Snowflake de optimale methode te laten bepalen.
• INITIALIZE: bepaalt wanneer de tabel wordt geïnitialiseerd. ON_CREATE betekent dat de tabel direct wordt geïnitialiseerd. Met ON_SCHEDULE wordt de tabel geïnitialiseerd zodra de eerste lag-periode is bereikt.

Let op: Snowflake vereist change tracking om incrementele verversingen goed te ondersteunen; dat wordt automatisch ingeschakeld voor incrementele dynamic tables! 

Wil je dit handmatig controleren, dan kun je het ALTER TABLE-commando gebruiken. Change tracking ingeschakeld hebben maakt ook time travel mogelijk voor het herstellen van historische versies van tabellen.

CLONE en ICEBERG

Twee nuances bij Dynamic Tables zijn het klonen ervan en ze koppelen aan Snowflake Iceberg-tabellen, die zijn gebaseerd op externe Apache Iceberg-tabellen. 

Voor Iceberg-tabellen verandert er niets tijdens de set-up. Het belangrijkste voordeel van Dynamic Tables die op Snowflake Iceberg-tabellen zijn gebouwd, is dat je de externe data kunt blijven verwerken zonder continue inname of duplicatie van de data.

Klonen is mogelijk dankzij Snowflakes time travel, en we kunnen een oudere versie van onze Dynamic Table kopiëren met het CLONE-commando zoals hieronder:

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

De kanttekening is dat gekloonde tabellen mogelijk niet alle metadata van de brontabel delen en extra opslagruimte innemen. Wees voorzichtig met klonen en zorg dat het echt nodig is.

Voorbeeldopzet van data

Het is een goed idee om te oefenen met het opzetten van Dynamic Tables om de functionaliteit te testen. Dit is een algemeen stappenplan om dynamic tables te testen:

• Maak een eenvoudige tabel raw_sales met tijdstempels.
• Voeg periodiek nieuwe rijen in.
• Gebruik TARGET_LAG = '1 minute' om verversingen in actie te zien.

Je kunt bijvoorbeeld een stream maken die naar een S3-bucket kijkt waar je periodiek data uploadt. Terwijl deze data verandert, zie je hoe je Dynamic Table bijwerkt. Volg deze tutorial voor eenvoudige manieren om Snowflake data-ingestie op te zetten en bekijk vervolgens deze tutorial voor meer informatie over tabellen maken in Snowflake.

Dynamic Tables monitoren en beheren

Snowflake biedt verschillende tools om Dynamic Tables effectief te monitoren en beheren, zoals Snowsight of via queries. Zorg dat je monitorrechten op je account hebt om deze informatie te zien!

Monitoringsmethoden en tools

Snowsight gebruiken om Dynamic Tables te monitoren is eenvoudig:

• Ga naar Data en selecteer Dabatases
• Selecteer de database en het schema dat je Dynamic Table bevat
• Selecteer het tabblad Dynamic Tables
• Dit geeft een lijst met tabellen die je kunt selecteren voor meer informatie.

Snowsight kan nuttige info tonen, zoals hoe de Dynamic Table is gemaakt, de DAG en de verversingsgeschiedenis en -metrics.

Om hetzelfde met SQL te doen, gebruiken we het commando SHOW DYNAMIC TABLES. 

Als ik bijvoorbeeld alle sales-gerelateerde dynamic tables wil zien:

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

Dit geeft informatie zoals wanneer de tabel is gemaakt, de grootte, target lag en de meest recente status.

Dynamic tables beheren en wijzigen

Er komt waarschijnlijk een moment dat je je dynamic table wilt wijzigen of onderbreken. Gelukkig maakt Snowflake dit eenvoudig.

Om je tabel te pauzeren gebruiken we ALTER DYNAMIC TABLE en SUSPEND:

ALTER Dynamic Table sales_agg SUSPEND;Mogelijk gemaakt door

Om deze later te hervatten, doen we hetzelfde met RESUME:

ALTER Dynamic Table sales_agg RESUME;Mogelijk gemaakt door

Om parameters te wijzigen, kunnen we ook ALTER DYNAMIC TABLE gebruiken en de specifieke parameter SETten die we willen veranderen:

ALTER Dynamic Table sales_agg SET TARGET_LAG = '10 minutes';Mogelijk gemaakt door

De beste manier om afhankelijkheden te beheren en operationele verstoringen te minimaliseren, is ervoor zorgen dat je geen kritieke tabellen pauzeert. Als je van plan bent de lag aan te passen, zorg dan dat je begrijpt hoe dat de timing van downstreamtabellen kan beïnvloeden. 

Operationele beperkingen overwinnen

We hebben gezien dat Dynamic Tables erg nuttig zijn, maar ze hebben nog steeds enkele grenzen en aandachtspunten.

Architecturale beperkingen en limieten

Er zijn enkele account- en brontypelimieten. Huidige beperkingen zijn onder meer:

• Beperkt tot 50.000 Dynamic Tables per account (medio 2025).
• Niet alle Snowflake-objecttypen worden ondersteund als bron (bijv. streams)
• Dynamic Table-queries worden niet bijgehouden in de ACCESS_HISTORY-auditview

Andere zaken om te overwegen zijn klonen, time travel en toegangsbeheer. Time travel is wellicht het eenvoudigst: dit vereist een minimumwaarde van 1 dag. Je kunt time travel niet uitschakelen door DATA_RETENTION_TIME_IN_DAYS op 0 te zetten. 

Wees je er bij het klonen van een dynamic table van bewust dat niet alle metadata worden bewaard. Ook kun je geen Iceberg dynamic tables klonen. Als je een Dynamic Table kloont die afhankelijk is van een Iceberg dynamic table, dan wordt die Iceberg Dynamic Table niet verplaatst naar de nieuwe locatie.

Het maken en gebruiken van Dynamic Tables vereist de toegangsrollen CREATE DYNAMIC TABLE, SELECT en USAGE voor de bovenliggende database en het schema. 

Als je deze beperkingen in gedachten houdt, zul je minder problemen hebben met dynamic tables!

Technieken voor prestatie-optimalisatie

Dankzij hun eenvoudige implementatie is het makkelijk om het systeem te overladen. Een veelgemaakte fout is Dynamic Tables behandelen als een realtime datapijplijn. Ze zijn niet bedoeld om realtime databronnen te vervangen; we moeten in plaats daarvan rekening houden met timing- en dataactualiteitsvereisten. Volg bijvoorbeeld deze best practices:

• Gebruik REFRESH_MODE = incremental waar mogelijk, zodat we niet de hele Dynamic Table bij elke load opnieuw creëren
• Stel TARGET_LAG af om de kosten en versheidseisen van de stakeholder in balans te brengen.
• Kies een passend formaat WAREHOUSE om compute-resources te optimaliseren
• Breek grote transformaties op in kleinere staged tabellen.
• Schrijf slimme en efficiënte SQL die niet leunt op enorme joins en geneste SELECT-statements.

Door deze eenvoudige tips te volgen, houd je je Dynamic Tables soepel draaiend. Verstandig gebruik kan je kritieke datapijplijnen echt vereenvoudigen tegen minimale kosten, maar roekeloos gebruik kan later juist meer problemen veroorzaken!

Prijzen en kostenovertwegingen

Zoals genoemd zijn er opslag- en compute-kosten verbonden aan het gebruik van dynamic tables. We laten strategieën zien om deze kosten te begrijpen en te beheren in Snowflake.

Kostencomponenten

Er zijn twee grote onderdelen in de kosten van dynamic tables: opslag en compute. Elk heeft enkele componenten, dus laten we erin duiken.

Opslagkosten bij Dynamic Tables

Voor opslagkosten betaal je voor het opslaan van de gematerialiseerde resultaten van elke dynamic table. Er zijn ook extra kosten voor zaken als Time Travel, fail-safe storage en klonen. 

De uitzondering zijn dynamische iceberg-tabellen, waarbij je geen Snowflake-opslagkosten hebt omdat ze extern worden opgeslagen. Je kunt deze kosten beperken door je Dynamic Table zo slank mogelijk te maken of het aantal klonen en time travel te minimaliseren.

Compute-kosten bij Dynamic Tables

Compute-kosten bestaan grofweg uit twee delen: virtual warehouse en Cloud Services compute. Virtual warehouses zijn de resources die je gebruikt om je tabellen te initialiseren en te verversen; denk aan de kosten van het uitvoeren van de query. 

De Cloud Services compute draait meer om de automatisering die Snowflake biedt. Dit omvat het identificeren van wijzigingen in onderliggende basisobjecten en het onderhouden van de DAG’s. Denk aan al het achtergrondwerk dat Snowflake doet om je Dynamic Tables draaiende te houden. 

Dit is een functie van je gedefinieerde table lag, en de kosten zijn direct gekoppeld aan die ingestelde frequentie.

Voor een volledig beeld van hoe deze kosten samenkomen, raadpleeg de kostendocumentatie van Snowflake, die de componenten uitsplitst.

Kosten monitoren en besparen

Snowflake maakt het eenvoudig om deze kosten te monitoren met Snowsight. Ga naar Monitoring, vervolgens Dynamic Tables zoals gebruikelijk, en op de pagina van de dynamic table staat een tab Refresh History waar je de gebruikte warehouse-credits ziet.

Wil je het bredere gebruik van je account zien, dan kun je ook de volgende query gebruiken:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY;Mogelijk gemaakt door

Dit geeft de kosten weer die door verschillende services op het account zijn gemaakt en kan worden gekoppeld aan je dynamic tables. 

Daarnaast raad ik aan om te testen op een dedicated warehouse, zodat je de warehouse-kosten die bij de dynamic table horen volledig begrijpt. Zodra je een goed beeld hebt van de kosten, kun je ze naar je gedeelde warehouses verplaatsen.

Wil je kosten besparen, overweeg dan autosuspension. Gepauzeerde Dynamic Tables betalen alleen opslag en niet voor verversingsresources. 

Je kunt ook transient Dynamic Tables gebruiken die geen fail-safe-opslagkosten hebben. En als je je TARGET_LAG op de juiste frequentie afstemt en waar mogelijk incrementele verversing gebruikt, kun je flink besparen op compute-kosten. 

Zoals altijd helpen goed geschreven SQL en geoptimaliseerde transformaties ook om compute-resourcegebruik te beperken.

Use-cases voor Snowflake Dynamic Tables

Dynamic Tables kun je overal inzetten waar je een ingewikkelde, lastige tijdgebaseerde ETL-reload wilt vervangen door een vereenvoudigde, op lag gebaseerde en zelfbeheerde pijplijn.

Enterprise-implementatiepatronen

Hier zijn enkele implementatie-use-cases die nuttig kunnen zijn voor jouw specifieke sector.

Voor financiële organisaties kan het nuttig zijn om periodieke verversingen van transactionele data te hebben, zoals fraudedetectie of chargebacks. 

Omdat we geen seconde-nauwkeurige data nodig hebben, is een TARGET_LAG van 10 minuten misschien geschikt voor algemene systeemgezondheidsdashboards. Misschien heb je een datasciencemodel dat alle fraudewaarschuwingen in één tabel opslaat en een extern chargebackmonitoringsysteem dat naar een andere tabel schrijft. 

Je kunt deze twee eenvoudig samenbrengen in een geaggregeerde tabel, zonder complexe Airflow-DAG’s. Dit zou de queryprestaties moeten vereenvoudigen en verbeteren.

Voor retailanalytics zijn we wellicht geïnteresseerd in hoe verschillende regio’s presteren. Het kan zijn dat elke regio een eigen centrale database heeft die periodiek data doorstuurt, maar net niet synchroon. In plaats van ETL-pijplijnen te bouwen die hun timing moeten afstemmen op elke database, kunnen we een Dynamic Table bouwen die dit alles samenvoegt op basis van de lag van elke tabel. Dit vermindert de complexiteit van pijplijnen en minimaliseert de behoefte aan constant onderhoud.

Andere scenario’s kunnen zijn:

• Realtime gedragsanalyse: aggregeer realtime klantgedrag om opkomende trends samen te vatten
• CDC-workflows: houd near-real-time data bij voor operationele wijzigingen om bedrijfsissues te monitoren
• Data vault-modellering: voeg incrementeel nieuwe data toe zodra deze binnenkomt en fungeer als enkele bron van hoe de data is ingeladen

Conclusie

Snowflake Dynamic Tables zijn een fantastisch hulpmiddel om complexe, tijdgebaseerde ETL-pijplijnen te vereenvoudigen. Ze bieden een elegante balans tussen automatisering, flexibiliteit en performance. Onthoud best practices zoals testen met niet-kritieke pijplijnen om verversingsgedrag te begrijpen, je lag- en kostenmetrics monitoren en de visuele DAG’s beoordelen om afhankelijkheden te begrijpen.

Dynamic Tables zijn geen volledige vervanging voor Streams en Tasks in elk scenario, maar ze bieden een robuuste nieuwe optie die code minimaliseert en efficiëntie maximaliseert. Gebruik ze verstandig en je maakt je leven een stuk makkelijker. Voor meer informatie over Snowflake en een paar SQL-opfrissers, bekijk de volgende bronnen:

• SQL Basics Cheat Sheet
• Snowflake Foundations
• Snowflake Architecture Deep Dive
• Best Snowflake Certification 2025
• Top 32 Snowflake Interview Questions