dbt selbst einrichten: v2 und Python-v1 sauber trennen

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.

Erst den Installationsweg festlegen

Diese Anleitung nutzt die synthetischen Snowflake-Objekte aus Teil 2. Der Testnutzer darf nur im vorgesehenen DEV-Ziel schreiben. Für Menschen ist hier interaktive SSO-Anmeldung vorgesehen; das Beispiel ist kein unbeaufsichtigter Produktionsjob.

Die OS-Anleitungen richten die lokale Laufzeit ein. Anschließend folgen hier Profil, Verbindung und ein kleines Projekt.

1. Lokale Einrichtung nach Betriebssystem

• dbt unter Windows installieren und mit Snowflake verbinden
• dbt unter macOS installieren und mit Snowflake verbinden
• dbt unter Linux installieren und mit Snowflake verbinden

Diese Wege verwenden den aktuellen v2-Paketweg in einer eigenen Umgebung. Bestehende v1-Projekte behalten ihre separat geprüfte Core-/Adapter-Kombination. Nutze dafür die passende Versionsansicht der Herstellerhilfe; mische beide Laufzeiten nicht in einer Umgebung.

2. Verbindung außerhalb des Repositories konfigurieren

Ein Profil sagt dbt, wohin und als wer es sich verbindet. Im geschützten, für diesen Pilot gewählten Profilverzeichnis eine profiles.yml ablegen; vorhandene Profile nicht überschreiben. Ein eigens gewählter Profilpfad wird unten über --profiles-dir verwendet.

bn_setup:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: "{{ env_var('DBT_ACCOUNT') }}"
      user: "{{ env_var('DBT_USER') }}"
      authenticator: externalbrowser
      role: BN_SETUP_DBT_DEV
      database: BN_SETUP_LAB
      warehouse: BN_SETUP_WH
      schema: DEV_RUNNER
      threads: 2

DBT_ACCOUNT enthält die für den Connector bestätigte Accountkennung, DBT_USER die genehmigte Nutzerkennung. Beide Variablen im tatsächlichen Ausführungsprozess setzen. Dieser Profiltext enthält kein Passwort. Die Snowflake-Verbindungshilfe beschreibt die je Laufzeit unterstützten Anmeldeverfahren. Ein geplanter Scheduler darf nicht auf einen menschlichen Browserdialog warten.

3. Ein minimales Projekt mit bekanntem Ergebnis anlegen

In einem neuen Projektverzeichnis die folgende Struktur erstellen:

bn_setup/
  dbt_project.yml
  models/
    orders.sql
    orders.yml

dbt_project.yml:

name: bn_setup
version: '1.0.0'
config-version: 2
profile: bn_setup
model-paths: [models]
models:
  bn_setup:
    +materialized: view

models/orders.sql:

select order_id, amount
from {{ source('pilot', 'ORDERS') }}

models/orders.yml:

version: 2
sources:
  - name: pilot
    database: BN_SETUP_LAB
    schema: RAW
    tables:
      - name: ORDERS
models:
  - name: orders
    columns:
      - name: order_id
        data_tests:
          - not_null
          - unique

Die Source benennt vorhandene Rohdaten; sie lädt keine Daten. Das Modell ist SQL, aus dem dbt die gewählte View baut. Die Tests prüfen hier zwei konkrete Eigenschaften des Schlüssels, nicht sämtliche fachlichen Qualitätsregeln.

4. Verbindung, Modell und tatsächliches Ziel prüfen

Aus dem Projektverzeichnis, mit dem vorbereiteten Profilpfad anstelle von /PFAD/ZUM/PROFIL:

dbt debug --profiles-dir /PFAD/ZUM/PROFIL --target dev
dbt parse --profiles-dir /PFAD/ZUM/PROFIL --target dev
dbt build --profiles-dir /PFAD/ZUM/PROFIL --target dev --select orders

Danach in Snowflake das tatsächlich erzeugte Objekt prüfen:

SELECT COUNT(*) AS ROWS_FOUND, SUM(AMOUNT) AS TOTAL
FROM BN_SETUP_LAB.DEV_RUNNER.ORDERS;

Erwartet: 3 / 50. Zusätzlich bestätigen, dass kein PROD-Objekt geändert wurde. Lauf-ID, Git-Commit, Ziel und vorhandene Laufartefakte gemeinsam sichern; welche Artefakte erzeugt werden, mit der tatsächlich gewählten Engine abgleichen. Ein alter target/-Ordner ist kein Nachweis des aktuellen Laufs.

5. Häufige Fehler gezielt eingrenzen

Abschließend die Einrichtungsprüfungen belegen. Für die Prüfungsvorbereitung passt der dbt-Analytics-Engineering-Check. Verbindungs- und Buildtests im eigenen Account bleiben davon unabhängig.

Herstellerquellen

• dbt: Installation / version selector
• dbt: Snowflake connection
• dbt: Data tests

Lokal mit von Fivetran geladenen Sources arbeiten

Der lokale dbt-Client liest in diesem Fall genehmigte Snowflake-Tabellen, nicht ungeprüft direkt die ursprüngliche Geschäftsanwendung. Sources müssen die tatsächlichen Datenbank-, Schema- und Tabellennamen des Ladeziels abbilden. Ladestand, Auswahlscope und erlaubte Entwicklungsdaten vor dem ersten Modelllauf kontrollieren.

Eine lokale dbt-Ausführung startet nicht automatisch den benötigten Fivetran-Sync. Für den Pilot einen abgeschlossenen Quellenlauf und dessen Stand dokumentieren. Anschließend einen schmalen Modellausschnitt samt Tests prüfen. Lade- und Entwicklungsidentität getrennt halten. Die Fivetran-Einrichtung und die gemeinsame Betriebsabnahme schließen den Weg.