Databricks-Architektur: Was vor dem ersten Workspace entschieden werden sollte

Databricks verbindet Datenverarbeitung, Analytics und KI auf einer gemeinsamen Plattform (in der Vendor-Sprache: Data Intelligence Platform). Auf der Plattform liegen vier Workload-Familien: Lakeflow für Ingest, ETL und Streaming; Databricks SQL für das Data Warehouse; Mosaic AI für KI, ML und Model Serving; AI/BI für Dashboards und Genie. Darunter sitzt Unity Catalog als Governance-Schicht für Berechtigungen, Lineage, Audit und Discovery, gefolgt von den offenen Tabellenformaten Delta Lake (Default) und Apache Iceberg (Interop). Strukturentscheidungen (Account, Workspaces, Unity-Catalog-Metastore) und Betriebs-Pillars wie Compute, Netzwerk, Identity und Sicherheit gehören ebenfalls in den Rahmen. Der Cloud-Speicher bleibt bewusst außerhalb der Plattform-Klammer, weil er im eigenen Cloud-Konto liegt.

Delta Lake sorgt dafür, dass Daten im Cloud-Speicher zuverlässig geändert, versioniert und geprüft werden können. Die Daten liegen dabei in einem offenen Tabellenformat im eigenen Cloud-Speicher (ADLS Gen2, S3, GCS) und bringt zuverlässige und konsistente Änderungen an Tabellen, Zugriff auf frühere Tabellenstände (Versionsabfragen über Zeit und Versionsnummer), Prüfung und kontrollierte Weiterentwicklung der Tabellenstruktur sowie Optimierungen wie Z-Order und automatisches Zusammenführen kleiner Dateien. Architektonisch bedeutet das: Dieselben Tabellen können für regelmäßige Datenläufe und laufende Datenströme verwendet werden, Rollbacks sind möglich, und frühere Datenstände lassen sich leichter nachvollziehen und prüfen. Wenn das Lakehouse als Architektur-Layer trägt, gehört Delta Lake als verbindliches Standardformat über alle Stufen. Apache Iceberg wird ergänzend über Unity Catalog und UniForm unterstützt, damit Tabellen auch von Iceberg-Engines außerhalb von Databricks gelesen werden können, relevant für Cross-Engine- und Multi-Vendor-Szenarien.

Wichtiger als die Feature-Liste ist die strukturelle Eigenschaft: Databricks ist nicht nur eine fertige Anwendung, die nach der Aktivierung vollständig betrieben ist. Databricks betreibt die Benutzeroberfläche und zentrale Steuerungsdienste. Ein großer Teil der Daten, Infrastruktur und Netzwerkanbindung liegt jedoch weiterhin im eigenen Cloud-Konto. Diese Aufteilung ist die Grundlage für jede weitere Architektur-Entscheidung. Netzwerk, Berechtigungen und Kosten entscheidet damit das Unternehmen, nicht Databricks. Die Produktdokumentation hilft hier nur begrenzt: Sie richtet sich an Engineering-Teams, die auf der Plattform arbeiten, und setzt die Plattform-Architektur dahinter voraus. Daraus folgt direkt: Die Lizenzierung der Plattform ersetzt keine Architekturentscheidungen. Du triffst Architektur-Entscheidungen, die Databricks dir nicht abnimmt. Diese Entscheidungen bestimmen langfristig Sicherheit, Betriebsaufwand, Kosten und Erweiterbarkeit. Wie diese Aufteilung im Detail trägt, klären wir im Überblick zu Databricks insgesamt.

Über der Control- und Data-Plane-Trennung liegen drei Ebenen mit unterschiedlichen Aufgaben, die häufig nicht klar getrennt werden. Sie sauber zu trennen, ist die Voraussetzung für jedes belastbare Berechtigungs- und Betriebsmodell.

Der Account ist die zentrale Verwaltungsebene. Hier hängt die Identity (Entra ID, Okta, AWS IAM Identity Center) per System for Cross-domain Identity Management (SCIM), hier wird der Unity-Catalog-Metastore aufgesetzt, hier laufen die Workspaces als Ressource. Accountweite Einstellungen werden zentral verwaltet, während die tägliche Arbeit in den Workspaces stattfindet.

Der Workspace ist der Arbeitsbereich für Datenentwicklung und Plattformbetrieb. Dort entstehen Cluster, Jobs und Notebooks. Die Compute-Policies, die hier wirken, sind FinOps-relevant: Sie definieren erlaubte Node-Typen, Auto-Termination-Zeiten und Tags. Ohne klare Compute-Regeln entstehen schnell zu große oder unnötig lange laufende Cluster.

Unity Catalog ist die dritte Ebene. Sie ist heute die zentrale Daten- und Berechtigungsschicht für jede neue Databricks-Plattform und ersetzt schrittweise die früheren, je Workspace getrennten Berechtigungen. Berechtigungen, Lineage, Audit und Daten-Discovery laufen über ein konsistentes Modell, das accountweit und workspaceübergreifend genutzt werden kann. Wie dieser Layer im Detail trägt, klären wir im Überblick zu Unity Catalog.

Die Netzwerkanbindung bestimmt, über welche Wege Nutzer, Compute und Datenquellen miteinander kommunizieren. Standardkonfigurationen verwenden häufig öffentliche Endpunkte und eine weniger stark eingeschränkte ausgehende Verbindung; für sensible oder regulierte Daten häufig nicht ausreichend.

Für produktive und regulierte Umgebungen sollten drei Bereiche geplant werden:

Einbindung des klassischen Compute in ein vom Unternehmen kontrolliertes Netzwerk stellt sicher, dass die Compute-Cluster in einem von dir kontrollierten Netzwerk laufen. Dadurch lassen sich Firewall-Regeln, Routen und erlaubte Verbindungen selbst steuern, entsprechend den bestehenden Cloud- und Sicherheitsstandards. Auf Azure heißt das VNet-Injection mit zwei Subnetzen (Container und Host), auf AWS Customer-managed VPC, auf GCP analoge VPC-Konstruktion.

Private Link führt den Datenverkehr zwischen Workspace, Compute und Control Plane über private Netzwerkpfade statt über das öffentliche Internet. Zwei Richtungen werden getrennt entschieden: Back-End Private Link verbindet die klassischen Compute-Cluster privat mit der Databricks-Control-Plane; Front-End Private Link macht Workspace-UI und APIs nur aus dem eigenen Unternehmensnetz erreichbar. Zusammen sind sie die Grundlage für Workspaces ohne öffentlichen Internet-Pfad.

Secure Cluster Connectivity (SCC) und Egress-Regeln begrenzen, welche externen Systeme und Internetdienste die Workloads erreichen dürfen. Das ist relevant für regulierte Branchen, kritische Datenklassen und Workloads mit besonderen Nachweisanforderungen. Den vollständigen Schichtenaufbau dokumentiert Microsoft Learn in der allgemeinen Architektur-Übersicht zu Azure Databricks.

Die Netzwerk-Entscheidung wird oft zu spät getroffen. Eine spätere Umstellung auf ein kundenseitig kontrolliertes Netzwerk kann einen neuen Workspace und eine Migration erforderlich machen. Wenn Compliance- oder Audit-Anforderungen plausibel sind, sollte die Netzwerkanbindung daher vor dem produktiven Start entschieden werden.

Storage liegt in deinem Cloud-Konto: ADLS Gen2 auf Azure, S3 auf AWS, GCS auf GCP. Drei Bausteine regeln den Zugriff von Databricks auf den Cloud-Speicher.

Storage Credentials legen fest, mit welcher technischen Identität Databricks auf den Speicher zugreift (Azure Managed Identity, AWS IAM Role, GCP Service Account).

External Locations sind benannte Verweise auf Pfade im Cloud-Speicher (z. B. ein bestimmter Container in ADLS Gen2 oder ein S3-Bucket), die in Unity Catalog registriert werden. Erst über diese Registrierung weiß Databricks, welche Speicherpfade es überhaupt verwenden darf, und mit welchem Storage Credential. An ihnen hängen die Berechtigungen, wer aus diesem Pfad lesen oder schreiben darf.

Volumes verwalten Dateien wie Dokumente, Bilder oder Modellartefakte innerhalb des zentralen Berechtigungsmodells (nicht-tabellarische Daten wie Parquet-Dumps, Modellartefakte, Bilder, PDFs). Sie laufen über External Locations, werden aber genauso berechtigt wie Tabellen.

Unity Catalog adressiert jede Tabelle, View, Volume oder Function über eine dreistufige Struktur: Catalog, Schema, Objektname. Diese Struktur ist Pflicht und ersetzt den zweistufigen Namespace aus Hive-Metastore-Zeiten. Der Catalog steht meist für eine Umgebung oder einen größeren fachlichen Bereich, das Schema gruppiert zusammengehörige Datenprodukte, die dritte Ebene benennt den konkreten Datensatz. Auf der übergeordneten Metastore-Ebene hängen zusätzlich Service Credential, Storage Credential, External Location und External Metadata sowie die Sharing-Objekte Share, Recipient, Provider, Connection und Clean Room als Geschwister neben dem Catalog.

Auf dieser Ebene fällt die zweite Entscheidung: Managed Table oder External Table. Bei Managed Tables legt Unity Catalog die Datendateien selbst an einem von ihm verwalteten Speicherort ab und übernimmt den vollständigen Lebenszyklus. Wird die Tabelle gelöscht, sind auch die Daten weg. Bei External Tables verwaltet Unity Catalog nur die Metadaten, die Datendateien liegen weiter an einem vorgegebenen Pfad im Cloud-Speicher und bleiben dort erhalten, auch wenn die Tabelle entfernt wird. Für neue Datenprodukte sind Managed Tables meist der einfachere Standard; External Tables bleiben sinnvoll für gewachsene Storage-Layouts und für Daten, die zusätzlich von anderen Systemen außerhalb von Databricks geschrieben werden.

Auf der Logik-Ebene trennt die Medallion-Architektur Rohdaten, aufbereitete Daten und fachlich nutzbare Datenprodukte: Unveränderte oder nur leicht aufbereitete Quelldaten (schema-on-read), bereinigte und vereinheitlichte Daten (normalisiert, mit Schema), fachlich freigegebene Daten für Reports, Anwendungen und KI (denormalisiert für Konsumenten). Die technische Struktur sollte an Umgebungen und Verantwortlichkeiten ausgerichtet werden, nicht automatisch nur an Bronze, Silber und Gold. Den Lakehouse-Hintergrund dahinter dokumentiert Databricks in der Lakehouse-Produktseite.

Daneben hält jeder Workspace einen eigenen Workspace-Speicher: bei klassischen Workspaces ein dediziertes Speicherkonto im Cloud-Abonnement, bei Serverless Workspaces ein von Databricks verwalteter Default Storage. Dort liegen interne Dateien und Metadaten des Workspaces (Job-Ergebnisse, Query-Caches, interne Metadaten) und der automatisch angelegte Workspace-Default-Catalog von Unity Catalog. Diese automatisch verwalteten Speicherbereiche sollten nicht manuell verändert werden, sonst ist der Workspace nicht wiederherstellbar. Ältere DBFS-Mounts sollten in neuen Plattformen nicht mehr als Standard verwendet werden. Datenzugriff läuft über External Locations und Volumes.

Die frühe Plattformstruktur entscheidet mit darüber, ob Kosten später nachvollziehbar und steuerbar sind. Drei Grundlagen sind dafür besonders wichtig.

Compute Policies legen fest, welche Clustergrößen und Einstellungen Teams verwenden dürfen. Ohne solche Regeln können unnötig große oder lange laufende Cluster entstehen; mit ihnen erzwingst du Instanzgrößen, automatische Abschaltung und Photon-Nutzung. Sie gehören ab Tag 1 in jedes Setup.

Einheitliche Angaben zu Team, Kostenstelle und Anwendungsfall auf allen Workloads sind Grundlage dafür, Kosten später den richtigen Verantwortlichen zuzuordnen. Tags werden über Cluster-Policies erzwungen, in den Verbrauchs- und Abrechnungsdaten ausgewertet und in Unity Catalog ergänzend als Catalog-/Schema-Tags geführt.

Die Wahl zwischen klassischem und serverlosem Compute hat großen Einfluss auf Kosten und Betriebsaufwand. Serverless SQL Warehouses sind teurer pro DBU, höhere Verbrauchspreise können durch weniger Leerlauf und geringeren Verwaltungsaufwand ausgeglichen werden. Classic Job Cluster sind günstiger pro DBU, kosten dafür Cluster-Verwaltung und das Risiko interaktiver Cluster, die unnötig lange weiterlaufen.

DBUs sind die Abrechnungs-Einheit gegenüber Databricks. Cloud-VM-Kosten kommen darauf direkt von Azure, AWS oder GCP. Für eine vollständige Kostenbetrachtung müssen Databricks-Verbrauch und Cloud-Infrastruktur gemeinsam ausgewertet werden: DBUs aus Databricks-System-Tabellen, Cloud-Kosten aus dem Cloud-Billing.

Die Plattformarchitektur schafft den technischen Rahmen. Sie beantwortet jedoch nicht alle Fragen zu Datenprodukten, Anwendungen und KI.

Vorgehen für Datenaufnahme, Transformation, Qualität und Betrieb von Pipelines auf der Plattform gehören in eine separate Diskussion. Wie Lakeflow, Auto Loader und Declarative Pipelines zusammenspielen, zeigen wir im Überblick zu Data Engineering auf Databricks.

Wie die Plattform für Fachbereiche nutzbar wird, ist eine eigene Architektur-Frage. Darauf zahlen AI/BI Dashboards, Genie, Databricks One und Databricks Apps ein, die Konsumenten-Schicht über der Plattform. Dort fallen zusätzliche Entscheidungen: ob Fachbereiche eigene Workspaces bekommen, wie Berechtigungen vom Catalog bis ins Dashboard durchgereicht werden und welche Qualitätsanforderungen die freigegebenen Daten erfüllen müssen.

Entwicklung und Betrieb eigener KI-Anwendungen über AI Functions, Vector Search, Model Serving und Mosaic AI sind eine weitere Schicht. Die Plattform legt die technischen Möglichkeiten und Grenzen fest. Der fachliche Nutzen muss für jeden KI-Anwendungsfall separat bewertet werden.

Die Übernahme bestehender Daten, Berichte und Anwendungen ist ein eigenes Migrationsprojekt und kein Teil des Plattform-Setups. Zielbild, Wellen-Plan und Quell-Strecke werden separat geführt, damit die Architektur-Entscheidungen nicht vorzeitig fixiert werden.