SAP HANA – In-Memory-Technologie

In-Memory-Technologie ist zurzeit eines der interessantesten technischen Themen in der Informationstechnologie, die in naher Zukunft sicher einiges an Veränderungen bringen wird. Hauptanwendungsgebiet sind zurzeit analytische Systeme, die durch den Einsatz von In-Memory-Technologie einen enormen Performancegewinn erzielen. Weitere Einsatzgebiete werden von den großen Herstellern derzeit getestet und pilotiert. SAP mit seiner In-Memory-Lösung HANA geht hier einen sehr konsequenten, innovativen Weg.

Unternehmen, in denen SAP-Software eine zentrale Rolle in der Applikationslandschaft spielt, müssen sich mit diesem Thema früher oder später auseinandersetzen. Vielfach existiert zurzeit noch eine recht große Unsicherheit darüber, wie man mit SAP HANA umgehen soll. Ist es bereits marktreif? Wird es für das eigene Unternehmen eine Rolle spielen? Wann ist der richtige Zeitpunkt, eigene Aktivitäten zu entwickeln? Wie sieht die eigene Strategie aus? Einige Informationen zum Verständnis und einige Anregungen sollen helfen, sich dem Thema HANA zu nähern.

Zunächst ein paar Hinweise zu den Grundlagen der HANA-Technologie. Systemtechnisch gesehen basiert SAP HANA auf einer hybriden In-Memory-Datenbank. Diese vereint zeilen-, spalten- und objektbasierte Datenbanktechnologie, die optimiert ist auf Parallelverarbeitungsfunktionalität moderner Multi-Core-/CPU-Architekturen. Hierzu wird spezielle Hardware benötigt, die durch SAP-Partner bereitgestellt wird. Das Ganze läuft dann auf einem SUSE Linux Enterprise Server (SLES). SAP HANA stellt aber nicht nur die gerade beschriebene Systemumgebung dar, sondern ist als ein Paket zu sehen, das neben der Systemumgebung auch entsprechende Software bereitstellt. Diese wird je nach Umfang in unterschiedlichen Editionen geliefert.  Wichtigster Bestandteil ist in jedem Fall die Datenbank, die quasi die Schnittstelle zur Systemumgebung darstellt. Darum herum existieren weitere HANA-Komponenten, einige wichtige sind:

SAP HANA Studio und SAP HANA Client stellen Werkzeuge dar, mit denen die HANA-Datenbank administriert werden kann, z.B. durch Erstellung von Datenbankobjekten, Zugriff auf Datenbankobjekte etc. Dies lässt sich vergleichen mit den Administrationswerkzeugen herkömmlicher Datenbanken. Auch die Abfragesprache der Datenbank ist mit der SQL-Abfragesprache herkömmlicher Datenbanken zu vergleichen.

Mit dem SAP Landscape Transformation (LT) replication server können Daten von externen Datenprovidern wie z.B. SAP ERP oder SAP BW in die HANA-Datenbank repliziert werden.

Mit dem SAP HANA Client Package for Microsoft Excel wird der Zugriff auf HANA-Daten aus Excel heraus ermöglicht.Darüber hinaus können Daten auch über die Business Objects Clients abgefragt werden, die selbst aber nicht Bestandteil des SAP HANA sind.

Der effizienteste Weg, Daten in SAP HANA zu laden,
ist die Replikation.

Wie die Abbildung zeigt, gibt es verschiedene Replikationsarten, Trigger-, ETL- und Log-Based Replikation, auf die hier aber nicht näher eingegangen wird.

SAP HANA stellt eine komplexe System- und Applikationsumgebung dar, die sehr starke Veränderungen in der Applikationsarchitektur mit sich bringen wird. Eine wesentliche Veränderung wird sein, dass SAP ERP und SAP BW auf einer zentralen HANA-Datenbank laufen werden. Dies wird nicht von heute auf morgen geschehen, vielmehr ein evolutionärer Prozess sein. Um sich als Unternehmen auf SAP HANA einzustellen, ist es notwendig, diesen Prozess zu verstehen. Schauen wir uns daher die HANA-Roadmap der SAP an. Der Entwicklungsprozess findet grob in drei Phasen statt.

Die drei Entwicklungsphasen von HANA

In der ersten Phase I („SAP HANA 1.0")  wurde die HANA- Datenbank als separate Datenbank entwickelt. Daten konnten per Replikation in die Datenbank übertragen werden, darauf basierend konnten auf der Datenbank-Applikationen erstellt werden. Der Anwendungsbereich war eingeschränkt, diese Phase ist abgeschlossen.

In der Phase II („SAP HANA 1.0 SPS3") dient HANA als primäre Datenbank für SAP BW. Dies ist der zurzeit aktuelle Stand, in dieser Phase erfolgt eine „echte" Integration von SAP BW und HANA. Zum einen werden bestehende Funktionalitäten aus dem SAP BW nach HANA verlagert (z.B. Aktivierung von DSO-Objekten), zum anderen entstehen neue Funktionalitäten, die nur auf einer HANA-Plattform verfügbar sind (z.B. Workspaces). Auf die wesentlichen Veränderungen, die sich dadurch für das SAP BW ergeben, wird gleich noch etwas genauer eingegangen.

In der Phase III („SAP HANA Vision") dient HANA auch als Datenbasis für das ERP, infolgedessen dann ERP und BW auf einer Plattform laufen werden. Diese Phase wird mittelfristig erreicht werden, hier spricht man wahrscheinlich über einen Zeitraum von zwei bis drei Jahren. Diese Phase wird vermutlich die größte Auswirkung insbesondere in Hinblick auf das Thema Business Intelligence haben. Welche es genau sein werden, darüber gibt es mehr oder weniger konkrete Vorstellungen, eine genaue Vorhersage ist an dieser Stelle eher schwierig.

Wesentliche Auswirkungen von HANA auf das SAP BW

Schauen wir uns zunächst an, welche Auswirkungen der bestehende Entwicklungsstand von HANA für das SAP BW heute hat. Mit der Integration von SAP BW und HANA ist BW die erste Applikation, die die Stärken von SAP HANA effektiv nutzt.

• Wesentlicher Effekt ist natürlich die enorm gestiegene Performance, zum einen bei der Ausführung von Query‘s, aber auch bei administrativen Tätigkeiten, wie z.B. die Aktivierung von DSO-Objekten.
• Durch die hohe Kompressionsrate wird das Datenvolumen deutlich verringert.
• Der BWA (BW Accelerator) wird obsolet.
• Deutliche Performancesteigerung der ETL-Prozesse (DSO fund Inocube)
• Verschlankung der BW-Modellierung durch Nutzung von
  • HANA-optimierten DSOs
  • HANA-optimierten Infocubes
• Integration von Ad-hoc-Modellen, die den Fach-bereichen eine einfache, schnelle Möglichkeit bieten, Informationen zu integrieren, die (noch) nicht im BW vorhanden sind, z.B. Verdichtungskriterien für Planung oder Simulation. Dies kann über Workspaces erfolgen, die eine SAP BW / HANA voraussetzen.
• Durch eine HANA-optimierte Planung kann der Planungsprozess optimiert und performanter gestaltet werden.

Die nachfolgende Grafik zeigt im Überblick die wesentlichen Auswirkungen von HANA auf das BW.

Wichtig ist die Erkenntnis, wie sich durch HANA die BW-Modellierung ändert. Hier liegt der größte Unterschied z.B. gegenüber dem Einsatz eines BW-Accelerators oder auch zum HANA-Einsatz als Side-by-Side Lösung. Obwohl sich im Grunde die Modellierung vereinfacht, ist dennoch eine genaue Kenntnis einer HANA-optimierten Modellierung notwendig. Ansätze zur HANA-optimierten Architektur werden seitens SAP durch die LSA++-Architektur beschrieben, auf die hier aber nicht weiter eingegangen wird.

Über die weiteren Auswirkungen, die eine künftige Integration von ERP und BW auf einer einzigen HANA-Plattform mit sich bringt, kann nur in allgemeiner Form etwas gesagt werden, da hier naturgemäß viel Spielraum für Spekulation besteht. Aussagen, dass damit BI-Systeme überflüssig werden und durch die Performancepotentiale der In-Memory-Technologie direkt auf operativen Daten reportet werden kann, dürften ebenso wenig zutreffen wie die Vermutung, dass es bei der Trennung zwischen ERP- und BW-System in der bisherigen Form bleibt. Im Grundsatz wird es bei einer Trennung zwischen analytischen und operativen Modellen bleiben. Diese Trennung wird in der Tendenz aber eher durch Virtualisierung („Analytical Views") erfolgen. ETL-Prozesse im herkömmlichen Sinne dürften dann wohl der Vergangenheit angehören. Starken Einfluss wird diese Entwicklung auf die Art der Modellierung haben sowie die Möglichkeiten, die sich im Bereich der Realtime-Analysen ergeben. Aus heutiger Sicht ist es wichtig, die Tendenzen dieser Veränderungen zu erkennen und in der weiteren Entwicklung zu beobachten.

Die Integration von HANA und SAP BW stellt den zurzeit wichtigsten Anwendungsfall dar. Daneben gibt es noch weitere, die hier nicht alle im Einzelnen aufgeführt werden. Ein Anwendungsfall, der aber für viele SAP-Bestandskunden eine Rolle spielen könnte, wäre die HANA-/CO-PA-Lösung. Das klassische CO-PA basiert auf relativ einfachen Datenstrukturen, denen aber ein oft riesiges Datenvolumen gegenübersteht. Dies führt häufig dazu, dass Verarbeitungszeiten im CO-PA unverträglich lang sind oder auch Planungsprozesse innerhalb des CO-PA sehr inperformant sind.  Hier bietet die SAP eine Out-of-the-Box-Lösung an, die im Groben wie folgt funktioniert:

Die COPA-Daten des ERP werden in gleiche Strukturen einer HANA-Datenbank repliziert. Ein zusätzlicher Layer im ERP („CO-PA read function module") entscheidet, welche Datenquelle für eine bestimmte Funktionalität die beste ist, in aller Regel wird es HANA sein. Diese  Out-of-the-Box-Lösung kann für Unternehmen eine sinnvolle oder auch notwendige Lösung sein, die aber durch den Lauf der Entwicklung an Bedeutung verlieren wird.

HANA ist strategisch die Plattform für ERP und BW. Folglich werden sich alle SAP-basierten Unternehmen früher oder später mit dieser Technologie auseinandersetzen müssen. Wenn die Aussage „Einfach wie Apple – schnell wie Google" vielleicht im Kern zutreffend ist, ist der Weg dahin für Unternehmen nicht immer so einfach, insbesondere da HANA mehr als nur eine In-Memory-Datenbank ist. Man muss sich fragen

• wie weit die Technologie ist (verfügbar bedeutet nicht unbedingt einsetzbar),
• wie groß der Handlungsdruck im Unternehmen ist,
• ob eine SAP (BW) Landschaft bereits existiert oder aufgebaut wird,
• wie die weitere HANA-Strategie seitens SAP ist,
• wie hoch die eigene Bereitschaft zum Einsatz neuer Technologien ist,
• wie hoch die Kosten für HANA sind.

Da die Voraussetzungen in den Unternehmen sehr unterschiedlich sind, kann hierzu natürlich keine generelle Em-pfehlung gegeben werden. Ein konkreter Einsatz ist – abgesehen von Spezialszenarien wie CO-PA – aufgrund des derzeitigen Entwicklungsstandes zurzeit nur im Bereich SAP BW zu sehen. Unternehmen, die eine Einführung von SAP BW planen, sollten sich durchaus damit auseinandersetzen, gleich auf SAP HANA aufzubauen, um insbesondere die Architektur und Modellierung gleich auf HANA zu optimieren. Eine spätere Remodellierung entfällt dann. Gleiches gilt für Unternehmen, die eine klassische BW-Implementierung haben, hier aber z.B. aufgrund von Performanceproblemen ein Redesign vornehmen wollen. Auch hier kann ein Umstieg auf HANA heute schon sinnvoll sein.

In jedem Fall aber ist es sinnvoll und notwendig, sich mit dem Thema HANA auseinanderzusetzen und eine eigene HANA-Strategie zu entwickeln.