dbt Jobs in Microsoft Fabric: Lakehouse, Warehouse und Grenzen der Preview

dbt rückt in Microsoft Fabric deutlich näher an die Plattform heran. Native dbt Jobs bringen Ausführung, Scheduling, Monitoring und Pipeline-Integration direkt in Fabric. Gleichzeitig unterstützt Microsoft inzwischen sowohl Fabric Data Warehouse als auch Lakehouse als Ziel. Damit stellt sich weniger die Frage, ob dbt und Fabric zusammenpassen – sondern wo dbt in einer Fabric-Architektur sinnvoll eingesetzt wird, welcher Ausführungsweg zum jeweiligen Workload passt und welche Grenzen der Preview vor einem produktiven Einsatz berücksichtigt werden sollten.

Wer dbt bisher gemeinsam mit Microsoft Fabric einsetzen wollte, musste den Betrieb häufig außerhalb von Fabric organisieren: dbt Core auf einer eigenen Runtime, dbt Cloud oder ein anderer externer Orchestrierungsweg. Fabric stellte Warehouse, Lakehouse und OneLake bereit, während Ausführung und Betriebsmodell des dbt-Projekts separat organisiert wurden.

Mit den nativen dbt Jobs ändert sich dieses Bild.

Ein dbt Job in Microsoft Fabric ist ein eigenes Fabric-Element, das dbt-Projekte in einer von Fabric verwalteten Runtime ausführt und Scheduling, Monitoring sowie die Einbindung in Data Pipelines unterstützt. Für Fabric Data Warehouse und Fabric Lakehouse stehen dabei unterschiedliche Adapter und damit auch unterschiedliche Ausführungswege zur Verfügung.

Das macht dbt zu einer echten Architekturentscheidung innerhalb von Fabric.

Was sich mit nativen dbt Jobs in Fabric verändert

dbt folgt einem klaren Prinzip: Transformationen werden als deklarative Modelle beschrieben, Abhängigkeiten zwischen diesen Modellen werden aufgelöst und Tests, Dokumentation sowie wiederverwendbare Logik werden Teil des Projekts.

Neu ist nicht dieses Konzept, sondern wo dbt ausgeführt und betrieben werden kann.

Fabric stellt für dbt Jobs eine verwaltete Runtime zur Verfügung. Ein Team muss damit nicht zwingend eine eigene CLI-Umgebung oder einen externen Orchestrator betreiben, nur um ein dbt-Projekt gegen Fabric auszuführen.

Zu den wichtigen Funktionen gehören derzeit:

• Ausführung zentraler dbt-Befehle wie build, run, test, compile, seed und snapshot

• Auswahl einzelner Modelle oder Modellgruppen über dbt-Selektoren

• native Zeitplanung von Jobs

• Run-Status, Logs und Fehleranalyse innerhalb von Fabric

• Visualisierung von Modellabhängigkeiten

• Einbindung eines dbt Jobs als Aktivität in eine Fabric Data Pipeline

• Verwendung eines vorhandenen dbt-Projekts aus GitHub

• verwaltete Adapter für unterschiedliche Zielplattformen

Damit entsteht ein Betriebsmodell, bei dem Datenplattform, Transformation und Orchestrierung stärker zusammenrücken. Das bedeutet allerdings nicht, dass jeder bestehende dbt-Stack nach Fabric verschoben werden sollte.

Der Adapter entscheidet über den Ausführungsweg

Besonders wichtig ist die Unterscheidung zwischen Fabric Data Warehouse und Fabric Lakehouse.

Beide können inzwischen mit nativen dbt Jobs verwendet werden. Technisch handelt es sich aber nicht um denselben Transformationsweg.

dbt mit Fabric Data Warehouse

Für das Fabric Data Warehouse kommt der dbt-fabric-Adapter zum Einsatz. Das ist der naheliegende Weg für SQL-zentrierte Analytics-Engineering-Workloads. dbt erstellt und verwaltet seine Modelle im Warehouse und nutzt dessen SQL-Engine für die Transformationen.

Typische Einsatzbereiche sind:

• Staging- und Intermediate-Modelle

• dimensionale Datenmodelle

• Facts und Dimensions

• fachliche Data Marts

• wiederverwendbare SQL-Transformationen

• Tests auf Datenqualität und Modellbeziehungen

• SQL-first Medallion-Architekturen

Ein Warehouse-only-Ansatz kann beispielsweise Bronze, Silver und Gold innerhalb eines oder mehrerer Warehouses abbilden. dbt übernimmt dabei Transformationen, Tests und Modellabhängigkeiten. Das ist vor allem dann interessant, wenn ein Team ohnehin stark mit SQL arbeitet und für seine Transformationen keinen zusätzlichen Spark-Layer benötigt.

Lakehouse als Quelle, Warehouse als Transformationsziel

Eine zweite Variante kombiniert beide Welten. Rohdaten landen zunächst im Lakehouse. dbt liest die dort verfügbaren Delta-Tabellen über den SQL Analytics Endpoint und materialisiert die transformierten Modelle anschließend im Fabric Data Warehouse.

Damit lässt sich beispielsweise folgende Architektur aufbauen:

Lakehouse Bronze → dbt → Warehouse Silver → dbt → Warehouse Gold

Dieser Ansatz ist interessant, wenn offene Delta-Strukturen für die Datenaufnahme benötigt werden, die eigentliche Transformation und das Serving für BI aber SQL- und Warehouse-zentriert bleiben sollen.

Wichtig ist die technische Grenze: Der SQL Analytics Endpoint des Lakehouse ist für diesen Weg eine lesende Schnittstelle. dbt schreibt seine Modelle nicht über diesen Endpoint zurück in das Lakehouse, sondern in das Ziel-Warehouse.

dbt direkt im Fabric Lakehouse

Für Lakehouse-Transformationen steht inzwischen dbt-fabricspark zur Verfügung. Damit führt Fabric dbt-Modelle als Spark SQL aus und schreibt die Ergebnisse als Delta-Tabellen in OneLake.

Eine Lakehouse-only-Architektur kann dadurch beispielsweise so aussehen:

Lakehouse Bronze → dbt/Spark SQL → Lakehouse Silver → dbt/Spark SQL → Lakehouse Gold

Hier bleibt der komplette Datenbestand im Delta-Format.

Das kann für lakehouse-zentrierte Plattformen interessant sein, in denen Daten nicht erst für jede Transformationsstufe in ein relationales Warehouse verschoben werden sollen.

Der entscheidende Unterschied ist deshalb nicht nur Lakehouse gegen Warehouse, sondern die darunterliegende Engine:

• Warehouse: SQL-zentrierte Ausführung mit dem Fabric-Warehouse-Adapter

• Lakehouse: Spark-SQL-Ausführung mit dbt-fabricspark

Ein dbt-Modell sollte deshalb nicht allein aufgrund seiner fachlichen Funktion einem Lakehouse oder Warehouse zugeordnet werden. Entscheidend sind auch Engine, SQL-Dialekt, Materialisierung und das gewünschte Betriebsmodell.

Vier sinnvolle Architekturvarianten

Mit der aktuellen Fabric-Unterstützung lassen sich vier grundlegende Muster unterscheiden.

Architektur	Bronze	Silver	Gold	Typischer Einsatz
Warehouse-only	Warehouse	Warehouse	Warehouse	SQL-first Analytics und dimensionales BI
Lakehouse + Warehouse	Lakehouse	Warehouse	Warehouse	offene Rohdatenhaltung mit SQL-zentrierter Transformation
Lakehouse + Warehouse Serving	Lakehouse	Lakehouse	Warehouse	Lakehouse für Engineering, Warehouse für kuratiertes BI
Lakehouse-only	Lakehouse	Lakehouse	Lakehouse	Delta-first und Spark-orientierte Plattformen

Keine dieser Varianten ist automatisch die beste. Entscheidend ist, welche Engine welche Verantwortung übernehmen soll. Gerade in größeren Fabric-Umgebungen entsteht sonst schnell ein Anti-Pattern: Eine Transformation beginnt in einem Notebook, wird teilweise in einem Dataflow fortgeführt, anschließend durch dbt ergänzt und endet in einer Stored Procedure.

Technisch kann das funktionieren. Operativ wird es jedoch schwerer nachvollziehbar, testbar und wartbar. Eine klare Verantwortungsverteilung ist deshalb wichtiger als die Anzahl verfügbarer Fabric-Werkzeuge.

dbt und die Medallion Architecture sind nicht dasselbe

Ein verbreiteter Denkfehler besteht darin, dbt-Projektstrukturen direkt auf Bronze, Silver und Gold abzubilden.

Typische dbt-Gruppen wie

• Staging

• Intermediate

• Marts

sind zunächst logische Strukturen eines dbt-Projekts. Bronze, Silver und Gold beschreiben dagegen Architektur- und Qualitätsstufen einer Datenplattform. Beide Konzepte können aufeinander abgestimmt werden, müssen aber nicht eins zu eins übereinstimmen.

Beispielsweise kann ein Lakehouse die vollständige Bronze-Schicht enthalten, während mehrere dbt-Staging- und Intermediate-Modelle gemeinsam die Silver-Schicht eines Warehouses bilden.

Die Zuordnung sollte fachlich und architektonisch erfolgen – nicht nur aufgrund ähnlich wirkender Schichtnamen. Das wird besonders wichtig, sobald Lakehouse und Warehouse gemeinsam eingesetzt werden.

Scheduling oder Fabric Pipeline?

Ein dbt Job kann in Fabric eigenständig geplant werden. Für einen isolierten Transformationslauf reicht das häufig aus.

Beispielsweise:

• jeden Morgen um 06:00 Uhr Modelle aktualisieren

• anschließend Tests ausführen

• Run-Ergebnis im Job überwachen

Sobald die Transformation jedoch Teil einer größeren Verarbeitungskette wird, ist die Einbindung in eine Fabric Data Pipeline interessanter.

Eine Pipeline könnte beispielsweise folgende Schritte koordinieren:

Daten laden → Validierung → dbt Build → dbt Tests → Semantic Model aktualisieren → Benachrichtigung

Fabric stellt dafür eine eigene dbt-Job-Aktivität bereit.

Sie kann einen bestehenden dbt Job ausführen und mit anderen Pipeline-Aktivitäten über Erfolgs-, Fehler- oder Abschlussbedingungen verbinden. Auch Parameter und dynamische Inhalte können an die dbt-Ausführung übergeben werden.

Damit entsteht eine klare Aufgabenteilung:

dbt verantwortet Modelle, Tests, Abhängigkeiten und Materialisierung. Fabric Pipelines verantworten den übergeordneten Workflow.

Diese Trennung ist wichtig. Eine Pipeline ersetzt nicht den dbt-DAG und dbt sollte umgekehrt nicht zwangsläufig die vollständige End-to-End-Orchestrierung einer Fabric-Plattform übernehmen.

Native Fabric dbt Jobs oder externer dbt-Betrieb?

Die native Integration macht einen externen dbt-Betrieb nicht grundsätzlich überflüssig.

Vielmehr entsteht eine zusätzliche Option.

Native dbt Jobs passen gut, wenn …

… Microsoft Fabric die zentrale Datenplattform ist.

… Transformationen überwiegend innerhalb von Fabric stattfinden.

… ein Team Ausführung, Zeitplanung und Monitoring möglichst nah an der Plattform betreiben möchte.

… Fabric Pipelines bereits die zentrale Orchestrierung übernehmen.

… zusätzliche Infrastruktur für einen dbt Runner vermieden werden soll.

… ein überschaubarer und Fabric-zentrierter Deployment-Lifecycle ausreicht.

Ein externer dbt-Betrieb bleibt interessant, wenn …

… ein bestehendes dbt-Betriebsmodell bereits etabliert ist.

… dieselben Projekte mehrere Datenplattformen oder Clouds bedienen.

… CI/CD und Release-Prozesse unabhängig von Fabric organisiert werden sollen.

… dbt einen eigenen Lifecycle innerhalb der Data-Plattform-Organisation besitzt.

… vorhandene Automatisierungen und Integrationen von einem externen Runner abhängig sind.

… Funktionen benötigt werden, die der aktuelle Fabric-Preview-Stand nicht abdeckt.

Die entscheidende Frage lautet deshalb nicht "Fabric oder dbt?" sondern "Wo soll der dbt-Lifecycle betrieben werden?".

Das dbt-Projekt kann weiterhin in GitHub liegen, während Fabric den Code für eine Ausführung abruft. Damit muss Source Control nicht zwangsläufig in die Fabric-Oberfläche verlagert werden.

Für bestehende Teams kann genau diese Trennung interessant sein: Code bleibt im Repository, Fabric übernimmt die Ausführung.

Wo dbt besser passt als Notebook, Dataflow oder Stored Procedure

Microsoft Fabric bietet mehrere Transformationswege. Native dbt Jobs machen diese Auswahl nicht kleiner. Sie machen die Abgrenzung wichtiger.

dbt

dbt eignet sich besonders für deklarative, SQL-basierte Transformationen mit vielen voneinander abhängigen Modellen.

Stärken liegen unter anderem in:

• modularen SQL-Modellen

• Dependency Management

• Tests

• wiederverwendbarer Logik

• Source Control

• nachvollziehbarer Modellstruktur

• Analytics Engineering

Notebook

Notebooks bleiben sinnvoll, wenn die Transformation über klassisches SQL hinausgeht.

Typische Beispiele sind:

• komplexe Spark-Verarbeitung

• Python-Logik

• Data Science

• Machine Learning

• APIs und Libraries

• umfangreiche Datei- oder Semi-Structured-Verarbeitung

Ein dbt Job ersetzt deshalb kein Fabric Notebook.

Dataflow Gen2

Dataflow Gen2 adressiert eher Low-Code- und Power-Query-orientierte Transformationen.

Das kann sinnvoll sein, wenn Fachanwender oder Analytics-Teams Daten integrieren und aufbereiten möchten, ohne dafür ein vollständiges codebasiertes Entwicklungsmodell aufzubauen.

SQL Scripts und Stored Procedures

Auch klassische SQL-Ausführung bleibt eine Option – insbesondere für gezielte, bereits vorhandene Datenbanklogik. Je stärker jedoch Abhängigkeiten zwischen vielen analytischen Modellen, Tests und wiederverwendbaren Transformationen wachsen, desto interessanter wird der strukturierte dbt-Ansatz.

Die Werkzeuge sollten nach Transformationstyp getrennt werden – nicht nach persönlicher Vorliebe des Entwicklers.

Die wichtigste Grenze: dbt Jobs sind weiterhin Preview

Die native dbt-Integration ist funktional bereits deutlich umfangreicher, bleibt aber eine Preview-Funktion. Das sollte bei Architekturentscheidungen nicht übersehen werden. Preview bedeutet nicht automatisch, dass ein Feature für jeden produktiven Workload ungeeignet ist. Es bedeutet aber, dass Organisationen bewusster prüfen müssen, welche Anforderungen sie an Stabilität, Support, Change Management und Betriebsprozesse stellen. Darüber hinaus bestehen konkrete technische Einschränkungen.

Kein Build Caching

Die aktuelle verwaltete dbt-Runtime kompiliert und verarbeitet das Projekt für einen Lauf erneut aus dem Quellstand. Artefakte früherer Runs stehen nicht als Build Cache für eine Wiederverwendung zur Verfügung. Bei kleinen und mittleren Projekten muss das kein entscheidender Faktor sein. Bei großen dbt-Projekten sollte die vollständige Compile- und Run-Zeit jedoch in Scheduling und SLA-Betrachtungen einfließen.

Adapter unterscheiden sich funktional

Warehouse und Lakehouse verwenden unterschiedliche Adapter und unterschiedliche Engines.

Ein dbt-Projekt, das für das Warehouse entwickelt wurde, lässt sich deshalb nicht automatisch unverändert gegen das Lakehouse ausführen.

Zu prüfen sind insbesondere:

• SQL-Dialekt

• Materialisierungen

• Packages

• Makros

• unterstützte Befehle

• Authentifizierung

• Performance-Verhalten

Ein Architekturwechsel ist damit mehr als das Austauschen eines Connection Strings.

GitHub-Anbindung ist keine vollständige Entwicklungsumgebung

Bestehende dbt-Projekte können aus einem GitHub-Repository mit einem Fabric dbt Job verbunden werden. Fabric lädt dabei den entsprechenden Branch für die Ausführung. Bei dieser Betriebsform liegt die eigentliche Bearbeitung des Projekts weiterhin im Repository beziehungsweise in der vorhandenen Entwicklungsumgebung. Die GitHub-Verbindung sollte deshalb nicht mit einer vollständigen browserbasierten dbt-IDE gleichgesetzt werden.

Preview erfordert einen Exit-Pfad

Für wichtige produktive Workloads sollte geklärt sein, was passiert, wenn sich Runtime, Adapter oder unterstützte Funktionen während der Preview ändern. Ein sinnvoller Pilot betrachtet deshalb nicht nur den Happy Path. Er testet auch:

• fehlgeschlagene Modelle

• fehlerhafte Tests

• Wiederanlauf

• Logging

• Berechtigungen

• Service-Identitäten

• Deployment zwischen Umgebungen

• Pipeline-Abhängigkeiten

• Laufzeiten

• Rückfall auf einen alternativen Ausführungsweg

Eine praktische Entscheidungsmatrix

Für die Architekturentscheidung hilft eine einfache Trennung.

Anforderung	Naheliegender Ansatz
SQL-first Transformation vollständig in Fabric	nativer dbt Job
Relationale Facts, Dimensions und Data Marts	dbt + Fabric Data Warehouse
Delta-first Transformation im Lakehouse	dbt + dbt-fabricspark
Lakehouse für Rohdaten, relationales BI Serving	Lakehouse + dbt + Warehouse
Python- oder komplexe Spark-Logik	Fabric Notebook / Spark
Low-Code-Datentransformation	Dataflow Gen2
Bestehender plattformübergreifender dbt-Lifecycle	externer dbt-Betrieb prüfen
End-to-End-Orchestrierung mit mehreren Fabric-Schritten	Fabric Pipeline + dbt Job Activity
Einfacher unabhängiger Wiederholungslauf	natives dbt Scheduling

Die Tabelle ist keine technische Rangliste. Sie zeigt vielmehr, dass dbt Jobs vor allem dort stark werden, wo eine klar abgegrenzte SQL- beziehungsweise Spark-SQL-Transformationsschicht innerhalb einer Fabric-Architektur benötigt wird.

So würde ich einen Fabric-dbt-Pilot aufsetzen

Statt ein vorhandenes Transformationssystem sofort umzustellen, bietet sich ein abgegrenzter Pilot an.

1. Einen echten Workload auswählen

Kein isoliertes Hello-World-Modell, sondern eine kleine zusammenhängende Modellgruppe.

Zum Beispiel:

• Staging für Sales-Daten

• Customer- und Product-Dimension

• Sales Fact

• zwei bis drei Datenqualitätstests

Damit lassen sich Abhängigkeiten, Materialisierungen und Tests realistisch bewerten.

2. Zuerst die Zielarchitektur festlegen

Bevor dbt konfiguriert wird, sollte feststehen:

• Warehouse oder Lakehouse?

• Wo liegt Bronze?

• Wo werden Silver und Gold materialisiert?

• Welche Engine soll transformieren?

• Wer konsumiert das Ergebnis?

Erst danach folgt die Adapterentscheidung.

3. Source Control von Ausführung trennen

Das dbt-Projekt sollte versioniert werden. Wenn GitHub bereits zum Entwicklungsprozess gehört, kann Fabric das Projekt von dort ausführen. So bleibt Source Control klar vom Runtime-Betrieb getrennt.

4. Beide Orchestrierungswege testen

Ein einfacher Job sollte einmal über das native Scheduling und einmal aus einer Fabric Pipeline gestartet werden. Dadurch wird schnell sichtbar, welcher Weg für Monitoring, Abhängigkeiten und Fehlerbehandlung besser zum eigenen Betriebsmodell passt.

5. Nicht nur erfolgreiche Runs testen

Der Pilot sollte bewusst Fehler provozieren.

Zum Beispiel:

• fehlgeschlagener dbt-Test

• ungültiges Modell

• fehlende Berechtigung

• nicht erreichbare Quelle

• Pipeline-Abbruch

• erneute Ausführung

Gerade diese Fälle entscheiden darüber, ob ein Werkzeug betrieblich funktioniert.

6. Preview-Gate vor Produktion einziehen

Vor einem produktiven Einsatz sollte dokumentiert sein:

• welche Preview-Funktionen verwendet werden

• welche Einschränkungen akzeptiert werden

• wie Änderungen beobachtet werden

• welcher alternative Ausführungsweg zur Verfügung steht

• wer Runtime und Adapter-Versionen überwacht

Damit wird aus einem technischen Test eine belastbare Architekturentscheidung.

---

Fazit: dbt wird zu einem echten Fabric-Baustein

Native dbt Jobs verändern die Rolle von dbt in Microsoft Fabric deutlich. dbt muss nicht mehr zwangsläufig als externe Transformationsschicht neben Fabric betrieben werden. Warehouse-Workloads können direkt über den Fabric-Warehouse-Adapter ausgeführt werden, und mit dem Lakehouse-Adapter sind inzwischen auch Delta-zentrierte dbt-Architekturen innerhalb von OneLake möglich. Gleichzeitig sollte die neue Integration nicht dazu führen, jeden Transformationsweg durch dbt zu ersetzen.

Der größte Nutzen entsteht dort, wo dbt eine klar definierte Verantwortung für modellbasierte Transformation, Tests und Abhängigkeiten erhält – und Fabric Storage, Compute, Orchestrierung, Governance und Consumption darum herum organisiert.

Für Warehouse-zentrierte Analytics-Teams kann das ein sehr natürlicher Fit sein. Für Lakehouse-first-Architekturen eröffnet dbt-fabricspark eine neue Alternative. Und für Organisationen mit einem etablierten externen dbt-Lifecycle kann die Fabric-Runtime eine Option sein, ohne dass deshalb automatisch die gesamte bisherige Toolchain abgelöst werden muss.

Die Preview-Grenze bleibt dabei entscheidend.

Wer dbt Jobs heute bewertet, sollte deshalb weniger fragen, ob die Demo funktioniert – sondern ob Architektur, Betrieb und Exit-Pfad für den eigenen Workload funktionieren.

---

Nächste Schritte

Du planst eine Fabric-Architektur und fragst dich, ob Transformationen besser mit dbt, Notebook, Dataflow oder direkt im Warehouse umgesetzt werden sollten?

Dann lohnt sich eine Architekturbetrachtung entlang eines konkreten Datenprodukts. Dabei lassen sich Storage, Transformationsengine, Orchestrierung, Deployment und BI-Serving gemeinsam betrachten – statt die Werkzeuge isoliert voneinander auszuwählen.

So wird aus „Wir möchten dbt einsetzen“ eine belastbare Entscheidung darüber, wo dbt in der Fabric-Plattform tatsächlich Mehrwert schafft.

---

Häufige Fragen zu dbt Jobs in Microsoft Fabric

Unterstützt Microsoft Fabric dbt nativ?

Ja. Microsoft Fabric bietet native dbt Jobs als Preview-Funktion. Fabric stellt eine verwaltete Runtime bereit und unterstützt unter anderem Ausführung, Scheduling, Monitoring und die Einbindung von dbt Jobs in Fabric Data Pipelines.

Funktioniert dbt sowohl mit Fabric Warehouse als auch mit Lakehouse?

Ja. Für Fabric Data Warehouse steht der Warehouse-Adapter zur Verfügung. Für Lakehouse-Workloads kann dbt-fabricspark verwendet werden. Dabei werden dbt-Modelle über Spark SQL ausgeführt und als Delta-Tabellen in OneLake geschrieben.

Kann ein dbt Job Teil einer Fabric Data Pipeline sein?

Ja. Fabric stellt eine eigene dbt-Job-Aktivität bereit. Dadurch kann ein dbt Job mit Ingestion, weiteren Transformationen, Validierungen, Benachrichtigungen und nachgelagerten Aktivitäten in einer gemeinsamen Pipeline orchestriert werden.

Ersetzt ein Fabric dbt Job dbt Cloud oder dbt Core?

Nicht grundsätzlich. Fabric verwendet dbt Core innerhalb seiner verwalteten Runtime und bietet einen Fabric-integrierten Betriebsweg. Ein externer dbt-Betrieb kann weiterhin sinnvoll sein, wenn beispielsweise plattformübergreifende Projekte, bestehende CI/CD-Prozesse oder ein von Fabric unabhängiger dbt-Lifecycle benötigt werden.

Sollte man dbt Jobs in Fabric bereits produktiv einsetzen?

Das hängt von den Anforderungen der Organisation und des jeweiligen Workloads ab. Die Funktion befindet sich weiterhin in Preview. Vor einem produktiven Einsatz sollten deshalb technische Einschränkungen, Betriebsanforderungen, Support-Vorgaben, Runtime-Verhalten und ein möglicher alternativer Ausführungsweg geprüft werden.

Wann sollte ich statt dbt ein Fabric Notebook verwenden?

Ein Notebook ist in der Regel naheliegender, wenn Python, komplexe Spark-Verarbeitung, Data Science, Machine Learning oder umfangreiche Datei- und Semi-Structured-Verarbeitung benötigt werden. dbt eignet sich besonders für modellbasierte Transformationen, bei denen SQL beziehungsweise Spark SQL, Modellabhängigkeiten und Tests im Mittelpunkt stehen.