Snowflake & dbt: Einrichtung und ersten Testlauf prüfen

Quellen- und Versionsstand: 26.10.2026. Snowflake: laufender Cloud-Dienst; tatsächlichen Accountstand mit CURRENT_VERSION() dokumentieren. dbt: v2-Generation sowie separate Python-v1-Linie; konkretes Paket/Adapter-Paar beziehungsweise Cloud-Engine und Release-Track selbst erfassen. Updates können Menüs und Verhalten ändern. Redaktionelle Anleitung, kein ausgeführter Plattformtest.

Die Einrichtung vollständig prüfen

Du prüfst die Verbindung, das erste Modell, den Testfehler und einen erneuten erfolgreichen Lauf. Verwende ausschließlich die synthetischen Daten aus dieser Serie. Eine ausgefüllte Projektakte oder ein Kundenauftrag sind dafür nicht erforderlich.

1. Verbindung und erstes Modell prüfen

1. Öffne das eingerichtete Projekt und verwende dieselbe Laufzeit wie im Installationsartikel. Bei lokalem dbt die zugehörige virtuelle Umgebung verwenden; in der Cloud die eingerichtete Entwicklungsumgebung öffnen.
2. Führe lokal dbt debug aus. In der Cloud prüfst du die Verbindung im eingerichteten Projekt. Bei einem Fehler zuerst Account, Anmeldeverfahren, Rolle und Warehouse prüfen.
3. Führe dbt build aus. Vergleiche in Snowflake die tatsächlich erzeugte Relation mit dem Modell aus dem vorherigen Kapitel: drei Zeilen und Gesamtsumme 50.
4. Kontrolliere die verwendete Datenbank und das Schema. Ein erfolgreicher Lauf im falschen Ziel ist kein erfolgreicher Einrichtungstest.

Notiere bei Bedarf Datum, tatsächliches Ergebnis und den zugehörigen Lauf beziehungsweise die Logdatei. Ein ausgewählter Status „bestanden“ ohne Beobachtung und Nachweis genügt nicht.

2. Einen Datenfehler kontrolliert erzeugen

Nur im isolierten, synthetischen Pilot aus Teil 2, nach Abstimmung mit dem Quellverantwortlichen: Dieser führt mit seiner berechtigten Rolle eine zusätzliche Bestellung mit bereits vorhandenem Schlüssel ein.

-- Nur der genehmigte synthetische Pilot, ausgeführt durch die Quellrolle.
INSERT INTO BN_SETUP_LAB.RAW.ORDERS VALUES (1, 99.00);

Danach den vorgesehenen dbt-Lauf ausführen. Der unique-Test für order_id muss scheitern. Protokolliert Lauf-ID, tatsächlichen Fehlerstatus, zuständigen Empfänger und die Wirkung auf eure Freigabe. Ein fehlgeschlagener Daten-Test rollt bereits erzeugte Objekte nicht automatisch zurück. Deshalb Veröffentlichung und Wiederanlauf ausdrücklich regeln.

Der Quellverantwortliche entfernt anschließend nur die injizierte Testzeile:

DELETE FROM BN_SETUP_LAB.RAW.ORDERS
WHERE ORDER_ID = 1 AND AMOUNT = 99.00;

Wiederholt den Build. Soll: ursprüngliche drei Zeilen / Summe 50, bestandene Schlüsseltests und neuer Laufnachweis. Bei anderen Datenbeständen diese Befehle nicht unverändert übernehmen.

3. Rückweg und Datenzustand unterscheiden

Ein Git-Revert stellt den Code eines früheren Commits wieder her. Er stellt nicht automatisch Tabellen, inkrementelle Zustände oder gelöschte Daten zurück. Für eure konkreten Materialisierungen festlegen:

1. Welche Objekte verändert der Lauf und wer besitzt sie?
2. Ist ein erneuter Lauf aus denselben Rohdaten ausreichend? Welche Änderungen sind nicht wiederholbar?
3. Welche Recovery-Verfahren sind im Account tatsächlich verfügbar und freigegeben?
4. Wann stoppt die Ausführung und wer entscheidet über Wiederholung oder Rückkehr?
5. Welcher Nachtest beweist den wiederhergestellten fachlichen Zustand?

Für weiterführende Szenarien die vorhandenen Snowflake-Recovery-Hilfen nutzen. Kein pauschaler full-refresh als universelles Reparaturverfahren: Umfang und Nebenwirkungen vorab klären.

4. Projekt nach einem Neustart wieder öffnen

Beende die lokale Sitzung beziehungsweise den Browser und öffne das Projekt erneut. Lokal die virtuelle Umgebung wieder verwenden, benötigte Umgebungsvariablen setzen und den richtigen Projektordner öffnen. Das Verbindungsprofil bleibt außerhalb des Git-Repositories; Geheimnisse gehören nicht in Projektdateien.

Wiederhole Verbindungsprüfung und Build. Fehlen Befehle, ist häufig eine andere Python-Umgebung aktiv. Fehlt das Profil, prüfe dessen Pfad. Scheitert nur die Anmeldung, prüfe die Sitzung oder die Gültigkeit des verwendeten Zugangs, bevor du Pakete neu installierst.

5. Einrichtung abschließen

Verbindung, Modell, Fehlerprobe und bereinigter Nachlauf funktionieren. Halte verbleibende Fehler mit nächstem Prüfschritt fest. Falls später jemand anderes die Umgebung übernimmt, lass diese Person den Start und denselben Testlauf anhand der Anleitung wiederholen; fehlende Angaben ergänzt du gezielt.

Die optionalen Installationsnotizen sammeln Version und Pfade. Für eine spätere betriebliche Übergabe gibt es das dbt-Werkzeug. Die offizielle Artefakthilfe erklärt die Laufresultate. Diese Vertiefungen sind keine zusätzlichen Pflichtschritte der lokalen Installation.

Herstellerquellen

• dbt: Run results
• dbt: Data tests
• Snowflake: Access control

Optional: einen vorhandenen Fivetran-Ladeweg prüfen

Nur wenn Fivetran bereits deine Quelle nach Snowflake lädt: Prüfe einen abgeschlossenen Ladevorgang und die tatsächlichen Tabellen im Ziel, bevor du dbt startest. Die Fivetran-Serie erklärt diesen eigenen Einrichtungsweg. Für die synthetischen Daten dieser Installationsserie benötigst du Fivetran nicht.