Für die Bereitstellung von Daten aus einem SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… BW an BI Frontends hat es lange nur die SAP BW Query gegeben. Mit SAP HANA und der Möglichkeit hybrider bzw. mixed Datenmodelle, ist eine neue Möglichkeit hinzu gekommen: Daten können ebenfalls über SAP HANA Calculation Views bereitgestellt werden.
Neben Aspekten der Modellierung, unterscheiden sich beide Konsumierungsarten ebenfalls in der Art der Datenbereitstellung. SAP BW-Queries werden über den OLAP-Prozessor (Online Analytical Processing) und damit dem ABAP-Server verarbeitet, wohingegen dies bei HANA-Calculation Views die Datenbank übernimmt. Zudem kommunizieren Query und Calculation Views anders. Die u.g. Grafik stellt diese Zusammenhänge dar.
Es gibt viele Gründe, sich für die ein oder andere Modellierungsvariante zu entscheiden. Entscheidend ist insb. welches BI Frontend eingesetzt werden soll. In diesem Blogpost möchten wir uns auf die Performanceunterschiede beschränken. Dabei fokussieren wir uns auf die Abfrageperformance des Backends und vergleichen nicht die Schnittstellen miteinander (MDX, BICS, etc.).
Vergleich anhand von Szenarien
Der Vergleich der Performance basiert auf dem folgenden Datenmodell. Es handelt sich um ein Datenvolumen von ca. 34 Mio. Zeilen. Der CompositeProvider stellt 56 Merkmale, sowie 4 Kennzahlen zur Verfügung.
Die Performance wird anhand von den drei folgenden Anwendungsfällen analysiert:
- Hochaggregiert – Salden, “Geschäftsjahr”, “Kontoart”
- Detaillevel – Hochaggregierter Anwendungsfall, zusätzlich aufgerissen um die Merkmale “Geschäftsjahr / Periode”, “Belegart” sowie “Bewertungsart”.
- Mit Logik – Hochaggregierter Anwendungsfall, aufgerissen nach “Geschäftsjahr” und “ProfitCenter”. Darüber hinaus werden eingeschränkte, sowie berechnete Spalten verwendet.
Im Detail: Praktische Messung der Ausführungszeiten mittels BW-Query
Die Queries der im folgenden betrachteten Anwendungsfälle haben alle die gleichen Einstellungen in den Tabs “Allgemein” und “Laufzeiteigenschaften”, welche die Standardkonfiguration widerspiegelt.
Zur Analyse der Performance wird die SAP Transaktion RSRT2 des BW/4HANA mit den folgenden Einstellungen herangezogen. Die Ausführung erfolgt immer drei Mal und der Mittelwert wird als Wertung verwendet.
Zur Auswertung der Statistiken ist es vorab wichtig zu wissen, dass beim Aufruf von Queries die in der Einleitung beschriebene Analytic Engine zum Einsatz kommt. Diese besteht unter anderem aus den Teilbereichen “Data-Manager”, welcher für das Nachlesen der Daten verantwortlich ist, sowie “OLAP-Services”, welcher die Queryergebnisse berechnet und bereitstellt.
Anwendungsfall 01
Beschreibung
Im ersten Szenario wird die Datengrundlage hoch aggregiert abgerufen. Die Query wird nur nach den vier Kennzahlen, sowie nach Geschäftsjahr und einem weiteren Merkmal (Kontoart) welches bis zu 5 Ausprägungen hat, aufgerissen. Die restlichen 54 Merkmale werden als freie Merkmale zur Verfügung gestellt. Ergebniszeilen werden nur für die Gesamtsummen, also nur für das Merkmal Geschäftsjahr ausgegeben. Diese recht schmale Abfrage liefert eine Ergebnismenge von 34 Zeilen.
Performanceanalyse
Die folgende Grafik stellt die wesentlichen Events während des Queryaufrufs dar. Die kumulierte Dauer jeder zum Test durchgeführten Ausführung ist im markierten Bereich ersichtlich. Anhand dieser wird die durchschnittliche Ausführungszeit ermittelt.
Den größten Einfluss auf die Gesamtzeit hat in diesem Anwendungsfall das Event “Daten-Manager”, welches dem Teilbereich “Data-Manager” zuzurechnen ist. Dieses misst die Zeit, sobald es aus der Analytic Engine heraus aufgerufen wird. Weitere ins Gewicht fallende Events sind dem Teilbereich OLAP-Services zuzuordnen. Diese sind u.a. “OLAP: Query-Generierung” (Zeitmessung: Prüfung der Querydefinition und ggf. der Querygenerierung), “OLAP sonstige Zeit” (Laufzeiten nicht näher bestimmt, jedoch innerhalb der Analytic Engine (OLAP) und “OLAP: Einstellungen” (Zeitmessung: Verarbeitung der Oberflächeneinstellungen sowie insbesondere Bekanntgabe der Anzeigehierarchie).
Ergebnis
Durchschnittliche Ausführungszeit: 0,4s
Anwendungsfall 02
Beschreibung
Aufbauend auf dem ersten Anwendungsfall wird in diesem Szenario eine höhere Anzahl an Zeilen ausgegeben. Hierfür wird der Aufriss erweitert um die Merkmale “Geschäftsjahr / Periode”, “Belegart” sowie “Bewertungsart”. Als Ergebnismenge erhalten wir so knapp 94.000 Zeilen.
Auch hier werden nur Ergebniszeilen für die Gesamtsummen des Geschäftsjahres ausgegeben.
Querydefinition
Performanceanalyse
Die folgende Grafik stellt die wesentlichen Events während des Queryaufrufs dar. Die kumulierte Dauer jeder zum Test durchgeführten Ausführung ist im markierten Bereich ersichtlich. Anhand dieser wird die durchschnittliche Ausführungszeit ermittelt.
In diesem Szenario fällt ein großer Teil der benötigten Ausführungszeit in den Teilbereich “OLAP-Services” der Analytic Engine. Hier ist insbesondere zu nennen “OLAP: Datentransfer”, welches die Daten an das jeweilige Frontend übergibt. Dies umfasst u.a. Ausnahmeaggregationen, Währungsumrechnungen, Formeln, Nachkommastellen sowie die Aufbereitung der Ergebnismenge anhand der Querydefinition. Daneben kosten aus diesem Teilbereich auch die Events “OLAP: Datenselektion” sowie “OLAP: Texte lesen” einiges an Zeit. Weitere ins Gewicht fallende Events sind dem Teilbereich “Data-Manager”, und hier genauer dem Event “Daten-Manager” zuzuordnen.
Ergebnis
Durchschnittliche Ausführungszeit: 15,6s!!!
Anwendungsfall 03
Beschreibung
Das dritte Szenario liefert wieder einen relativ aggregierten Aufriss, nach Geschäftsjahr, ProfitCenter und Anzahl Sätze. Ergänzt wird dieser durch eingeschränkte, sowie berechnete Kennzahlen, welche anhand von Logiken zur Laufzeit gebildet werden. Die zusätzlichen Kennzahlen setzen sich zusammen aus:
| Art | Beschreibung |
|---|---|
| Eingeschränkte Kennzahlen (Einfach) | Jeweils über ein Merkmal eingeschränkt |
| Berechnete Kennzahlen (Einfach) | Beispiel (s.u.) |
| Art | Beschreibung |
|---|---|
| Komplexere berechnete Kennzahl | Beispiel (s.u.) |
Querydefinition
Performanceanalyse
Die folgende Grafik stellt die wesentlichen Events während des Queryaufrufs dar. Die kummulierte Dauer jeder zum Test durchgeführten Ausführung ist im markierten Bereich ersichtlich. Anhand dieser wird die durchschnittliche Ausführungszeit ermittelt.
In diesem Szenario fällt wie in Szenario 1, auch eher der Teilbereich Data-Manager ins Gewicht. Hier ist ebenfalls das Event “Daten-Manager”, mit fast der Hälfte der Gesamtausführungszeit zu verknüpfen. In der Reihenfolge der Zeit-intensivsten Events, folgen danach “OLAP: Datentransfer”, “OLAP: Datenselektion” sowie “OLAP: Einstellungen”.
Ergebnis
Durchschnittliche Ausführungszeit: 0,4s
Im Detail: Praktische Messung der Ausführungszeiten mittels HANA-CalculationView
Eine HANA CalculationView wird auf der SAP HANA Datenbank ausgeführt und verarbeitet. Für die Performanceanalyse wird der Plan Visualizer verwendet. Hierzu wird ein SELECT SQL-Statement generiert und mittels des Plan Visualizers komplett ausgeführt. Auch hier wird für die Wertung der Performance der Mittelwert aus drei Messungen verwendet.
Die folgende Grafik liefert eine Übersicht der Analyseergebnisse des Plan Visualizers zur Ausführung einer HANA CalculationView. Zentrale Kennzahlen zur Performance sind unter anderem die Ausführungszeit (“Execution” im Abschnitt “Time”) sowie der benötigte Speicher (RAM) zur Ausführung (“Memory Allocated” im Abschnitt “Context”). Daneben ist es auch sehr hilfreich zu wissen, wie viele Tabellen genutzt werden, und wie groß die Ergebnismenge ist (“Number of Tables Used” und “Result Record Count” unter dem Abschnitt “Data Flow”). Des Weiteren werden Details zu den benutzten Operatoren sowie zum System und der Abfrage selbst geliefert.
Anwendungsfall 01
Beschreibung
Die SAP BW Query wird mit Hilfe des Calculation Views nachgebildet. So wird die Datengrundlage hoch aggregiert, sowie aufgerissen nach vier Kennzahlen, Geschäftsjahr und einem weiteren Merkmal (Kontoart) welches bis zu 5 Ausprägungen hat, abgerufen.
Ergebniszeilen werden nicht ausgegeben, da dies im Plan Visualizer nicht unterstützt wird.
Performanceanalyse
In der folgenden Abbildung ist das Ergebnis von einer der drei Ausführungen mittels Plan Visualizer zu sehen:
Alle dominanten Operatoren bewegen sich im Millisekunden Bereich, und der Speicherverbrauch ist hier im Vergleich zu den beiden anderen Szenarien am geringsten.
Ergebnis
Durchschnittliche Ausführungszeit: 0,1s
Anwendungsfall 02
Beschreibung
Analog zum zweiten Anwendungsfall mit einer BW-Query, wird in diesem Szenario eine höhere Anzahl an Zeilen ausgegeben. Hierfür wird der Aufriss erweitert um die Merkmale “Geschäftsjahr / Periode”, “Belegart” sowie “Bewertungsart”. Als Ergebnismenge erhalten wir so knapp 94.000 Zeilen. Ergebniszeilen werden nicht ausgegeben, da dies im Plan Visualizer nicht unterstützt wird.
Performanceanalyse
In der folgenden Abbildung ist das Ergebnis von einer der drei Ausführungen mittels Plan Visualizer zu sehen:
Anhand der dominanten Operatoren lässt sich erkennen, dass offenbar auf eine in diesem Fall eher zeit-kostende “Column Search” zurückgegriffen wurde. Der Speicherverbrauch von den drei getesteten Anwendungsfällen ist hier mit Abstand am höchsten.
Ergebnis
Durchschnittliche Ausführungszeit: 1,6s
Anwendungsfall 03
Beschreibung
Das dritte Szenario liefert wie bei Anwendungsfall 3 mit einer BW-Query, wieder einen relativ hochaggregierten Aufriss, nach Geschäftsjahr, ProfitCenter und Anzahl Sätze. Ergänzt wird dieser durch eingeschränkte, sowie berechnete Kennzahlen, welche anhand von Logiken zur Laufzeit gebildet werden. Die zusätzlichen Kennzahlen setzen sich zusammen aus:
| Art | Beschreibung |
|---|---|
| Eingeschränkte Kennzahlen (Einfach) | Jeweils über ein Merkmal eingeschränkt, Beispiel (s.u.) |
| Art | Beschreibung |
|---|---|
| Berechnete Kennzahlen (Einfach) | Prozentfunktion, Beispiel (s.u.) |
| Art | Beschreibung |
|---|---|
| Komplexere berechnete Kennzahl | IF-Abfrage bezüglich der anderen drei berechneten Kennzahlen, Beispiel (s.u.) |
Performanceanalyse
In der folgenden Abbildung ist das Ergebnis von einer der drei Ausführungen mittels Plan Visualizer zu sehen:
Auch dieser Anwendungsfall hat Ausführungszeiten der dominanten Operatoren im Millisekundenbereich. In diesem Fall ist der Speicher jedoch “nur” auf Platz 2. von den drei Anwendungsfällen.
Ergebnis
Durchschnittliche Ausführungszeit: 0,1s
Fazit
Unsere Analyse hat sich ausschließlich auf die Performance beider Modellierungsarten konzentriert und stellt keinen funktionalen Vergleich dar. Insofern beschränkt sich unser Fazit auf die Performance von Abfragen.
Hierbei gibt es einen klaren Gewinner: Die Abfragegeschwindigkeit von HANA Calculation Views ist, insb. bei der Ausgabe von hohen Datenmengen besser als die Konsumierung durch die BW Query. Sind die Unterschiede bei kleineren Datenmengen fast vernachlässigbar, zeigt sich bei der Ausgabe des zweiten Anwendungsfalls ein deutlicher Unterschied. Die BW Query bzw. der OLAP-Prozessor verliert hier im Vergleich zur HANA CalculationView, zu viel Zeit, weil die Daten erst in den ABAP-Server übertragen werden müssen, bevor die Query verarbeitet werden kann. Dies äußert sich durch das Event “OLAP: Datentransfer”, welches ca. 6 Sekunden * 2 in Anspruch nimmt.
Beim Thema Performance kommt es generell neben den reinen Ausführungszeiten jedoch immer auch auf den Speicherverbrauch drauf an. Dieser sollte wenn möglich stets auch analysiert werden. In diesem BlogPost lag das Hauptaugenmerk zwar auf den Zeiten, dennoch kann festgehalten werden, dass sich bei den HANA CalculationViews enorme Unterschiede hinsichtlich des benötigten Speichers aufzeigten (Anwendungsfall 1: ~35MB, Anwendungsfall 2: ~248MB, Anwendungsfall 3: ~82MB. Diese Unterschiede fallen bei komplexeren Szenarien mit Sicherheit noch deutlicher aus.
Nachfolgend die Ergebnisse der in diesem Artikel betrachteten Szenarien noch einmal grafisch dargestellt. Die Grafik zeigt anschaulich, dass für die betrachteten Szenarien HANA CalculationViews schneller sind als BW Queries.
Autor: David Pangalela
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
