GIBT ES PERFORMANCEUNTERSCHIEDE ZWISCHEN BW-QUERIES UND CALCULATIONVIEWS?

Beitrag teilen

Share on xing
Share on linkedin
Share on facebook
Share on twitter

Für die Bereitstellung von Daten aus einem SAP 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. 

Performanceanalyse: BW Queries und Calculation Views: Frontend Zugriff

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.

Performanceanalyse: BW Queries und Calculation Views: vergleich Szenarien

Die Performance wird anhand von den drei folgenden Anwendungsfällen analysiert:

  1. Hochaggregiert – Salden, „Geschäftsjahr“, „Kontoart“
  2. Detaillevel – Hochaggregierter Anwendungsfall, zusätzlich aufgerissen um die Merkmale „Geschäftsjahr / Periode“, „Belegart“ sowie „Bewertungsart“.
  3. 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. 

Performanceanalyse: BW Queries und Calculation Views

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: BW Queries und Calculation Views

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.

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). 

Performanceanalyse: BW Queries und Calculation Views: Analyse 01

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 knapp 94.000 Zeilen.

Auch hier werden nur Ergebniszeilen für die Gesamtsummen des Geschäftsjahres ausgegeben.

Querydefinition

Performanceanalyse: BW Queries und Calculation Views

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.

Performanceanalyse: BW Queries und Calculation Views: Analyse 02

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.)
Performanceanalyse: BW Queries und Calculation Views
Art Beschreibung
Komplexere berechnete Kennzahl Beispiel (s.u.)
Performanceanalyse: BW Queries und Calculation Views

Querydefinition

Performanceanalyse: BW Queries und Calculation Views

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.

Performanceanalyse: BW Queries und Calculation Views: Analyse 03

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. 

Performanceanalyse: BW Queries und Calculation Views

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, wieviele Tabellen genutzt werden, und wie groß die Ergebnismenge ist („Number of Tables Used“ und „Result Record Count“ unter dem Abschnitt „Data Flow“). Desweiteren werden Details zu den benutzten Operatoren sowie zum System und der Abfrage selbst geliefert.

Performanceanalyse: BW Queries und Calculation Views

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:

Performanceanalyse: BW Queries und Calculation Views

Alle dominanten Operatoren bewegen sich im Millisekundenbereich, 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:

Performanceanalyse: BW Queries und Calculation Views

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.)
Performanceanalyse: BW Queries und Calculation Views
Art Beschreibung
Berechnete Kennzahlen (Einfach) Prozentfunktion, Beispiel (s.u.)
Performanceanalyse: BW Queries und Calculation Views
Art Beschreibung
Komplexere berechnete Kennzahl IF-Abfrage bezüglich der anderen drei berechneten Kennzahlen, Beispiel (s.u.)
Performanceanalyse: BW Queries und Calculation Views

Performanceanalyse

In der folgenden Abbildung ist das Ergebnis von einer der drei Ausführungen mittels Plan Visualizer zu sehen:

Performanceanalyse: BW Queries und Calculation Views

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.

Performanceanalyse: BW Queries und Calculation Views: Fazit

Autor: David Pangalela

SAP_Kamp

KONTAKT

Christopher Kampmann
Senior Manager
SAP Information Management

christopher.kampmann@isr.de
+49 151 422 05 411

Über ISR

Die ISR Information Products AG ist Ihr Experte für Analytics, Prozess-Digitalisierung und Application Management. Mit Blick auf die Bedürfnisse namhafter Kunden konzipieren, modernisieren, implementieren und betreuen ca. 200 Mitarbeiter an sechs Standorten IT-Architekturen, Software-Lösungen und IT-Infrastrukturen. Das Ziel: Unseren Kunden die wirtschaftliche Nutzung von Daten zu ermöglichen.
News Kategorien
News Archiv

News nach Autoren

Zuletzt erschienen

Nächste ISR Events

Es gibt derzeit keine anstehenden Veranstaltungen.

ISR Facebook Feed

Facebook

Mit dem Laden des Beitrags akzeptieren Sie die Datenschutzerklärung von Facebook.
Mehr erfahren

Beitrag laden

Haben wir Ihr Interesse geweckt?