SAP NetWeaver BW powered by SAP HANA

DWH-Management und Reporting in neuen Dimensionen

Haben Sie auch schon während mehrerer Minuten auf das Ergebnis eines komplexen Querys gewartet? Oder beim Management von Aggregaten zu viel Zeit und evtl. sogar die Übersicht verloren?

Die Datenmengen werden grösser, die Integrationsschritte in den Datenmo-dellen komplexer. Immer mehr Geschäftsbereiche möchten ihre Daten via BW reporten und Fragestellungen im Zusammenhang mit anderen Unterneh-mensdaten untersuchen. Dabei erreichen wir sowohl beim Staging, als auch im Reporting vermehrt die Grenze des Zumutbaren. Tätigkeiten wie DSO-Daten aktivieren oder zurückrollen, das Management von Jahrescubes und die Erweiterung oder Remodellierung von intensiv genutzen Datenmodellen können in den verfügbaren Zeitfenstern nicht mehr durchgeführt werden.In all den erwähnten Beispielen ist das Lesen, Vergleichen, Berechnen und Schreiben von Massendaten auf der Datenbank der Hauptverursacher der langen Laufzeiten. Hier können wir den Performancevorteil der SAP HANA zu 100% nutzen.

Bei itelligence haben wir die oben erwähnten Arbeitsschritte im direkten Vergleich zwischen einer herkömmlichen Installation mit einer Oracle DB und einem SAP NW BW powered by SAP HANA System gezogen. Die Messer-gebnisse finden Sie in diesem Dokument.

Voraussetzungen für den Einsatz von SAP BW auf SAP HANA

SAP BW auf SAP HANA ist möglich ab einem BW Release 7.3x min. SP 5. Seit

Oktober 2012 ist hier bereits SPS 8 frei verfügbar. Dualstack Systeme werden nicht

unterstützt. Allfällig vorhandene Dualstack Installationen müssen vorgängig in eine

separate ABAP- und JAVA-Instanz getrennt werden. Es ist eine separate SAP Central

Instanz nötig. SAP kann nicht auf der gleichen Maschine, wie SAP HANA laufen.

Natürlich muss eine SAP HANA Appliance installiert sein. Informationen zum Sizing

einer SAP HANA finden Sie in den Hinweisen 1637145 und 1736976 von SAP. Vor-

her sollten Sie sich aber Gedanken zum Lifecycle Ihrer bestehenden Daten machen.

Können ältere Daten gelöscht, archiviert oder in ein Nearline Storage ausgelagert wer-

1

expertpaper

den? Es macht wenig Sinn, die SAP HANA wegen solcher Daten zu gross zu dimensi-

onieren und entsprechend mehr zu bezahlen. itelligence verwendet für die Tests eine

SAP HANA Release 1.2 mit 256 GB Memory.

Der Hinweis 1681092 beschreibt die Möglichkeit, mehrere, nicht produktive Instan-

zen auf einem SAP HANA System einzurichten.

Migration des Datenmodells

Nachdem das SAP BW technisch auf der SAP HANA DB läuft, sollten die BW–Ob-

jekte in ihre SAP HANA optimierte Form migriert werden. Nur dann kann von den

enormen Performancevorteilen von SAP HANA profi tiert werden. Dieser Schritt ist

optional und kann zu einem passenden Zeitpunkt durchgeführt werden. Es ist mög-

lich, die Objekte als Teil der technischen Migration in einem Massenlauf zu migrie-

ren. Wir empfehlen jedoch eher, die Objekte Applikationsweise zu migrieren. Dies

lässt sich idealerweise mit einer Analyse der Datenmodellqualität und der Perfor-

mance vorher / nachher kombinieren.

DSOs und Basiscubes können mit der Transaktion RSMIGRHANADB oder mit dem

Report RSDRI_CONVERT_CUBE_TO_INMEMORY in ihre optimierte Form überführt

werden. Die Datenfl üsse von und zu migrierten Objekten müssen nicht verändert

werden.

DSOs

Nur Standard- DSOs können migriert werden. Zwei Optionen sind möglich: Mit und

ohne Rekonstruktion des Changelogs. Ein In-Memory optimiertes DSO ist anders

aufgebaut, als das bisher bekannte Schema mit den drei Tabellen. aufgebaut, als das bisher bekannte Schema mit den drei Tabellen.

Abbildung 1: Tabellen des In-Memory optimierten Standard DSOs

expertpaper

2

Gedanken zum Datenmanagement

Die aktiven Daten sind neu in drei Tabellen enthalten: Aktuelle Daten, historische

Daten und eine Deltatabelle. : Bei der Aktivierung werden die neuen mit den aktu-

ellen Daten verglichen und veraltete Stände in die Tabelle der historischen Daten

verschoben. Das Changelog existiert nicht mehr physisch. Es ist neu als Calculation

View implementiert, der zur Laufzeit die gewünschten Daten aus den anderen Tabel-

len errechnet. Den Performancegewinn bei der Aktivierung ohne SID gibt SAP mit

Faktor 7-10 an. Da vorallem auch die SID Ermittlung optimiert wurde, ist die Aktivie-

rung mit SID-Ermittlung nochmals erheblich schneller.

Bei SAP HANA-optimierten DSOs sollte das ‚SID-Flag‘ immer gesetzt sein, da nur in

diesem Fall alle angestrebten Verarbeitungsschritte des DSOs auch wirklich auf SAP

HANA direkt durchgeführt werden können.

Antwortzeiten - unsere Ergebnisse ■ Daten laden ins DSO: ca. gleich schnell, wie ohne SAP HANA.

■ Aktivieren ohne SID: 10 - 20 mal schneller.

■ Aktivieren mit SID: siehe Grafik unten.

■ Auf SAP HANA: Faktor 30 - 40 mal schneller!

Da wir hier sehr grosse Datenpakete aktivieren, musste unser Vergleichssystem bald

aufgeben. Auf SAP HANA jedoch lassen sich auch Pakete mit 50 Mio Sätzen ohne

Probleme aktivieren. Nur schon der Stabilitätsgewinn bei grossen Datenmengen ist

bemerkenswert.

Ausschlüsse: In den folgenden Situationen, kann ein DSO nicht migriert werden:

■ Falls ein DSO einen ausgehenden 3.x Datenfluss hat.

■ DSOs, die mit einem RDA versorgt werden.

■ DSOs und Cubes, die zu einem Semantisch Partitionierten Objekt gehören.

Es können aber neue SPOs und Hybrid Provider basierend auf HANA-optimierten

Objekten angelegt werden.

3

expertpaper

Cubes

Beim optimierten Cube entfallen die Dimensionstabellen (bis auf die Paketdimen-

sion). Die Stammdaten-SIDs werden direkt in die Faktentabelle geschrieben. Dies ist

möglich, weil Tabellen in SAP HANA keine Limitierung auf 16 Schlüsselfelder haben.

Durch den Verzicht auf die Dimensionstabellen entfällt die Ermittlung der DIM-IDs

beim Staging und der Umweg via DIM-IDs beim Reporting.

Weil die Komprimierung nicht mehr in der bisherigen Form nötig ist, entfällt auch

die E-Faktentabelle. Dadurch reduziert sich die Tabellensammlung eines Cubes von

max. 18 Tabellen auf 2. Dies macht Strukturänderungen viel einfacher möglich.

Antwortzeiten - unsere Ergebnisse: ■ An der Kurve ist ersichtlich, dass das Beladen eines SAP HANA-optimierten Cubes

beträchtlich schneller ist, im Vergleich zu einem herkömmlichen System.

■ Die von uns festgestellte Performance ist 45 mal schneller, als bei der bisherigen Instal-

lation.

■ Einen Request von 50 Mio Sätzen in einen Cube zu verbuchen, ist für bisherige Syste-

me eine erhebliche Anstrengung. Auf SAP HANA dauert dieser Vorgang gerade mal 3

Minuten.

Limitationen: ■ Die Remodeling toolbox kann nicht verwendet werden.

■ Auf SAP HANA können neue Cubes nur In-Memory optimiert angelegt werden.

Die In-Memory optimierten Strukturen von DSO und Cube ähneln sich stark. Das

Sternschema der Cubes ist verschwunden. Die Frage stellt sich: Braucht es noch In-

focubes? SAP schreibt tatsächlich, dass nun in gewissen Szenarien auf die Datamart-

4

expertpaper

Schicht verzichtet und direkt auf DSO reportet werden kann.

Aber: Bei Bestandskennzahlen und für die integrierte Planung ist weiterhin ein Cube

nötig. Allerdings hat SAP bereits beplanbare DSOs in Aussicht gestellt. (Siehe

Expertpaper „HANA BW-IP“).

Messergebnisse bei der Auswertung

Die Messungen wurden direkt im BW mit der Transaktion RSRT gemacht. Damit

kann jeglicher Einfluss von Frontend und Netzwerk auf die Messergebnisse ausge-

schlossen werden. Wir haben erstmal ein Query mit ausschliesslich Summationen

auf beiden Systemen auf Datenbestände von 5 und 10 Mio Sätzen ausgeführt. Das

erzeugte Resultset ist mit ca. 200 Zellen durchschnittlich gross. Der Unterschied zwi-

schen den beiden Systemen ist enorm gross.

SAP vermeldet bspw. beim Ramp-up Kunden Innogence eine Beschleunigung um

den Faktor 220 bei 20 Mio ausgewerteten Sätzen. Wir konnten diesen Faktor genau

bestätigen! Der von uns gemessene Faktor liegt zwischen 200 und 220.

In der Grafik sehen Sie unsere Messergebnisse. 2 Dinge sind bemerkenswert:

■ Während unser eher klein bemessenes Vergleichssystem bei 10 Mio Sätze seine Grenze

fand, konnten wir auf der HANA locker 80 Mio Sätze auswerten.

■ Eine Query mit demselben Ergebnis auf das optimierte DSO zeigt exakt dieselben, sehr

kurzen Laufzeiten. Es spielt auf der SAP HANA tatsächlich keine Rolle, ob auf einen

Cube oder ein DSO reportet wird.

Abbildung 2: Messwerte der Antwortzeiten bei einem einfachen Query

Fast immer haben wir in realen Geschäftsanforderungen auch Ausnahmeaggrega-

tionen in den Queries dabei. Natürlich haben wir auch solche Fälle gebildet und

getestet.

5

expertpaper

Abbildung 3: Messwerte bei einem Query mit Ausnahmeaggregation

Es ist ersichtlich, dass die Kurve der SAP HANA-Messwerte ein wenig steiler liegt, als

bei der einfachen Query. Bei diesem Testfall wurde die Ausnahmeaggregation Durch-

schnitt auf das Merkmal Material mit rund 5 Mio Ausprägungen gelegt. Die SAP

HANA, resp. der OLAP-Prozessor mussten also zusätzlich zum Rest des Ergebnisses

einen Durchschnitt auf 5 Mio Einzelwerte rechnen.

Die SAP HANA ist immer noch sehr viel schneller, als das herkömmliche System.

Der von uns gemessene Faktor liegt hier bei 22. Auch hier konnte sogar ein Ergebnis

auf der Basis von 80 Mio Sätzen mit Ausnahmeaggregation in nur 165 sec errechnet

werden. Da scheint noch viel Luft nach oben vorhanden zu sein.

Achtung: Damit auch die Ausnahmeaggregation auf der SAP HANA durchgeführt

wird, muss eine Einstellung im RSRT vorgenommen werden:

Abbildung 4: Einstellung im RSRT Monitor.

6

expertpaper

Wird diese Einstellung nicht gemacht, so wird die Ausnahmeaggregation, wie bisher,

im OLAP gerechnet. Damit kann natürlich keine Beschleunigung festgestellt werden.

Zusammenfassung

SAP HANA bringt wirklich fantastische Performancevorteile. Ein BW System auf SAP

HANA ist bei den verschiedenen Vorgängen zwischen 10 und 200 Mal schneller, als

eine herkömmliche Installation. Wahrlich ein Quantensprung. Gerade bei Installati-

onen mit grossem Datenvolumen und anspruchsvollem Reporting begrüssen wir dies

aber nicht nur als tollen Fortschritt, sondern als notwendigen, nächsten Evolutions-

schritt eines Datawarehouses. Mit dieser grossen Beschleunigung können die Daten-

modelle noch so viele Daten enthalten und die Abfragen noch so komplex sein; Der

Betrieb kann nun wieder mit vernünftigem Aufwand gewährleistet werden.

Informationen

Weitere Erfahrungen der itelligence zu SAP HANA und SAP BI haben wir in den fol-genden Expert Paper zusammengetragen:

■ Planung in Echtzeit: SAP BW powered by SAP HANA

■ Erfahrungen mit SAP BI 4.0 Mobile

expertpaper

Alexander Jost

Funktion: SAP Senior Expert Business Warehouse/ Business Intelligence

Seit: 2008 bei der itelligence Schweiz AG

AG Althardstrasse 80 CH-8105 Regensdorf Telefon: +41 44 735 85 55 Fax: +41 44 735 85 50 www.itelligence.ch Bolligenstrasse 52 CH-3006 Bern Telefon: +41 31 340 32 32 Fax: +41 31 340 32 30 info@itelligence.ch