Zero Copy statt ETL mit SAP Databricks

Beim klassischen ETL-Ansatz (Extract, Transform, Load) werden Daten aus dem Quellsystem herausgezogen, unterwegs aufbereitet und in ein Zielsystem geschrieben. Am Ende liegt eine Kopie der Daten am neuen Ort – zusätzlich zum Original.

Das funktioniert seit Jahrzehnten zuverlässig, bringt aber drei typische Folgekosten mit sich:

• Redundanz: Dieselben Daten liegen mehrfach vor, an unterschiedlichen Orten.
• Latenz: Die Kopie ist immer nur so aktuell wie der letzte Ladelauf. Zwischen zwei Läufen driftet sie vom Original weg.
• Abstimmungsaufwand: Weichen Original und Kopie voneinander ab, beginnt die Suche nach der „richtigen“ Zahl.

Gerade im regulatorischen Reporting, wo Nachvollziehbarkeit und Konsistenz zählen, wird dieser Aufwand schnell spürbar.

Zero Copy dreht den Ansatz um. Statt Daten zu kopieren, greifen die konsumierenden Systeme direkt auf die Daten am Quellort zu. Es gibt keinen Ladelauf, keine zweite Kopie und keinen Versatz zwischen Original und Duplikat – alle Beteiligten arbeiten auf demselben Datenbestand.

Delta Sharing – das Protokoll hinter Zero Copy

Technisch ermöglicht wird Zero Copy bei SAP durch ein offenes Protokoll namens Delta Sharing, ursprünglich von Databricks entwickelt. Es erlaubt den sicheren Datenaustausch zwischen Plattformen, unabhängig davon, welche Systeme die Beteiligten einsetzen.

Der entscheidende Punkt: Die empfangende Seite liest die Daten live an der Quelle. Der Zugriff erfolgt über gängige, offene Konnektoren – etwa für Python, Apache Spark, Power BI, Tableau oder Excel. Weil das Protokoll offen ist, bleibt der Empfänger unabhängig von einem einzelnen Anbieter.

Die SAP Business Data Cloud stellt Daten in Form sogenannter Data Products bereit – fertig modellierte, konsumierbare Datenpakete, ob Stamm- oder Bewegungsdaten.

Nach SAPs eigener Darstellung nutzt die Business Data Cloud das Delta-Sharing-Protokoll, um diese Data Products per Zero Copy zu teilen: Die Daten werden nicht bewegt oder kopiert, komplexes ETL entfällt, und der Datenbestand bleibt über die gesamte BDC-Landschaft konsistent.

Konkret heißt das: Ein Data Product, das in SAP Datasphere modelliert wurde, lässt sich in SAP Databricks weiterverarbeiten – etwa für Data Science oder KI – ohne vorherige ETL-Kopie. Die Anreicherung aus Databricks kann auf demselben Weg zurück nach Datasphere geteilt werden. Der Austausch läuft in beide Richtungen.

Für Banken, die ihre bestehende BW-Landschaft modernisieren, ist Zero Copy ein zentraler Baustein – mehr dazu unter SAP BW Modernisierung mit der SAP Business Data Cloud und in unserem Überblick zum SAP Data Warehousing.

„Zero Copy“ ist ein starkes Versprechen – und gilt in der Praxis mit einer wichtigen Einschränkung. Kopierfrei bleibt es nur bei einer viewbasierten Verarbeitung: Über eine Sicht wird auf die Originaldaten zugegriffen, ohne diese zu materialisieren (physisch als eigene Kopie abzulegen).

Sobald ein Data Product physisch gespeichert (materialisiert) oder über eine Transformation abgeleitet wird, entsteht sehr wohl eine Kopie. Aufschlussreich sind die jeweiligen Standardeinstellungen:

• SAP Datasphere erzeugt Data Products standardmäßig viewbasiert – hier fällt keine Kopie an. Kommt ein Transformation Flow zum Einsatz, wird kopiert.
• SAP Databricks legt die Daten standardmäßig physisch ab – demnach entstehen hier in der Regel Kopien.

Für eine realistische Architekturbewertung ist diese Unterscheidung wesentlich: Zero Copy ist kein Automatismus, sondern das Ergebnis bewusster Entscheidungen bei der Modellierung.

Zero Copy über Delta Sharing ist keine technische Spielerei, sondern eine Antwort auf ein reales Problem gewachsener SAP-Landschaften: zu viele Kopien, zu viel Abstimmung, zu wenig Aktualität. Die wichtigsten Punkte im Überblick:

• Zero Copy liest Daten an der Quelle, statt sie per ETL zu kopieren.
• In der SAP Business Data Cloud setzt Delta Sharing dieses Prinzip für Data Products um.
• Ob wirklich kopierfrei gearbeitet wird, hängt von der Modellierung ab – viewbasiert statt materialisiert.

Wer die Grundlagen kennt, kann die richtige Architekturentscheidung treffen, bevor die erste Datenstrecke gebaut wird.