Egal ob SAP HANA Live, Core Data Services oder ähnliches; mit den neuen HANA-Plattformen geht der Trend eindeutig weg von Standard-ETL-Prozessen mit Datenvorhaltung im DWH hin zu virtuellen Datenmodellen mit direktem Durchgriff auf die Datenbank.
Dabei ist auch der SAP HANA Smart Data Access (SDA) zu erwähnen. Mit diesem lässt sich im SAP HANA die Kernkompetenz des SAP BW, Daten aus verschiedenen Quellen an einer Stelle zusammenzuführen, ohne Datenreplikation abdecken. Im HANA Studio können diese externen Daten in virtuellen Tabellen angebunden werden. Darüber hinaus kann man bei der Verwendung von SDA die Rechenoperationen in die externen Quellen verlagern, um eine voraggregierte Sicht und eine bessere Performance auf der HANA zu erhalten.

Diese Idee des Echtzeit-Reporting ist nicht neu. Bereits im klassischen SAP BW gibt es einige virtuelle Objekte, nicht zuletzt die virtuellen Info Provider. Die Vorteile dieses Ansatzes sind nicht von der Hand zu weisen: verbesserte Laufzeit, keine Ladeprozesse, keine Daten-Redundanz. Es stellt sich jedoch die Frage, wie weit man dabei gehen kann. Wann ist der Punkt erreicht, an dem beispielsweise die Datenmenge zu groß, oder die implementierte Logik zu komplex wird?

Anforderungen bedingen virtuellen Ansatz

In einem aktuellen SAP BW-Projekt sahen wir uns exakt mit diesem Dilemma konfrontiert. Aus den Anforderungen bzw. der Definition der abzubildenden KPIs resultierte eine Abhängigkeit vom Navigationsstatus der Query. Je nachdem, welche freien Merkmale der Benutzer im Aufriss verwendete, ergab sich in Summe zunächst ein anderer Wert. Um dies zu beheben, musste die Berechnung zur Laufzeit jedes Mal neu erfolgen, sobald sich der Aufriss änderte, weshalb wir die Query auf einem virtuellen Provider mit Funktionsmodul bauten. Dadurch berücksichtigten wir bei der Berechnung jeweils den aktuellen Drilldown.

Hybrid-Lösung für bessere Laufzeit

Die Berechnungslogik an sich war allerdings derart kompliziert, dass es beim ungefilterten Aufruf zu einem Timeout kam. Es mussten mehrere Millionen Datensätze (etwa 80 Mio.) in der komplexen Logik verarbeitet werden, wobei das im System eingestellte Laufzeit-Maximum von zwei Stunden überschritten wurde.

Aus diesem Grund sind wir zu einer Hybrid-Lösung übergegangen. Dabei reduzierten wir die Anzahl der freien Merkmale, so dass die möglichen Aufrisse über Nacht vorberechnet und auf der Datenbank abgelegt werden konnten. Darauf aufbauend selektierte der virtuelle Provider zur Laufzeit je nach Drilldown nur noch den entsprechenden vorberechneten Datenraum. Hier hat sich der Spagat zwischen einer Berechnung „on the fly“ und der DWH-Technologie bewährt.

Das Beste aus zwei Welten – Grenzen des Realtime BI im Projekt ausgelotet

Die Erfahrungen aus diesem Projekt belegen die Restriktionen des rein virtuellen Ansatzes (egal ob virtuelle Provider im SAP BW oder CDS-Views in SAP HANA) bei großer Datenmenge oder komplexer Logik. In solchen Fällen ist ganz klar ein hybrides Szenario zu empfehlen. Mit der Ergänzung der Echtzeit-Reporting Funktionalitäten um die klassische DWH-Technologie bietet sich die Möglichkeit, auch anspruchsvolle Aufgaben performant zu bewältigen.

Mithilfe des SDA kann man dies umsetzen, sofern man darauf achtet, die Vorberechnungen in den Quelldatenbanken durchzuführen. Genauso stellt auch das Embedded BW im neuen S/4HANA einen Schritt in diese Richtung dar. Da es jedoch nicht beliebig skalierbar ist, stößt man bei großen Datenmengen ebenfalls an Grenzen. Laut SAP-Empfehlung soll das Embedded BW maximal 20 % des Gesamtdatenvolumens ausmachen. Es ist also kein vollwertiger Ersatz für ein Business Warehouse, sobald das System eine gewisse Größe überschreitet oder komplexe Aufgaben bewältigt werden sollen.

Um alle Vorteile sowohl des virtuellen Ansatzes, als auch der DWH-Technologie komplett auszuschöpfen, empfiehlt es sich, das virtuelle Modell mit Embedded BW um ein zusätzliches BW zu erweitern, welche die Aufgaben eines EDWH übernimmt.