dbt: Was das Data Build Tool aus­zeich­net – und was es nicht ist

dbt (Data Build Tool) ist ein Open-Source-Tool, das Unter­neh­men dabei unter­stützt, Roh­da­ten effi­zi­ent und struk­tu­riert in hoch­wer­tige Daten­pro­dukte zu trans­for­mie­ren. Dabei setzt dbt auf Daten, die sich bereits im Data Ware­house befin­den. Somit ist dbt klar auf den Trans­for­ma­ti­ons­teil (T) im ETL/ELT-Pro­zess spezialisiert.

In dbt wer­den soge­nannte Models als SQL-Dateien ent­wi­ckelt, die jeweils eine klar beschrie­bene Trans­for­ma­tion ent­hal­ten. Diese SQL-Trans­for­ma­tio­nen wer­den von dbt orches­triert und per Push-Down-Logik direkt im Data Ware­house aus­ge­führt, wodurch des­sen Rechen­leis­tung opti­mal genutzt wird.

dbt ist bewusst fokus­siert – und das ist eine Stärke:

Was dbt kann:

• Trans­for­ma­tio­nen im Data Ware­house struk­tu­rie­ren und versionieren
• Abhän­gig­kei­ten (Lineage) auto­ma­tisch ableiten
• Doku­men­ta­tion und Meta­da­ten (Arti­facts) erzeugen
• Inte­griert Best Prac­ti­ces aus Soft­ware-Engi­nee­ring in die Ent­wick­lung von Daten­mo­del­len z. B. Git, CI/CD, Modu­la­ri­sie­rung oder Tests

Was dbt kann nicht (bzw. nicht als Kernfunktion):

• Ingestion/Datenanbindung (APIs, Files, Strea­ming) in das Ware­house übernehmen
• als Uni­ver­sal-Orchestra­tor für belie­bige tech­ni­sche Tasks die­nen (dafür nutzt man meist Air­flow, Dags­ter etc.)

Statt­des­sen lie­fert dbt ein sta­bi­les Engi­nee­ring- und Meta­da­ten-Fun­da­ment für Trans­for­ma­tio­nen und ana­ly­ti­sche Daten­pro­dukte. Die Ent­wick­lung mit dbt kann auf unter­schied­li­che Weise erfol­gen, wobei zwi­schen Engine und Platt­form zu unter­schei­den ist. Es gibt dbt Core (das Open-Source-Frame­work) und dbt Cloud (die Mana­ged Platt­form). dbt Cloud nutzt intern zuneh­mend die neue, in Rust geschrie­bene Fusion Engine für deut­lich schnel­lere Kompilierungszeiten.

Ein Screen­shot der Cloud-UI (Abbil­dung 1). Auf der lin­ken Seite wer­den die vor­ge­nom­me­nen Ände­run­gen ange­zeigt, dar­un­ter befin­det sich der Datei-Explo­rer. Rechts davon sind der Datei-Edi­tor sowie die Lineage-Ansicht ange­ord­net. Am unte­ren Rand der Ober­flä­che ist die Kom­man­do­zeile zu sehen.

SQL-first: Trans­for­ma­tion dort, wo die Daten liegen

dbt setzt auf einen SQL-first-Ansatz, bei dem Trans­for­ma­tio­nen direkt im Data Ware­house in sau­be­rem SQL umge­setzt wer­den. Durch die Kom­bi­na­tion mit Makros kön­nen Models modu­lar auf­ge­baut, wie­der­ver­wend­bar und gut struk­tu­riert gestal­tet wer­den. dbt sorgt dafür, dass die Models in der rich­ti­gen Abhän­gig­keits­rei­hen­folge aus­ge­führt wer­den, und bie­tet mit Makros, auto­ma­ti­sier­ten Tests und Doku­men­ta­tion eine hohe Wartbarkeit.

Gleich­zei­tig lässt sich der Code über Git ver­wal­ten, inklu­sive Bran­ches, Pull Requests und Reviews, sodass nach­voll­zieh­bar in grö­ße­ren Pro­jek­ten und Teams gear­bei­tet wer­den kann. Mit­hilfe des dbt-build-Befehls kön­nen Models zusam­men mit allen Upstream- oder Down­stream-Abhän­gig­kei­ten aus­ge­führt wer­den. Dadurch wird der Ent­wick­lungs­pro­zess, das Deploy­ment und die Abhän­gig­kei­ten klar geregelt.

Jinja und Makros in dbt

dbt kom­bi­niert SQL mit Jinja-Tem­pla­ting und macht ein Daten­pro­jekt damit zu einer Art Pro­gram­mier­um­ge­bung für SQL. Mit Varia­blen, Bedin­gun­gen, Schlei­fen und wie­der­ver­wend­ba­ren Makros las­sen sich wie­der­keh­rende Auf­ga­ben lösen, ohne dass die fach­li­che Logik in unle­ser­li­che Kon­strukte abdriftet.

Bei­spiel: Dyna­mi­sche Aggre­ga­tion (SQL + Jinja)

Das Bei­spiel (Abbil­dung 2) zeigt, wie mit­hilfe der Jinja-Tem­p­late-Engine ein sta­ti­sches SQL fle­xi­bel gemacht wird. Zunächst wird eine Varia­ble als Liste von Län­der­codes erstellt, gefolgt von einem Sel­ect-State­ment, das ein Model mit dem Namen „fct_sales“ mit­tels ref()-Makro refe­ren­ziert. Die dar­auf­fol­gende Schleife ite­riert über jedes Ele­ment in der Varia­ble „count­ries“ und setzt nach jedem Ele­ment ein Komma, außer nach dem letzten.

Damit kön­nen Ent­wick­ler­teams kon­sis­tente Struk­tu­ren auf­bauen, Stan­dard­lo­gik zen­tral pfle­gen und repe­ti­tive Arbeit redu­zie­ren. Gleich­zei­tig bleibt der Kern wei­ter­hin SQL – trans­pa­rent und gut reviewbar.

Für Debug­ging ist wich­tig: Jinja wird zur Kom­pi­lier­zeit-Zeit aus­ge­führt, bevor das SQL an das Ware­house wei­ter­ge­ge­ben wird. Dadurch kann man das kom­pi­lierte SQL ein­se­hen und ana­ly­sie­ren – gerade bei kom­ple­xer Logik sehr hilfreich.

Makros ber­gen auch das Risiko von Über­abs­trak­tion. Eine gute Faust­re­gel ist: Makros dort ein­set­zen, wo sie Wie­der­ver­wend­bar­keit und Klar­heit erhö­hen – nicht, um ein­fa­che Logik „zu verstecken“.

Kern­kon­zepte und Fea­tures von dbt

dbt ermög­licht es, Daten­pipe­lines klar, nach­voll­zieh­bar und auto­ma­ti­siert zu gestal­ten. Mit Models, Refe­ren­zen, Mate­ria­liza­ti­ons, Tests und Snapshots las­sen sich Abhän­gig­kei­ten, Daten­qua­li­tät und His­to­rie direkt abbil­den – ideal für trans­pa­rente und effi­zi­ente Projekte.

Models, ref()und DAG (Lineage)

In dbt wird mit Models gear­bei­tet, die als SQL-Dateien defi­niert sind. Über {{ ref(‚…‘) }} refe­ren­ziert man andere Models. Dar­aus erstellt dbt auto­ma­tisch einen DAG (Direc­ted Acy­clic Graph) inklu­sive Lineage.

Vor­teile:

• klare Build-Rei­hen­folge und Abhängigkeiten
• bes­sere Über­sicht bei gro­ßen Projekten
• leich­te­res Debugging
• Ände­run­gen sind review- und deploy­bar (z. B. per PR)
• Model- und Column-Level Lineage

Bei­spiel­bild für DAG in der Cloud UI mit Column-Level Lineage (Abbil­dung 3):

Sources & Freshness

Über source() wer­den Roh­da­ten expli­zit als Inputs beschrie­ben. Dadurch wird transparent:

• woher Daten stammen,
• wel­che exter­nen Systeme/Teams ver­ant­wort­lich sind,
• was „Input“ vs. „eigene Trans­for­ma­ti­ons­lo­gik“ ist.

Auf die­ser Basis las­sen sich Fresh­ness-Checks kon­fi­gu­rie­ren (z. B. ob ein täg­li­cher Load ein­ge­trof­fen ist). Das ermög­licht früh­zei­tige War­nun­gen bei Lie­fer- oder Daten­qua­li­täts­pro­ble­men und ver­bes­sert Gover­nance und Ownership.

Mate­ria­liza­ti­ons (view / table / incre­men­tal / ephemeral)

Mate­ria­liza­ti­ons bestim­men, wie dbt ein Model auf der Daten­bank defi­niert ist. Das spielt eine große Rolle für Lauf­zeit und Kosten.

• view: Wird bei jeder Abfrage aus­ge­führt, ideal für Sta­ging oder kleine Models, bei gro­ßen Daten­men­gen langsam
• table: Per­sis­tent, oft schnel­ler bei Abfra­gen, spei­chert Daten dau­er­haft, gut für Reporting-Tabellen
• incre­men­tal: Lädt nur neue/aktualisierte Daten, sehr effi­zi­ent bei gro­ßen Datenmengen
• eph­emeral:  Nicht mate­ria­li­siert, wird als Com­mon Table Expres­sion (CTE) in das Ziel-SQL eingefügt.

Tests und Data Qua­lity als Teil des Deployments

dbt bringt gene­ri­sche Tests wie not_null, uni­que, rela­ti­onships und accepted_values mit. Zusätz­lich kannst du eigene SQL-Tests für fach­li­che Regeln defi­nie­ren. Tests las­sen sich u. a. auf Models, Spal­ten, Sources, Snapshots und Seeds anwenden.

Pro­jekt-Doku­men­ta­tion

dbt kann aus Models, Tests und YAML-Kon­fi­gu­ra­tio­nen auto­ma­tisch eine Pro­jekt-Doku­men­ta­tion erstel­len. Typi­scher­weise ent­ste­hen dabei u. a.:

• manifest.json (Res­sour­cen, Kon­fi­gu­ra­tio­nen, kom­pi­lier­tes SQL, Abhängigkeiten)
• catalog.json (Meta­da­ten aus dem Ware­house: Tabel­len, Spal­ten, Datentypen)

Damit erhält man eine zen­trale, durch­such­bare Über­sicht über das gesamte Projekt.

Snapshots

Mit Snapshots las­sen sich Ände­run­gen über die Zeit erfas­sen. Frü­here Zustände wer­den gespei­chert, sodass du nach­voll­zie­hen kannst, wie sich Werte his­to­risch ver­än­dert haben (z. B. bei Slowly Chan­ging Dimensions).

Effi­zi­enz durch Makros

Makros hel­fen, Pro­jekte kon­sis­tent zu ska­lie­ren: weni­ger Wie­der­ho­lun­gen, weni­ger Inkon­sis­ten­zen, weni­ger Review-Auf­wand. Ein Bei­spiel aus der Pra­xis sind dbt-Packa­ges wie Auto­ma­teDV (Open Source), die Stan­dard­auf­ga­ben im Data-Vault-Umfeld unter­stüt­zen – z. B. Hash Keys, gene­rierte Model-Struk­tu­ren und Regressionstests.

Meta­da­ten: Artifacts

dbt erzeugt bei Runs stan­dar­di­sierte Arti­facts (JSON-Dateien), die den Pro­jekt­zu­stand doku­men­tie­ren: Models, Sources, Tests, Abhän­gig­kei­ten, Lauf­zei­ten etc. Diese Meta­da­ten sind ideal für Lineage-Ana­ly­sen, Moni­to­ring oder auto­ma­ti­sierte Dokumentation.

Wich­tige Artifacts:

• manifest.json – voll­stän­dige Reprä­sen­ta­tion der Pro­jekt­res­sour­cen (Models, Tests, Makros etc.)
• run_results.json – Ergeb­nis­de­tails eines Runs (Lauf­zei­ten, Feh­ler, Status)
• catalog.json – Ware­house-Meta­da­ten nach Aus­füh­rung (Tabel­len, Spal­ten, Datentypen)

Je nach Setup/Features kön­nen wei­tere Arte­fakte hin­zu­kom­men (z. B. rund um Sources/Freshness oder seman­ti­sche Schichten).

dbt im Ver­gleich zu ähn­li­chen Technologien

Im Fol­gen­den wer­den dbt, Matil­lion und Tal­end gegen­über­ge­stellt, um einen gro­ben Über­blick über Stär­ken und Schwer­punkte zu geben. Die Tools ver­fol­gen unter­schied­li­che Phi­lo­so­phien, wer­den in der Pra­xis aber häu­fig im glei­chen Umfeld diskutiert.

Deploy­ment von dbt und unter­stützte Data-Warehouse-Technologien

dbt folgt dem Push­down-Ansatz: SQL läuft im Ziel-Ware­house, und dbt steu­ert Build, Abhän­gig­kei­ten und Meta­da­ten. dbt unter­stützt eine breite Palette moder­ner Warehou­ses, z. B. Snow­flake, Big­Query, Reds­hift, Dat­ab­ricks u. a. Dadurch kön­nen Teams rela­tiv ware­house-unab­hän­gig ent­wi­ckeln und pro­fi­tie­ren gleich­zei­tig von Per­for­mance und Ska­lie­rung der jewei­li­gen Engine. Dabei muss jedoch beach­tet wer­den, dass der jewei­lige Ware­house-Dia­lekt ein­ge­hal­ten wird, da das SQL an das Ware­house wei­ter­ge­reicht wird.

Ein­schub: dbt + Data Vault – warum das gut zusam­men­pas­sen kann

Data Vault trennt typi­scher­weise in Raw Vault (Hubs, Links, Satel­li­tes), Busi­ness Vault (Regeln, Har­mo­ni­sie­rung) und Data Marts. dbt passt gut dazu, weil Data-Vault-Struk­tu­ren schnell kom­plex wer­den und ohne gute Too­ling-Unter­stüt­zung schwer beherrsch­bar sind.

Hier spie­len dbt-Stär­ken beson­ders aus:

• DAG/Lineage macht Abhän­gig­kei­ten und Build-Rei­hen­fol­gen sichtbar
• Packa­ges (z. B. Auto­ma­teDV) redu­zie­ren Standardarbeit
• Tests sichern Inte­gri­tät sys­te­ma­tisch ab
• Git-basierte Ver­sio­nie­rung unter­stützt große Teams mit nach­voll­zieh­ba­ren Änderungen

Fazit

dbt fokus­siert sich auf Daten-Trans­for­ma­tio­nen im Ziel­sys­tem. Die größ­ten Stär­ken lie­gen im SQL-first-Ansatz, der engen Ver­zah­nung mit Soft­ware-Engi­nee­ring-Prin­zi­pien (Git, CI/CD, Tests) und der trans­pa­ren­ten Abbil­dung von Abhän­gig­kei­ten über den DAG. Gerade in moder­nen Cloud-Ware­house-Archi­tek­tu­ren und bei kom­ple­xen Model­lie­rungs­an­sät­zen wie Data Vault ent­fal­tet dbt sein Poten­zial durch Gover­nance, Wart­bar­keit und Reviewbarkeit.

Auf­ga­ben wie API-Anbin­dun­gen, File-Hand­ling, Strea­ming oder das Steu­ern belie­bi­ger tech­ni­scher Work­flows gehö­ren nicht zum Kern von dbt und wer­den typi­scher­weise durch zusätz­li­che Tools (klas­si­sche ETL/ELT-Platt­for­men oder Orchestra­to­ren wie z. B. Air­flow) ergänzt. Teams ohne solide SQL-Kennt­nisse oder ohne eta­blier­ten Git-/De­ploy­ment-Pro­zess kön­nen dbt als weni­ger attrak­tiv emp­fin­den. Auch ein über­mä­ßi­ger Makro-Ein­satz kann zu unnö­ti­ger Abs­trak­tion führen.

Unterm Strich: dbt ist kein Ersatz für eine voll­stän­dige ETL-Platt­form, son­dern eine spe­zia­li­sierte Lösung für qua­li­ta­tiv hoch­wer­tige Trans­for­ma­tio­nen und ana­ly­ti­sche Daten­pro­dukte im Data Warehouse.