Snowflake 2026: Architektur, SQL und Interviewfragen für Data Engineers

Snowflake-Interviewfragen testen, ob ein Data Engineer die entkoppelte Architektur der Plattform verstanden hat und nicht nur ihre SQL-Syntax beherrscht. Das von Snowflake eingeführte Multi-Cluster-Shared-Data-Design trennt Storage, Compute und Services in drei unabhängige Schichten, und diese Trennung erklärt fast jede Performance- und Kostenentscheidung, die ein Team auf der Plattform trifft. Dieser Leitfaden behandelt die Snowflake-Architektur, die SQL-Muster, die Abfragen 2026 schnell und günstig halten, und die Interviewfragen, die echte Produktionserfahrung offenlegen.

Snowflake-Architektur: Storage, Compute und Cloud Services

Das prägende Merkmal der Snowflake-Architektur ist, dass Storage und Compute physisch getrennt sind. Daten liegen genau einmal in einer zentralen Storage-Schicht, die von Cloud-Objektspeichern wie Amazon S3 oder Azure Blob Storage gestützt wird. Beliebig viele Compute-Cluster können dieselben Daten gleichzeitig lesen, ohne sie zu kopieren – ein Ansatz, den das ursprüngliche Engineering-Team in der SIGMOD-Veröffentlichung von 2016, die das Design vorstellte, Multi-Cluster Shared Data nannte.

Die Storage-Schicht hält Daten in unveränderlichen, komprimierten, spaltenorientierten Dateien, den sogenannten Micro-Partitions. Ein Nutzer verwaltet diese Dateien nie direkt. Snowflake schreibt sie, verfolgt ihre Metadaten und gibt sie wieder frei. Die Compute-Schicht besteht aus Virtual Warehouses, jeweils einem Cluster von Servern, die Snowflake bei Bedarf bereitstellt. Die Cloud-Services-Schicht liegt über beiden und koordiniert alles: Sie parst SQL, plant Abfragen, setzt die Zugriffskontrolle durch, verwaltet Transaktionen und speichert die Metadaten, die Features wie Time Travel und Zero-Copy-Cloning möglich machen.

Da diese Schichten unabhängig sind, lässt sich ein Warehouse in der Größe ändern oder löschen, ohne ein einziges Byte an Daten zu berühren, und der Storage kann auf Petabytes wachsen, ohne dass Compute bereitgestellt werden muss.

-- setup_warehouse.sql
-- Create an isolated compute cluster and a database.
CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'MEDIUM'      -- 4 credits/hour, doubles each size step
  AUTO_SUSPEND = 60             -- suspend after 60s idle to stop billing
  AUTO_RESUME = TRUE            -- resume automatically on the next query
  INITIALLY_SUSPENDED = TRUE;

CREATE DATABASE sales_analytics;
USE WAREHOUSE analytics_wh;
USE DATABASE sales_analytics;

-- Storage and compute are independent: dropping the warehouse
-- leaves every table in sales_analytics untouched.

Das Löschen von analytics_wh nach dem Ausführen dieses Skripts würde die gesamte Compute-Abrechnung stoppen, während jede Tabelle abfragbar bleibt, sobald ein neues Warehouse erstellt wird. Diese Entkopplung ist die wichtigste Idee, die es in einem Interview zu artikulieren gilt.

So skalieren Virtual Warehouses die Compute-Leistung von Snowflake

Ein Virtual Warehouse ist ein benannter Compute-Cluster, dessen Größe in T-Shirt-Einheiten angegeben wird: X-Small, Small, Medium, Large und größer. Jeder Schritt nach oben verdoppelt sowohl die Anzahl der Server als auch den Credit-Verbrauch pro Stunde. Ein Large-Warehouse kostet also das Vierfache eines Small-Warehouse, erledigt eine scan-intensive Abfrage aber auch rund viermal schneller. Dieser lineare Zusammenhang zwischen Preis und Leistung bedeutet, dass die günstigste Option oft ein größeres Warehouse ist, das kürzer läuft.

Es gibt zwei Skalierungsdimensionen, und sie zu verwechseln ist eine häufige Interview-Falle. Vertikales Skalieren ändert die Größe eines einzelnen Warehouse, um eine Abfrage zu beschleunigen. Horizontales Skalieren fügt einem Multi-Cluster-Warehouse Cluster hinzu, um mehr gleichzeitige Abfragen zu bedienen. Ein Dashboard, das um 9 Uhr morgens von 200 Analysten aufgerufen wird, braucht mehr Cluster, nicht ein größeres; ein nächtlicher Backfill von einer Billion Zeilen braucht ein größeres, nicht mehr Cluster.

-- scale_compute.sql
-- Multi-cluster warehouse: add clusters when concurrency rises and
-- remove them when demand falls. Each cluster is a separate MEDIUM engine.
ALTER WAREHOUSE analytics_wh SET
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4          -- up to 4 clusters during peak load
  SCALING_POLICY = 'STANDARD';   -- favor performance over credit savings

-- Resize vertically for one heavy job, then shrink back afterward.
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'XLARGE';
-- ... run the heavy backfill ...
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'MEDIUM';

AUTO_SUSPEND und AUTO_RESUME machen dies wirtschaftlich. Ein pausiertes Warehouse kostet nichts, und Snowflake rechnet sekundengenau mit einer Mindestdauer von 60 Sekunden ab. Ein kurzer Auto-Suspend auf interaktiven Warehouses verhindert, dass ungenutzte Cluster zwischen Abfragen Credits verbrennen.

Micro-Partitions und Clustering Keys für schnelles SQL

Snowflake speichert jede Tabelle als eine Menge von Micro-Partitions, von denen jede 50 bis 500 MB an unkomprimierten Daten im spaltenorientierten Format hält. Für jede Micro-Partition erfasst Snowflake den minimalen und maximalen Wert jeder Spalte in ihren Metadaten. Wenn eine Abfrage auf eine Spalte filtert, liest der Optimizer diese Metadaten und überspringt jede Partition, deren Wertebereich nicht passen kann – ein Vorgang, der Partition Pruning genannt wird. Deshalb braucht Snowflake keine manuellen Indizes: Das Pruning geschieht automatisch auf jeder Spalte.

Pruning funktioniert am besten, wenn die Filterspalte mit der Reihenfolge korreliert, in der die Daten geladen wurden. Eine nach Datum geladene Tabelle prunt Datumsbereichsabfragen effizient. Wird eine große Tabelle häufig auf einer Spalte gefiltert, die nichts mit der Ladereihenfolge zu tun hat, sorgt ein Clustering Key dafür, dass verwandte Zeilen über Micro-Partitions hinweg zusammengelegt werden, damit das Pruning auch bei wachsender Tabelle wirksam bleibt.

-- clustering.sql
-- Filters on naturally ordered columns prune partitions with no index.
SELECT order_date, SUM(amount_usd) AS revenue
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY order_date;

-- For a multi-terabyte table queried by a non-load-order column,
-- a clustering key co-locates related rows to keep pruning effective.
ALTER TABLE orders CLUSTER BY (customer_region, order_date);

-- Inspect clustering depth before committing to a key.
SELECT SYSTEM$CLUSTERING_INFORMATION('orders', '(customer_region, order_date)');

Clustering Keys sind nicht kostenlos: Snowflake betreibt einen automatischen Hintergrunddienst, um sie zu pflegen, und dieser Dienst verbraucht Credits. Als Faustregel gilt, einen Clustering Key nur zu Tabellen im Terabyte-Bereich hinzuzufügen, deren Query-Profile schlechtes Pruning zeigen. Kleinere Tabellen prunen von allein gut, und ein verfrühter Clustering Key verschwendet Geld. Diesen Kompromiss zu erklären, macht oft den Unterschied zwischen einer Junior- und einer Senior-Antwort aus.

Daten laden und transformieren: Snowpipe, Streams und Dynamic Tables

Drei Ingestion-Muster decken die meisten Workloads ab. Das Bulk-COPY INTO lädt bereitgestellte Dateien in einem einzigen Befehl und eignet sich für geplante Batch-Jobs. Snowpipe lädt Dateien kontinuierlich in serverlosen Micro-Batches, ausgelöst durch Events des Cloud-Storage, für einen nahezu in Echtzeit erfolgenden Eingang. Snowpipe Streaming schiebt einzelne Zeilen über eine Low-Latency-API, wenn Aktualität im Sub-Sekunden-Bereich zählt. Die Auswahl anhand von Latenz- und Dateigrößenanforderungen ist eine häufige Interviewfrage, und die richtige Antwort beginnt mit „Es kommt darauf an, welche Aktualität der nachgelagerte Consumer tatsächlich benötigt.“

Die Transformation innerhalb des Warehouse stützte sich historisch auf Streams und Tasks. Ein Stream erfasst Änderungen auf Zeilenebene an einer Tabelle (Change Data Capture), und ein Task führt SQL nach einem Zeitplan aus, um diese Änderungen zu konsumieren und nachgelagert zu mergen.

-- incremental_pipeline.sql
-- A stream tracks row-level changes (CDC) on the raw landing table.
CREATE STREAM orders_stream ON TABLE raw_orders;

-- A task consumes the stream on a schedule and merges changes downstream.
CREATE TASK refresh_orders
  WAREHOUSE = analytics_wh
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO orders t
  USING orders_stream s ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET t.amount_usd = s.amount_usd
  WHEN NOT MATCHED THEN INSERT (order_id, amount_usd)
    VALUES (s.order_id, s.amount_usd);

2026 sind Dynamic Tables die bevorzugte Art geworden, inkrementelle Transformationen auszudrücken. Statt einen Stream mit einem Task zu verdrahten und den Merge von Hand zu schreiben, deklariert eine Dynamic Table einen Target Lag und eine Abfrage, und Snowflake ermittelt den inkrementellen Refresh automatisch. Das entfernt den größten Teil des Orchestrierungs-Boilerplates und hält die Ergebnisse dennoch aktuell.

-- dynamic_table.sql
-- Dynamic Tables replace the stream + task pattern with a declarative
-- target lag. Snowflake computes the incremental refresh automatically.
CREATE DYNAMIC TABLE daily_revenue
  TARGET_LAG = '5 minutes'
  WAREHOUSE = analytics_wh
AS
  SELECT order_date, SUM(amount_usd) AS revenue
  FROM orders
  GROUP BY order_date;

Für Teams, die auf offene Formate setzen, erlauben Snowflakes Iceberg-Tabellen dem Warehouse, Apache Iceberg-Daten zu lesen und zu schreiben, die im eigenen Cloud-Bucket des Kunden liegen. Das vermeidet Lock-in und behält zugleich Snowflakes Query-Engine und Governance. Viele Teams kombinieren Snowflake mit dbt für versionierte, getestete Transformationen – ein Workflow, der im Leitfaden zu dbt-Datentransformationen und -Tests behandelt wird.

Snowflake-Interviewfragen für Data Engineers

Die folgenden Fragen tauchen in Snowflake-Data-Engineering-Interviews immer wieder auf. Starke Antworten verknüpfen ein Feature mit der Trennung von Storage und Compute, statt Syntax aufzusagen.

Welches Problem löst die Trennung von Storage und Compute? Sie beseitigt Contention. Analysten, die Dashboards ausführen, ein Data-Science-Team, das Features trainiert, und ein ELT-Job, der Daten lädt, können jeweils auf ihrem eigenen Warehouse gegen dieselben Tabellen laufen, ohne um Ressourcen zu konkurrieren oder Daten zu kopieren. Compute skaliert für einen schweren Job hoch und pausiert im Leerlauf, während die Storage-Kosten unabhängig davon konstant bleiben, wie viel Compute angehängt ist.

Wie funktionieren Time Travel und Zero-Copy-Cloning? Beide beruhen auf der Unveränderlichkeit der Micro-Partitions. Da Snowflake eine Micro-Partition nie überschreibt, bleiben ältere Versionen für das Aufbewahrungsfenster (bis zu 90 Tage bei Enterprise) auf der Platte. Time Travel fragt eine Tabelle zu einem vergangenen Zeitpunkt ab, indem es auf diese älteren Partitions zeigt, und CLONE erstellt eine neue Tabelle, die dieselben Partitions referenziert, ohne Storage zu duplizieren, bis eine Seite geändert wird. Copy-on-Write macht das Klonen einer Petabyte-Tabelle sofort und nahezu kostenlos.

Wann sollte ein Clustering Key definiert werden? Nur bei großen Tabellen (etwa ab einem Terabyte), die häufig auf einer Spalte gefiltert oder gejoint werden, die nichts mit ihrer Ladereihenfolge zu tun hat, und erst nachdem ein Query-Profil schlechtes Pruning bestätigt hat. Clustering verursacht laufende Wartungs-Credits, es ist also eine bewusste Optimierung, keine Standardeinstellung.

Wie werden die Kosten von Snowflake kontrolliert? Durch Warehouse-Dimensionierung, aggressiven Auto-Suspend, das Anpassen der Cluster-Anzahl an die tatsächliche Nebenläufigkeit und Resource Monitors, die die Credit-Ausgaben deckeln. Ein Resource Monitor kann Warehouses automatisch benachrichtigen oder pausieren, sobald ein Kontingent erreicht ist.

-- cost_control.sql
-- A resource monitor caps credit spend and suspends warehouses
-- automatically when the monthly quota is reached.
CREATE RESOURCE MONITOR monthly_cap
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_cap;

Streams und Tasks oder Dynamic Tables? Dynamic Tables eignen sich für deklarative Pipelines, bei denen eine Ziel-Aktualität die Anforderung ist und Snowflake den Refresh verwalten kann. Streams und Tasks bleiben das richtige Werkzeug, wenn die Transformation imperative Kontrolle, Seiteneffekte oder Logik erfordert, die eine einzelne Abfrage nicht ausdrücken kann. Zu wissen, wo jedes hingehört, statt standardmäßig auf eines zu setzen, signalisiert Produktionserfahrung.

Wie unterscheidet sich ELT auf Snowflake von klassischem ETL? Snowflakes günstiger Storage und elastische Compute-Leistung machen es praktikabel, Rohdaten zuerst zu laden und sie an Ort und Stelle zu transformieren – das Muster, das im Leitfaden zur ETL-vs-ELT-Architektur untersucht wird. Wer sich auf die gesamte Bandbreite vorbereitet, kann das Modul zu ETL- und ELT-Mustern neben dem breiteren Data-Engineering-Track üben.

Fazit

• Die Snowflake-Architektur trennt Storage, Compute und Cloud Services in drei unabhängige Schichten, und fast jede Design-Antwort führt auf diese Trennung zurück
• Virtual Warehouses skalieren vertikal für schwerere Einzelabfragen und horizontal für höhere Nebenläufigkeit; Auto-Suspend und sekundengenaue Abrechnung halten ungenutzte Compute-Leistung kostenlos
• Micro-Partitions mit Min/Max-Metadaten pro Spalte ermöglichen automatisches Partition Pruning, weshalb Snowflake keine manuellen Indizes braucht
• Clustering Keys nur zu Tabellen im Terabyte-Bereich mit nachweislich schlechtem Pruning hinzufügen, da die Wartung Credits verbraucht
• Das Ingestion-Muster an die erforderliche Aktualität anpassen: Bulk-COPY für Batch, Snowpipe für kontinuierliche Micro-Batches, Snowpipe Streaming für Sub-Sekunden-Latenz
• 2026 Dynamic Tables für deklarative inkrementelle Transformationen bevorzugen und Streams und Tasks für imperative Logik reservieren
• Time Travel und Zero-Copy-Cloning nutzen beide die Unveränderlichkeit der Micro-Partitions und Copy-on-Write, was Point-in-Time-Abfragen und sofortige Klone günstig macht
• Kosten mit richtig dimensionierten Warehouses, aggressivem Auto-Suspend, an die Nebenläufigkeit angepassten Clustern und Resource Monitors kontrollieren