Databricks Asset Bundles

Databricks Asset Bundles (kurz DABs, offiziell seit 2025 auch „Declarative Automation Bundles") sind ein Paket-Format für Databricks-Projekte: eine Handvoll YAML-Dateien (menschenlesbare Textdateien für Konfiguration), die beschreiben, welche automatisierten Auswertungen (Jobs), Datenverarbeitungs-Strecken (Pipelines) und Machine-Learning-Modelle in einer Databricks-Arbeitsumgebung (Workspace) laufen sollen. Ein einziges Kommandozeilen-Werkzeug rollt dieses Paket dann versioniert in Test-, Vorschau- und Produktionsumgebungen aus.

Was sind Databricks Asset Bundles?

Ein Asset Bundle ist technisch ein Ordner mit einer Hauptdatei databricks.yml, vergleichbar mit einer Stückliste, die auflistet, welche Bestandteile ein Databricks-Projekt hat und wie sie zusammengehören. Der Ansatz heißt „Infrastructure-as-Code" (Infrastruktur als Programm-Code): Die Beschreibung liegt in einem Git-Repository (einem Ablage- und Historien-System für Textdateien, verbreiteter Standard in der Software-Entwicklung) und ist damit prüfbar, testbar und rücksetzbar wie Anwendungscode. Verfügbar ist das Format seit 2023 mit der offiziellen Freigabe der Databricks-Kommandozeile (CLI), seit 2025 firmiert es offiziell als „Declarative Automation Bundle"; der ältere Name Databricks Asset Bundles bleibt in der Kommandozeile (databricks bundle …) und in der Community gebräuchlich.

Vier Konfigurations-Bereiche bilden die Struktur eines Bundles. Der bundle-Block trägt Namen und optionale Git-Metadaten. Der include-Block lädt weitere YAML-Dateien per Glob-Pattern, damit sich Ressourcen auf mehrere Dateien und Verzeichnisse verteilen lassen. Der variables-Block deklariert typisierte Konfigurationswerte mit Standard, Beschreibung und Target-Overrides. Der targets-Block beschreibt die Stage-Profile (üblicherweise Dev, Stage, Prod) mit Workspace-Host, Run-As-Identität, Deployment-Mode und variablen-spezifischen Overrides. Der resources-Block deklariert die eigentlichen Workspace-Objekte und orientiert sich direkt an den zugehörigen Databricks-REST-APIs.

Über einen einzigen resources-Baum lassen sich Lakeflow-Jobs, Lakeflow Declarative Pipelines, registrierte Modelle, Model-Serving-Endpoints, Volumes, Schemas, Dashboards und Databricks Apps beschreiben. Deployment, Validierung und Ausführung laufen über dieselben CLI-Kommandos (databricks bundle validate, bundle deploy, bundle run), lokal wie in einer CI/CD-Pipeline. Bundles arbeiten dabei stets innerhalb eines konkreten Workspaces: sie deployen Objekte in einen bereits existierenden Workspace, ersetzen aber nicht die Plattform-Ebene darunter (Accounts, Metastores, Netzwerke, IAM, Cluster Policies).

Abgrenzung zu dbx, Terraform und dbt

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

Die häufigste Verwechslung betrifft Terraform. Wer den Terraform Databricks Provider einsetzt, definiert damit die Plattform: welche Workspaces existieren, welcher Metastore hängt daran, welche Cluster Policies gelten. Ein Bundle setzt darauf auf und beschreibt, welche Jobs, Pipelines und Modelle innerhalb eines Workspaces existieren und wie sie zwischen Umgebungen wandern. Ein produktives Setup nutzt beide Werkzeuge nebeneinander, mit klarem Schnitt an der Workspace-Grenze.

Beispiel: Bundle für eine nächtliche Ingestion-Pipeline

Ein Data-Engineering-Team versioniert eine Lakeflow-Job-Definition als Bundle. Die Root-Datei 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, stage und prod mit den jeweiligen Workspace-Hosts und einem Service Principal.

bundle:
  name: nightly_ingest

include:
  - resources/jobs/*.yml

variables:
  catalog:
    description: "Ziel-Katalog fuer die Ingestion"
    default: "dev_ingest"

targets:
  dev:
    mode: development
    workspace:
      host: https://adb-dev.azuredatabricks.net
  prod:
    mode: production
    workspace:
      host: https://adb-prod.azuredatabricks.net
    run_as:
      service_principal_name: sp-ingest-prod
    variables:
      catalog: prod_ingest

In einer GitHub-Actions-Pipeline wird beim Merge auf main das Kommando databricks bundle deploy --target prod ausgeführt. Derselbe Job läuft anschließend im Produktions-Workspace mit dem Katalog prod_ingest und dem Service Principal sp-ingest-prod, ohne dass für die Promotion ein separates Repository oder ein zweiter Job-Definitions-Weg nötig wäre. Der Deployment-Mode production aktiviert die Schedules automatisch und legt das Bundle unter dem gemeinsamen /Shared/-Pfad im Workspace ab.