Product Information
Performanceoptimierung – SAP BW/4HANA Teil 2
Dies ist der zweite Blog aus einer kleinen Reihe, welcher Ihnen eine Übersicht über die zentralen Stellhebel zur Performanceoptimierung in der SAP BW/4HANA vermitteln soll.
– Performanceoptimierung – SAP BW/4HANA Teil 1
– Performanceoptimierung – SAP BW/4HANA Teil 2
– Performanceoptimierung – SAP BW/4HANA Teil 3
Während sich der erste Blog hauptsächlich mit allgemeinen HANA-Techniken und Ansätzen zur Performanceerhöhung befasst, sollen Ihnen hier SAP BW/4HANA spezifische Optionen zur Verbesserung der Auswertungsperformance skizziert werden:
Wie können Sie als Modellierer für SAP BW on HANA oder SAP BW/4HANA eine gute Laufzeit-Performance erreichen?
Sie nutzen schon für ihr Data Warehouse die SAP-HANA-Datenbank mit besonders guten Möglichkeiten für optimierte Laufzeit. In einem früheren Blog haben wir Tipps für die SAP-HANA-basierte Performance-Optimierung gegeben. Doch was gilt für die Anwendungsebene? Speziell einige traditionelle BW-User bleiben in Modellvarianten verhaftet, die nicht mehr optimal sind. Welche Fallen können Sie vermeiden, um keine unnötigen Performance-Verluste zu erleiden?
1) Vermeiden Sie unnötige Datenladeprozesse
Früher wurden Daten typischerweise in mehreren Stufen verdichtet, und jede Verdichtung erforderte einen eigenen Ladeprozess. Da SAP HANA besonders gut Daten im Hauptspeicher aggregieren kann, reicht in den meisten Fällen ein einziges DataStore Object (advanced) der Modellvariante Standard aus, das als Grundlage für Ihre Berichte dient. Wenn (einfache) Berechnungen auf dieser Datenbasis gebraucht werden, können Sie diese in Composite Provider und BW Queries einbauen. Nur für spezifische Berechnungen, die nicht beim Reporting ausführbar sind, empfehlen wir eine weitere physische Datenbasis in Form eines DataStore Objects (advanced).
Wenn die Quelle schnell genug gelesen werden kann, reicht es sogar aus, in SAP HANA vorhandene Daten virtuell zu kombinieren. Nutzen Sie dazu Open ODS Views, wenn die Daten 1:1 über Data Sources, Tabellen oder virtuelle Tabellen verfügbar sind oder mit BW-Mitteln transformiert werden können. Wenn Sie darüber hinausgehende Features von SAP HANA nutzen wollen oder Hybridszenarien aus BW- und HANA-Modellen verwenden wollen, definieren Sie native Calculation Views. In beiden Varianten empfehlen wir Composite Provider zur Integration von weiteren Daten und von (Navigations-)Attributen.
2) Wählen Sie die beste Kombinationsmöglichkeit
Wenn Sie beispielsweise einen Ladenhüterbericht (unverkaufte Produkte) erstellen wollen, haben Sie mehrere Optionen: Sie könnten alle Produkte in ein Data Store Object (advanced) laden und dabei bei unverkauften Produkten in der Transformation Nullwerte ergänzen. Damit würden Sie aber unnötige Daten speichern. Sparsamer ist es, wenn Sie durch einen Composite Provider Stammdaten und Bewegungsdaten kombinieren. Dafür haben Sie zwei Optionen: Outer Join oder Union. Union ist die schnellere Variante, da das Aggregieren schneller geht als das Identifizieren von korrespondierenden Werten in einem Join. Sie können aber am einfachsten ein Navigationsattribut mit der Lese-Option “Stammdaten” in der Bw-Query verwenden, dann wird die Kombination nur für die in der Query benötigten Werte herausgesucht.
3) Definieren Sie Queries HANA-optimiert
Worauf können Sie bei der BW-Query-Definition achten? Bei der Definition von Einschränkungen in vordefinierten Kennzahlen und BW-Queries verwenden Sie eher ein einziges Filtermerkmal (Kalenderjahr/Monat) als zwei (Kalenderjahr und Monat), erst recht, wenn dieses Merkmal als Kriterium für die Partitionierung des Datenspeichers verwendet wurde. Bedenken Sie außerdem: Eine positive Auswahl der gewünschten Werte ist schneller als eine Negativliste der nicht benötigten Werte oder als eine Auswahl über Hierarchieknoten.
BW-Queries sind vor allem langsam, wenn Sie Sonderfunktionen wie Ausnahmeaggregation oder Top-%-Bedingung verwenden, die ein Ansehen aller Datensätze benötigen. In diesen Fällen sollten Sie unbedingt sicherstellen, dass Sie bei der Runtime-Eigenschaft “Ausführung in SAP HANA” die Eigenschaft “offensiv” verwenden.
English Translation for Above:
While the first blog mainly focuses on general HANA techniques and approaches to performance improvement, here, SAP BW/4HANA-specific options for improving evaluation performance will be outlined:
How can you, as a modeler for SAP BW on HANA or SAP BW/4HANA, achieve good runtime performance?
You are already using the SAP HANA database for your data warehouse, which offers particularly good possibilities for optimized runtime. In a previous blog, we provided tips for SAP HANA-based performance optimization. But what applies to the application layer? Specifically, some traditional BW users remain stuck in modeling variants that are no longer optimal. What pitfalls can you avoid to prevent unnecessary performance losses?
In the past, data was typically condensed in several stages, and each consolidation required its own loading process. Since SAP HANA excels at aggregating data in-memory, in most cases, a single DataStore Object (advanced) of the Standard model variant is sufficient as a basis for your reports. If (simple) calculations are needed on this data foundation, you can incorporate them into Composite Providers and BW Queries. Only for specific calculations that cannot be executed during reporting, do we recommend an additional physical data foundation in the form of a DataStore Object (advanced).
If the source can be read fast enough, it is even sufficient to virtually combine data existing in SAP HANA. To do this, use Open ODS Views when the data is available 1:1 through Data Sources, tables, or virtual tables or can be transformed using BW methods. If you want to leverage additional features of SAP HANA or use hybrid scenarios of BW and HANA models, define native Calculation Views. In both variants, we recommend Composite Providers for integrating additional data and (navigation) attributes.
For example, if you want to create a slow-moving items report (unsold products), you have several options: You could load all products into a DataStore Object (advanced) and fill in null values in the transformation for unsold products. However, this would store unnecessary data. It is more efficient to combine master data and transaction data through a Composite Provider. For this, you have two options: Outer Join or Union. Union is the faster option as aggregation is faster than identifying corresponding values in a join. But the easiest way is to use a navigation attribute with the "master data" read option in the BW Query; then, the combination is only selected for the values required in the query.
What can you consider when defining BW queries? When defining constraints in pre-defined key figures and BW Queries, it's better to use a single filter characteristic (calendar year/month) rather than two (calendar year and month), especially if this characteristic was used as a criterion for partitioning the data storage. Also, remember: a positive selection of desired values is faster than a negative list of unwanted values or a selection via hierarchy nodes.
BW Queries are particularly slow when using special functions such as exception aggregation or top-% condition, which require a view of all records. In these cases, you should definitely ensure that you use the "offensive" execution property in SAP HANA for the runtime property "Execution in SAP HANA."