vorheriger Artikel
Ausnahmeaggregationen waren vor HANA in SAP BW häufiger eine Herausforderung bei der Laufzeit; dazu gehörte auch die Distinct-Count-Operation. Diese wird zum Beispiel beim Zählen von Kunden aus den Aufträgen genutzt.
Früher wurden Distinct-Count-Operationen häufig folgendermaßen umgesetzt: Es wurde eine berechnete Kennzahl mit dem Wert 1 angelegt und diese dann über eine Ausnahmeaggregation aufsummiert. Was in Umgebungen ohne HANA gut geklappt hat, führt aktuell jedoch dazu, dass der Pushdown nicht mehr funktioniert. Je nach Einstellung kann es also dazu kommen, dass die Berechnung nicht optimal durchgeführt wird.
Eine Lösung für HANA-Umgebungen muss also her: Konzentrieren wir uns daher im Weiteren auf die optimale Implementierung von Distinct Count mit BW on HANA oder BW/4HANA.
Einstellungen in der Query
Die Funktion ist als Ausnahmeaggregation in SAP BW bereits integriert und kann für Kennzahlen oder in Queries in bereits berechneten Kennzahlen direkt aktiviert werden. Dadurch wird erreicht, dass der optimale Ausführungsplan ausgewählt wird. Da wir zu einem InfoObjekt die Vorkommnisse in den Daten zählen wollen (zum Beispiel unsere Kunden in den Aufträgen), muss das zu zählende InfoObjekt ausgewählt werden. Dies sieht in den BW-MT so aus:
Der Ausführungsplan
Für eine optimale Ausführung des Distinct Count ist im nächsten Schritt das Datenmodell vorzubereiten, um unnötige Operationen auf der Datenbank zu verhindern. Gerade bei einer Ablage in InMemory-Datenbanken mit Column Store ist dies relevant, um eine optimale Ausnutzung der Datenbank-Features sicherzustellen. Dies gilt datenbankübergreifend auch für Produkte anderer Hersteller und stellt ein systemimmanentes Verhalten dar.
Für die Ermittlung der Kunden benötigt das BW ohne Optimierung des Datenmodells folgende Objekte, die im Ausführungsplan berücksichtigt werden müssen:
- SID vom zu zählenden InfoObjekt
- ADSO mit Fakten
Problem: SIDs von InfoObjekten
Da die ADSOs keine SID enthalten, muss während der Ausführung ein Join auf die SID-Tabelle des InfoObjekts stattfinden. Dies kostet sehr viel Ressourcen, da der Column Store nicht voll genutzt werden kann (Column vs. Join-Operation), und führt bei einer hohen Anzahl von Stammdaten zu einer längeren Laufzeit. Sind nur wenige Ausprägungen vorhanden, ist dies zu vernachlässigen.
Um diesen Join zu vermeiden, existiert im ADSO die Einstellung „Stammdatenprüfung beim Laden/Aktivieren und SID-Speicherung“, wenn man ein InfoObjekt in dem ADSO-Dialog auswählt (siehe Screenshot unten). Somit wird bei der Aktivierung des ADSOs zusätzlich zur Merkmalsausprägung auch der SID-Wert in einer eigenen Spalte gespeichert. Dies verhindert die Notwendigkeit eines Joins, und die Distinct-Count-Operation kann direkt auf der aktiven Tabelle des ADSOs ausgeführt werden.
In neueren Support Packages kann diese Optimierung auch über eine Remodellierung durchgeführt werden und das ADSO muss vorher nicht geleert werden. In früherern Versionen kann dabei noch eine Lösung der Inhalte notwendig sein. Abschließend sollte diese Einstellung nicht pauschal für alle Objekte genutzt werden, da die SID-Spalten generell mehr Speicher belegen, sondern wohlüberlegt eingesetzt werden (siehe Webinar: Best Practice – Implementierung von SAP BW on HANA).
Problem: Materialisierung bei Union-Operation
Ähnlich dem SID-Problem kann es bei objektübergreifenden Datenmodellen/Abfragen auch zu Performanceproblemen kommen. Dies resultiert daraus, dass die Datenbank bei einem Union von Tabellen (wie zum Beispiel bei Nutzung eines Composite Providers mit mehreren Objekten) diese einzeln behandeln muss. Im PlanWiz-Ausführungsplan sieht man dies daran, dass zum Beispiel eine temporäre Tabelle angelegt wird. Dies erhöht die Anforderungen an den Hauptspeicher und auch die Laufzeit zur Ausführung.
Behandlung der Ursachen
Die "Probleme" führen zu folgenden Ausführungsschritte, sich wie auch in anderen Datenbanken notwendig wären:
- Join der SIDs
- GROUP BY aus allen SIDs der Unterobjekte und Speichern in temporäre Tabelle
- Distinct Count auf die temporäre Tabelle
Lösung Schritt 1:
Diesen können wir einfach vermeiden, indem wir die SID in das ADSO aufnehmen.
Lösung Schritt 2 und 3:
Das Datenmodell muss anhand der häufigen Abfragen der Anwender angepasst werden. Erkennt die Analytic Engine beispielsweise, dass ein ADSO für die Ergebnisse nicht notwendig ist, wird dieses auch nicht gelesen (Pruning). Somit erreichen wir die beste Laufzeit, indem sichergestellt ist, dass nur ein ADSO bei der Ermittlung eines Ergebnisses genutzt wird. Einfach lässt sich dies mit semantischen Gruppen in BW/4HANA erreichen. Die analytische Engine muss vorher wissen, was in einem ADSO enthalten ist, um dieses auszuschließen. Ohne diese Information muss es die Inhalte prüfen und nutzt eine temporäre Tabelle. In der Praxis konnte in dem Beispiel für eine ähnliche Problemstellung die Speichernutzung der Query von 20 GByte während der Ausführung mit einer Laufzeit von 30 s auf 200 MByte und 1 s reduziert werden, da wenig Daten von der Datenbank zwischengespeichert werden müssen.
„Design follows function“
Eine Optimierung des Datenmodells ist immer abhängig von den Abfragen der Anwender. Somit sollte regelmäßig eine Prüfung durchgeführt werden, ob es noch den Anforderungen an die aktuellen Analytics-Prozesse genügt. Berücksichtigt man dies, kann sich die volle Leistung der HANA-Datenbank zusammen mit einem BW entfalten und die Anwender zufriedenstellen.
