Vom Durchschnittstypen zum Klassenprimus
Bernd Weber ist ein Allerweltstyp. Er ist nicht wirklich groß, aber auch nicht klein, trägt gerne Kleidung in gedeckten Tönen und bewegt sich langsam. Er selber würde sich wohl als einen Mann mit wichtigen Aufgaben, kleinen Wehwehchen und in seinen besten Jahren beschreiben.
Viele von uns kennen diesen Bernd irgendwoher, besser bekannt ist er unter seinen Initialen BW. Wir wollen uns diesen Durchschnittsbernd einmal näher ansehen. Wie sieht er wirklich aus?
Die Ergebnisse, die in diesem Artikel genannt werden, basieren auf zahlreichen automatisierten Analysen von produktiven Business-Warehouse-Systemen, welche wir im Jahr 2012 im Rahmen des DataVard SAP BW Fitnesstest durchführten. Die Systeme stammen von Unternehmen aus verschiedenen Branchen und Größen, von Chemie bis Utilities, von KMU bis DAX.
Der Durchschnittstyp
Unser Bernd Weber, also das absolut durchschnittliche SAP BW, hat eine Systemgröße von circa 4,2 Terabyte. Unser Überblick zeigt, dass mit 46 Prozent fast die Hälfte aller Systeme ebenfalls im Bereich zwischen einem und fünf Terabyte liegt.
Weitere 31 Prozent, also immerhin jedes dritte System, sind sogar kleiner als ein Terabyte. Zehn Prozent der Systeme sind fünf bis zehn Terabyte groß und lediglich 13 Prozent aller von uns analysierten Systeme überspringen die Zehn-Terabyte-Grenze.
Im Angesicht der aktuellen Big-Data-Diskussion fragen wir uns, woher dieses Trendthema im Kontext von SAP BW kommt, sind die meisten Systeme doch anscheinend gar nicht so groß. Ein wichtiges Indiz für Big Data ist unserer Meinung nach aber nicht die reine Systemgröße, sondern das Datenvolumen, welches in einer Query abgefragt werden muss.
In unserem Durchschnittssystem liegen weniger als ein Drittel der Daten in der Reporting-Schicht. Des Weiteren besteht das System meist zu über 40 Prozent aus temporären und sonstigen Daten.
Unter sonstigen Daten verstehen wir alles außer Stamm-, Cube-, ODS-, PSA-Daten sowie ChangeLogs. Häufig stellen wir fest, dass die größten Tabellen in dieser Gruppe die BW-Statistiken sind. Der Rest des BW-Systems setzt sich aus den Datenaufbereitungsschichten und den Stammdaten zusammen.
Die Größe eines BW-Systems lässt wenig Rückschlüsse auf Herausforderungen der Zukunft zu. Ein wichtiger Indikator ist dafür das Wachstum. Unser Bernd Weber hat eine Wachstumsrate von stolzen 30 Prozent im Jahr!
Wachstumsschmerzen bleiben hier natürlich nicht aus. Nach zwei bis drei Jahren hat sich das System in seiner Größe verdoppelt. Auf der einen Seite sinken die Kosten für bestehende Speichertechnologien und können damit einen Teil des Wachstums zumindest finanziell auffangen.
Auf der anderen Seite sehen wir aber aktuelle Entwicklungen, wie In-memory Computing, welche die Kosten pro Gigabyte wieder in die Höhe treiben. Wachsende Datenbestände führen neben einer steigenden TCO (Total Cost of Ownership) auch zu Herausforderungen für die Performance.
Das Durchschnittssystem hat eine Weighted Query Step Runtime von 14 Sekunden. Dieses Ergebnis erklärt so manchen Frust auf der Anwenderseite. Das blasse Auftreten unseres Durchschnittstypen liegt nicht nur an seinen unauffälligen Eigenschaften, wie seiner Größe und seiner Performance, sondern auch an seinem letzten Upgrade.
Bernd Weber ist ein BW-System auf dem NetWeaver Release 7.01. Lediglich neun Prozent der Systeme laufen auf 7.30 und höher. Dies ist besonders interessant im Zusammenhang mit Hana, denn für einen Umstieg auf diese Technologie ist mindestens dieses Release vonnöten.
Der Klassenprimus
Im Gegensatz zu unserem unauffälligen Durchschnittsystem ist der Klassenprimus eine schillernde Persönlichkeit. Den großen Unterschied finden wir in seiner Statur und Fitness. Er ist athletisch und schnell.
Im Gegensatz zu den 14 Sekunden Weighted Query Step Runtime des Durchschnittstypen ist der Primus in vier Sekunden ins Ziel gekommen – und das ganz ohne Hana. Interessant ist auch der Körperfettanteil des Primus: Die temporären und Systemdaten machen hier nur noch 20 Prozent des Gesamtsystems aus.
Des Weiteren ist die Datenhaltung schlanker, da nur aktuelle Daten in den Infoprovidern vorgehalten werden und „kalte“ Daten regelmäßig ausgelagert werden. Es gibt sicherlich viele Gründe für diese gute Performance, drei stellen wir hier kurz vor:
1. Die Nutzung seiner guten Veranlagung, der Bordmittel eines BW-Systems, sind hier ein wichtiger Erfolgsfaktor. Das Datenmodell ist zugriffszeitenoptimiert – der Leseaufwand pro Query ist gering. Wir berechnen die Anzahl der zu lesenden Zeilen pro ausgegebene Zeile, um dies zu messen.
Im Durchschnittssystem kommen auf eine angezeigte Zeile 57 gelesene Datensätze. Bei den Topsystemen sind es lediglich drei bis fünf Zeilen. Eine solche Optimierung des BW-Systems ist ohne externe Lösungen zu schaffen.
2. Die besten Systeme haben ein gutes Housekeeping gemeinsam, durch welches Daten, die für Reporting und Datenaufbereitung nicht nötig sind, ausgemistet werden. Die führenden Systeme arbeiten hier mit voll automatisierten Lösungen, um Nachhaltigkeit zu gewährleisten.
Im Gegensatz zu diesen Systemen stellen wir bei der Untersuchung vieler normaler BW-Systeme fest, dass Statistik- und Log-Tabellen zu den größten im System gehören. Hier drängt sich die Frage auf, ob die drei Jahre alte Query-Zugriffsstatistik ebenso werthaltig ist wie die Auftragseingänge des Vortags.
3. Beim Klassenprimus werden außerdem die Daten nach Häufigkeit des Zugriffs aufgeteilt, um Reportingzeiten zu optimieren – dies wird typischerweise über Zeitscheiben realisiert. Die Reportingzeit wird deshalb optimiert, weil die Datenmenge, auf die zugegriffen wird, reduziert ist.
Wir beobachten hierfür zwei Vorgehensweisen: Partitionierung und Archivierung/NearLine Storage. Bei der Partitionierung werden die Infoprovider häufig noch manuell aufgespalten. Das kann zum Beispiel heißen, dass die Auftragsdaten eines jeden Geschäftsjahrs in einem eigenen Infoprovider liegen.
Bei der Archivierung beziehungsweise dem NearLine Storage (NLS) werden die Daten automatisch nach Ablauf einer Aufbewahrungszeit aus dem aktiven Infoprovider herausgeladen. SAP hat durch die NLS-Schnittstelle die Möglichkeit geschaffen, die Daten trotzdem im vollen Zugriff der Benutzer zu halten.
NLS ist dabei nicht gleichbedeutend mit Sybase IQ: Die Daten werden je nach eingesetzter Lösung direkt im SAP-System hochkomprimiert gespeichert oder in eine separate Datenhaltung geladen. Der Vorteil gegenüber der Partitionierung ist, dass das System weniger Ballast enthält, da die alten Daten einen geringeren Teil des Systems ausmachen.
Fazit
Wie wir gesehen haben, unterscheiden sich BW-Systeme in großem Ausmaß. Besonders die Performance kann in durchschnittlichen und unterdurchschnittlichen Systemen schnell zu Frust auf der Anwenderseite führen.
Hana hilft hier nur eingeschränkt: Durch einen Technologiewechsel wird ein schlechtes Datenmodell nicht auch gleich besser. Es gibt verschiedene Möglichkeiten, um das System auf Vordermann zu bringen. Eine detaillierte Analyse des BW-Systems ist der beste Start, um die richtigen Ansatzpunkte hierfür zu finden.
Der SAP BW Fitnesstest von DataVard bietet neben einer Analyse des Ist-Zustandes auch ein Benchmarking mit über 100 produktiven BW-Systemen. So ist auf einen Blick ersichtlich, in welchen Bereichen das eigene Business Warehouse Verbesserungspotenziale besitzt.
