Blog

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.

‍

Optimierte Hauptspeichernutzung bei SAP BW on HANA

Die Ausnutzung des Hauptspeichers ist bei SAP-HANA- und Data-Warehouse-Szenarien immer ein spannendes Thema im Vergleich zu ERP-Anwendungen bzw. Anwendungen mit einem sich gering verändernden Datenvolumen. Somit muss man eines im Hinterkopf behalten: Lasse niemals den freien Hauptspeicher ausgehen.

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.

Bei dem Einsatz eines SAP Business Warehouses hat es in der Vergangenheit häufig verschiedene Ansätze in Unternehmen gegeben, die zu dem Aufbau einer parallelen Infrastruktur führen konnten. Die Betreuung dieser Infrastruktur liegt dabei stärker im Fachbereich als in der IT. Verbreitet sind Lösungen wie QlikView, SQL Server, Oracle oder TM1. Diese erfüllen ihre Aufgaben in der jeweiligen Situation sehr gut, ansonsten würde es sicher nicht den Drang geben, sie einzusetzen.

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.

Diesen Blog-Eintrag verfasse ich mal nicht in einer ruhigen Minute in unseren b.telligent-Büros, sondern live aus Brüssel vom Spark Summit. Für Data Scientists bietet es einen enormen Umfang an Machine-Learning-Verfahren, sowohl klassisch für statische Datensätze als auch für Streamingdaten in Echtzeit. Jeder mit Praxiserfahrung in der Python-Bibliothek sklearn wird sich sofort zuhause fühlen, da diese als Vorbild verwendet wurde.

Eine besonders fruchtbare aktuelle Diskussion dreht sich um die Frage, was ein Data-Science-Team eigentlich sinnvollerweise herstellt. Die beiden Möglichkeiten sind dabei schnell benannt: Auf der einen Seite steht die "Analyse", also ein einmalig erstelltes, eher statisches Endergebnis; die meisten denken hier sofort an eine PowerPoint-Präsentation. Auf der anderen Seite steht die "App", also ein interaktives, ständig mit frischen Daten versorgtes Endprodukt, häufig in Form einer Website oder einer Mobile App.

Aufgrund zunehmender Herausforderungen der Digitalisierung läuft E-Commerce dem stationären Handel mehr und mehr den Rang ab. Laut dem Kölner IfH-Institut verstärkt sich dieser Trend in den nächsten Jahren zunehmend. Bei Rückgang des Umsatzes im stationären Handel soll parallel der Umsatz des Onlinehandels bis 2020 auf ca. 77 Milliarden Euro ansteigen.

Der lokale Verbindungspfeil ermöglicht eine Einschränkung von Strukturen, ohne dabei auch die Daten einzuschränken. Diese Funktion gibt es schon viele Jahre, gerät aber schnell in Vergessenheit und ist bei vielen Anwendungsarchitekten und -entwicklern vollkommen unbekannt. Daher ist dies ein Blog, um diese Funktion einmal wieder aufzufrischen bzw. bekannt zu machen.

Notiz: arcplan Information Services GmbH ist nach der Fusion mit Longview umbenannt worden und heißt nun Longview Europe GmbH.

Mit SAP BW on HANA kommt das ADSO mit neuen Tabellenstrukturen und Funktionen. Im Vergleich zu den InfoProvidern, die auf nicht auf HANA basierenden SAP BW-Systemen genutzt werden, besitzen ADSOs die Fähigkeit, ihre Funktion ohne Verlust der abgelegten Daten zu ändern. Dies schließt auch eine Änderung der Inhalte von Tabellen mit ein, wenn der Typ verändert wird.

Ein ADSO besteht dabei immer aus drei Tabellen, die je nach ADSO-Typ gefüllt und verarbeitet werden. Nicht genutzte Tabellen werden vom System trotzdem angelegt. Somit ist die Nutzung in Routinen, HANA-Experten-Skripten etc. möglich, aber generell nicht immer richtig.

Die Rolle des Kunden

Die zentrale Rolle des Kunden für die Unternehmensausrichtung wird in der Wissenschaft seit Jahrzehnten diskutiert:

"It costs much more to acquire a customer than it does to keep a customer. That is why a sale to a customer is good, but a relationship with a customer is great." [1]

"Personal data are the fuel of the modern economy." [2]

"In a global information-based economy, data about customers are one of the most important sources for competitive advantage." [3]

Seitdem das Supportende für den OWB offiziell bekannt gemacht wurde, ist der Oracle Data Integrator (ODI) das ETL-Tool der Wahl in der Oracle-Welt. Die Entwicklung ist zu der Version 12 fortgeschritten, die einige Änderungen und Verbesserungen gebracht hat. Die GUI hat sich dem OWB noch weiter angenähert, jedoch stehen einige Möglichkeiten zur Verfügung, die der OWB so nicht bot. In diesem Eintrag wollen wir uns mit der Implementierung von Slowly Changing Dimensions im ODI beschäftigen.