Konzeptkarte

Databricks

Stand 2026-08-29

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist Databricks?

Databricks ist eine Daten- und KI-Plattform, aufgebaut um die **Lakehouse**-Idee: eine Speicherschicht, die offene Tabellenformate hält, mit Engines für SQL, Streaming, Data Science und Machine Learning, die dieselben Tabellen lesen, statt dass jede ihre eigene Kopie führt.

Worum es geht

Databricks ist eine Daten- und KI-Plattform, aufgebaut um die Lakehouse-Idee: eine Speicherschicht, die offene Tabellenformate hält, mit Engines für SQL, Streaming, Data Science und Machine Learning, die dieselben Tabellen lesen, statt dass jede ihre eigene Kopie führt. Den größten Teil seines Lebens war es aus Sicht einer SAP-Praxis ein benachbarter Stack — etwas, das der Kunde ebenfalls besaß und das jemand anderes administrierte.

Das änderte sich, als SAP es in Business Data Cloud einbettete. BDC liefert eine Databricks-Fähigkeit innerhalb des SAP-Bestands aus, und die Bedeutung für einen Berater liegt nicht in der Technologie: sie liegt darin, dass sich die Grenze verschoben hat. Fragen, die früher mit „das liegt auf der Datenplattformseite“ beantwortet wurden, landen jetzt innerhalb eines SAP-Gesprächs, und vom Berater im Raum wird erwartet, eine Meinung dazu zu haben.

Wofür es tatsächlich gut ist, unverblümt gesagt. Databricks verdient seinen Platz dort, wo die Arbeit großskalige Transformation, Streaming-Ingestion und Machine Learning auf Daten ist, die nicht nur SAP-Daten sind — die Workloads, für die eine semantische Modellierungsschicht nicht ausgelegt ist. SAP Datasphere verdient seinen Platz dort, wo die Arbeit Geschäftssemantik, gesteuerte Wiederverwendung und ein Modellierungsparadigma ist, das SAP-Daten bereits sprechen. Keines ersetzt das andere, und eine Architektur, die die Wahl als Entweder-oder behandelt, endet meist damit, die semantische Schicht von Hand in Notebooks nachzubauen.

Das Gelenk sind die Daten, nicht das Werkzeug. Was die Paarung tragfähig macht, ist offenes Teilen von Tabellen zwischen beiden Seiten statt einer weiteren Kopie der Daten: die SAP-Seite behält Semantik und Governance, die Lakehouse-Seite behält Skalierung und die ML-Oberfläche. Der Fehlermodus, der es wert ist, benannt zu werden, ist Duplizierung — der Moment, in dem dieselbe Geschäftsentität einmal in einem semantischen Modell und einmal in einem Notebook definiert wird, driften die beiden Definitionen auseinander, und die Frage „welche Zahl stimmt“ hat keinen Verantwortlichen.

Wo der Wert eines Beraters liegt. Nicht im Betrieb von Clustern. Er liegt darin, die Person zu sein, die sagen kann, welche Fragen auf welche Seite gehören, was die Grenze überquert, und wer die Definition besitzt, wenn es dazu kommt. Das ist ein Semantik- und Governance-Gespräch, und es ist eines, das ein SAP-Analytics-Berater besser führen kann als jeder andere im Raum.

Die Bausteine, die man namentlich kennen sollte. Unter dem Marketing sind vier Dinge, die ein Berater einordnen können sollte. Delta Lake ist das offene Tabellenformat, das Dateien auf Objektspeicher transaktionales Verhalten verleiht — der Grund, warum ein Lakehouse sicher von mehreren Engines gleichzeitig gelesen und geschrieben werden kann. Unity Catalog ist die Governance-Schicht: Kataloge, Schemata, Tabellen, Eigentümerschaft, Zugriff und Lineage an einem Ort, und die Oberfläche, auf der jedes glaubwürdige „wer darf das sehen“-Gespräch stattfindet. Delta Sharing ist ein offenes Protokoll, um einer anderen Plattform live-Lesezugriff auf eine Tabelle zu geben, ohne sie zu kopieren. Mosaic AI und MLflow sind die Modellseite — Training, Tracking, Serving. Alles andere in einem Databricks-Bestand hängt an diesen vier.

Wie SAP es tatsächlich angebunden hat. SAP hat Business Data Cloud im Februar 2025 als gemeinsames Angebot mit Databricks gestartet, mit einem eingebetteten SAP Databricks innerhalb des SAP-Bestands, und später BDC Connect ausgeliefert für Kunden, die bereits einen eigenen Databricks-Workspace betreiben. Beide Wege stützen sich auf dieselbe Idee: Tabellen teilen statt kopieren. Was für einen Berater zählt, ist das Detail darunter — SAPs semantische Metadaten können mit den geteilten Daten mitreisen, sodass die Lakehouse-Seite den SAP-Geschäftskontext lesen kann, statt ihn aus Feldnamen neu abzuleiten. Das ist der Unterschied zwischen einem Share und einem Export, und es ist das gesamte Argument dafür, es so zu tun.

Die Entscheidung, und der Trade-off, den sie verbirgt. Die Frage, die ein Kunde stellt, ist „Datasphere oder Databricks“; die Frage, die es wert ist, beantwortet zu werden, ist, welche der tatsächlichen Fragen des Kunden auf welche Seite gehört, und wer jede Geschäftsdefinition besitzt, sobald die Grenze gezogen ist. Der Trade-off ist real: eine Definition auf die Lakehouse-Seite legen, gewinnt Skalierung und ML-Reichweite, verlässt aber die SAP-semantische Schicht; sie auf der SAP-Seite behalten, gewinnt gesteuerte Wiederverwendung, kostet aber Bewegung, wenn der ML-Workload sie braucht. Kein Trade-off ist, sie zweimal zu definieren — das ist keine Wahl, das ist ein Fehler, der sechs Monate später bei einem Audit auffällt.

Warum es zählt

Seit BDC es eingebettet hat, ist Databricks kein Stack mehr, zu dem ein SAP-Berater keine Meinung haben kann — die Grenze hat sich in den SAP-Bestand hinein verschoben.
Es ist im Markt, den diese Plattform verfolgt, noch immer ein dünner Skill: 244 der 9.103 veröffentlichten Firmenprofile erwähnen Databricks, gegenüber 4.184 für S/4HANA, und 60 von 3.307 aktiven Opportunity-Zeilen nennen es (gemessen 2026-08-29 auf public/api/company-profiles.json und public/api/contracts.json).
Die Entscheidung, die es erzwingt — Semantik hier, Skalierung dort, wer die Definition besitzt — ist genau die, die standardmäßig keinen Verantwortlichen hat, weshalb es sich lohnt, die Person im Raum zu sein, die sie klären kann.

Kernpunkte

Lakehouse-Plattform: eine offene Speicherschicht, mehrere Engines lesen dieselben Tabellen, statt dass jede eine Kopie führt.
Vier Bausteine, die man namentlich kennen sollte: Delta Lake (offenes Tabellenformat), Unity Catalog (Governance), Delta Sharing (offenes Sharing-Protokoll), Mosaic AI/MLflow (Modell-Lebenszyklus).
SAP hat Business Data Cloud im Februar 2025 mit Databricks gestartet und ein SAP Databricks in den SAP-Bestand eingebettet; BDC Connect deckt Kunden ab, die bereits einen Workspace besitzen.
Das Gelenk ist ein SHARE, keine Kopie — und SAPs semantische Metadaten können mit den geteilten Daten mitreisen, sodass der Geschäftskontext nicht aus Feldnamen neu abgeleitet wird.
Es trägt großskalige Transformation, Streaming und ML auf Daten, die nicht nur SAP-Daten sind; Datasphere trägt Geschäftssemantik und gesteuerte Wiederverwendung.
Keines ersetzt das andere; die Wahl als Entweder-oder zu behandeln bedeutet meist, die semantische Schicht von Hand in Notebooks nachzubauen.
Der Fehlermodus ist DUPLIZIERUNG einer Geschäftsdefinition über beide Seiten hinweg — danach hat „welche Zahl stimmt“ keinen Verantwortlichen.
Der Wert eines Beraters liegt hier in Grenzarbeit — Fragen zuordnen, benennen was die Grenze überquert, Eigentümerschaft zuweisen —, nicht im Betrieb von Clustern.

Quellen

In der App öffnen →