Databricks Data Intelligence Platform: Architektur, Komponenten und Entscheidungshilfe
Die Kernaussagen auf einen Blick.
- Die Data Intelligence Platform bündelt Data Engineering, Data Warehousing, BI und KI auf einer gemeinsamen Lakehouse-Grundlage.
- Der zentrale Vorteil liegt in gemeinsamer Governance, gemeinsamer Datenbasis und wiederverwendbarem Compute für verschiedene Workloads.
- Der Mehrwert entsteht nicht dadurch, dass ein weiteres Tool eingeführt wird, sondern dadurch, dass Teams schneller mit verlässlichen Daten arbeiten können, bessere Entscheidungen treffen und KI-Anwendungsfälle kontrolliert umsetzen.
- Empfehlenswert ist, bei konkreten Geschäftsfragen, Datenprodukten und Anwendungsfällen zu starten, die den größten Nutzen schaffen, und die Technologieentscheidung daraus abzuleiten.
Inhaltsverzeichnis
Zehn Tools sind noch keine Datenplattform
In Plattform-Reviews sieht man häufig ein ähnliches Bild: ein Data Warehouse für das Controlling, ein Data Lake für die Sensordaten, eine separate ML-Umgebung für die Instandhaltungsmodelle und ein Governance-Tool, das kaum gepflegt wurde. Vier Systeme, mehrere Kopien derselben Stammdaten und unterschiedliche Rechtekonzepte. Jede einzelne Komponente funktionierte. Gemeinsam ergab sich aber keine durchgängige Verbindung von der Rohdatenquelle bis zur Kennzahl im Vorstandsbericht.
Dieses Muster entsteht oft, wenn eine Datenlandschaft über mehrere Jahre gewachsen ist. Jedes Team löst sein Problem mit dem Werkzeug, das in dem Moment am besten passt. Am Ende stehen Datenkopien, die nachts synchronisiert werden, Zahlen, deren Herkunft niemand mehr durchgängig nachvollziehen kann, und Governance, die an jeder Systemgrenze erneut aufgebaut werden muss. Genau für diese Lücke positioniert Databricks die Data Intelligence Platform.
In solchen Entscheidungsrunden kommen meist dieselben Fragen:
Lohnt sich eine einheitliche Plattform oder erhöhen wir nur die Anbieterbindung? Was sollte wirklich auf eine gemeinsame Plattform, und was bleibt besser eigenständig? Wie viel Migration steckt darin, und was kostet der Betrieb danach? Welches Problem löst die Plattform besser als mehrere gute Einzelwerkzeuge?
Die zentrale These: Der Wert dieser Plattform entsteht durch gemeinsame Datenhaltung, Governance und Compute über mehrere Workloads hinweg. Wenn Databricks nur als weiteres Tool eingeführt wird, bleibt ein teurer Baustein, dessen eigentlicher Vorteil kaum genutzt wird. Als Architekturentscheidung verstanden, reduziert sie Datenkopien, Schnittstellen und unterschiedliche Berechtigungsmodelle.
Was ist die Databricks Data Intelligence Platform?
Databricks ist eine Cloud-Datenplattform für Daten-, Analyse- und KI-Workloads. Die Databricks Data Intelligence Platform ist der Architektur- und Produktbegriff für die Kombination aus Komponenten, die auf einer offenen Lakehouse-Grundlage zusammenarbeiten: Data Engineering, Data Warehousing, Streaming, Machine Learning, generative KI und Governance, auf Basis gemeinsamer Datenhaltung in Delta Lake und einer gemeinsamen Verwaltungsschicht in Unity Catalog. Databricks bezeichnet die KI-Schicht darüber, die Struktur und Bedeutung der eigenen Daten interpretiert, als Data Intelligence Engine.
Der Begriff hat zwei Seiten: echte Architektur und Produktpositionierung. Der architektonische Teil ist konkret: weniger Datenkopien, ein zentrales Berechtigungsmodell und eine gemeinsame Lineage über Workloads hinweg. Der Markenbegriff bündelt viele Bausteine unter einem Namen: „Data Intelligence" fasst Bausteine zusammen, die teils seit Jahren existieren, unter einem neuen Dach. Für eine Architekturentscheidung ist diese Trennung wichtig. Der reale Vorteil entsteht nur, wenn die gemeinsame Daten- und Governance-Schicht tatsächlich genutzt wird. Der Name allein erzeugt diesen Vorteil nicht.
Diese Abgrenzung hat eine konkrete Folge für die Architekturplanung. Sobald die gemeinsame Governance- und Rechenschicht nicht genutzt wird, bleibt Databricks vor allem eine teurere Compute-Umgebung. Der Begriff verspricht Integration, die erst durch Unity Catalog, gemeinsame Datenhaltung und klare Betriebsregeln entsteht.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Lakehouse, Workloads und Governance
Die Plattform lässt sich in drei Ebenen einordnen: ein Datenfundament, mehrere Workload-Schichten und eine Governance-Schicht, die alles verbindet. So wird schneller sichtbar, welche Bausteine für die eigene Entscheidung relevant sind.
Ganz oben stehen die Workload-Bausteine, mit denen Teams täglich arbeiten: AI/BI für Reporting und Self-Service-Analyse, Databricks Apps für operative Anwendungen, Lakeflow für Ingestion und Pipelines, Databricks SQL für Data-Warehouse-Workloads, Lakebase für operative Datenbank-Workloads und Agent Bricks für agentenbasierte KI. Darunter liegt Unity Catalog als durchgehende Governance-Schicht, die Berechtigungen, Lineage und Katalog über alle diese Workloads hinweg trägt. Das Fundament bilden offene Tabellenformate, Delta Lake und Apache Iceberg, auf denen die gesamte Plattform aufsetzt.
Die wichtigsten Bausteine der Databricks Data Intelligence Platform
| Ebene | Komponente | Wofür sie genutzt wird |
|---|---|---|
| Fundament | Delta Lake, Lakehouse | offene, transaktionssichere Datenbasis |
| Compute | Photon, Serverless | Compute für SQL und Datenverarbeitung, möglichst ohne manuelle Clusterverwaltung |
| Engineering | Lakeflow | Ingestion, Pipelines und Orchestrierung |
| Warehousing und BI | Databricks SQL, Genie, One Genie | Reporting, SQL-Abfragen und Self-Service auf Lakehouse-Daten |
| KI | Mosaic AI, DatabricksIQ | Modelle, generative KI und Funktionen, die Metadaten und Datenkontext nutzen |
| Governance | Unity Catalog | Berechtigungen, Lineage und Katalog über alle Workloads hinweg |
Die Übersicht soll keine vollständige Produktliste sein, sondern die wichtigsten Bausteine für eine Entscheidung einordnen. Für die meisten Vorhaben sind drei Bausteine besonders wichtig: das Fundament aus Delta Lake, die Governance aus Unity Catalog und die Workload-Schicht, in der das konkrete Problem gelöst werden soll. Wie die Bausteine zu einer betriebenen Grundlage zusammenwachsen, führen wir im Aufbau und Betrieb der Databricks-Foundation aus. Die offene Speicherbasis selbst erklären wir in der Lakehouse-Architektur, die Rechte- und Herkunftsschicht darüber im Überblick zu Unity Catalog. Wo Echtzeit-Profile die Engine-Wahl drücken, zeigen wir im Überblick zu Lakehouse-RT.
Unity Catalog als gemeinsame Governance-Schicht
Der Unterschied zu einer reinen Werkzeugsammlung liegt unterhalb der einzelnen Workloads. In einer klassischen Best-of-Breed-Landschaft hat jedes System oft ein eigenes Rechtemodell, einen eigenen Katalog und eine eigene Lineage-Sicht. Eine Kennzahl im Vorstandsbericht über mehrere Systeme zurückzuverfolgen, wird dann schnell zur Handarbeit. Genau diese Nachvollziehbarkeit entscheidet im Ernstfall darüber, ob eine Zahl belastbar ist, wenn sie kritisch wird.
Unity Catalog bündelt diese Governance-Schicht als gemeinsamen Kern der Plattform: ein Berechtigungsmodell mit fein abgestuften Zugriffsrechten, eine durchgehende Lineage von der Quelle bis zum Dashboard, ein Katalog über Tabellen, Dateien, Modelle und KI-Funktionen. Auf diesem Kern aus einheitlicher Governance und einheitlichen Daten setzen die Workloads Business Intelligence, Data Warehousing, KI & Data Science, ETL & Echtzeit-Analytik und Orchestrierung auf, getragen von einem offenen Data Lake (genau das Bild, das auch im Hero-Diagramm oben auf dieser Seite zu sehen ist). Databricks beschreibt die Plattform entsprechend als einheitliche Grundlage für alle Daten und Governance. Für den Betrieb ist diese gemeinsame Schicht einer der größten Hebel: weniger getrennte Rechtekonzepte, bessere Nachvollziehbarkeit im Audit und Compute für Engineering, BI und KI auf derselben Datenbasis.
Daraus ergibt sich eine wichtige Regel für jeden Plattformumbau. Die Reihenfolge heißt erst Datenbasis und Governance, dann breiter Zugriff. Wenn das Rechtemodell in Unity Catalog steht, bevor breiter Zugriff freigeschaltet wird, kann die Plattform kontrolliert wachsen. Wird Governance erst später ergänzt, entstehen genau die Inseln wieder, die die Plattform eigentlich auflösen sollte.
Lakehouse und Data Intelligence Platform: Was ist der Unterschied?
Lakehouse und Data Intelligence Platform werden häufig gleichgesetzt. Für eine Architekturentscheidung lohnt sich die Trennung. Das Lakehouse ist die darunterliegende Architektur: eine offene Speicherschicht, die Data-Warehouse-Eigenschaften mit der Flexibilität eines Data Lake verbindet. Die Data Intelligence Platform ist das Produkt- und Plattformangebot, das Databricks darauf aufbaut, inklusive Compute, BI, KI und der datenverstehenden Intelligenz-Schicht.
Das Lakehouse beantwortet vor allem die Frage, wie Daten gespeichert und verwaltet werden. Die Plattform beantwortet, welche Workloads auf dieser Basis gemeinsam entwickelt und betrieben werden. Ein Lakehouse kann grundsätzlich auch ohne Databricks aufgebaut werden, etwa mit offenen Tabellenformaten auf einer eigenen Cloud. Die Plattform fügt die Integration, die Governance-Schicht und die KI-Funktionen hinzu, die in einem Eigenbau einzeln zusammengesetzt und betrieben werden müssten.
Diese Unterscheidung ist wichtig für die Investitionsentscheidung. Für eine offene, günstige Speicherbasis allein genügt die Lakehouse-Architektur. Sobald Engineering, Reporting und KI auf einer gemeinsamen, abgesicherten Plattform laufen sollen, fällt die Entscheidung für die Plattform, einschließlich der stärkeren Bindung an Databricks.
Ist Databricks ETL, Data Warehouse oder AI-Plattform?
Diese Frage kommt in fast jeder ersten Diskussion auf und ist berechtigt. Databricks ist als Spark-Plattform für Datenverarbeitung und ETL groß geworden. Mit Databricks SQL und der Lakehouse-Grundlage übernimmt Databricks inzwischen auch viele klassische Data-Warehouse-Aufgaben: strukturierte Tabellen, schnelle SQL-Abfragen, Anschluss an gängige BI-Werkzeuge. Beides kann auf derselben Datenbasis laufen, ohne Daten zwingend in ein zweites System zu kopieren.
Genau darin liegt der architektonische Anspruch der Plattform. Statt einen Lake für Verarbeitung und ein separates Warehouse für Reporting zu betreiben, liegen beide Workloads auf einer Schicht. Für Controlling und BI bedeutet das: weniger Kopien zwischen Rohdaten und Bericht und ein geringeres Risiko unterschiedlicher Zahlen in verschiedenen Systemen.
Die wichtige Einschränkung: Databricks ersetzt ein spezialisiertes Data Warehouse nicht in jedem Szenario eins zu eins, vor allem bei sehr speziellen, latenzkritischen BI-Anforderungen lohnt ein Einzelfallvergleich. Für die große Mehrheit der Workloads, die Engineering und Reporting verbinden, macht die gemeinsame Plattform den Betrieb oft deutlich einfacher.
Welche Workloads gehören auf Databricks zusammen?
ETL und Warehousing sind nur zwei von mehreren Workload-Typen, die auf derselben Basis laufen: Datenaufnahme und Pipelines, Streaming, Reporting und BI, Machine Learning und generative KI. Mit Lakebase rücken auch operative und transaktionale Daten näher an analytische Workloads. BARC beschreibt die nahtlose Integration transaktionaler und analytischer Daten über Unity Catalog als einen der jüngeren Entwicklungsschritte der Plattform. Für die Architektur bleibt der entscheidende Punkt derselbe: Je mehr Workloads dieselbe Datenhaltung und Governance nutzen, desto weniger Kopien, Schnittstellen und Berechtigungsmodelle entstehen.
Die Auswahl sollte sich an der Zusammengehörigkeit der Daten orientieren. Auf eine gemeinsame Plattform gehören vor allem Workloads, die dieselben Daten, Berechtigungen und Lineage brauchen: die Datenaufnahme, das Reporting darauf und die Modelle, die auf denselben Tabellen rechnen. Workloads mit eigenen Daten und eigenem Lebenszyklus gewinnen weniger durch die gemeinsame Plattform und können bewusst eigenständig bleiben.
Wann passt die Data Intelligence Platform?
Eine einheitliche Plattform ist eine Architekturentscheidung, die Aufbau, Migration und Betrieb kostet, und sie passt nicht zu jeder Ausgangslage. Vor der Entscheidung lohnt sich deshalb ein ehrlicher Blick darauf, ob die eigene Situation den Aufwand rechtfertigt. Die Plattform lohnt sich vor allem, wenn mehrere dieser Symptome zusammenkommen:
Mehrere Datenkopien
Mehrere Datenkopien und Pipelines, die dieselben Stammdaten zwischen Lake, Warehouse und ML-Umgebung bewegen.
Fragmentierte Governance
Governance, die an jeder Systemgrenze neu aufgebaut wird, ohne durchgehende Herkunftskette.
KI-Vorhaben blockiert
KI-Vorhaben, die an Datenzugriff, Datenqualität oder Berechtigungen hängenbleiben, bevor das erste Modell produktiv läuft.
Parallele Rechtemodelle
Ein Betrieb, der mehrere Rechtemodelle, Kataloge und Lineage-Sichten parallel pflegt.
Wann ist es zu früh für die Plattformfrage?
Auch für kleinere Vorhaben kann Databricks technisch passen. Sein voller Wert zeigt sich aber erst, wenn mehrere Workloads, Datenquellen und KI-Vorhaben auf einer gemeinsamen Schicht zusammenlaufen. Bei einem einzelnen, stabilen Reporting auf überschaubarer Datenbasis rechnet sich der Plattformaufwand oft noch nicht, und ein fokussiertes Werkzeug kann vorerst die wirtschaftlichere Wahl sein.
Entscheidend ist weniger das Werkzeug als die Grundlage darunter: eine saubere, fundierte Datenstrategie. Solange nicht geklärt ist, wer Datenprodukte verantwortet, welche Geschäftsfragen im Vordergrund stehen und welche Prozesse die gemeinsame Plattform beschleunigen soll, kommt die Plattformfrage zu früh, unabhängig vom Anbieter. Steht diese Strategie, lässt sich die Entscheidung für oder gegen Databricks fundiert treffen.
Grenzen der Databricks Data Intelligence Platform
Trotz der Integration hat die Data Intelligence Platform klare Grenzen, die vor der Entscheidung auf dem Tisch liegen sollten.
Anbieterbindung ist Teil der Entscheidung
Je stärker Governance, Compute und KI-Funktionen auf Databricks aufbauen, desto höher werden spätere Wechselkosten. Die offene Speicherbasis reduziert dieses Risiko teilweise, produktnahe Schichten wie Governance, Serving und Workflows binden trotzdem stärker.
Kosten müssen aktiv gesteuert werden
Ein häufiger Kritikpunkt im Betrieb ist die Transparenz der Verbrauchskosten. Compute ist schnell gestartet und kann ebenso schnell teuer werden, wenn Nutzung und Verantwortung nicht klar zusammengehören.
Die Plattform ersetzt keine Datenorganisation
Eine gemeinsame Plattform löst kein fehlendes Ownership. Ohne klare Verantwortung für Datenprodukte, Qualität und Kennzahlenlogik entstehen dieselben Konflikte wie zuvor, nur auf einer moderneren Plattform.
Der Nutzen hängt von echter Nutzung ab
Wenn Databricks nur als isoliertes Verarbeitungstool genutzt wird, bleibt vom Integrationsvorteil wenig übrig. Der Vorteil entsteht erst, wenn Governance und Datenhaltung tatsächlich workloadübergreifend genutzt werden.
Die letzte Meile im Reporting bleibt oft bei BI-Tools
Die integrierten Dashboard- und BI-Funktionen sind nach unabhängiger Einschätzung noch weniger ausgereift als bei spezialisierten BI-Tools. BARC ordnet die integrierten BI-Fähigkeiten als weniger reif gegenüber den Marktführern ein und sieht den Katalog vor allem auf technisches Metadatenmanagement ausgerichtet.
Diese Grenzen sprechen nicht grundsätzlich gegen Databricks. Sie zeigen aber, unter welchen Bedingungen die Plattform wirklich funktioniert, und welche Vorarbeit eine Datenorganisation vorher leisten muss.
Fazit
Die Databricks Data Intelligence Platform soll getrennte Daten-, Analyse- und KI-Systeme näher zusammenbringen, mit offener Datenhaltung, gemeinsamer Governance und Compute für Engineering, Reporting und KI.
Drei Faktoren entscheiden über den Erfolg. Erstens Governance vor breitem Zugriff: das Rechtemodell in Unity Catalog sollte stehen, bevor breiter Zugriff freigeschaltet wird. Zweitens eine klare Workload-Auswahl: nur Daten- und Analyse-Workloads, die wirklich von einer gemeinsamen Plattform profitieren, gehören auf die Plattform, der Rest bleibt bewusst eigenständig. Drittens aktive Kostenkontrolle, weil flexibler Compute ohne klare Verantwortung schnell teuer wird.
Besonders relevant ist die Plattform für Unternehmen, die heute mehrere Datenkopien zwischen Lake, Warehouse und ML-Umgebung pflegen und deren KI-Vorhaben an Datenzugriff, Datenqualität oder Berechtigungen hängenbleiben. Wer diese Probleme nicht hat, braucht Databricks nicht zwingend als nächstes Plattformprojekt. Dann liegt die eigentliche Arbeit eher bei Ownership, Datenmodell und fachlichen Prozessen. Das Ziel ist weniger Reibung zwischen Datenbasis, Analyse, KI und Betrieb.
Vor dem nächsten Plattformschritt sollte das Rechtemodell in Unity Catalog stehen, bevor breiter Zugriff freigeschaltet wird.
Vereinfacht die Data Intelligence Platform oder erzeugt sie zusätzliche Komplexität?
Ob die Data Intelligence Platform bei euch wirklich vereinfacht oder zusätzliche Komplexität erzeugt, lässt sich in einem ersten Data & AI Assessment gut einordnen.
- welche Workloads aus Engineering, BI und KI wirklich auf eine gemeinsame Plattform gehören
- welche Risiken bei Governance, Kosten und Anbindung vor dem nächsten Ausbau geprüft werden sollten
- welcher Migrations- und Betriebspfad zu eurer Ausgangslage passt
FAQ
Sie ist Databricks' Architektur- und Produktbegriff für ein Bündel aus Data Engineering, Data Warehousing, BI und KI auf einer gemeinsamen Lakehouse-Grundlage. Daten liegen in Delta Lake, die Verwaltung läuft über Unity Catalog, darüber sitzen Compute, Reporting und Modelle. Der Wert entsteht durch gemeinsame Datenhaltung, Governance und Compute, die alle Workloads teilen.
