Asset Bundles (DABs): Definition, Aufbau, Abgrenzung

Databricks Asset Bundles, kurz „Asset Bundles" oder „DABs", sind YAML-Dateien, die beschreiben, welche Notebooks, Jobs, Pipelines, Modelle und Dashboards in einen Databricks-Workspace gehören und wie sie zwischen Entwicklungs-, Test- und Produktionsumgebung wandern. Mit einem Bundle wird die Konfiguration eines Databricks-Projekts als Code im Git-Repository verwaltet und über das Kommandozeilen-Werkzeug Databricks CLI (Command Line Interface) reproduzierbar in einen Workspace ausgerollt.

Was sind Databricks Asset Bundles?

Databricks Asset Bundles sind das offizielle Deployment-Format, um Databricks-Projekte reproduzierbar zwischen mehreren Umgebungen auszurollen. Ein Bundle ist ein Ordner mit einer Root-Datei namens databricks.yml, optionalen weiteren YAML-Dateien für einzelne Ressourcen und dem eigentlichen Projektcode (Notebooks, Python-Skripte, SQL-Files). Die YAML-Dateien tragen die Konfiguration; der Code liegt daneben im selben Verzeichnis. Alles zusammen wird in einem Git-Repository verwaltet, sodass Änderungen wie normaler Anwendungscode über Pull Requests, Code-Reviews und Continuous-Integration-Pipelines (CI/CD) laufen statt über manuelle Klicks in der Databricks-Oberfläche.

Ausgerollt wird ein Bundle über die Databricks CLI, das Kommandozeilen-Werkzeug für Databricks. databricks bundle validate prüft die YAML-Konfiguration auf Syntax und Referenzen, databricks bundle deploy überträgt die Ressourcen in einen Workspace, databricks bundle run startet einen konfigurierten Job oder eine Pipeline. Die CLI ruft im Hintergrund die Databricks REST API auf; das YAML-Format ist eine deklarative Ebene darüber, die diese API-Aufrufe zu einem konsistenten Deployment-Paket zusammenfasst.

Databricks hat Asset Bundles 2023 als generell verfügbares Feature der Databricks CLI eingeführt, um die vorherige Community-CLI dbx abzulösen und ein einheitliches Format für Job-, Pipeline- und Modell-Deployments zu etablieren. 2025 hat Databricks das Format offiziell in „Declarative Automation Bundles" umbenannt, um den deklarativen Charakter zu betonen; die bisherigen Bezeichnungen Databricks Asset Bundles und die Kurzform DABs bleiben in Dokumentation, CLI-Kommandos (databricks bundle …) und Community-Sprache aktiv.

Ein Bundle bündelt fünf Konfigurations-Bereiche unter einer gemeinsamen Wurzel: bundle mit Namen und Git-Metadaten, include zum Nachladen weiterer YAML-Dateien per Glob-Pattern, variables für typisierte Konfigurationswerte, targets für die Umgebungs-Overlays (üblicherweise dev, staging, prod) und resources für die eigentlichen Workspace-Objekte. Der resources-Block deckt Lakeflow Jobs, Lakeflow Declarative Pipelines, in MLflow registrierte Modelle, Model-Serving-Endpoints, Unity-Catalog-Volumes und -Schemas, Dashboards und Databricks Apps ab. Über targets bekommt jede Umgebung einen eigenen Workspace-Host, eine eigene Ausführungs-Identität (persönlicher Nutzer im Dev-Target, Service Principal in Staging und Prod) und eigene Variablenwerte, sodass dieselbe Bundle-Definition unverändert in allen drei Stages läuft.

Abgrenzung zu Terraform, dbx, REST API und Databricks Repos

Der Begriff „Deployment für Databricks" wird für Werkzeuge auf sehr unterschiedlichen Ebenen verwendet. Die folgende Tabelle grenzt die Nachbarn ab.

Werkzeug	Ebene	Abgrenzung zu Asset Bundles
Terraform Databricks Provider	Plattform-Infrastruktur	Verwaltet Workspaces, Metastores, Cloud-Accounts, Identitäten und Cluster Policies als Infrastructure-as-Code. Asset Bundles arbeiten eine Ebene darüber und verwalten die Inhalte eines bereits existierenden Workspaces. Beide Werkzeuge koexistieren mit klarem Schnitt an der Workspace-Grenze.
dbx (Databricks Labs)	Vorgänger für Job-Deployments	Community-CLI für Job-Definitionen als JSON, 2023 offiziell als „legacy" markiert und zugunsten von Asset Bundles abgekündigt. Bundles decken denselben Anwendungsfall deklarativ und breiter ab.
Databricks REST API	Unteres Interface	Die zugrundeliegende HTTP-Schnittstelle für alle Workspace-Objekte. Bundles rufen im Hintergrund dieselbe API auf, bieten aber eine deklarative YAML-Ebene darüber statt manueller JSON-Aufrufe. Für ad-hoc-Skripting bleibt die REST API sinnvoll.
Databricks Repos	Code-Synchronisation	Git-Integration im Workspace, die Notebooks und Code aktuell hält. Repos definieren keine Job- oder Pipeline-Ressourcen; Bundles beschreiben, wie aus dem synchronisierten Code eine ausführbare Ressource wird.

Die häufigste Verwechslung betrifft Terraform. Wer den Terraform Databricks Provider einsetzt, verwaltet damit die Plattform-Infrastruktur: welche Workspaces existieren, welcher Unity-Catalog-Metastore hängt daran, welche IAM-Rollen und Cluster Policies gelten. Ein Bundle setzt darauf auf und beschreibt, welche Jobs, Pipelines und Modelle innerhalb eines Workspaces existieren und wie sie zwischen Dev, Staging und Prod wandern. Ein produktives Setup nutzt beide Werkzeuge nebeneinander, mit klarem Schnitt an der Workspace-Grenze: alles außerhalb des Workspaces liegt bei Terraform, alles darin bei Asset Bundles.

Databricks Repos werden häufig mit Bundles verwechselt, weil beide Git-nah wirken. Repos halten das Verzeichnis im Workspace mit einem Git-Branch synchron; sie sagen nichts darüber aus, welcher Job welches Notebook aus welchem Pfad ausführt. Bundles definieren genau diese Verknüpfung zwischen Code und Ressource, plus Trigger, Compute-Profil, Berechtigungen und Umgebungs-Overlay.

Beispiel: Asset Bundle für einen nächtlichen Ingestion-Job

Ein Datenteam versioniert einen nächtlichen Ingestion-Job als Asset Bundle. Das Repository enthält eine databricks.yml im Root, ein Verzeichnis resources/jobs/ mit einzelnen Job-Definitionen und ein Verzeichnis src/ mit Notebooks und Python-Modulen. Die databricks.yml deklariert den Bundle-Namen, lädt Ressourcen aus resources/jobs/*.yml und definiert drei Targets: dev mit dem Entwicklungs-Workspace und dem eigenen Nutzer als Run-As-Identität, staging und prod mit den jeweiligen Workspace-Hosts und einem Service Principal.

yaml

bundle:
  name: nightly_ingest

include:
  - resources/jobs/*.yml

variables:
  catalog:
    description: Unity-Catalog-Ziel je Umgebung
    default: dev_bronze

targets:
  dev:
    default: true
    workspace:
      host: https://adb-1234.azuredatabricks.net
    run_as:
      user_name: alex@example.com
  prod:
    workspace:
      host: https://adb-5678.azuredatabricks.net
    run_as:
      service_principal_name: sp-prod-deployer
    variables:
      catalog: prod_bronze

Ein GitHub-Actions-Workflow ruft databricks bundle validate in jedem Pull Request auf, databricks bundle deploy --target staging beim Merge in main und nach manueller Freigabe databricks bundle deploy --target prod. Eine Änderung an der Job-Konfiguration ist damit ein Code-Diff im Pull Request, kein UI-Klick im Produktions-Workspace; ein Rollback ist ein Git-Revert plus erneutes Deploy.