Zum Hauptinhalt springen
DatabricksLakehouseDatenanalytik

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.

TL;DR

Databricks ist eine Lakehouse-Plattform in der Cloud, die Data Engineering, Analytik mit SQL und maschinelles Lernen in einer Laufzeitumgebung vereint. Sie legt Daten in offenen Formaten ab (Delta Lake auf dem Objektspeicher der Cloud), läuft auf AWS, Azure und GCP und nutzt Apache Spark für verteilte Verarbeitung. Organisationen setzen sie ein, um getrennte Data Lakes und Warehouses zu einer gesteuerten Plattform zusammenzuführen.

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.

ARCHITEKTUR DES LAKEHOUSEObjektspeicher der CloudS3 / ADLS / GCS - Parquet-Dateien, geringe Kosten, unbegrenzte SkalierungSPEICHERDelta LakeACID-Transaktionen · Durchsetzung des Schemas · Time Travel · StreamingVERLÄSSLICHKEITAnalytik mit SQLBI-Abfragen, DashboardsData EngineeringETL, Pipelines, SparkML / KITraining, MLflow, AusliefernStreamingErfassung in EchtzeitARBEITSLASTEN
Zum Vergrößern klicken

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. Die Databricks Runtime, gebaut auf Apache Spark, enthält die Photon-Engine, eine native vektorisierte 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 hält außerdem fest, welche Notebooks, Jobs und Dashboards 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.

DATABRICKS IM MODERNEN DATA STACKDatenbankenSaaS-APIsEreignisströmeQUELLENErfassungFivetran, AirbyteERFASSENDatabricksDelta Lake + SparkAufbereiten, liefern, trainierendbt + SQL + PythonAUFBEREITEN + LIEFERNBI-WerkzeugePower BI, Tableau, LookerBereitstellung von KI / MLNUTZENDawiso - plattformübergreifende Governance, Katalog, Business Glossary
Zum Vergrößern klicken

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 Lakeflow-Pipelines (früher Delta Live Tables) die Orchestrierung der Pipeline und die Erwartungen an die Datenqualität verwalten. 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. Bei klassischer Rechenzeit berechnet Ihr Anbieter der Cloud getrennt die VMs, auf denen diese Lasten laufen; bei serverloser Rechenzeit ist die Infrastruktur im Satz je DBU enthalten. Den Speicher für Ihre Daten und jeglichen Abfluss im Netz berechnet in beiden Fällen der Anbieter der Cloud.

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 nach den Listenpreisen für AWS Premium rund 3- bis 4-mal so viel (0,55 US-Dollar gegenüber 0,15 US-Dollar je DBU). Auch die Plattformstufe bestimmt den Satz. Die Stufe Standard wurde auf AWS und GCP am 1. Oktober 2025 eingestellt und auf Azure am 1. Oktober 2026. Aktuell gibt es daher Premium und Enterprise auf AWS und GCP und Premium auf Azure. Unity Catalog setzt Premium voraus; Enterprise ergänzt erweiterte Funktionen für Sicherheit und Compliance.

Die Gesamtkosten hängen von der Mischung der Lasten, der Cloud, der Region und den Rabatten ab, einen typischen Monatsbetrag gibt es daher nicht. 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). Zeilenfilter und Spaltenmasken erlauben 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 die nachgelagerten Tabellen, Databricks-Dashboards, Jobs und Notebooks, die von ihr abhängen.

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 ein Compliance-Sicherheitsprofil, das Anforderungen wie HIPAA, HITRUST, PCI-DSS und FedRAMP unterstützt. Databricks dokumentiert außerdem, wie Delta-Tabellen für Anfragen nach der DSGVO wie das Recht auf Vergessenwerden vorbereitet werden. Protokolle für Audits erfassen jeden Zugriff auf Daten, jede ausgeführte Abfrage und jede Änderung von Rechten.

Unity Catalog dehnt die Governance über Lakehouse Federation auf föderierte Quellen aus, sein Umfang ist aber auf die Plattform Databricks zentriert. Organisationen, die Databricks neben Snowflake, SaaS-Werkzeugen und alten Datenbanken betreiben, ergänzen oft eine plattformübergreifende Schicht der Governance, und genau dort setzen externe Kataloge wie Dawiso an.

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, Lakeflow-Pipelines) 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. Snowflake fasst Credits für Rechenzeit, eine Gebühr je TB Speicher und den Datentransfer in einer Gesamtsumme zusammen; bei klassischer Rechenzeit 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 und starten typischerweise in 2 bis 6 Sekunden; Pro- und klassische Warehouses brauchen Minuten. Bei Dashboards mit seltener Nutzung auf einem Pro- oder klassischen Warehouse kann die erste Abfrage nach einem Stopp eine spürbare Wartezeit für Fachbereiche bedeuten, die sofortige Ergebnisse gewohnt sind.

In einer von Databricks beauftragten Studie von Forrester zum Total Economic Impact berichteten Organisationen, die die Plattform von Databricks einsetzen, über drei Jahre eine Rendite von 417 %, eine um bis zu 25 % höhere Produktivität der Datenteams und 40 % weniger Rechenzeit.

- Forrester, Total Economic Impact Spotlight (Databricks)

Wie Dawiso Databricks ergänzt

Unity Catalog steuert die Plattform Databricks und die Quellen, die sie föderiert. Dawiso katalogisiert Metadaten plattformübergreifend, also Databricks neben Snowflake, BI-Werkzeugen und weiteren angebundenen Quellen. Die beiden ergänzen einander, sie konkurrieren nicht.

UMFANG DER GOVERNANCE: UNITY CATALOG UND DAWISOUnity Catalogauf Databricks zentriertDelta-TabellenML-ModelleViews / FunctionsVolumes / DateienDawisoplattformübergreifender UmfangDatabricksSnowflakeSaaS + BI-WerkzeugeBusiness Glossary
Zum Vergrößern klicken

Der Datenkatalog von Dawiso erfasst Metadaten aus dem Databricks Unity Catalog neben Metadaten aus den anderen Plattformen, die Dawiso anbindet, etwa Snowflake, dbt und Power BI. Fachleute suchen Datensätze an einer Stelle, ob die Daten in einer Delta-Tabelle oder einer View in Snowflake liegen. Dawiso führt die Lineage aus den Konnektoren für Databricks, dbt und Power BI in einem Katalog zusammen.

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. Weil das Glossar von Dawiso Plattformen übergreift, gilt eine Definition überall dort, wo die Kennzahl genutzt wird.

Über das Model Context Protocol (MCP) können KI-Agenten programmatisch auf den Katalog von Dawiso zugreifen, also den Katalog durchsuchen, die Lineage verfolgen und Objekte sowie Datenstichproben einsehen, 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.

Quellen

In Aktion erleben

Data & Analytics Catalog

Schaffen Sie eine einheitliche Sicht auf Ihre Datenbestände und gewinnen Sie mit automatischer Datenerkennung schneller Erkenntnisse.

Ein Cookie am Tag hält schlechte UX fern.

Wir verwenden Cookies, um Inhalte und Werbung zu personalisieren und unseren Traffic zu analysieren. Außerdem geben wir Informationen zu Ihrer Nutzung unserer Website an unsere Partner für Werbung und Analyse weiter, die sie mit weiteren Daten zusammenführen können, die Sie ihnen bereitgestellt haben oder die sie bei Ihrer Nutzung ihrer Dienste gesammelt haben. Mit einem Klick auf „Alle akzeptieren“ erlauben Sie uns, Cookies für Analyse und Werbung über Google Tag Manager zu verwenden. Sie können Cookies auch einzeln einstellen.

Einstellungen zur Zustimmung anpassen

Wir verwenden Cookies, um Inhalte und Werbung zu personalisieren und unseren Traffic zu analysieren. Außerdem geben wir Informationen zu Ihrer Nutzung unserer Website an unsere Partner für Werbung und Analyse weiter. Datenschutzerklärung

Notwendige Cookies ermöglichen zentrale Funktionen der Website, etwa die Anmeldung und die Kontoverwaltung. Ohne unbedingt notwendige Cookies lässt sich die Website nicht richtig nutzen.

Funktionale Cookies speichern Informationen zu Besuchern der Website, etwa Sprache, Zeitzone oder erweiterte Inhalte.

Analyse-Cookies zeigen, wie Besucher die Website nutzen. Sie können nicht dazu verwendet werden, einen bestimmten Besucher direkt zu identifizieren.

Wir verwenden Microsoft Clarity, um zu sehen, wie Sie unsere Website nutzen (einschließlich Heatmaps und Sitzungsaufzeichnungen), damit wir sie verbessern können. Mit der Nutzung unserer Website stimmen Sie zu, dass wir und Microsoft diese Daten erheben und verwenden. Details finden Sie in unserer Datenschutzerklärung.

Werbe-Cookies erkennen Besucher über verschiedene Websites hinweg, etwa bei Content-Partnern oder Bannernetzwerken. Unternehmen können damit ein Profil der Interessen eines Besuchers aufbauen oder auf anderen Websites passende Werbung anzeigen.