Delta Loading ist eine wichtige Funktion von Enterprise Data Warehouses (DWH), die, bei regelmäßiger Replikation von Daten aus Quellsystemen in das DWH, eine kontinuierliche und stabile Performance gewährleistet und minimale Auswirkungen auf beteiligte Systeme sicherstellt. Dies wird in der Regel durch den Einsatz eines Mechanismus erreicht, der die minimal erforderlichen Zeilen der Quelldaten bestimmt, die in das DWH übertragen werden müssen, um die Aktualität des Zielmodells zu gewährleisten. Die konkrete Umsetzung dieses Mechanismus variiert stark zwischen verschiedenen DWH-Lösungen auch innerhalb der SAP-Produktlandschaft.
In diesem Artikel möchten wir unsere Erfahrungen aus Kundeneinsätzen und internen Tests über den Umfang und die Funktionsweise der Delta Loading Möglichkeiten in SAP Datasphere [früher bekannt unter dem Namen "Data Warehouse Cloud (DWC)"] teilen und aufzeigen. Während die Delta Möglichkeiten in Datasphere im Vergleich zu SAP Business Warehouse tatsächlich noch recht eingeschränkt sind, haben wir zwei Ansätze gefunden, die sich für eine Vielzahl von Anwendungsfällen eignen.
In diesem Szenario haben wir ein S/4HANA OnPrem-System untersucht, welches als Testinstanz über die SAP Cloud Application Library (CAL) eingerichtet wurde und als Datenquelle für unseren internen Datasphere-Tenant dient. Wir haben eine Verbindung zwischen S/4HANA und Datasphere hergestellt, sowie einen Data Provisioning Agent konfiguriert, um die Nutzung von Remote-Tabellen und der Real-Time-Replication Funktionalität zu ermöglichen.
Unsere verwendete Architektur besteht weiterhin aus S/4HANA Change Data Capture (CDC) fähigen Core Data Service (CDS) Views, auf die als Remote-Tabellen in Datasphere zugegriffen wird und welche damit als Staging Layer fungieren.
Der geneigte Leser kann unter folgendem Link mehr über die Funktionsweise von CDC in CDS Views erfahren: CDS based data extraction – Part II Delta Handling | SAP Blogs
An dieser Stelle sollte es jedoch genügen, darauf hinzuweisen, dass CDC es dem Zielsystem ermöglicht, zu erkennen, welche Zeilen im Quellobjekt seit der letzten Replikation geändert worden sind.
Wir haben zwei wesentliche Designansätze für die Implementierung von Delta Loading in einem enterprise Szenario mit Datasphere ermittelt:
Der einfachste Ansatz Delta Loading zu implementieren, ist die Nutzung von CDC-fähigen CDS Views. Diese werden als Remote-Tabellen in Datasphere importiert und für den Echtzeit-Zugriff im Data Integration Monitor freigeschaltet.
Dadurch wird sichergestellt, dass die Remote-Tabelle in Datasphere eine nahezu in Echtzeit aktualisierte Kopie der CDS View in der Quelle ist. Dies ist ein sehr einfacher, schneller und effektiver Ansatz, der jedoch auch einige Einschränkungen mit sich bringt.
a) Die Aktualisierungsfrequenz kann nicht angepasst werdenEs gibt zwar Anzeichen dafür, dass diese Funktion mittelfristig von SAP eingeführt werden könnte, aber es ist derzeit nicht möglich die Häufigkeit der Replikation anzupassen, d. h. sie erfolgt immer nahezu in Echtzeit. Während dies für die meisten Szenarien kein Problem darstellt, werden Kunden, die an nächtliche Upload-Zyklen gewöhnt sind, feststellen, dass ein Change-Management-Konzept erforderlich sein wird, da Änderungen am Quellsystem unmittelbar im DWH vorhanden sein werden, anstatt erst am nächsten Arbeitstag verfügbar zu sein.
b) Die Remote-Tabelle ist immer eine 1:1-Kopie der QuelleDa wir eine Remote-Tabelle replizieren und eine Remote-Tabelle nur eine Kopie der Metadaten des Quellobjekts ist, können wir sie in Datasphere nicht anpassen, indem wir z. B. zusätzliche technische Felder anlegen. Anpassungen in nachträglich verwendeten Views sind natürlich trotzdem möglich.
Bei diesem Ansatz muss im Quellobjekt ein geeignetes Feld ermittelt werden, welches als Delta Indikator verwendet werden kann. Idealerweise sollte die Quelle so etwas wie ein LastChangeDate-Feld vorweisen, das den Zeitpunkt markiert, an dem ein neuer Datensatz erstellt, oder ein bestehender Datensatz gelöscht oder geändert wird. Für das Lösch Szenario wäre zusätzlich ein binäres Feld wie DeletionFlag erforderlich. Wenn diese Anforderungen erfüllt sind, können wir dem Ansatz in Datasphere folgen, indem wir ein Data Flow Objekt erstellen, eine Remote-Tabelle, eine lokale Zieltabelle und einen Filter einfügen, um damit den Data Flow z. B. auf LastChangeDate = CurrentDate - 1 zu beschränken. Anschließend würden wir diesen Data Flow in einer Schedule einplanen, sodass dieser jede Nacht ausgeführt wird. Auf diese Weise werden bei jedem nächtlichen Lauf nur die Datensätze zu geladen, die am Vortag geändert wurden.
Dieser Ansatz funktioniert für Inserts und Updates, wenn garantiert werden kann, dass alle Änderungen dieser Art in einem Feld wie LastChangeDate reflektiert sind. Das Deletion Szenario hingegen wäre nur dann gelöst, wenn einer der folgenden Punkte zutrifft:
a) Löschungen in der Quelle sind nicht möglichIn einem ERP-Quellsystem könnten viele potenzielle Quellobjekte bereits so eingerichtet sein, dass dort niemals ein Datensatz gelöscht wird.
b) Löschungen in der Quelle werden über einen Löschvermerk durchgeführtWenn Löschungen stattfinden, dann ist es notwendig, dass dies nicht durch ein tatsächliches Löschen der Zeile im Quellobjekt geschieht, sondern durch das Setzen eines Indikatorfeldes wie DeletionFlag.
c) Löschungen in der Quelle müssen nicht im DWH gelöscht werdenSelbst wenn Löschungen im Quellobjekt stattfinden und durch tatsächliches Löschen der Zeile erfolgen, ist das Deletion Problem gelöst, wenn zumindest die Anforderungen des Datasphere-Modells keine Löschung im Data Warehouse erfordern. Dabei müssen jedoch weiterhin Randfälle berücksichtigt werden, wie z. B. die Erstellung und Löschung eines bestimmten Datensatzes am selben Arbeitstag, welcher hierdurch entsprechend niemals im DWH-Modell erscheinen würde.
Trifft keiner der oben genannten Punkte zu, oder gibt es kein LastChangeDate-ähnliches Feld zur Behandlung von Inserts/Updates, ist es immer noch möglich ein Pseudo-Delta zu implementieren, indem einige SQL-basierte Quell-/Zielabgleiche durchgeführt werden, um festzustellen, welche Datensätze geändert wurden und daher übertragen werden sollten. Leider hat dieser Ansatz weitaus größere Performance Auswirkungen, da wir zusätzliche Daten aus der Quelle abrufen müssen, um diesen Vergleich zu ermöglichen. Wenn alles andere fehlschlägt, kann dieser Ansatz als letzter Ausweg verwendet werden.
Wir haben zwei wesentliche Ansätze für die Implementierung eines Delta Mechanismus in Datasphere aufgezeigt. Diese sind geeignet, um einige der häufigsten Szenarien abzudecken. Der Ansatz der Real-Time-Replication auf Remote-Tabellen ist die bequemste Lösung, wenn diese im konkreten Integrationsszenario möglich ist und wenn die genannten Einschränkungen kein Problem darstellen. Andere Fälle können größtenteils mit dem Data Flow Ansatz abgedeckt werden, solange die beschriebenen Limitierungen berücksichtigt werden.
Es sollte erwähnt werden, dass wir auch weitere mögliche Lösungen untersucht haben, u.a. jene, welche die Integration zusätzlicher Softwarekomponenten wie SAP Landscape Transformation Replication Server (SLT) oder SAP Data Intelligence erfordern würden. Wenn Ihr Unternehmen diese Softwarekomponenten jedoch nicht bereits einsetzt, empfehlen wir einen reinen Datasphere-Ansatz zu verwenden, um Overengineering zu vermeiden.
Im Rahmen der kontinuierlichen weiterentwicklung von Datasphere als Produkt hoffen wir auf mehr Freiheiten bei der Implementierung der beschriebenen Ansätze, um komplexere Szenarien abdecken zu können und gleichzeitig die Vorteile der CDC basierten Architektur beizubehalten.
Haben Sie Fragen zu diesem oder anderen Themen? Versuchen Sie das nötige Know-How in Ihrer Abteilung aufzubauen oder benötigen Sie Unterstützung bei einer konkreten Fragestellung? Wir helfen Ihnen gerne dabei. Fordern Sie noch heute ein unverbindliches Beratungsangebot an.