expertpaper 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 Datenmodellen komplexer. Immer mehr Geschäftsbereiche möchten ihre Daten via BW reporten und Fragestellungen im Zusammenhang mit anderen Unternehmensdaten untersuchen. Dabei erreichen wir sowohl beim Staging, als auch im Reporting vermehrt die Grenze des Zumutbaren. Tätigkeiten wie DSODaten 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 Messergebnisse 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. Vorher 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 Gedanken zum Datenmanagement
den? Es macht wenig Sinn, die SAP HANA wegen solcher Daten zu gross zu dimensionieren 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 Instanzen auf einem SAP HANA System einzurichten.
Migration des Datenmodells Nachdem das SAP BW technisch auf der SAP HANA DB läuft, sollten die BW–Objekte in ihre SAP HANA optimierte Form migriert werden. Nur dann kann von den enormen Performancevorteilen von SAP HANA profitiert werden. Dieser Schritt ist optional und kann zu einem passenden Zeitpunkt durchgeführt werden. Es ist möglich, die Objekte als Teil der technischen Migration in einem Massenlauf zu migrieren. Wir empfehlen jedoch eher, die Objekte Applikationsweise zu migrieren. Dies lässt sich idealerweise mit einer Analyse der Datenmodellqualität und der Performance 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.
Abbildung 1: Tabellen des In-Memory optimierten Standard DSOs
2
expertpaper Die aktiven Daten sind neu in drei Tabellen enthalten: Aktuelle Daten, historische Daten und eine Deltatabelle. : Bei der Aktivierung werden die neuen mit den aktuellen 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 Tabellen 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 Aktivierung 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 Paketdimension). 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 Installation. ■■ Einen Request von 50 Mio Sätzen in einen Cube zu verbuchen, ist für bisherige Systeme 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 Infocubes? 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 ausgeschlossen 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 zwischen 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 Ausnahmeaggregationen 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 Durchschnitt 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 Installationen mit grossem Datenvolumen und anspruchsvollem Reporting begrüssen wir dies aber nicht nur als tollen Fortschritt, sondern als notwendigen, nächsten Evolutionsschritt eines Datawarehouses. Mit dieser grossen Beschleunigung können die Datenmodelle 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 folgenden Expert Paper zusammengetragen: ■■ Planung in Echtzeit: SAP BW powered by SAP HANA ■■ Erfahrungen mit SAP BI 4.0 Mobile
Alexander Jost
AG
Funktion:
SAP Senior Expert Business Warehouse/ Business Intelligence
Seit:
2008 bei der itelligence Schweiz AG
Althardstrasse 80
CH-8105 Regensdorf
Bolligenstrasse 52
CH-3006 Bern Telefon: +41 31 340 32 32
Telefon: +41 44 735 85 55
Fax: +41 44 735 85 50
Fax: +41 31 340 32 30
www.itelligence.ch
info@itelligence.ch