Zero-Copy Delta Share: Das Ende des Data Plumbing
- Databricks
- Databricks
- 5 Min Lesezeit
Dr. Andreas Wagner
In diesem Wiki wird erklärt, wie eine der grössten Hürden in der modernen Datenlandschaft überwunden werden kann: der oft komplexe, langsame und kostspielige Austausch von Daten. Von SAP nach SAP Databricks.
Die Lösung lautet: Databricks Delta Sharing und das „Zero-Copy“-Prinzip. Andreas beschreibt im Wiki, wie sich dadurch Live-Daten sicher und in Echtzeit teilen lassen, ohne dass eine physische Kopie erstellt werden muss.
Inhaltsverzeichnis
Es gab eine Zeit, in der Datenintegration vor allem eines war: mühsam. Wer SAP-Daten in einer modernen Plattform wie Databricks nutzen wollte, musste Pipelines verlegen, Extraktoren programmieren und zusehen, wie wertvolle Business-Semantik in flachen CSV-Dateien verdampfte. Wir nannten es „Data Plumbing“ – und es war das Gegenteil von Aufbruch.
Doch mit der Einführung der SAP Business Data Cloud (BDC) und dem Prinzip von Zero-Copy Delta Share bricht diese Ära der redundanten Kopien endgültig in sich zusammen. Die letzten Vorbereitungen sind abgeschlossen. Der Countdown läuft.
2. Der Maschinenraum: Wo die Daten wirklich liegen
Alles beginnt im FOS (File Object Store), der Cloud-nativen Speicherschicht von SAP. Hier liegen die Daten nicht in starren Datenbanktabellen, sondern im HDLF (High-performance Data Lake Format) – technisch gesehen eine hochoptimierte Apache-Parquet-Implementierung.
Das Besondere: Diese Dateien sind immutable, also unveränderlich. Jede Änderung erzeugt neue Versionen mit Metadaten, was echte ACID-Transaktionen (Atomicity, Consistency, Isolation, Durability) auf Dateiebene ermöglicht. Kurz gesagt: Ein Fundament, das trägt. Und das ist keine Kleinigkeit – es ist die Voraussetzung für alles, was folgt.
3. Die Vorteile von Zero-Copy Delta Sharing auf einen Blick
Warum ist dieser technologische Sprung so entscheidend? Die Antwort liegt in der massiven Reduktion von Komplexität – weniger Gewicht, mehr Schubkraft:
- Keine Datenkopien, keine ETL-Pipelines: Wir eliminieren die Kosten und Fehlerquellen, die durch das Duplizieren und Verschieben von Daten entstehen.
- Datenaustausch in Echtzeit: Teams arbeiten immer mit den aktuellsten Informationen direkt aus der Quelle – ohne auf zeitaufwändige Batch-Läufe zu warten.
- Sicherheit und Kontrolle: Die Datenhoheit bleibt bei SAP. Zugriffsrechte werden zentral verwaltet und können jederzeit widerrufen werden.
- Offen und flexibel: Als offener Standard funktioniert Delta Sharing über verschiedene Plattformen und Cloud-Anbieter hinweg.
4. Der digitale Handschlag: Die Cloud-Native Mechanik hinter Delta Sharing
Aber wie funktioniert das technisch konkret? Werfen wir einen Blick unter die Haube. Stellen wir uns vor, die Databricks-Systeme und die SAP BDC unterhalten sich. Statt dass SAP die Daten mühsam einpackt und verschickt, findet ein eleganter REST-basierter Austausch statt – die strikte Trennung von Speicher (Storage) und Rechenleistung (Compute) in ihrer reinsten Form.
Zuerst erfolgt der Handshake: Der Databricks-Client weist sich mit einem Bearer-Token – einem digitalen Sicherheitsschlüssel – aus. Der BDC-Server schickt ein Manifest zurück: eine strukturierte Liste der Dateien, die den aktuellen Datenzustand repräsentieren. Dann kommt der entscheidende Kniff: Der Server generiert für jede dieser Dateien eine Pre-signed URL – einen temporären Link mit eingebauten Zugriffsrechten und kurzer Lebensdauer.
Der eigentliche Datenstrom passiert den SAP-Applikationsserver dabei niemals. Die Databricks-Worker-Nodes übernehmen das Ruder: Sie laden via Byte-Range Requests gezielt nur jene Datenblöcke direkt aus dem SAP-Speicher, die tatsächlich benötigt werden (Columnar Pruning). Das analytische Compute findet vollständig in Databricks statt – der Storage bleibt sicher bei SAP.
5. Praxisbeispiel: Der intelligente Cashflow-Forecast
Wie sieht das in der Realität aus? Ein Vertriebsteam möchte tagesaktuelle Verkaufszahlen aus S/4HANA nutzen, um mit einem ML-Modell in Databricks Prognosen zu erstellen.
Ohne Delta Sharing:
Ein aufwändiger ETL-Prozess extrahiert die Daten täglich. Wenn der Data Scientist seine Analyse startet, sind die Daten bereits 12–24 Stunden alt. Der Prozess ist teuer, fehleranfällig – und erinnert fatal an eine Rakete, die ihren eigenen Treibstoff erst mühsam in Kanistern zum Pad schleppt.
Mit Delta Sharing:
Die Verkaufsdaten werden direkt aus S/4HANA als Datenprodukt freigegeben. Das Data-Science-Team greift live darauf zu. Die Prognosen sind präziser, da sie auf dem echten Ist-Zustand basieren. Der gesamte Overhead für den Pipeline-Bau entfällt.
6. Die Kunst der Übersetzung: Warum wir Metadaten brauchen
Doch damit die Daten im Zielsystem auch verstanden werden, reicht der blosse Zugriff darauf noch nicht aus. Daten ohne Kontext sind nur Rauschen. BDC Connect nutzt deshalb zwei Protokolle als „Dolmetscher“:
- ORD (Open Resource Discovery): Beschreibt maschinenlesbar, woher Daten kommen und wie sie versioniert sind.
- CSN (Core Schema Notation): Sorgt dafür, dass beim Mounten im Unity Catalog Primärschlüssel und Tabellenbeziehungen automatisch erkannt werden.
7. Universal Governance: Wer darf an Bord – und wer nicht?
Doch Kontext allein reicht nicht – es braucht auch klare Regeln, wer auf diese Daten zugreifen darf. Sicherheit endet nicht an Systemgrenzen. Wir bauen eine lückenlose Identitäts-Pipeline: Microsoft Entra ID fungiert als Ankerpunkt. Über das IPS (Identity Provisioning System) spiegeln wir Identitäten in den SAP IAS, während Databricks dieselben Entra-Identitäten nutzt. Wenn der Unity Catalog nun Zugriffskontrollen wie Row-Level Security durchsetzt, geschieht dies auf Basis einer synchronen, konsistenten Identität – unabhängig davon, auf welchem System jemand arbeitet.
Das Ergebnis: Rollenänderungen oder Deaktivierungen greifen sofort und konsistent – von der SAP Datasphere bis zum Databricks Notebook.
8. Die Dremio-Zäsur & der Blick auf 2026
Dabei lohnt sich auch ein Blick auf das, was sich am Horizont abzeichnet: Wer heute die richtige Architektur wählt, schützt seine Investitionen auch für morgen. Im Mai 2026 hat SAP mit der Akquisition von Dremio den Weg zu Apache Iceberg geebnet. Der Katalog wird dezentral, die BDC format-agnostisch. Das bedeutet: Eine Catalog Orchestration Layer (z. B. Atlan) wird zunehmend wichtiger, um im Multi-Katalog-Umfeld (Unity, Polaris, Horizon) den Überblick zu behalten.
Für AI-Szenarien kommt zudem das MCP (Model Context Protocol) ins Spiel. Es abstrahiert die technische Ebene, sodass ein AI-Agent nur noch den stabilen Daten-Kontrakt sieht – egal ob Delta oder Iceberg im Hintergrund läuft.
9. Fazit: Ready for liftoff!
Zero-Copy ist nicht nur eine Architekturentscheidung. Es ist der Moment, in dem wir aufhören, Leitungen zu verlegen, und anfangen, echte Architekten des Geschäftserfolgs zu sein.
Das „Data Plumbing“ hat ausgedient. Und die Frage ist nicht mehr ob – sondern wann Sie das Startfenster nutzen.
Die Mission Lakehouse hebt ab. Sind Sie an Bord? 🚀
Andreas & Yvonnes Databricks-Guide
Möchten Sie alle wichtigen Informationen auf einen Blick?
Laden Sie sich jetzt den kostenlosen Guide zur SAP Databricks!
Ihre Datenstrategie ist individuell – Ihre Beratung sollte es auch sein
Die Einführung von Zero-Copy Delta Sharing ist mehr als eine technische Implementierung – es ist ein strategischer Schritt zur Modernisierung Ihrer Datenarchitektur. Ob und wie Sie diese Technologie optimal nutzen, hängt von Ihrer spezifischen Systemlandschaft, Ihren Sicherheitsanforderungen und Ihren langfristigen Zielen für Analytics und KI ab. Eine Standardlösung gibt es hier nicht.
Lassen Sie uns unverbindlich darüber sprechen, wie Sie mit Delta Sharing den Datenaustausch in Ihrem Unternehmen revolutionieren und das volle Potenzial Ihrer SAP-Daten heben können. Kontaktieren Sie uns für ein persönliches Gespräch.
