Was ist Databricks? Architektur, Einsatzfälle und die Einordnung im modernen Data Stack

Databricks ist eine Analyseplattform in der Cloud, gebaut auf Apache Spark, die Data Engineering, Analytik mit SQL und maschinelles Lernen in einer einzigen Laufzeitumgebung vereint. In ihrem Kern steht die Architektur des Lakehouse, ein Entwurfsmuster, das den günstigen, flexiblen Speicher eines Data Lake mit der Verlässlichkeit und der Leistung eines Data Warehouse verbindet. Die Daten liegen in offenen Formaten (Delta Lake auf dem Objektspeicher der Cloud wie S3, ADLS oder GCS), und Arbeitslasten von Batch-ETL bis zum Training von ML in Echtzeit laufen gegen dieselben Daten, ohne sie zwischen Systemen zu kopieren.

Was Databricks auszeichnet, ist die Verbindung aus offenen Formaten, Betrieb in mehreren Clouds (AWS, Azure, GCP) und einer einzigen Plattform für Entwickler, die Pipelines in Python schreiben, Analysten, die SQL fahren, und Data Scientists, die Modelle trainieren. Organisationen setzen es ein, um die Trennung aus Data Lake und Data Warehouse abzulösen, die zu doppelten Daten, doppeltem ETL und doppelter Governance zwingt. Für einen ausführlichen Vergleich mit der wichtigsten Alternative siehe Databricks und Snowflake im Vergleich.

Die Architektur des Lakehouse

Die klassische Datenarchitektur trennt den Speicher in zwei Ebenen. Ein Data Lake hält rohe, unstrukturierte und halbstrukturierte Daten zu geringen Kosten, es fehlen ihm aber ACID-Transaktionen, die Durchsetzung von Schemata und die Abfrageleistung, die Analysten erwarten. Ein Data Warehouse liefert diese Zusicherungen, legt Daten aber in proprietären Formaten ab, verlangt Aufpreise für Speicher und Rechenzeit und kann mit unstrukturierten Daten wie Bildern, Logs oder Sensormesswerten nicht umgehen.

Das Muster des Lakehouse hebt diese Trennung auf. Die Daten landen im Objektspeicher der Cloud (S3, ADLS, GCS) im Format Parquet. Delta Lake, eine quelloffene Speicherschicht, ergänzt diese Parquet-Dateien um ACID-Transaktionen, die Durchsetzung von Schemata, Time Travel (das Abfragen früherer Versionen) und Unterstützung für Streaming. Das Ergebnis: eine Kopie der Daten, die Abfragen auf dem Niveau eines Warehouse und die Flexibilität eines Lake trägt.

Ein konkretes Beispiel: ein Händler, der Clickstream-Daten, Transaktionen aus dem Kassensystem und Momentaufnahmen des Bestands speichert. In einem klassischen Aufbau geht der Clickstream nach S3, die Transaktionen nach Redshift, und die Bestandsdaten fließen in beides. Mit einem Lakehouse auf Databricks landen alle drei Datensätze in einem einzigen Delta Lake. Das Team für Data Engineering verarbeitet sie mit Spark, das Team für Analytik fragt sie mit SQL ab, und das Team für Data Science trainiert Modelle zur Bedarfsprognose, alles gegen dieselben gesteuerten Daten und ohne eine einzige Pipeline zum Kopieren zwischen Systemen.

Die Kernbausteine

Delta Lake ist die Speicherschicht, die das Lakehouse möglich macht. Sie hüllt Parquet-Dateien in ein Transaktionslog und gibt Ihnen damit ACID-Zusicherungen auf dem Objektspeicher der Cloud. Sie können auf frühere Versionen der Daten zurückrollen (Time Travel), Streaming und Batch in dieselben Tabellen zusammenführen und Schemata durchsetzen, damit fehlerhafte Datensätze produktive Bestände nicht beschädigen. Delta Lake ist quelloffen, das heißt, Ihre Daten sind nie in Databricks eingeschlossen; andere Engines lesen sie unmittelbar.

Die Laufzeitumgebung von Apache Spark übernimmt die verteilte Verarbeitung. Databricks pflegt einen optimierten Ableger von Spark samt der Photon-Engine, einer vektorisierten Ausführungsmaschine in C++, die Operationen in SQL und auf DataFrames beschleunigt. Für Arbeitslasten im Data Engineering verarbeitet Spark alles von Gigabyte bis Petabyte über automatisch skalierende Cluster. Sie schreiben Python, SQL, Scala oder R; die Laufzeitumgebung parallelisiert die Ausführung über die verfügbaren Knoten.

Unity Catalog ist die Governance-Schicht von Databricks. Sie bietet zentrale Zugriffskontrolle, Protokollierung für Audits, das Verfolgen der Data Lineage und Auffindbarkeit über alle Tabellen, Views, Modelle und Dateien im Lakehouse. Unity Catalog setzt Rechte auf Ebene der Tabelle, der Spalte und der Zeile durch, was für Organisationen in regulierten Branchen entscheidend ist. Sie verfolgt außerdem, welche Notebooks und Jobs aus welcher Tabelle lesen oder in sie schreiben, und erzeugt so einen automatischen Graphen der Lineage.

Databricks SQL gibt Analysten eine vertraute Schnittstelle in SQL, um Tabellen in Delta Lake abzufragen. Es unterstützt serverlose Rechenzeit (ohne Verwaltung von Clustern), bindet über die Standardtreiber JDBC und ODBC BI-Werkzeuge wie Power BI und Tableau an und bringt eine eingebaute Schicht zur Visualisierung für das freie Erkunden mit. Für Teams, die BI-Werkzeuge anbinden, siehe Power BI mit Databricks verbinden.

MLflow ist eine quelloffene Plattform zum Verwalten des Lebenszyklus im ML: das Verfolgen von Experimenten, das Versionieren von Modellen, eine Registry und das Ausrollen. Databricks bindet MLflow nativ ein, sodass Data Scientists Experimente protokollieren, die Leistung von Modellen vergleichen, Modelle in den Produktivbetrieb befördern und Vorhersagen ausliefern können, und zwar im selben Workspace, in dem die Trainingsdaten liegen.

Gemeinsame Notebooks bieten einen interaktiven Arbeitsraum, in dem Entwickler, Analysten und Data Scientists in Python, SQL, Scala oder R im selben Notebook arbeiten. Zusammenarbeit in Echtzeit, Anbindung an die Versionsverwaltung und eingebettete Visualisierungen ersetzen das Muster, Jupyter-Notebooks zwischen Teams per E-Mail zu schicken.

Wo Databricks sitzt

Databricks besetzt im modernen Data Stack die zentrale Schicht zum Aufbereiten und Ausliefern. Es sitzt zwischen den Werkzeugen zur Erfassung und denen zur Nutzung und ist die Maschine für Rechenzeit und Speicher, in der aus Rohdaten analysefertige Datensätze und Modelle werden.

Vorgelagert holen Werkzeuge zur Erfassung wie Fivetran und Airbyte Daten aus Quellsystemen (Datenbanken, SaaS-APIs, Ereignisströme) in das Lakehouse. Innerhalb von Databricks nutzen Teams Spark, SQL und dbt, um Rohdaten in saubere, modellierte Tabellen zu verwandeln. Nachgelagert verbinden sich BI-Werkzeuge (Power BI, Tableau, Looker) mit Databricks SQL für Dashboards und Berichte. In Databricks trainierte Modelle liefern Vorhersagen über REST-APIs an Anwendungen.

Die Governance spannt sich über die volle Breite. Unity Catalog übernimmt Zugriffskontrolle und Lineage innerhalb von Databricks. Für Organisationen, die mehrere Plattformen betreiben, also Databricks plus Snowflake plus SaaS-Werkzeuge plus alte Datenbanken, liefert ein externer Datenkatalog wie Dawiso die plattformübergreifende Governance.

Häufige Einsatzfälle

Pipelines im Data Engineering. Ein Fintech erfasst Transaktionsdaten von Zahlungsdienstleistern, reichert sie mit Kundenprofilen aus einem CRM an und schreibt saubere, entdoppelte Tabellen in Delta Lake. Spark übernimmt die schwere Arbeit, also Entdopplung, Prüfung der Schemata und Typumwandlung, während Delta Live Tables (DLT) die Orchestrierung der Pipeline und die Erwartungen an die Datenqualität verwaltet. Die entstehenden Tabellen speisen sowohl Berichte für die Compliance als auch das Scoring von Betrug in Echtzeit.

Training und Bereitstellung von Modellen. Ein Logistikunternehmen trainiert Modelle zur Optimierung von Routen auf historischen Zustelldaten. Feature Engineering, Training, das Abstimmen der Hyperparameter und das Verfolgen der Experimente geschehen alle in Databricks. MLflow protokolliert jeden Lauf. Schlägt ein Modell die aktuelle produktive Fassung, wird es über die Registry befördert und an einem Endpunkt bereitgestellt, ohne Übergabe an eine eigene Plattform für ML.

Analytik und Berichte in SQL. Ein SaaS-Unternehmen betreibt mit Databricks SQL seine operativen Dashboards. Produktverantwortliche fragen Kennzahlen zum Engagement der Nutzer über ein serverloses SQL-Warehouse ab, das an Tableau angebunden ist. Dieselben Tabellen in Delta Lake, die die Dashboards speisen, speisen auch das Modell zur Vorhersage der Abwanderung: eine Kopie der Daten, zwei Arbeitslasten, keine Pipeline zum Abgleich.

Streaming in Echtzeit. Ein Medienunternehmen verarbeitet Clickstream-Ereignisse seiner Plattform über Spark Structured Streaming. Die Events landen binnen Sekunden in Delta Lake und speisen eine Empfehlungsmaschine in Echtzeit sowie ein nahezu echtzeitfähiges Dashboard zur Leistung der Inhalte. Dieselbe Architektur trägt die Erfassung im Streaming und die nächtlichen Aggregationen für die Wochenberichte.

Bepreisung und Kostenmodell

Die Bepreisung von Databricks verwirrt Teams, weil es zwei getrennte Rechnungen gibt. Databricks berechnet Rechenzeit in Databricks Units (DBUs), einem normierten Maß für Rechenleistung. Ihr Anbieter der Cloud berechnet getrennt die VMs, auf denen diese Lasten laufen, den Speicher für Ihre Daten und jeglichen Abfluss im Netz.

Die Sätze je DBU schwanken nach Art der Last. Jobs Compute (Verarbeitung im Batch) ist am günstigsten; All-Purpose Compute (interaktive Notebooks) kostet je DBU 2- bis 3-mal so viel. Drei Editionen, also Standard, Premium und Enterprise, legen einen Faktor obendrauf. Premium (rund 1,5-mal Standard) ergänzt RBAC und Protokollierung für Audits. Enterprise (rund 2-mal Standard) ergänzt Unity Catalog und Funktionen für die Compliance.

Für ein kleines Team mit täglichem ETL und freier Analyse liegen die monatlichen Gesamtkosten typischerweise zwischen 1.500 und 3.000 US-Dollar. Mittelgroße produktive Installationen mit Analytik in SQL und Training von Modellen liegen bei 15.000 bis 25.000 US-Dollar pro Monat. Die größten Hebel sind die Wahl der Lastart, die Einstellungen zum automatischen Beenden von Clustern und Rabatte aus Abnahmevereinbarungen. Eine ausführliche Aufschlüsselung finden Sie im Leitfaden zur Bepreisung von Databricks. Für die Unterschiede nach Cloud siehe den Vergleich von Azure, AWS und GCP.

Governance und Sicherheit

Unity Catalog ist die Antwort von Databricks auf Governance. Er bietet einen zentralen Metastore, der jede Tabelle, jede View, jedes Modell und jede Datei über alle Workspaces hinweg führt. Die Zugriffskontrolle arbeitet auf drei Ebenen: Katalog (oberster Namensraum), Schema (Datenbank) und Objekt (Tabelle, View, Modell). Sicherheit auf Ebene von Spalten und Zeilen erlaubt feine Einschränkungen: Eine Analystin in EMEA sieht nur Kundendaten aus EMEA, obwohl die Tabelle weltweite Datensätze enthält.

Die Data Lineage in Unity Catalog entsteht automatisch. Wenn ein Notebook aus Tabelle A liest, die Daten umformt und in Tabelle B schreibt, hält Unity Catalog diese Abhängigkeit fest. Dieser Graph erscheint in der Oberfläche und über APIs und macht die Folgenabschätzung einfach: Bevor Sie eine Spalte in einer Quelltabelle ändern, sehen Sie jede nachgelagerte Tabelle und jedes Dashboard, das von ihr abhängt.

Zu den Funktionen für Sicherheit gehören Verschlüsselung im Ruhezustand und bei der Übertragung, der Betrieb in einer VPC oder einem VNet zur Trennung im Netz, die Anbindung von SSO an Azure AD, Okta und andere Anbieter von Identitäten sowie Zertifizierungen für die Compliance, darunter SOC 2, HIPAA, HITRUST und die DSGVO. Protokolle für Audits erfassen jeden Zugriff auf Daten, jede ausgeführte Abfrage und jede Änderung von Rechten.

Wo Unity Catalog an seine Grenze kommt, ist der Umfang: Er steuert nur, was innerhalb von Databricks liegt. Organisationen, die Databricks neben Snowflake, SaaS-Werkzeugen und alten Datenbanken betreiben, brauchen eine plattformübergreifende Schicht der Governance, und genau diese Lücke füllen externe Kataloge wie Dawiso.

Grenzen und Abwägungen

Abhängigkeit vom Anbieter trotz offener Formate. Delta Lake ist quelloffen und Parquet-Dateien sind übertragbar, doch die Optimierungen der Laufzeitumgebung von Databricks (Photon, adaptive Ausführung von Abfragen, Delta Live Tables) wirken nur innerhalb von Databricks. Wegzugehen heißt, diese Vorteile bei der Leistung zu verlieren und die Orchestrierung der Pipelines neu zu schreiben. Ein offenes Format ist nicht dasselbe wie ein Wechsel ohne Kosten.

Komplexität der Kosten. Das Modell mit zwei Rechnungen (DBU plus Infrastruktur der Cloud) macht die Schätzung schwierig. Ein Team, das für interaktives Erkunden All-Purpose-Cluster hochfährt, ohne Richtlinien zum automatischen Beenden, kann unerwartet hohe Rechnungen erzeugen. Anders als beim Modell mit einer Rechnung bei Snowflake verlangt Databricks aktive Steuerung der Kosten über zwei Anbieter hinweg.

Lernkurve bei Spark. Teams mit tiefen Kenntnissen in SQL, aber ohne Erfahrung mit Spark, brauchen Anlaufzeit. Databricks SQL bietet zwar eine vertraute Schnittstelle in SQL, doch die volle Kraft der Plattform, also Orchestrierung von Pipelines, Streaming und ML, verlangt Verständnis von Konzepten des verteilten Rechnens. Das ist keine Schulung an einem Nachmittag.

Anlaufzeit bei serverlosen Diensten. Serverlose SQL-Warehouses ersparen die Verwaltung von Clustern, bringen aber Verzögerungen beim Kaltstart mit sich, wenn ein Warehouse untätig war. Bei Dashboards mit seltener Nutzung kann die erste Abfrage nach einer Pause 10 bis 30 Sekunden zum Hochfahren brauchen, eine spürbare Wartezeit für Fachbereiche, die sofortige Ergebnisse gewohnt sind.

Wie Dawiso Databricks ergänzt

Unity Catalog steuert, was innerhalb von Databricks liegt. Dawiso steuert den ganzen Stack, also Databricks neben Snowflake, SaaS-Anwendungen, BI-Werkzeugen und alten Datenbanken. Die beiden ergänzen einander, sie konkurrieren nicht.

Der Datenkatalog von Dawiso erfasst Metadaten aus dem Databricks Unity Catalog neben Metadaten aus jedem anderen System der Organisation. Fachleute suchen Datensätze an einer Stelle, unabhängig davon, ob die Daten in einer Delta-Tabelle, einer View in Snowflake oder einer SaaS-API liegen. Die Lineage in Dawiso spannt sich über die ganze Pipeline, von der Quelle über die Aufbereitung in Databricks bis zum Dashboard in Power BI, das das Ergebnis zeigt.

Das Business Glossary in Dawiso sorgt dafür, dass „Umsatz“, „aktiver Kunde“ und „Abwanderungsquote“ dasselbe bedeuten, ob die Kennzahl in Databricks SQL berechnet, in Snowflake abgefragt oder in einem Dashboard in Tableau gezeigt wird. Ohne ein gemeinsames Glossar bauen verschiedene Teams widersprüchliche Definitionen, ein Problem, das Unity Catalog nicht löst, weil er nur die Bestände in Databricks sieht.

Über das Model Context Protocol (MCP) können KI-Agenten programmatisch auf den Katalog von Dawiso zugreifen, also Definitionen von Spalten nachschlagen, die Aktualität von Daten prüfen, die Lineage abrufen und die Verantwortung für eine Kennzahl bestätigen, und zwar über ein vereinheitlichtes Protokoll. So skaliert Data Governance von Arbeit von Hand zu einem von KI unterstützten Betrieb über den ganzen Datenstapel.

Fazit

Databricks löst ein echtes Problem der Architektur: die Trennung aus Data Lake und Warehouse, die doppelte Daten, doppelte Pipelines und Lücken in der Governance erzeugt. Das Muster des Lakehouse, also Delta Lake auf dem Speicher der Cloud mit Spark für die Rechenzeit, beseitigt diese Doppelung. Für Organisationen, deren wichtigste Arbeitslasten Data Engineering, Analytik mit SQL und ML verbinden, ist es die am stärksten integrierte verfügbare Option. Die Abwägungen sind real, also die Komplexität der Kosten, die Lernkurve bei Spark und die herstellereigenen Optimierungen, doch für Teams, die bereit sind, in die Plattform zu investieren, ist der Gewinn aus der Konsolidierung beträchtlich. Die Lücke in der Governance jenseits der eigenen Grenze von Databricks ist der Ort, an dem ein plattformübergreifender Katalog wie Dawiso unverzichtbar wird.