Die Risiken beim Umstieg im Griff

Sonderdruck aus Heft 9/2015 vom 14.09.2015 · www.sap-port.de
SAP BW auf SAP HANA
Die Risiken beim Umstieg im Griff
Quelle: Camelot ITLab
Potenzielle Chancen und Risiken bei der BW-auf-HANA Einführung
SAP BW auf SAP HANA (kurz BW-auf-HANA) vereint die Funktionen von SAP BW mit den Geschwindigkeitsvorteilen von SAP HANA. Im Vergleich zu einem klassischen SAP BW-System beschleunigt BW-auf-HANA
unter anderem die Berichtsausführung. Kommen jedoch bei der BW-auf-HANA-Einführung strategische Überlegungen zu kurz und werden Optimierungspotenziale nicht ausgeschöpft, können auch Risiken entstehen.
Von Dr. Matthias Merz*
*Dr. Matthias Merz
ist Head of Center of
Excellence HANA bei
Camelot ITLab.
ie mit einer BW-auf-HANA-Einführung verbundenen Chancen
und Risiken skizziert Abbildung 1. Ohne
die Anpassung bestehender Konzepte,
Strategien und Datenmodelle ergeben
sich potenzielle Risiken in Zusammenhang mit der Beherrschbarkeit künftiger Datenmengen, der Konsistenz von
Datenmodellen und nicht realisierten
Optimierungspotenzialen. Demgegenüber lassen sich mit einem geeigneten
Datenhaltungskonzept, dem Anpassen
von Strategien und Leitlinien an BWauf-HANA sowie mit dem Optimieren
bestehender Datenmodelle neue Chancen nutzen und zeitgleich die potenziellen Risiken minimieren.
D
Das Datenhaltungskonzept
Bereits vor der Einführung von BW-aufHANA ist es sinnvoll, ein individuelles
und langfristiges Datenhaltungskonzept
zu erarbeiten. Zwar werden die Datenbestände in SAP HANA stark komprimiert, wodurch das Datenvolumen zunächst sinkt. Dennoch muss auch das Datenwachstum der nächsten Jahre im Auge
behalten werden. Schließlich ist der limitierende Faktor zur effektiven Nutzung der In-Memory-Technik der verfügbare Hauptspeicher. Hier kann beispielsweise ein Near Line Storage (NLS)
helfen, die steigenden Datenmengen
langfristig zu beherrschen. Die Daten,
die seltener für Auswertungen benötigt
werden, können dann in das kostengünstigere NLS verschoben werden.
Der Online-Zugriff auf die archivierten
Daten bleibt dabei erhalten. So ist ein Reporting auf Basis archivierter Daten jederzeit möglich, ohne dass Daten zuvor
in das BW zurückgeladen werden müssen. Lediglich die Zugriffszeit erhöht sich
in diesem Fall. Da jedoch nur selten genutzte Daten archiviert werden, sind höhere Zugriffszeiten hier meist vertretbar.
Mit dem passenden Datenhaltungskonzept, das eine regelmäßige Archivierung
von Daten berücksichtigt, kann auch langfristig auf die wachsenden Datenmengen
flexibel reagiert werden. Zudem lassen
sich mit dem Einsatz eines NLS idealerweise sogar Kosten sparen, etwa dann,
wenn damit eine teure Scale-Out-Lösung
vermieden werden kann.
Strategien und Leitlinien
Auch die Strategien und Leitlinien werden
nicht immer an die neuen HANA-spezifischen Gegebenheiten angepasst. Dabei
erschließen sich die vollen Potenziale von
BW-auf-HANA erst durch Nutzung neuer
Funktionen. Diese setzen meist den Einsatz der neuen BW-Modellierungsobjekte
voraus:
䡲 SAP HANA CompositeProvider
(HCPR):
Mit diesem Modellierungsobjekt können die Daten anderer InfoProvider besonders performant über JOIN- und
UNION-Operationen zusammengeführt werden.
䡲 Open ODS View:
Ermöglicht den Zugriff auf Daten externer Systeme, so dass eine zusätz-liche
Datenablage im BW nicht erforderlich
ist.
䡲 Advanced DataStore-Object
(ADSO):
Das ADSO soll zum zentralen Modellierungsobjekt im BW werden und
sämtliche InfoProvider mit eigenständiger Datenhaltung ablösen. Ein
ADSO kann wahlweise aus Feldern
oder InfoObjekten aufgebaut sein. Im
Vergleich zu klassischen DSOs weist
es schnellere Aktivierungs- und Ladezeiten auf.
Bevor mögliche Strategien im Umgang
mit den neuen BW-Modellierungsobjekten zur Sprache kommen, soll zunächst
deren Verwendung erläutert werden.
Abbildung 2 basiert auf einer Vorlage
von SAP (http://scn.sap.com/docs/DOC63681, Seite 15) und wurde geringfügig
erweitert. Sie stellt den heute verwendeten InfoProvidern das jeweils neue, korrespondierende BW-Modellierungsobjekt
gegenüber. Demnach soll der HCPR den
klassischen CompositeProvider (COPR),
den MultiProvider, das InfoSet sowie den
TransientProvider ablösen.
Der Open ODS View wird den VirtualProvider ersetzen. Keine Veränderungen
sind derzeit beim Einsatz von InfoObjekten vorgesehen. Alle weiteren InfoProvider
mit eigenständiger Datenhaltung, wie In-
foCubes oder DSOs, sollen mittel- bis
langfristig vom ADSO abgelöst werden.
Übergangsweise können InfoCubes aber
auch in SAP HANA optimierte InfoCubes
konvertiert werden, um direkt von den
schnelleren Lade- und Reporting-Zeiten
zu profitieren.
Ein Muss: Richtlinien für Entwickler
Die neuen BW-Modellierungsobjekte
beschleunigen Berechnen und Ausführen von BW-Queries, bieten eine höhere
Flexibilität bei der Datenhaltung und
verkürzen die Zeiten der Datenladeprozesse. Entsprechend groß ist der Reiz
für BW-Entwickler, diese Objekte sofort
in den laufenden Projekten einzusetzen.
Um zu verhindern, dass die klassisch
verwendeten InfoProvider und die neuen Modellierungsobjekte quasi zufällig
nach den persönlichen Vorlieben einzelner Personen eingesetzt werden, müssen auch die Entwicklerrichtlinien an
die neuen Gegebenheiten angepasst
werden.
Nur so lässt sich verhindern, dass es zu
Inkonsistenzen („Wildwuchs“) in den
Datenmodellen kommt. Andernfalls
könnte dies die Wartung und Erweiterung von BW-Applikationen mittel- bis
langfristig erschweren, wodurch entsprechend die Aufwände und folglich
auch die Kosten steigen.
Eine mögliche Strategie ist, bei Anpassungen bestehender BW-Modelle ausschließlich klassische BW-Objekte zu
verwenden. Schließlich sind die Datenflüsse meist über Jahre gewachsen und
die etablierten Datenbeladungsvorgänge
laufen stabil. Modifikationen können ohne die neuen BW-Modellierungsobjekte
dann in der Regel effizienter durchgeführt werden und führen nicht zu potenziellen neuen Problemen.
Anders sieht es jedoch beim Aufbau
neuer BW-Applikationen aus. Hier
sollte generell entschieden werden, ob
und wann die neuen Modellierungsobjekte zum Einsatz kommen. Diese Entscheidung ist individuell zu fällen und
sollte erst nach sorgfältiger Prüfung erfolgen.
Dabei ist etwa zu berücksichtigen, dass
ein Teil der neuen Objekte nur mit
Hilfe der BW-Modelling-Tools in Eclipse bearbeitet werden können. Diese
Tools müssen dann allen erforderlichen
Mitarbeitern zur Verfügung stehen und
das notwendige Know-how muss aufgebaut sein. Zudem sind aktuell auch
Restriktionen zu berücksichtigen, beispielsweise dass ein ADSO derzeit weder für Planungszwecke eingesetzt noch
in semantisch partitionierten Objekten
(SPOs) genutzt werden kann. Je nach Fall
kann es daher durchaus sinnvoll sein, mit
dem Einsatz der neuen Modellierungsobjekte noch eine gewisse Zeit zu warten. Dennoch können Unternehmen auch
in diesem Fall von den wesentlichen Vorzügen von BW-auf-HANA profitieren.
Dann sind jedoch Anpassungen an den
bestehenden Datenmodellen erforderlich,
die im folgenden Abschnitt aufgezeigt
werden.
Existierende Datenmodelle
In der Praxis werden nach Einführung
von BW-auf-HANA häufig keine Optimierungen an existierenden Datenmodellen durchgeführt – zu kostspielig erscheinen manchem Verantwortlichen solche Maßnahmen. Dass sich im Gegenzug
die Total Cost of Ownership (TCO) reduzieren lassen, wenn etwa das Datenvolumen sinkt, weniger InfoProvider gewartet werden müssen oder sich Ladezeiten verkürzen, findet nur gelegentlich
Beachtung.
Das Optimierungspotenzial bei der Datenmodellierung ergibt sich aus den neuen Leistungseigenschaften von BW-aufHANA. So werden beispielsweise BWQueries, die auf DSOs basieren, unter
BW-auf-HANA genauso schnell ausgeführt wie diejenigen, die auf InfoCubes
aufsetzen. Aus Performancegründen gibt
es daher keine Veranlassung mehr, Daten
in einen InfoCube fortzuschreiben. Werden Daten im bestehenden Datenmodell
unverändert von einem DSO in einen
InfoCube übertragen, kann dieser in der
Regel eliminiert werden. Hierdurch reduzieren sich die Beladungszeiten und
das Datenvolumen sinkt.
Ist das Entfernen von InfoCubes nicht
überall möglich, bietet es sich an,
die verbleibenden InfoCubes in SAP
HANA optimierte InfoCubes zu konvertieren. Dies sollte zwar zunächst im Entwicklungssystem getestet werden, verursacht aber im Allgemeinen keine größeren
Schwierigkeiten. So können Anwender
auch ohne den Einsatz von ADSOs von
den schnelleren Lade- und ReportingZeiten profitieren. Dies ist insofern hervorzuheben, weil derzeit noch Migrationswerkzeuge zur Konvertierung zusammenhängender Datenmodelle fehlen (vgl.
http://scn.sap.com/docs/DOC-64718).
Frühe Diskussion, verbindliches
Festschreiben
Weiter lohnt sich auch der Blick auf
Transformationen. Werden hier bestimmte Regeln eingehalten, kann der Lade-
Quelle: Camelot ITLab
Ablösung klassischer InfoProvider durch neue BW-Modellierungsobjekte
vorgang zur Beschleunigung mittels CodePushdown in die SAP HANA-Datenbank
verlagert werden. Daher kann es ratsam
sein, besonders performance-kritische
Ladevorgänge zu analysieren und die
Transformationen so anzupassen, dass im
DTP die SAP HANA-Ausführung aktiviert werden kann.
Ganz gleich, welches Datenhaltungskonzept Unternehmen erarbeiten, welche strategischen Entscheidungen sie treffen und
ob oder wie sie bestehende Datenmodelle optimieren – wichtig ist, dass die erläuterten Fragen frühzeitig diskutiert und
Ergebnisse verbindlich festgeschrieben
werden. Nur so können Verantwortliche
die künftige Ausrichtung ihres BW-Systems gezielt lenken, die potenziellen Risiken minimieren und gleichzeitig die
Chancen optimal nutzen.
In absehbarer Zeit werden sich die Unternehmen ohnehin noch intensiver mit sol-
chen Themen beschäftigen dürfen. Denn
SAP hat für künftige BW-Versionen einen
speziellen Modus „BW run simple mode“ angekündigt (http://scn.sap.com/docs/
DOC-63681, Seite 36), in dem sich ausschließlich die neuen Modellierungsobjekte nutzen lassen. Dann rücken die Fragen in den Mittelpunkt, ob, wie und wann
bestehende Datenmodelle auf die neuen
Modellierungsobjekte überführt werden
sollen. (ur) @

Download Report