Data Platform & Data Management

Mit der Einführung von SAP BW on HANA im Jahre 2010 wurden viele bisherigen Maßnahmen zur Performancesteigerung in BW-Systemen obsolet; gleichzeitig drängen sich aber viele neuen Fragen bezüglich der neuartigen Plattform auf. Von großer Relevanz ist dabei auch die Frage, ob es immer noch sinnvoll ist, die sogenannten "Advanced Business Application Programming-Routinen" zu cachen. Denn mit HANA werden die Daten einerseits in der unter einem Applikationsserver liegenden Datenbank im Hauptspeicher abgelegt und andererseits für Abfragen optimiert. Hinzu kommt, dass die Abfragen in Routinen systembedingt auf dem Applikationsserver ausgeführt werden. Die Frage nach der Sinnhaftigkeit der Nutzung eines Caches für ABAP-Routine-Abfragen soll deshalb im nachfolgenden Blogbeitrag eingehend erläutert werden:

Bei häufig wiederkehrenden Daten lässt sich dies grundsätzlich bejahen. Denn wenn beispielsweise das Attribut "Kontinent" von dem Info-Objekt "Land" hinzugelesen werden soll, ist der zeitliche Overhead eines Zugriffs durch den SQL Parser, das Netzwerk, etc. auf HANA wiederkehrend für jede Zeile zu hoch. Zwischen dem ABAP-Programm und den eigentlichen Daten liegen etliche technische Layer, welche damit wiederholend ausgeführt werden. Ist es jedoch notwendig, mehrere Joins zwischen Tabellen durchzuführen oder ist die Anzahl der zu lesenden Zeilen sehr groß, kippt der Vorteil wieder in Richtung der HANA-Datenbank.

Nach meinen Erfahrungen bei Kunden mit großen Datenmengen beschleunigt ein Cache im ABAP die DTP-Ausführung in einem SAP BW on HANA System teils um den Faktor 3. Dies ist natürlich immer abhängig von der Situation (z.B. Datenverteilung, Homogenität der Daten etc.), sowie von der aufgebauten Infrastruktur. Alles noch ohne Einsatz des Shared Memory. Dieser führt für alle Datenpakete zusammen, also pro Beladung, nur eine Abfrage auf die Datenbank aus. Im Handling ist dieser aber unnötig kompliziert.

Ausnahmeaggregationen waren vor HANA in SAP BW häufiger eine Herausforderung bei der Laufzeit; dazu gehörte auch die Distinct-Count-Operation. Diese wird zum Beispiel beim Zählen von Kunden aus den Aufträgen genutzt.

Früher wurden Distinct-Count-Operationen häufig folgendermaßen umgesetzt:  Es wurde eine berechnete Kennzahl mit dem Wert 1 angelegt und diese dann über eine Ausnahmeaggregation aufsummiert. Was in Umgebungen ohne HANA gut geklappt hat, führt aktuell jedoch dazu, dass der Pushdown nicht mehr funktioniert. Je nach Einstellung kann es also dazu kommen, dass die Berechnung nicht optimal durchgeführt wird.

Eine Lösung für HANA-Umgebungen muss also her: Konzentrieren wir uns daher im Weiteren auf die optimale Implementierung von Distinct Count mit BW on HANA oder BW/4HANA.

Wir wissen jetzt, wie wir die Daten richtig selektieren, welche Tabellenart wir bei Lookups nutzen sollten und wie wir sicherstellen können, dass wir nur relevante Datensätze durchlesen.

In der Praxis ist es aber oft so, dass man erstmals eine größere und/oder nicht eindeutige Datenmenge von der Datenbank selektieren muss, die dann nach bestimmten Regeln fürs performante Nachlesen aggregiert werden sollte.

Nachdem wir uns mit relevanten Selektionstechniken und mit den unterschiedlichen Arten von internen Tabellen auseinandergesetzt haben, sind die wichtigsten Performanceoptimierungen für die Lookups in unseren BW-Transformationen zunächst einmal sichergestellt.

Hiermit ist das Thema jedoch nicht komplett abgedeckt. Denn bis jetzt sind wir davon ausgegangen, dass nur die relevanten Informationen in unseren Lookup-Tabellen durchsucht werden. Wie können wir dies aber sicherstellen?

Dies ist vielleicht die grundlegendste aller ABAP-Fragen, und zwar nicht nur, wenn man sich mit performanten Lookups auseinandersetzt. Sobald man etwas in ABAP macht, wird man auf diese Frage stoßen.

In dieser Serie wollen wir uns mit Implementierungstechniken für Lookups auseinandersetzen, bei denen jeder Datensatz der zu durchsuchenden Tabelle überprüft werden sollte. Je größer unsere Datenpakete und unsere Lookup-Tabellen, desto wichtiger ist eine performante Implementierung.

‍

Performanceoptimierungen können nicht in Stein gemeißelt werden. Denn Optimierungen, die bei einem Unternehmen mit bestimmter Systemarchitektur und bei gewissem Datenvolumen super funktioniert haben, müssen nicht zwingend an einer anderen Stelle genauso gut klappen. Kurzum: Es müssen individuelle Lösungen erarbeitet werden. Prinzipiell geht es aber immer darum, die Balance zwischen Arbeitsspeicherauslastung und Datenbankauslastung sowie zwischen Implementierungskomplexität und Wartbarkeit zu finden. Dabei steht die Verarbeitungszeit stets im Zentrum.

Große Teile an bisher manueller Programmierung können durch DWA-Tools abgelöst oder zumindest stark vereinfacht werden. Welche Teile der Entwicklung dabei genau automatisiert werden können, kann von Tool zu Tool stark differieren. So gibt es Ansätze von reinen Code-Generatoren, mithilfe derer Datenbankstrukturen und ETL-/ELT-Prozesse automatisch generiert werden können („design-time“). Auf der anderen Seite existieren umfangreiche Integrationssuiten, die den gesamten DWH-Lebenszyklus, von der Bereitstellung der Daten in den Quellen bis hin zu den Data Marts, generieren, aber auch verwalten können („run-time“).

Bei der Entwicklung gibt es eine Reihe von Aufgaben, bei denen ein DWA-Tool unterstützen kann. Im Folgenden wird insbesondere auf die Bereiche Reverse Engineering und Kompatibilität, Analyse, Implementierung und Rahmenbedingungen eingegangen.

Die Automatisierung von immer wiederkehrenden Aufgabenstellungen gehört zu den grundlegendsten Prinzipien der modernen Welt. Bereits Henry Ford erkannte daraus resultierende Vorteile, wie sinkende Fehleranfälligkeit, kürzere Fertigungszyklen und eine gleichbleibende, einheitliche Qualität. Eben diese Vorteile lassen sich bei Data-Warehouse-Initiativen anwenden.