SAP-Daten nach Databricks: Ein strategischer Leitfaden zur Datenintegration
- Databricks
- Databricks
- 7 Min Lesezeit
Dr. Andreas Wagner
Crew? Steht. Rakete? Ausgewählt. Jetzt folgt die Frage, die über Erfolg oder Abbruch entscheidet: Wie kommt der Treibstoff eigentlich in das System?
Historisch betrachtet agierten SAP-Systeme als geschlossene Ökosysteme. Wertvolle Unternehmensdaten waren in proprietären Strukturen gebunden, was den Zugriff für moderne Analytics-Plattformen und künstliche Intelligenz zu einer ressourcenintensiven Herausforderung machte. In der heutigen Daten-Economy, in der die Verarbeitungsgeschwindigkeit von Informationen den primären Wettbewerbsvorteil darstellt, ist diese Isolation nicht mehr tragbar.
Mit der Einführung der SAP Business Data Cloud (BDC) vollzieht SAP eine strategische Kehrtwende hin zu einem offenen Ökosystem. Diese Transformation ermöglicht es Unternehmen, die Databricks Data Intelligence Plattform nicht mehr nur als externes Zielsystem, sondern als integralen Bestandteil einer hybriden Architektur zu betreiben.
Inhaltsverzeichnis
- 1. Die sechs Pfade der Datenextraktion
- Methode 1: JDBC/ODBC (Infrastrukturbasierter Direktzugriff)
- Methode 2: SAP SLT (Trigger-basierte Echtzeit-Replikation)
- Methode 3: SAP Datasphere Premium Outbound (Semantische Abstraktion)
- Methode 4: 3rd Party (Compliance-Risiko ODP-RFC)
- Methode 5: Zero-Copy Delta Share
- Methode 6: ABAP SDK für Hyperscaler
- 2. Technische Rahmenbedingungen
- 3. Fazit und Handlungsempfehlungen
1. Die sechs Pfade der Datenextraktion
Die Wahl der Integrationsmethode ist eine Entscheidung über die Skalierbarkeit, die Latenz und den Erhalt der geschäftlichen Semantik. Oder anders gesagt: Es geht darum, welche Leitungen man verlegt, bevor man überhaupt an den Start denken kann. Klingt logisch, oder? In der Praxis haben sich fünf Ansätze etabliert.
Methode 1: JDBC/ODBC (Infrastrukturbasierter Direktzugriff)
Dieser klassische Ansatz nutzt den SAP HANA JDBC-Treiber für eine Punkt-zu-Punkt-Verbindung. Es handelt sich um einen technisch direkten Weg, bei dem Abfragen unmittelbar gegen das Datenbankschema ausgeführt werden. Während dies für punktuelle Ad-hoc-Analysen funktional ist, stößt das Modell bei massiven Datenvolumina an seine Grenzen. Da ein natives Change Data Capture (CDC) fehlt, müssen inkrementelle Logiken manuell über Zeitstempel implementiert werden. Zudem belastet die Serialisierung der Daten auf dem Applikationsserver die Systemressourcen, was häufig zu Performance-Engpässen führt.
Sinnvolle Einsatzszenarien für diesen Ansatz:
- Rapid Prototyping & PoCs: Wenn für einen Proof-of-Concept schnell Ergebnisse benötigt werden und die Infrastruktur für BDC oder OData noch nicht final bereitgestellt ist.
- Extraktion von Stammdaten: Für Tabellen mit geringem Volumen und niedriger Änderungsrate (z. B. Buchungskreise, Werke oder Materialarten), bei denen eine einfache Batch-Extraktion ausreicht.
- Data Discovery: Wenn Analysten ad-hoc explorative Abfragen direkt auf HANA-Schattenviews durchführen müssen, ohne eine dauerhafte Pipeline zu etablieren.
- Systeme ohne ODP-Lizenzierung: In älteren Landschaften, in denen das ODP-Framework oder moderne Konnektoren technisch noch nicht unterstützt werden.
- Architektur-Risiko: Gemäß SAP Note 2415336 führt dieser Ansatz zu einer vollständigen semantischen Entkopplung. Da der SAP-Applikationsserver umgangen wird, fehlen sämtliche Metadaten, Währungsumrechnungen und Sicherheitsrichtlinien (DCL) der Anwendungsebene.
- TCO-Falle: Die gesamte Business-Logik muss in Databricks manuell rekonstruiert werden, was zu hohen Aufwänden im Data Engineering und doppelter Pflege der Datenmodell führt.
Methode 2: SAP SLT (Trigger-basierte Echtzeit-Replikation)
Der SAP Landscape Transformation Replication Server erfasst Datenänderungen auf Tabellenebene mittels Datenbank-Triggern nahezu in Echtzeit.
Technischer Aufwand: Die Implementierung von SLT ist hochgradig komplex und ressourcenintensiv. Sie erfordert eine dedizierte Server-Infrastruktur sowie tiefgreifendes Expertenwissen für die Konfiguration der Delta-Mechanismen und das Monitoring der Datenbank-Trigger. Da die Replikation auf rein technischer Tabellenebene erfolgt, müssen sämtliche betriebswirtschaftlichen Verknüpfungen, Joins und semantischen Logiken (z.B. Währungsumrechnungen) im Zielsystem Databricks komplett manuell rekonstruiert werden. Dies führt zu einem signifikanten initialen Entwicklungs- und Wartungsaufwand.
Wann lohnt sich dieser Ansatz? Trotz des hohen Aufwands ist SLT die Methode der Wahl für:
- Mission-Critical Real-Time: Prozesse, die eine Latenz im Sekundenbereich erfordern (z.B. Just-in-Time-Produktion, Lagerbestandsführung in Hochgeschwindigkeits-Logistikzentren).
- Kontinuierlicher Datenstrom: Szenarien, in denen ein Batch-Fenster aufgrund von 24/7-Betrieb nicht existiert und Daten permanent fließen müssen.
- Legacy-Integration: Wenn Quellsysteme keine modernen OData- oder Zero-Copy-Schnittstellen unterstützen, aber dennoch Echtzeitdaten liefern müssen.
- Strategische Deadline: Ein Standalone SLT-Server basiert auf SAP NetWeaver 7.5. Laut SAP Note 2881788 endet die Mainstream-Wartung hierfür am 31.12.2027.
- Logik-Verlust: Da meist Roh.Tabellen repliziert werden, müssen geschäftliche Verknüpfungen (z.B. Hierarchien, Währungskonvertierungen) in Databricks aufwendig nachgebaut werden.
Hier fungiert die SAP Datasphere als intelligenter Orchestrierungs-Layer. Sie bündelt Daten aus S/4HANA- oder BW-Systemen und stellt sie über koordinierte Replication Flows bereit. Der entscheidende Vorteil liegt im Erhalt des geschäftlichen Kontextes. Die Daten werden innerhalb der SAP-Sicherheitshülle semantisch aufbereitet. Beim Schreiben in den Objektspeicher (ADLS/S3) bleibt die logische Struktur erhalten, was die anschließende Verarbeitung in Databricks erheblich beschleunigt.
Sinnvolle Einsatzszenarien für diesen Ansatz:
- Enterprise-Reporting auf harmonisierten Daten: Wenn Daten aus mehreren SAP-Quellen (z. B. verschiedene Buchungskreise aus unterschiedlichen ERP-Instanzen) bereits in der Datasphere konsolidiert wurden und als einheitliches Produkt an Databricks übergeben werden sollen.
- Governed Data Products für Fachbereiche: Bereitstellung von zertifizierten Datenmodellen, bei denen die Einhaltung von Business-Regeln und Berechtigungen bereits auf Ebene der Datasphere sichergestellt wurde.
- Vermeidung von Logik-Nachbau: Szenarien, in denen tief verschachtelte CDS-View-Hierarchien oder komplexe Berechnungen (z.B. kalkulatorische Kennzahlen) nicht mühsam in Databricks rekonstruiert werden sollen.
- Hybride Datenintegration: Wenn die Datasphere als Brücke dient, um Daten aus On-Premise-Systemen (z. B. SAP BW/4HANA) sicher und kontrolliert in einen Cloud-Storage für die Nutzung in Databricks zu replizieren.
Methode 4: 3rd Party (Compliance-Risiko ODP-RFC)
Spezialisierte ETL-Werkzeuge (z. B. Theobald Software, Fivetran oder Hyperscaler-Dienste) haben über Jahre die Lücke zwischen SAP und Drittplattformen geschlossen. Diese Methode steht jedoch vor einer kritischen Zäsur, die ein tiefes Verständnis der zugrunde liegenden Protokolle erfordert.
Die Rolle der RFC-Schnittstelle: Der Remote Function Call (RFC) ist das technologische Nervensystem der SAP-Welt. Er erlaubt es externen Systemen, Funktionsbausteine innerhalb des SAP-ABAP-Stacks direkt aufzurufen. Drittanbieter nutzten RFC primär als Transportprotokoll für das Operational Data Provisioning (ODP) Framework.
Warum wurde dieser Weg genutzt?
- Performance: RFC bietet im Vergleich zu HTTP-basierten Schnittstellen einen sehr hohen Datendurchsatz.
- Delta-Fähigkeit: Über ODP-RFC konnten Drittanbieter nativ auf die Delta-Queues der SAP-Extraktoren zugreifen. Dies ermöglichte ein effizientes Change Data Capture (CDC) für riesige Tabellen, ohne die Quellsysteme durch Voll-Extraktionen zu überlasten.
- Universeller Zugriff: Es war der „Generalschlüssel“, um sowohl auf klassische SAPI-Extraktoren (Service API Extraktoren), BW-Provider als auch auf moderne ABAP CDS Views zuzugreifen.
Was hat sich verändert?
Mit den SAP-Hinweisen 3255746 und 3439624 deklariert SAP die ODP-RFC-API exklusiv für die Kommunikation zwischen SAP-Anwendungen. Technisch bedeutet dies, dass SAP einen Validierungsmechanismus einführt: Ab Juni 2026 prüft ein Security Patch bei jedem ODP-Aufruf den „Subscriber-Typ“. Handelt es sich um eine Nicht-SAP-Applikation, wird der Zugriff blockiert. SAP erzwingt damit den Umstieg auf modernere, besser kontrollierbare Schnittstellen wie ODP-OData oder den strategischen Zero-Copy-Ansatz (Methode 5), um Sicherheitsrisiken zu minimieren und IP-Schutzrechte auf Datenebene besser durchsetzen zu können. Allerdings schränkt SAP die Nutzung von OData-Services für den Datenexport von Non-SAP Systemen mit der SAP API Policy unter 2.2.2 ebenfalls stark ein.
Der architektonische Paradigmenwechsel – oder auch der sauberste Weg zum Start?
Dies ist die effizienteste Methode der modernen Datenintegration – und architektonisch der eleganteste Ansatz, den der Systemcheck zu bieten hat. Statt Daten aufwendig durch Leitungen zu pumpen, entfällt die physische Datenbewegung vollständig.
Basierend auf dem offenen Delta Sharing Protokoll generiert BDC Connect kryptografisch gesicherte Kurzzeit-Links (Pre-signed URLs). Die Databricks Worker-Nodes greifen direkt auf die Originaldaten im SAP Object Store zu – ohne zwischengeschaltete Applikationsserver, ohne redundante Speicherkopien, ohne Engpässe. Das Ergebnis ist nahezu unbegrenzte Skalierbarkeit bei maximalem Datenschutz.
Regeln zur Datenpersistierung:
- Temporäre Materialisierung: Das Speichern von Datenkopien im Zielsystem (z. B. Databricks) ist ausschließlich zur Performance-Optimierung gestattet. Dies verhindert wiederholte Abfragen identischer Datensätze und verbessert die User Experience. Eine dauerhafte Speicherung der unveränderten Originaldaten als primärer Zugriffspunkt ist jedoch untersagt.
- Permanente Speicherung durch Enrichment: Sobald SAP-Daten transformiert, aggregiert oder durch KI-Modelle angereichert werden (z. B. Joins mit Drittdaten), verliert das Resultat den Status eines reinen SAP-Datenprodukts. Diese veredelten Daten dürfen zeitlich unbegrenzt im Zielsystem (z. B. Databricks Delta Lake) persistiert werden.
- Distributionsverbot: Die bereitgestellten Datenprodukte dürfen innerhalb der angebundenen Plattform genutzt, aber nicht an nachgelagerte Systeme außerhalb des SAP- oder Partner-Ökosystems weiterverteilt werden (kein Pass-Through).
Methode 6: ABAP SDK für Hyperscaler
Der autonome ”Clean Core-Weg – Maximale Kontrolle ohne Middleware
Während andere Methoden darauf warten, dass Daten abgeholt werden (Pull), übernimmt hier das SAP-System selbst das Steuer. Über das ABAP SDK (verfügbar für AWS, Azure und GCP) schreibt der ABAP-Stack Daten aktiv und hoch performant direkt in den Cloud-Storage (z.B. S3, Cloud Storage oder ADL Gen2), auf welchem die Databricks-Umgebung operiert. Dieser Ansatz ist die architektonische Antwort auf das ”Clean Core”-Paradigma.
Vorteile der Cloud-nativen Integration:
- Eliminierung der Middleware: Es ist keine zusätzliche ETL-Schicht erforderlich. Die Kommunikation erfolgt verschlüsselt direkt zwischen SAP und dem Hyperscaler –Storage.
- Performance & Skalierung: Da Daten im hocheffizienten Parquet- oder JSON-Format gepusht werden, entfällt die serielle Last auf dem Applikationsserver, die bei klassischen RFC-Abfragen oft zum Bottleneck wird.
Regeln zur Datenbereitstellung:
- Storage-basierte Ingestion: Die Daten landen zunächst in einer ”Landing Zone” des Cloud-Speichers. Von dort aus übernimmt Databricks die Orchestrierung. Dies ermöglicht eine strikte Trennung zwischen SAP-Transaktionslast und Analytics-Compute.
- Governance: Die Hoheit über den Extraktionszeitpunkt und den Umfang der Daten bleibt vollständig im SAP-System, was die Einhaltung interner Compliance vereinfacht.
- Skalierung vs. Aufwand: Die Implementierung via ABAP SDK bietet zwar maximale Performance und Unabhängigkeit, ist jedoch im Vergleich zu BDC Connect mit einem höheren initialen Entwicklungsaufwand verbunden.
Andreas & Yvonnes Databricks-Guide
Möchten Sie alle wichtigen Informationen auf einen Blick?
Laden Sie sich jetzt den kostenlosen Guide zur SAP Databricks!
2. Technische Rahmenbedingungen
Technischer Vergleich der Integrationsparameter
Regulatorische Notwendigkeit: Die ODP-RFC Migration 2026
Der SAP-Hinweis 3255746 definiert die ODP-RFC API als exklusiv für die Kommunikation zwischen SAP-Anwendungen. Für alle Drittanbieter-Tools bedeutet dies das Ende eines etablierten, aber nun als unsicher klassifizierten Zugriffsweges.
Unternehmen, die weiterhin auf RFC-basierten Extraktoren aufsetzen, müssen bis zum Security Patch Day am 9. Juni 2026 eine neue Zielarchitektur implementiert haben.
Universal Governance: End-to-End Sicherheit
In einer hybriden Datenlandschaft darf die Sicherheit nicht an den Systemgrenzen enden – so wenig wie ein Kontrollzentrum nur für eine Hälfte der Space Mission zuständig ist. Die moderne Architektur erfordert eine lückenlose Identitätsharmonisierung:
- Microsoft Entra ID fungiert als zentraler Identity Provider.
- Identity Provisioning System (IPS) synchronisiert Identitäten automatisiert in den SAP Cloud Identity Service (IAS).
- Unity Catalog (Databricks) nutzt dieselben Identitäten für granulare Zugriffskontrollen auf Tabellen-, Zeilen- und Spaltenebene.
Das Ergebnis: Rollenänderungen oder Deaktivierungen in Entra ID greifen sofort und konsistent – von der SAP Datasphere bis zum Databricks Notebook.
Wirtschaftlichkeit und TCO-Betrachtung
Traditionelle Integrationen binden erhebliche Ressourcen im Bereich des manuellen Pipeline-Managements (Data Plumbing). Oft fließen bis zu 80 % der Projektressourcen in die Wartung dieser Verbindungen statt in die eigentliche Wertschöpfung. Der Zero-Copy-Ansatz reduziert diese Total Cost of Ownership (TCO) durch die Adressierung zentraler Kostentreiber:
- Infrastrukturgebühren: Kosten entstehen primär durch Inter-Region-Datentransfers und prozessierte API-Anfragen. Da jedoch keine redundanten Speicherkopien in Drittsystemen verwaltet werden müssen, sinken die Bruttospeicherkosten.
- Premium Fees: Bei der Nutzung von Partnerplattformen wie Snowflake oder Microsoft Fabric wird ein Uplift basierend auf dem Compute-Workload der SAP-Datenprodukte berechnet. Dieser entfällt bei der Nutzung nativer OEM-Lösungen innerhalb des SAP-Ökosystems.
- Operativer Aufwand: Der Wegfall komplexer ETL-Wartung reduziert die Personalkosten für Data Engineers signifikant.
Im Vergleich zu den Lizenzgebühren für Drittanbieter-Tools und den massiven personellen Aufwänden für den klassischen Pipeline-Bau bietet der Zero-Copy-Ansatz eine architektonisch sauberere und langfristig skalierbare Kostenstruktur.
3. Fazit und Handlungsempfehlungen
Die Wahl der Integrationsmethode ist eine fundamentale Entscheidung für die Zukunftsfähigkeit der Datenstrategie. Während Legacy-Schnittstellen unter regulatorischem und technischem Druck stehen, bietet die SAP Business Data Cloud den Weg in ein skalierbares und offenes Ökosystem.
Identifizieren Sie umgehend alle RFC-basierten Schnittstellen mittels des Reports RODPS_REPL_SUBSCRIBER_ASSESS.
Ersetzen Sie wartungsintensive ETL-Strecken durch BDC Connect, um die Innovationskraft von Databricks Mosaic AI unmittelbar auf Ihren SAP-Daten zu nutzen.
Etablieren Sie SAP Databricks für tiefe SAP-Kontextanalysen und nutzen Sie BDC Connect als Brücke für die globale Enterprise-Datenintegration.
Bereit für den nächsten Schritt? Unsere Experten begleiten Sie von der Auditierung bis zur produktiven Datenintegration.
Ihre Datenstrategie ist individuell – Ihre Beratung sollte es auch sein.
Die Wahl zwischen diesen Methoden hängt von unzähligen Faktoren ab: Ihrer bestehenden Systemlandschaft, Ihren Unternehmenszielen und Ihrer Datenkultur. Eine Standardantwort gibt es nicht.
Lassen Sie uns unverbindlich darüber sprechen, welcher Weg für Sie der richtige ist. Kontaktieren Sie uns für ein persönliches Gespräch.
