dbt Cloud mit Microsoft Fabric nutzen

dbt Cloud transformiert Daten, die schon in einem Warehouse liegen. Sie schreiben SQL-Modelle, die aufeinander verweisen, dbt Cloud kompiliert sie in die richtige Ausführungsreihenfolge, führt sie auf dem Warehouse aus und lässt Tests gegen die Ergebnisse laufen. Es bringt keine Daten ins Warehouse. Das ist ein eigener Ingestion-Schritt, den ein Tool wie Fivetran oder eine Fabric-Data-Factory-Pipeline übernimmt.

Wie ein dbt-Modell aussieht

Ein dbt-Modell ist eine SQL-Datei, die eine Tabelle oder View definiert. Modelle verweisen mit der Funktion ref() aufeinander statt mit fest eingetragenen Tabellennamen, damit dbt die Reihenfolge der Abhängigkeiten selbst bestimmen kann:

-- models/marts/fct_orders.sql
with orders as (
    select * from {{ ref('stg_orders') }}
),
customers as (
    select * from {{ ref('stg_customers') }}
)

select
    orders.order_id,
    orders.order_date,
    orders.order_total,
    customers.customer_id,
    customers.customer_name
from orders
left join customers on orders.customer_id = customers.customer_id

Ein Aufruf von dbt run baut jedes Modell des Projekts in Reihenfolge der Abhängigkeiten: zuerst stg_orders und stg_customers, dann fct_orders, sobald beide vorliegen.

Ein Modell testen

Tests werden neben dem Modell in einer YAML-Datei definiert, nicht im Code:

## models/marts/schema.yml
models:
  - name: fct_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: customer_id
        tests:
          - relationships:
              to: ref('stg_customers')
              field: customer_id

dbt test führt jeden definierten Test aus und lässt den Lauf fehlschlagen, wenn eine Spalte, die eindeutig sein soll, Duplikate hat, eine Pflichtspalte Nullwerte enthält oder ein Fremdschlüssel auf eine Zeile zeigt, die es nicht gibt. Tests laufen gegen die echten Daten des Warehouse, nicht gegen eine Attrappe. Sie fangen deshalb Datenprobleme aus vorgelagerten Systemen ebenso ab wie SQL-Fehler.

Der dbt-Cloud-Workflow

dbt Cloud ergänzt das Open-Source-dbt um eine gehostete Ebene: eine IDE im Browser oder CLI für die Entwicklung, einen Job-Scheduler und Umgebungen für Entwicklung und Produktion.

1. Entwickeln. Schreiben und prüfen Sie Modelle gegen das Warehouse in der dbt-Cloud-IDE oder in einer lokalen CLI, die mit einem Entwicklungsschema verbunden ist.

2. Versionskontrolle. Jedes Projekt liegt in einem Git-Repository. Änderungen laufen über einen Branch und einen Pull Request, genau wie Anwendungscode.

3. Nach Plan oder beim Merge ausführen und testen. Ein dbt-Cloud-Job führt dbt build aus (das Modelle und ihre Tests zusammen ausführt), nach Plan oder automatisch, wenn ein Pull Request in den Main-Branch gemergt wird.

4. In Produktion bringen. Ein erfolgreicher Lauf in der Produktionsumgebung ist das, woraus nachgelagerte Tools, auch Power BI, lesen sollten.

dbt Cloud mit Microsoft Fabric verbinden

dbt verbindet sich über den dbt-fabric-Adapter, den Microsoft pflegt, mit dem Microsoft Fabric Data Warehouse. Der Ablauf ist derselbe wie bei jedem anderen Warehouse: Modelle werden zu SQL kompiliert, und dbt Cloud führt sie gegen den SQL-Endpunkt des Fabric Warehouse aus. Die entstehenden Tabellen liegen in OneLake, der gemeinsamen Speicherebene von Fabric, die auch die anderen Fabric-Workloads nutzen.

Von dort verbindet sich Power BI mit den transformierten Tabellen wie mit jeder anderen Fabric-Warehouse-Tabelle, auch im Direct-Lake-Modus. Das Gegenstück für Snowflake finden Sie in unserer Anleitung zur Verbindung von Power BI mit Snowflake. Müssen die Daten erst ins Warehouse gelangen, bevor dbt sie transformieren kann, zeigt unser Data-Factory-Vergleich, wie dieser Ingestion-Schritt in Fabric im Vergleich zu Azure Data Factory funktioniert.

Was dbt Cloud nicht leistet

dbt Cloud transformiert Daten, die schon in einem Warehouse liegen. Es extrahiert keine Daten aus Quellsystemen und baut weder das Power-BI-Semantic-Model noch DAX-Measures oder das Berichtslayout nach den Tabellen, die es erzeugt. Transformationslogik in versionierten SQL-Modellen zu halten, statt in Power-Query-Schritten in jedem Bericht, heißt: Dieselbe getestete Tabelle kann mehr als einen Bericht speisen, ohne die Logik zu wiederholen. Was ins Modell gehört, sobald die Ausgabe von dbt dort ankommt, lesen Sie in unserem Leitfaden zur Datenmodellierung in Power BI.

Quellen

• Set up dbt for Fabric Data Warehouse - Microsoft Learn

• About dbt tests - dbt Labs