Entwicklung von Analytics-Projekten mit Databricks Asset Bundles und IDE-Erweiterungen

Wenn Databricks in Unternehmen im Rahmen von Proof of Concepts verprobt oder von kleinen Teams neu eingeführt wird, erfolgt die Arbeit meist pragmatisch: Code wird direkt in Notebooks geschrieben und Jobs und Pipelines werden manuell über die Benutzeroberfläche erstellt und ausgeführt. Das ermöglicht schnelle Ergebnisse und unkomplizierte Tests – ideal für erste Anwendungsfälle oder das Validieren von Ideen mit begrenztem Setup-Aufwand.

Für die Entwicklung und den Betrieb unternehmenskritischer Analytics-Projekte, an denen mehrere Personen mitwirken und die stabil über verschiedene Umgebungen hinweg laufen müssen, reicht dieser Ansatz jedoch nicht aus. Es braucht ein strukturiertes, versionierbares und nachvollziehbares Deployment – häufig umgesetzt mit Infrastructure-as-Code, beispielsweise mit Terraform. Das schafft Verlässlichkeit und Nachvollziehbarkeit, sowohl im Entwicklungsteam als auch im Betrieb.

In der Praxis entstehen damit schnell neue Herausforderungen: Die Verwaltung mehrerer Umgebungen bringt redundante Konfiguration oder komplexe Variablensteuerung mit sich, hohe Anforderungen müssen mit Workarounds oder zusätzlichen Skripten gelöst werden und der Entwicklungsworkflow wird stark verlangsamt, da Code-Änderungen über CI/CD in den Databricks Workspace gepusht werden müssen.

Databricks Asset Bundles (DAB) und die dazugehörige VS Code-Erweiterung setzen genau an diesem Punkt an. Sie bringen die Infrastrukturdefinition näher an den Code und ermöglichen es, Jobs, Pipelines, Dashboards, Zugriffsrechte und Compute-Ressourcen deklarativ zu verwalten, zu validieren und zu deployen – direkt aus der IDE heraus, versionskontrolliert und über Umgebungen hinweg konsistent.

Im folgenden Blogpost gebe ich einen Überblick über Funktionsumfang und Entwicklungsworkflow bei der Benutzung dieser Tools.

Databricks Asset Bundles (DAB) sind ein deklaratives Framework, um alle relevanten Artefakte eines Databricks-Projekts – von Jobs über Pipelines bis hin zu Dashboards – in einer einzigen, versionierbaren Projektstruktur abzubilden.

Sämtliche Ressourcen werden dabei über Konfigurationsdateien beschrieben. Dieses Konzept geht deutlich über klassische Job-Definitionen oder isolierte Notebook-Skripte hinaus: Mit DAB können auch Compute-Ressourcen spezifiziert und automatisch provisioniert werden. Damit lassen sich Entwicklungs- und Produktionsumgebungen präzise und reproduzierbar aufbauen.

DAB wendet damit das Prinzip von Infrastructure-as-Code (IaC) auf das Databricks-Ökosystem an und sorgt so dafür, dass alle Bestandteile des Data-Projekts – inklusive Berechtigungen, Compute, Pipelines und Dashboards – konsistent und automatisiert verwaltet werden können.

Neben dem klassischen CI/CD-Deployment bietet DAB zudem die Möglichkeit, Bundles direkt aus der Entwicklungsumgebung (z. B. VS Code) zu validieren und zu deployen. Dadurch kann man Änderungen schon in einer frühen Entwicklungsphase testen, ohne die vollständige Pipeline einer CI/CD-Strecke durchlaufen zu müssen. Gerade beim iterativen Entwickeln und Troubleshooting reduziert das die Feedback-Zeit erheblich.

Um die Möglichkeiten von Databricks Asset Bundles konkret zu illustrieren, möchte ich hier ein beispielhaftes Projektsetup vorstellen. Dieses verarbeitet Bestellungsdaten in einem klassischen Bronze-Silver-Gold-Modell und verwaltet darüber hinaus Berechtigungen sowie eine einfache Volumes-Definition. Die Volume dient in diesem Beispiel ausschließlich der Einfachheit halber als Quelle für Rohdaten – im produktiven Betrieb würde die Anbindung typischerweise über externe Datenquellen wie Cloud Storage, Datenbanken oder Streaming-Endpoints erfolgen.

Die Dateien sind wie folgt gegliedert:

Damit ist die Business-Logik (DLT-Pipeline) klar von den Ressourcen-Definitionen (Pipelines, Schemata und Volumes) und der zentralen Projektkonfiguration getrennt.

Die Datei databricks.yml bildet den Einstiegspunkt. Sie definiert das Bundle, inkludiert die übrigen YAML-Definitionen und legt die Zielumgebungen fest.

Damit werden alle Ressourcen, die in den untergeordneten Dateien definiert sind, gemeinsam verwaltet und in die angegebene Entwicklungsumgebung deployt.

In dieser Datei werden dedizierte Schemas (Bronze, Silver, Gold) definiert, jeweils mit eigenem Namen und Katalog. Zusätzlich wird der Nutzergruppe SALES-ANALYSTS-GROUP explizit Zugriff auf das Gold-Schema gewährt.

Auf diese Weise können Governance- und Berechtigungszuweisungen transparent und versioniert abgebildet werden.

Die DLT-Pipeline wird hier zentral beschrieben. Die Schemanamen werden hierbei als Konfigurationsparameter übergeben, sodass dieselbe Pipeline flexibel Bronze, Silver und Gold ansteuern kann.

Damit kann im Notebook (s.u.) zur Laufzeit dynamisch entschieden werden, in welche Schemata geschrieben wird. 

Der Job dient dazu, die Pipeline zu starten. Er nutzt dabei direkt die Pipeline-ID aus den zuvor definierten Ressourcen. In einem Produktivszenario werden häufig mehrere Tasks sequentiell oder parallel in einem Job ausgeführt und weitere Job-Konfigurationen, wie beispielsweise E-Mail-Benachrichtigungen oder die regelmäßige Ausführung des Jobs zu einer bestimmten Uhrzeit sind typisch.

In diesem Python-Notebook werden Daten aus einer CSV-Datei ins Bronze-Layer geladen, im Silver-Layer validiert abgelegt und anschließend zu Analysezwecken für das Gold-Layer aggregiert. Anstelle einer CSV-Datei würden die Daten in einem Produktivszenario üblicherweise aus einer externen Quelle eingelesen.

Das gezeigte Beispielprojekt lässt sich problemlos erweitern, etwa durch die Integration von Dashboards. Diese werden typischerweise zunächst im Databricks SQL Editor entwickelt und in der UI zusammengestellt. Nach der initialen Entwicklung in der Weboberfläche können sie über CLI oder API in das Bundle überführt und dort als Ressourcen definiert, versioniert und damit einfach in weitere Umgebungen deployt werden.

Ein weiterer sinnvoller Ausbau betrifft die Verwendung von Service Principals als ausführende Identität für Jobs oder Pipelines. Über die run_as-Konfiguration kann im Bundle festgelegt werden, dass ein Job nicht unter dem Benutzerkonto der Entwickler*innen, sondern unter einem dedizierten technischen Benutzer läuft. Das verbessert nicht nur Auditierbarkeit und Zugriffssteuerung, sondern ermöglicht auch konsistentes Verhalten über verschiedene Umgebungen hinweg – ein klarer Vorteil in regulierten oder arbeitsteiligen Projekten.

Ressourcen wie der Service Principal selbst, Nutzergruppen, der Databricks-Workspace an sich oder übergeordnete Cloud-Infrastruktur (z. B. Storage-Komponenten) werden in der Praxis häufig weiterhin mit anderen IaC-Tools wie Terraform verwaltet. Diese Infrastrukturkomponenten liegen in der Regel in einem separaten Repository, getrennt vom eigentlichen Datenprojekt. Die Trennung hat sich bewährt, da sich Lebenszyklen und Verantwortlichkeiten klar unterscheiden: Während Asset Bundles typischerweise von Data Engineers innerhalb einzelner Projekte gepflegt werden, wird die Plattformkonfiguration (z. B. Workspace Setup, Bereitstellung von Service Principals oder Rechtemanagement auf Organisationsebene) zentral und teamübergreifend verwaltet.

Um die Entwicklung von Projekten mit Databricks Asset Bundles möglichst effizient zu gestalten, empfiehlt es sich wie häufig, die Möglichkeiten der lokalen IDE auszureizen: Die offizielle Databricks VS Code Extension baut auf der Databricks CLI auf und bietet damit eine enge und intuitive Integration von lokalem Code und der Databricks-Plattform. 

Zu den wichtigsten Features gehört die Unterstützung der databricks.yml-Struktur: Die Erweiterung bietet Syntax-Highlighting, Autovervollständigung und statische Validierung für YAML-Definitionen. Fehler in der Bundle-Konfiguration oder unvollständige Ressourcenangaben werden so frühzeitig erkannt – noch bevor überhaupt ein Deployment angestoßen wird.

Ebenso unterstützt die Erweiterung eine einfache Authentifizierung über OAuth oder die Databricks CLI. Nach einmaliger Anmeldung lässt sich direkt aus VS Code heraus ein Bundle validieren oder in die Entwicklungsumgebung deployen. Das beschleunigt gerade in frühen Projektphasen die Iteration: Änderungen am Code und an der Ressourcenbeschreibung können lokal getestet werden, ohne jedes Mal den Weg über eine vollständige CI/CD-Pipeline gehen zu müssen.

Auch die Integration mit Log-Ausgaben laufender Jobs und Pipelines ist nützlich, etwa um direkt in der IDE nachvollziehen zu können, ob ein DLT-Lauf erfolgreich war oder wo genau ein Fehler auftritt. Für Entwickler*innen, die wiederverwendbare Pipelines und produktionsnahe Infrastruktur aufbauen, bietet die Integration einen durchgängig effizienten Workflow.

Allerdings stößt die Erweiterung dort an Grenzen, wo andere Rollen – insbesondere Data Analysts oder Data Scientists – typischerweise arbeiten: Interaktive Abfragen von Datenbanken, Ad-hoc-SQL-Analysen oder die Arbeit mit Visual Queries sind mit der VS Code-Erweiterung nicht möglich. Auch das direkte Browsen von Tabellen, das schnelle Schreiben und Testen von SQL-Statements oder das Erstellen von Dashboards wird nicht unterstützt.

Wer diese Aufgaben ausführen möchte, benötigt ergänzende Erweiterungen wie SQLTools oder arbeitet weiterhin direkt in der Web-Oberfläche von Databricks Studio.

In Summe eignet sich die Erweiterung hervorragend für produktionsorientierte Softwareentwicklung auf Databricks, ersetzt aber nicht vollständig die Arbeitsumgebung für analytisch geprägte Rollen oder UI-zentrierte Workflows.

Mit Databricks Asset Bundles steht ein leistungsfähiges Framework zur Verfügung, das die Entwicklung und den Betrieb von Analytics-Projekten deutlich systematisiert. Durch die deklarative Beschreibung aller zentralen Ressourcen – von Pipelines über Jobs und Zugriffsrechte bis hin zu Dashboards – wird die gesamte Projektarchitektur transparenter, auditierbar und besser wartbar.

DAB fördert die Einhaltung von Best Practices, insbesondere durch klar definierte Projektstrukturen, standardisierte Deployment-Prozesse und eine klare Trennung von Code und Konfiguration. Projekte werden reproduzierbar, besser testbar und lassen sich über verschiedene Umgebungen hinweg konsistent betreiben. Der Entwicklungsworkflow wird zusätzlich durch die VS Code-Erweiterung unterstützt, die Validierung, Deployment und Monitoring direkt aus der IDE ermöglicht und so die tägliche Arbeit deutlich erleichtert.

Zu bedenken ist, dass sich nicht alle Ressourcen und Anwendungsfälle vollständig mit DAB abbilden lassen. Für bestimmte Aufgaben – etwa die Verwaltung externer Cloud-Komponenten, wie private Netzwerke, Storage Buckets oder organisationsweite Berechtigungen – sind weiterhin ergänzende Tools wie Terraform erforderlich. Darüber hinaus resultiert der Effizienzgewinn durch die Nutzung von DAB aus der engen Verzahnung mit Databricks und geht damit mit einer noch stärkeren Plattformbindung einher. Dies ist angesichts einer in der Regel ohnehin langfristigen Entscheidung für eine Plattform wie Databricks in vielen Unternehmen als akzeptabel einzustufen.

In Summe ermöglicht der Einsatz von DAB einen konsequenten Schritt hin zu einer professionellen, nachhaltig wartbaren Analytics-Infrastruktur.