Date post: | 17-Mar-2016 |
Category: |
Documents |
Upload: | sap-schweiz-ag |
View: | 218 times |
Download: | 0 times |
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 [email protected]