Konzeptkarte

BDC Connect for Databricks

Stand 27. September 2026

Redaktion: Cédric Mary, 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 BDC Connect for Databricks?

BDC Connect for Databricks ist die Zero-Copy-Brücke, über die SAP Business Data Cloud und ein Databricks Lakehouse gegenseitig auf ihre jeweils verwalteten Daten zugreifen können, ohne dass eine der beiden Seiten auch nur eine einzige Zeile kopiert, exportiert oder repliziert. Für jeden Architekten, der eine Databricks-lastige Analytics-Landschaft gegen SAPs eigene semantische Schicht abwägt, verändert dies die Fragestellung von „welche Plattform gewinnt“ zu „wie teilen sich die beiden Plattformen eine gemeinsame, governte Wahrheit“.

Was es ist und warum es wichtig ist

Historisch bedeutete die Anbindung von SAP-Daten an ein Databricks Lakehouse — oder umgekehrt — den Aufbau und Betrieb einer Extract-Transform-Load-Pipeline: ein Batch-Job, ein Staging-Bereich, eine zweite Kopie der Daten, die gegenüber der Quelle aus der Synchronisation geraten konnte und die eigene Zugriffskontrollen, eigenes Monitoring und eine eigene Fehlerbehebung benötigte. BDC Connect for Databricks entfernt diese Pipeline vollständig, indem es das offene Delta-Sharing-Protokoll nutzt — denselben Mechanismus, den Databricks bereits verwendet, um Delta-Lake-Tabellen über Organisationsgrenzen hinweg zu teilen —, gepaart mit SAPs eigener Governance-Schicht für Data Products innerhalb von BDC. Das Ergebnis ist kein Konnektor im klassischen Sinn; es ist ein gemeinsamer Governance-Vertrag, der über zwei getrennte Speicherebenen gelegt wird, zwischen denen tatsächlich nie Daten bewegt werden.

Wie es funktioniert

Auf der einen Seite stellt BDC seine governten Data Products — die um die semantische Schicht angereicherten, auf Datasphere oder BW/4HANA aufgebauten Views — als Delta-Share-Endpunkte bereit. Databricks Unity Catalog, der Metastore der Plattform, registriert diesen Share über eine Share-URL und ein bereichsbeschränktes Bearer-Token, und ab diesem Zeitpunkt kann ein Databricks-Notebook das SAP-Data-Product direkt mit Standard-Spark-SQL abfragen, wobei die Lesevorgänge unmittelbar vom BDC-verwalteten Speicher zum Databricks-Compute-Cluster fließen. Die umgekehrte Richtung funktioniert nach demselben Prinzip: Eine von Databricks verwaltete Delta-Tabelle kann als externes Data Product innerhalb von BDC registriert und anschließend aus einer SAP-Analytics-Cloud-Story oder einer BDC Analytical Application über eine Live-Verbindung konsumiert werden, wobei die Daten die gesamte Zeit über im von Databricks verwalteten Cloud-Speicher verbleiben. Governance ist bei jedem Lesevorgang in beide Richtungen dabei — ein Data Product trägt einen Owner, eine Aktualitätszusage, eine Sensitivitätsklassifikation und eine Abonnentenliste, und auf SAP-Seite definierte Maskierungsregeln auf Spaltenebene werden auch dann durchgesetzt, wenn die Daten von der Databricks-Seite abgefragt werden.

Wann es einzusetzen ist, und der Kompromiss

Die klassische Alternative — Batch-Replikation in eine Staging-Schicht, sei es über klassische ETL-Werkzeuge oder SAPs eigene Replication Flows — bleibt die richtige Wahl, wenn das konsumierende System die Daten vor der Nutzung transformiert, umgeformt oder stark aggregiert benötigt, oder wenn nicht beide Plattformen das Delta-Sharing-Protokoll beherrschen. BDC Connect for Databricks gewinnt klar, wenn die Anforderung ein lesender Zugriff auf governte, aktuelle Daten ohne erforderliche Transformation ist und wenn Quelle und Konsument bereits in Ökosystemen sitzen, die Delta Sharing nativ unterstützen — weil es die Pipeline-Wartung eliminiert, die Replikationsverzögerung vollständig entfernt und die Doppelspeicherkosten für das Vorhalten zweier Kopien vermeidet. Der Kompromiss ist eine architektonische Bindung an das Delta-Sharing-Protokoll und an Unity Catalog als governenden Metastore auf der Databricks-Seite; ein Haus, das noch nicht in Databricks investiert ist, gewinnt wenig, wenn es diesen Weg gegenüber einem rein SAP-nativen Stack wählt, und ein Haus mit starkem Transformationsbedarf wird weiterhin irgendwo eine Pipeline benötigen — nur nachgelagert zum Zero-Copy-Lesevorgang statt vorgelagert. Es lohnt sich zudem, dies gegen BDC Connect for Snowflake oder für Microsoft Fabric abzuwägen, die dieselbe Idee eines Governance-Vertrags auf andere Lakehouse-Plattformen anwenden — die richtige Wahl folgt dort, wo der tatsächliche Compute-Bestand der Organisation bereits liegt, nicht einer abstrakten Plattformpräferenz.

Fallstricke und Anti-Patterns

Teams behandeln BDC Connect mitunter als Ersatz für Datenmodellierungsdisziplin und nehmen an, dass, weil keine Daten bewegt werden, auf der Databricks-Seite keine Governance-Arbeit nötig sei — in der Praxis müssen die Unity-Catalog-Berechtigungen weiterhin aktiv gepflegt werden, und ein BDC-Data-Product mit schwachen Lineage-Metadaten erscheint auf der Databricks-Seite als ebenso schwache, ungovernte Tabelle. Ein weiterer häufiger Fehler ist die Unterschätzung des Token- und Share-Registrierungs-Lebenszyklus: OAuth-bereichsbeschränkte Bearer-Token laufen ab und müssen rotiert werden, und ein Share, der still aufhört, sich zu aktualisieren, erzeugt eine stille Veralterung, die auf den ersten Blick wie eine Live-Verbindung aussieht. Ein dritter Fallstrick ist die Annahme, Zero-Copy bedeute Null Kosten — jede Abfrage gegen eine geteilte Delta-Tabelle verbraucht weiterhin Compute auf der lesenden Seite, und eine schwere analytische Workload gegen ein von BDC bereitgestelltes Data Product kann reale Databricks-Compute-Kosten erzeugen, die nicht eingeplant waren, als die Pipeline-Eliminierung als reine Einsparung präsentiert wurde.

Die Joule-Perspektive, September 2026

BDC Connect for Databricks ist eine Datenbrücke, keine Modellbrücke — das ist die erste Klarstellung, wenn ein Kunde nach dem Bezug zu Joule oder SAP AI Core fragt. Der Konnektor bewegt governte Zeilen zwischen Datasphere/BW4HANA und Databricks-Delta-Tabellen; er leitet keine Inferenzaufrufe weiter, und SAPs eigener Generative AI Hub ruft darüber kein auf Databricks gehostetes Modell auf. Was er ermöglicht, ist das Föderationsmuster, das die eigene Bewertung des Databricks Mosaic AI Agent Framework (C173) durch diese Plattform beschreibt: Ein Joule-Agent bleibt der prozessbewusste Orchestrator, mit dem ein Fachanwender tatsächlich spricht, und zieht einen Mosaic-AI-Agenten als spezialisiertes Tool hinzu, wenn das Reasoning wirklich Delta-Tabellen, ein registriertes ML-Modell oder einen Vector-Search-Index braucht, der nativ auf Databricks lebt. Dieser Konnektor ist die Verrohrung, die es diesem spezialisierten Tool erlaubt, SAP-Ist-Daten — etwa S/4-Hauptbuchdaten — ohne Exportschritt zu lesen, wobei SAPs Data Access Controls weiterhin bestimmen, welche Zeilen der Leser auf Databricks-Seite sehen darf.

Die umgekehrte Richtung zählt für KI-Arbeit genauso: Wenn ein auf Databricks trainiertes Modell (ein Demand-Sensing-Score, eine Abwanderungsprognose) eine Joule-Konversation oder eine SAP-Analytics-Cloud-Story erreichen soll, besteht das richtige Muster darin, die Modellausgabe als Delta-Tabelle zu veröffentlichen und sie in Richtung Databricks→BDC als externes BDC-Data-Product zu registrieren — nicht ein gleichwertiges Modell in SAP AI Core neu zu trainieren. SAPs eigene tabellarische Foundation-Modelle (SAP-RPT-1.5, sowie TabPFN-3.5-Plus seit dessen GA am 15.09.2026 in AI Core) lösen ein anderes Problem — In-Context-Vorhersage auf strukturierten Daten ohne Trainingsschritt — und sind kein Grund, ein bereits funktionierendes Mosaic-AI-Modell zu duplizieren.

Eine Governance-Lücke, die es einem Kunden zu nennen lohnt, der auf der SAP Business AI Platform aufbaut (die seit der Sapphire am 12.05.2026 BTP, BDC und Business AI in einer governten Umgebung vereint): Ein über diesen Konnektor bereitgestelltes, aus Databricks stammendes Data Product erscheint nicht automatisch als Knoten, über den der SAP Knowledge Graph reasonen kann. Jemand muss es als vollwertige Datasphere-Entität modellieren, bevor ein Joule-Agent eine Antwort darauf mit derselben Verlässlichkeit gründen kann wie auf nativen SAP-Daten — diesen Modellierungsschritt beim Scoping einer Architektur, in der ein Joule-Agent einen Mosaic-Agenten aufruft, als Liefergegenstand behandeln, nicht als Annahme.

Warum es zählt

Das direkte SQL-Abfragebeispiel ist der konkrete Beleg dafür, dass die Integration wirklich Zero-Copy ist und keine Marketingaussage — Lesevorgänge fließen direkt vom BDC-verwalteten Speicher zum Databricks-Compute-Cluster.
Die OAuth-2.0-Bearer-Token-Registrierung pro BDC-Mandant ist der eigentliche Sicherheitsmechanismus — ein konkretes Detail, das vor der Scoping-Phase gegen das IAM-Modell eines Kunden geprüft werden sollte.
Governance (Owner, Freshness-SLA, Klassifikation) gilt für jedes in beide Richtungen veröffentlichte Data Product — dies ist ein governter Marktplatz, keine rohe Datenleitung.

Kernpunkte

BDC Connect for Databricks ist eine bidirektionale Zero-Copy-Brücke auf Basis des offenen Delta-Sharing-Protokolls — eine Delta-Tabelle wird zum abfragbaren BDC Data Product und umgekehrt.
Keine ETL-Pipeline, keine Staging-Kopie: die Daten bleiben in ihrem maßgeblichen Speicher, also gibt es keine zweite Kopie, die abzusichern, zu überwachen oder abzugleichen wäre.
Die Architekturfrage verschiebt sich von „welche Plattform gewinnt“ zu „wie teilen beide Plattformen eine governte Wahrheit“.
Die Zugriffskontrolle setzt die teilende Seite durch — die Berechtigungen des Data Product vor der Freigabe modellieren, nicht danach.
Erreichte am 06.10.2025 die allgemeine Verfügbarkeit — der erste produktive, bidirektionale Zero-Copy-Kanal zwischen BDC und einem Databricks-Lakehouse.
Die Share-Registrierung auf Databricks-Seite nutzt ein pro BDC-Tenant skopiertes OAuth-2.0-Bearer-Token — nach Zeitplan rotieren, nicht als einmaligen Einrichtungsschritt behandeln.
Es ist eine Datenbrücke, keine Modellbrücke: Es leitet keine Inferenzaufrufe des Generative AI Hub nach Databricks weiter und umgekehrt — Modellausgaben überqueren die Grenze nur als veröffentlichte Delta-Tabellen oder BDC-Data-Products.
Es setzt voraus, dass der konsumierende Databricks-Workspace auf Unity Catalog läuft; ein Workspace, der noch den klassischen Hive-Metastore nutzt, kann keinen Delta Share konsumieren, bis er migriert ist.

Quellen

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.