Product Information
Performanceoptimierung – SAP BW/4HANA Teil 3
Dies ist der dritte 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 in diesem Blog ergänzend zu den bereits genannten SAP BW/4HANA spezifischen Optionen, weitere Möglichkeiten der Performanceverbesserung vorgestellt werden:
Wie können Sie als SAP BW/4HANA-Nutzer die Lade-Performance verbessern?
Sie haben BW/4HANA installiert und nutzen nun für ihr DataWarehouse eine Datenbank mit besonders guten Möglichkeiten für optimierte Laufzeit. In einem früheren Blog haben wir über die HANA-seitigen Performance-Optimierungs-Optionen gesprochen. Doch speziell einige traditionelle BW-User bleiben in Modellvarianten verhaftet, die nicht mehr optimal sind. Welche Fallen kann man vermeiden, um keine unnötigen Performance-Verluste zu erleiden?
1) Brauchen wir Datenladeprozesse?
Vermeiden Sie unnötige Datenladeprozesse. Aus performance-Aspekten ist es sinnvoll, für ihr Quellsystem (S/4HANA oder Business Suite on HANA) und das BW/4HANA-System die gleiche Datenbank zu verwenden. Dann brauchen Sie operative Daten nicht von dem Quellsystem-Schema in das BW-Schema zu laden. Statt dessen legen Sie Open ODS Views an, um den Zugriff auf die ERP-Daten mit BW-Usern zu ermöglichen (und für Filter und Berechnungen definieren Sie noch zusätzlich Composite Provider). Die Datenzugriffe sind vergleichbar schnell und die Datenbank wird nicht durch zusätzliche Ladeprozesse belastet.
2) Wie laden Sie Daten?
Wenn Sie doch einmal Daten laden müssen, z. B. aus externen System: Denken Sie daran, möglichst die HANA-Laufzeit zu nutzen. Wenn dies aufgrund des Quellsystems nicht möglich ist, Sie aber Daten harmonisieren müssen, speichern Sie die Rohdaten zuerst in einem DataStore Object (advanced) der Modellvariante Staging, nachfolgende Datentransferprozesse können dann in der SAP-HANA-Laufzeit abgearbeitet werden, wenn Sie ABAP-Routinen ersetzen. Statt dessen können Sie Formeln, Nachlesen (aus aDSO oder Stammdaten), oder AMDP in der SAP-HANA-Laufzeit nutzen. Filtern Sie die Daten früh und laden Sie nur die benötigten Spalten. Die vorgeschlagene Paketgröße im Datentransferprozess ist normalerweise gut geeignet.
3) Wie modellieren Sie die Ziele?
Bei einem Data Store Object (advanced) können Sie einzelne InfoObjekte durch Felder ersetzen oder gezielt bei einigen Info Objekten auf das Verproben der Stammdaten verzichten, was den Lade- bzw. Aktivierungsprozess beschleunigt.
Das Füllen leerer Ziele ist schneller als das Ergänzen von vorhandenen Zielen. Daher werden die Daten zunächst in einer Inbound-Tabelle eines Data Store Objects (advanced) “geparkt”, die nach Request partitioniert ist, so dass jeder Ladevorgang in einem eigenen Datenbereich landet. Sie können daher Bewegungsdaten aus verschiedenen Quellen parallel laden ohne die Befürchtung, dass ein Request einem anderen “in die Quere kommt”. (Dies gilt, sofern genug freie Prozesse vorhanden sind.) Ähnlich können Sie auch Ihre Stammdaten modellieren: Modellieren Sie Merkmale mit der Eigenschaft “Enhanced Master Data Update”, wenn Sie parallel aus mehreren Quellen Stammdaten laden wollen. Es werden dann Inbound-Tabellen für Attribute und Texte angelegt, und Sie können sogar die Daten ansehen, bevor Sie sie aktivieren.
Wenn Sie zu einem Produkt jeweils eine Produktgruppe laden und sich der Produktmanager aus der Produktgruppe ergibt, brauchen Sie den Produktmanager nicht als Attribut des Produkts laden. Sie können ihn als transitives Attribut definieren und müssen dann nur die Zuordnung von Produktgruppe zu Manger laden.
English Translated content for above:
While the first blog primarily deals with general HANA techniques and approaches to performance enhancement, this blog will provide you with additional options for improving performance in SAP BW/4HANA, in addition to those already mentioned:
How can you, as an SAP BW/4HANA user, improve loading performance?
You have installed BW/4HANA and are now using a database with exceptional capabilities for optimized runtime. In a previous blog, we discussed the performance optimization options on the HANA side. However, some traditional BW users are still stuck in modeling variants that are no longer optimal. What pitfalls can one avoid to prevent unnecessary performance losses?
Avoid unnecessary data loading processes. From a performance perspective, it makes sense to use the same database for your source system (S/4HANA or Business Suite on HANA) and the BW/4HANA system. This way, you don't need to load operational data from the source system schema into the BW schema. Instead, create Open ODS Views to allow BW users access to ERP data (and define Composite Providers for filtering and calculations). Data access is similarly fast, and the database is not burdened by additional loading processes.
If you do need to load data, for example, from external systems: Remember to use HANA runtime whenever possible. If this is not possible due to the source system but you need to harmonize data, store the raw data first in a DataStore Object (advanced) of the Staging model variant. Subsequent data transfer processes can then be executed in SAP HANA runtime if you replace ABAP routines. Instead, you can use formulas, lookups (from aDSO or master data), or AMDP in SAP HANA runtime. Filter the data early and load only the necessary columns. The proposed package size in the data transfer process is usually suitable.
For a DataStore Object (advanced), you can replace individual InfoObjects with fields or selectively skip master data verification for some InfoObjects, which speeds up the loading or activation process.
Filling empty targets is faster than supplementing existing targets. Therefore, data is initially "parked" in an inbound table of a DataStore Object (advanced) that is partitioned by request, so each loading process lands in its own data area. Consequently, you can load transaction data from various sources in parallel without the concern of one request interfering with another (provided enough free processes are available). Similarly, you can also model your master data: model attributes with the "Enhanced Master Data Update" property if you want to load master data from multiple sources in parallel. Inbound tables are created for attributes and texts, and you can even view the data before activating it.
If, for each product, you load a product group and the product manager is determined from the product group, you don't need to load the product manager as an attribute of the product. You can define it as a transitive attribute and only need to load the assignment of product group to manager.