Integration von SAP-Daten in Azure Databricks

Mit dem richtigen Integrationsmuster zur optimalen Anbindung von SAP-Daten an Azure Databricks

Die Integration von SAP-Daten in Azure Databricks erfordert eine bewusste Auswahl des passenden Integrationsmusters. Dabei stellen sich insbesondere zwei zentrale Fragen:

• Welches Integrationsmuster unterstützt die fachlichen Anforderungen am besten?
• Welche technischen und organisatorischen Rahmenbedingungen auf SAP-Seite müssen berücksichtigt werden?

In der Praxis lassen sich die meisten Analytics-Szenarien auf zwei grundlegende Integrationsmuster zurückführen:

• Periodische Full Loads (Snapshots)
• Delta-basierte Extraktionen bei relevanten Änderungen

SAP stellt für beide Fälle klar definierte Mechanismen bereit, die sich unterschiedlich auf Azure Databricks abbilden lassen.

1) Periodische Full Loads (Snapshots)

Für viele analytische Szenarien ist es ausreichend, Daten regelmäßig vollständig zu laden. Gemeint sind dabei zustandsorientierte Auswertungen, bei denen der fachliche Fokus auf einem konsistenten Stichtag liegt und nicht auf der lückenlosen Nachverfolgung einzelner Änderungen.

Das betrifft insbesondere Szenarien, bei denen:

• die fachliche Aussage ein periodischer Zustand ist und kein Änderungsverlauf
• eine tägliche oder mehrmals tägliche Aktualisierung ausreichend ist
• vollständige Reloads technisch beherrschbar bleiben

Dieses Integrationsmuster ist sowohl für SAP ECC als auch für SAP S/4HANA geeignet, da es auf einem generischen SAP-Mechanismus basiert, der unabhängig vom zugrunde liegenden Datenmodell funktioniert.

SAP unterstützt Full-Loads über den direkten Zugriff auf Tabellen oder Views via RFC. Die Extraktion ist damit bewusst technisch einfach gehalten. Die Verantwortung für Zeitbezug, Historisierung oder Aggregation liegt vollständig außerhalb von SAP.

Für Azure Databricks wird dieses Muster typischerweise über Azure Data Factory mit dem SAP-Table-Connector umgesetzt. ADF zieht die vollständigen Snapshots und legt sie in Azure Data Lake Storage (ADLS) ab. Azure Databricks liest sie von dort, idealerweise inkrementell über Auto Loader, und verarbeitet sie über die Medallion-Schichten (Bronze, Silver, Gold) im Lakehouse weiter.

Dieser Ansatz ist dann sinnvoll, wenn:

• Datenvolumen und Laufzeiten kontrollierbar bleiben
• keine fachliche Notwendigkeit besteht, jede einzelne Änderung separat abzubilden

Sobald sich diese Rahmenbedingungen ändern, stößt das Full-Load-Muster an seine Grenzen.

2) Delta-basierte Extraktion

Delta-basierte Extraktion wird erforderlich, sobald Änderungen fachlich relevant sind und nicht nur der Zustand, sondern auch die Veränderung selbst analysiert werden soll. Das betrifft insbesondere Szenarien mit laufenden Bewegungen, Statuswechseln oder historisierten Attributen.

Typische fachliche Auslöser sind:

• häufige Änderungen an Geschäftsvorfällen
• fachliche Notwendigkeit zur Historisierung von Zuständen
• technische oder organisatorische Grenzen bei vollständigen Reloads

Dieses Integrationsmuster ist für SAP ECC und SAP S/4HANA vorgesehen. In beiden Systemen stellt SAP mit ODP einen einheitlichen Mechanismus für inkrementelle Bereitstellung bereit.

SAP sieht für diese Anforderungen das Operational Data Provisioning Framework (ODP) vor. ODP stellt SAP-definierte Extraktoren, Delta-Queues zur inkrementellen Abholung und eine fachlich konsistente Änderungslogik bereit. Die Verantwortung dafür, was eine relevante Änderung ist, verbleibt damit im SAP-System.

Für Azure Databricks lassen sich ODP-basierte Deltas über Azure Data Factory mit dem SAP-CDC-Connector abholen und in ADLS bereitstellen. Azure Databricks übernimmt die Deltas idempotent über MERGE in Delta-Tabellen und historisiert sie dort fachlich sauber, etwa als Satellites in einem Data Vault oder als SCD-Dimensionen.

Gleichzeitig ist dieser Ansatz immer im Kontext der SAP-seitigen Nutzungs- und Compliance-Vorgaben zu bewerten. Insbesondere SAP Note 3255746 adressiert den Zugriff auf ODP Data Replication APIs durch Drittplattformen. In der Praxis bedeutet das, dass der Einsatz dieses Mechanismus häufig einer organisatorischen Prüfung unterliegt, unabhängig davon, ob er fachlich sinnvoll wäre.

Wenn ein direkter Zugriff auf ODP-Queues durch externe Plattformen nicht vorgesehen oder nicht freigegeben ist, haben sich zwei Integrationsmuster etabliert:

• SAP-nahe Extraktionsschichten über spezialisierte Anbieter, bei denen Delta-Logik kontrolliert SAP-nah umgesetzt und das Ergebnis nach ADLS bereitgestellt wird
• SAP Datasphere als Outbound-Layer, der Daten SAP-konform nach Azure Data Lake Storage Gen2 bereitstellt und von Azure Databricks über externe Tabellen oder Auto Loader konsumiert wird

Beide Muster adressieren delta-basierte Anforderungen, ohne dass Azure Databricks selbst direkt auf ODP-Queues zugreift.

3) SAP Databricks: der zero-copy-Weg

Mit der SAP Business Data Cloud und der darin enthaltenen SAP-Databricks-Variante kommt ein nativer Weg hinzu, der ohne klassische Extraktionsstrecke auskommt. Über Delta Sharing lassen sich kuratierte SAP-Datenprodukte zero-copy mit Azure Databricks teilen, also ohne physische Kopie und ohne eigene Pipeline. Der Zugriff bleibt über Unity Catalog governt, und SAP- sowie Non-SAP-Daten lassen sich auf derselben Plattform kombinieren. Wo verfügbar und lizenziert, reduziert dieser Ansatz Datenkopien und Pflegeaufwand erheblich und ist daher zunehmend die erste Option, die wir prüfen.

Fazit

Die Integration von SAP-Daten nach Azure Databricks folgt klar unterscheidbaren Mustern, die sich aus der fachlichen Anforderung, dem SAP-Quellsystem und den organisatorischen Rahmenbedingungen ableiten:

• Periodische Full Loads (Snapshots) empfehlen sich, wenn zustandsorientierte Auswertungen im Vordergrund stehen und eine regelmäßige vollständige Aktualisierung fachlich ausreichend ist. Für Azure Databricks ist der RFC-basierte Tabellenzugriff über Azure Data Factory mit Ablage in ADLS der naheliegende Standard, insbesondere für SAP ECC und SAP S/4HANA bei beherrschbarem Datenvolumen.
• Delta-basierte Muster sind erforderlich, sobald Änderungen selbst fachlich relevant werden oder Historisierung benötigt wird. ODP ist der von SAP vorgesehene Mechanismus und lässt sich über den SAP-CDC-Connector in Azure Data Factory umsetzen, unterliegt jedoch organisatorischen und lizenzseitigen Bewertungen. SAP-nahe Extraktionslösungen oder SAP Datasphere als Outbound-Layer ermöglichen delta-basierte Szenarien auch dann, wenn ein direkter ODP-Zugriff nicht vorgesehen ist.
• SAP Databricks innerhalb der SAP Business Data Cloud ermöglicht über Delta Sharing einen zero-copy-Zugriff ohne eigene Extraktionsstrecke und ist, wo verfügbar, oft der einfachste Weg.

← Zurück zum Blog