SAP HANA als In-Memory-Datenbank-Technologie für ein Enterprise Data Warehouse

SAP HANA als In-Memory-Datenbank-Technologie für ein Enterprise Data Warehouse Oliver Neumann, Edwin Schicker Kurzzusammenfassung Dieser Artikel beschreibt das Konzept der In-Memory Datenbank HANA von SAP zur Verwaltung sehr großer strukturierter und unstrukturierter Datenmengen in Unternehmen und beantwortet die Frage, warum sich der Umstieg lohnt. Neben der Darstellung von Implementierungsoptionen werden des Weiteren Migrationsstrategien präsentiert. Zuletzt werden praktische Hinweise zu neuen Modellierungsformen in SAP NetWeaver BW in Verbindung mit HANA gegeben. Laufzeitmessungen von definierten Anwendungsfällen mit Echtdaten liefern einen Überblick über die erzielbaren Geschwindigkeitsverbesserungen und zeigen vielversprechende Optimierungsstrategien auf. 1 Warum In-Memory? Big Data, Self-Service BI und Mobile BI sind Schlagwörter, die als Anforderungen in vielen Artikeln rund um die Entwicklung des Information- Management in der IT in Unternehmen publiziert und diskutiert werden. Big Data bezeichnet schwierig zu verwaltende, enorm große und unstrukturierte Datenmengen, die mit herkömmlicher Software nicht mehr analysierbar sind (vgl. [Many11]). Self-Service BI hingegen bezeichnet die Analyse von Daten weitestgehend ohne das Zutun der IT (vgl. [Geis13]), Mobile BI die Analyse auf mobilen Endgeräten. Offensichtlich stehen die letztgenannten Begriffe im Widerspruch zur ersten Begrifflichkeit, wenn unterstellt wird, dass selbst die IT mit den zunehmenden Datenmengen überfordert ist. Um diesem Anspruch in einem Unternehmensumfeld jedoch trotzdem gerecht zu werden, besteht die Herausforderung für die IT in der Balance aus dem Verwalten sehr großer Datenmengen und dem Zurverfügungstellen flexibler Analysen. Neue Technologien wie In-Memory können dabei helfen, diese Herausforderung zu bewältigen. 1.1 Reaktionszeit und die Geschwindigkeit der Gedanken In einer Stichwortsuche im Web hängt das optimale Ergebnis maßgeblich von der Auswahl der geeignetsten Suchwörter ab. Eine schnelle Antwortzeit der Suchmaschine ermöglicht ein Trial-and-Error-Verfahren und das schrittweise Verfeinern des Suchergebnisses. Im Umfeld der Datenanalyse in Unternehmen wäre diese Geschwindigkeit ebenfalls wünschenswert und könnte dem Analysten bessere Ergebnisse liefern (vgl. [Plat12], S. 4 f.).

Die durchschnittliche Reaktionszeit eines Betrachters für eine einfache Reaktion auf einen Reiz, liegt bei 220 ms (vgl. [Lami68]). Dagegen ist die durchschnittliche Zeit zur Erfassung eines Sachverhalts deutlich länger, weil ein Verständnis für die Bedeutung entstehen muss. Diese kann durchschnittlich mit 384 ms quantifiziert werden. Wird der Sachverhalt komplexer, kann das Intervall je nach Komplexität der Informationen zwischen 550 750 ms liegen. Es wird als Geschwindigkeit der Gedanken bezeichnet (vgl. [Plat12], S. 4 f.). Wird die Zeit der Geschwindigkeit der Gedanken überschritten, wird sie von einem Nutzer als Wartezeit empfunden und lässt ihn gedanklich abschweifen. Je länger die Wartezeit, desto größer die Ablenkung und desto schwieriger wird es für den Nutzer, zum eigentlichen Prozess zurückzukehren. Als Ziel für die Bereitstellung von Informationen kann daher eine Wartezeit von maximal einer Sekunde abgeleitet werden. 1.2 Hardware Trends Moderne Hardware verändert sich schnell und innovativ. Sie ist der Haupttreiber für die Entwicklung von In-Memory Datenbanken. Neben dem deutlichen Preisverfall des Hauptspeichers sind auch neue Trends wie parallele Verarbeitung mit Multicore-CPUs oder eine erhöhte Bandbreite innerhalb von Rechnern zu nennen. Zwar existieren In-Memory Datenbanken bereits seit den 1980er Jahren (vgl. [Garc92]), so sind sie jedoch erst seit ein paar Jahren erschwinglich genug, um große Systeme in Unternehmen damit auszustatten. Abbildung 1 veranschaulicht den Preisverfall von Hauptspeicher in Preis pro Megabyte. Abbildung 1: Preisentwicklung von Speichermedien ([Plat12] S. 10) Aufgrund der viel geringeren Zugriffszeiten ist der Hauptspeicher im Gegensatz zu Festplatten sehr gut geeignet, um schnell große Datenmengen zu analysieren. Verglichen mit plattenbasierten Systemen, können allein nur mit dem konsequenten Einsatz verbesserter Hardware, wie zum Beispiel die Parallelisierung von Rechenprozessen mit Multicore-CPU, sehr große Geschwindigkeitsverbesserungen erzielt werden.

1.3 Total Cost of Ownership Schließlich kann die TCO-Betrachtung (Total Cost of Ownership) eine Antwort auf die initiale Frage liefern: Warum In-Memory?. Im TCO-Konzept werden sämtliche Kosten einer Beschaffung berücksichtigt, die mit ihr in Zusammenhang stehen. Somit werden neben den Anschaffungskosten auch indirekte Kosten wie die Kosten der Nutzung mit einberechnet (vgl. [Schw14], S. 1). Die Geschwindigkeitsverbesserungen, die eine In-Memory Datenbank mit sich bringt, können die Kosten des gesamten Systems über den vollen Lebenszyklus hinweg verringern, damit also die TCO senken. Um die Geschwindigkeit analytischer Abfragen zu erhöhen, wurde in den Data-Warehouse-Systemen nach und nach materialisierte Sichten und persistente Aggregate eingeführt. Partitionen und Indexstrukturen wurden eingesetzt, um die relationale Speicherung weiter zu optimieren. All dies wird jedoch sofort obsolet, wenn Systeme schnell genug werden, um Berechnungen zur Laufzeit durchzuführen und ihre Optimierung selbst vornehmen. Generell kann deshalb dazu übergegangen werden, Systeme wieder schlanker zu machen, die Komplexität der Architektur zu reduzieren, indem weniger Schichten verwendet werden, und weniger Objekte zu nutzen. Ein schlankeres System ist weniger teuer, schneller zu erstellen, leichter zu ändern und zu skalieren und produziert deshalb weniger Fehler (vgl. [Plat12], S. 18 f.). Zusätzlich können die Mitarbeiter-Interaktionen genannt werden, deren Wartezeit, direkt in Kosten übersetzt, ebenfalls die TCO senken. Unter die verschwendete Zeit kann sowohl das Warten auf die Ausführung einer Abfrage als auch das Verstehen eines komplexen administrativen Vorgangs ein kategorisiert werden. 2 Das technische Konzept einer In-Memory Datenbank SAP HANA als konkretes Produkt einer In-Memory Datenbank profitiert erheblich von der Kombination technischer Neuerungen in Verbindung mit einer Neugestaltung der Datenorganisation. Die wichtigsten Aspekte werden im Nachfolgenden kurz erläutert. 2.1 Speichertechnologie Grundlegenden Einfluss auf die erhöhte Performance der Datenbank hat der Wechsel der Speichertechnologie. Im Gegensatz zu konventionellen ferromagnetischen Festplatten hat der elektronische Speicher DRAM (Dynamic Random Access Memory) eine deutlich geringere Zugriffszeit. Visualisiert wird dies in Abbildung 2. Die Zugriffszeiten sind allerdings nicht vollkommen konstant, sondern abhängig von der gelesenen Blockgröße. Um die Geschwindigkeit weiter zu optimieren, muss deshalb die Hierarchie der Cache Level einer CPU in Betracht gezogen werden. Werden Daten aus dem Hauptspeicher gelesen, werden sie in den unterschiedlichen Ebenen (Level 1 bis 3) zwischengespeichert, die jeweils verschiedene Speicherkapazitäten

Abbildung 2: Zugriffszeiten von Speicherkomponenten ([SAP13] S. 11) besitzen. Sind die gelesenen Blöcke jedoch zu groß für die Cache Level muss der Block aufgeteilt werden, wodurch ein sog. cache miss entsteht (vgl. [Plat12], S. 40 ff.). Der Prozessor muss nun nach der Abarbeitung des ersten Blocks warten, bis der nächste Teil der angeforderten Daten in den Cache geladen wurde. Um dies zu optimieren, werden die Daten neu organisiert und spaltenorientiert abgelegt. 2.2 Spaltenorientierte Speicherung Zeilenbasierte Speicherung ist optimal in OLTP-Systemen, um einzelne Tupel aus einer Datenbanktabelle zu lesen, jedoch eignet sie sich nicht, um eine Menge von Daten aus nur einer einzigen Spalte zu lesen (vgl. [Plat12], S. 33 ff.). Bei einem Zugriff auf Daten werden, wie in Kapitel 2.1 beschrieben, ganze Blöcke gelesen und in den CPU Cache geladen. Abbildung 3: Vergleich Zeilen- und Spaltenorientierte Speicherung in Anlehnung an ([SAP13], S.12) Nehmen wir an (siehe Abbildung 3), es sollen Umsatzwerte aggregiert werden. Bei einer zeilenbasierten Speicherung könnte es sein, dass pro gelesenem Block nur ein einzelner Umsatzwert enthalten ist. Die restlichen Tupel enthalten andere nicht relevante Werte. Bei einer spaltenorientierten Speicherung hingegen werden alle Umsatzwerte in zusammenhängenden Speicherbereichen allokiert und ein gelesener Block enthält nur Werte, die für die Rechenoperation der CPU benötigt werden (vgl. [SAP13], S. 12 f.).

2.3 Komprimierung Die Komprimierung der Daten verfolgt zwei Ziele: Zunächst einmal soll der Speicherverbauch reduziert werden. Weil bei SAP HANA alle Daten im Hauptspeicher abgelegt werden sollen, muss der Speicherbedarf so gering wie möglich sein. Die spaltenorientierte Speicherung eignet sich dabei sehr gut für eine Komprimierung, da Daten des gleichen Datentyps in aufeinander folgenden Speichersektionen abgelegt sind (vgl. [Abad08]). Ein weiterer Grund für die Komprimierung ist die verbesserte Abfragezeit. Dies liegt vor allem an der eingesetzten light-weight Komprimierung, die es ermöglicht, komprimierte Daten schneller zu lesen als unkomprimierte Daten und somit eine optimale Balance zwischen Cache und CPU-Verarbeitung bietet. Eine heavy-weight Komprimierung hingegen erzeugt viel Mehraufwand für die CPU durch Entkomprimierung und erneute Komprimierung (vgl. [Chen01]). SAP HANA setzt konkret die sog. Dictionary-Komprimierung ein. Für jeden Wert wird eine eindeutige ID erzeugt und in einer separaten Tabelle komprimiert gespeichert. Bei einer Abfrage müssen nur die optimiert komprimierten IDs gelesen werden, was für die Datenbank viel weniger Aufwand bedeutet als beispielsweise Text-Werte zu lesen (vgl. [Färb12]). 2.4 Parallele Verarbeitung Die In-Memory Datenbank von SAP macht sich eine weitere Hardware- Entwicklung der letzten Jahre zum Vorteil: Multicore-CPUs. SAP hat die Verarbeitung der Prozesse so entworfen, dass sie in kleinste Verarbeitungsschritte unterteilt werden und gleichzeitig auf mehreren Prozessoren verarbeitet werden können (vgl. [SAP13], S. 11). Außerdem werden die Daten über mehrere Serverblades 1 verteilt, um gleichzeitige Lesezugriffe zu ermöglichen. Die Ausfallsicherheit wird dadurch ebenfalls verbessert. Abbildung 4 stellt die Verteilung der Daten anschaulich dar. Abbildung 4: Daten-Verteilung bei SAP HANA in Anlehnung an ([SAP13], S.12) Nachdem nun das technische Konzept kurz vorgestellt wurde, werden im folgenden Kapitel die Implementierungsoptionen von SAP HANA beschrieben. 1 Ein Blade ist ein Server, der durch seine modulare, kompakte Bauweise eine hohe Leistung bei geringem Platzverbrauch zur Verfügung stellt (vgl. [Plat12], S. 246).

3 SAP HANA für ein Enterprise Data Warehouse Je nach vorhandener Systemlandschaft sind unterschiedliche Ansätze zur Implementierung denkbar und mit Lizenzmodellen von SAP vorgesehen. Drei Optionen werden im Folgenden dargestellt. 3.1 Implementierungsoptionen 3.1.1 Standalone-Implementierung für Analysen Soll ein Analyseproblem gelöst und kein Applikationsserver NetWeaver BW eingesetzt werden, kann die Standalone-Implementierung eingesetzt werden. Sämtliche Prozesse müssen jedoch neu modelliert und erstellt werden, da eine komplette Neuinstallation durchgeführt wird. Das Werkzeug zur Modellierung der Daten kann frei gewählt werden, man ist daher nicht nur auf das HANA Studio von SAP beschränkt. Benutzer und Berechtigungen müssen manuell festgelegt werden. Von SAP NetWeaver BW bekannte Funktionen, wie zum Beispiel der Business Content, können bei dieser Implementierung jedoch nicht verwendet werden (vgl. [Berg13], S. 55 ff.). 3.1.2 SAP NetWeaver BW auf SAP HANA Hat das Unternehmen bereits ein NetWeaver BW System im Einsatz, ist die zu empfehlende Option die sog. BW on HANA Implementierung. Dabei wird grob formuliert nur die darunterliegende Datenbank ausgetauscht. Alle Funktionen und Objekte der Schichten-Architektur von NetWeaver BW bleiben erhalten, somit gehen auch keine Investitionen für das Unternehmen verloren. Um eine Migration durchführen zu können, wird jedoch ein gewisser Versionsstand von NetWeaver BW vorausgesetzt. Möglicherweise muss daher vor der Migration erst ein Upgrade erfolgen. Ist die Migration schließlich abgeschlossen, profitiert man zwar sofort von der neuen Technologie, das heißt von einer besseren Abfragegeschwindigkeit, von schnelleren Datenladungen und einer Senkung des Speicherverbrauchs. Um jedoch in vollem Umfang zu profitieren, müssen zusätzlich einige Optimierungen manuell vorgenommen werden. Das Datenmodell kann beispielsweise verschlankt und vereinfacht werden, da Aggregate und redundante Tabellen nicht mehr notwendig sind. Zudem können InfoCubes in neue HANA-optimierte InfoCubes konvertiert werden, die eine nochmal verbesserte Abfragegeschwindigkeit liefern. Des Weiteren können neue InfoProvider die alten ersetzen und zusätzliche Geschwindigkeitsverbesserungen mit sich bringen (vgl. [Berg13], S. 69 ff.). 3.1.3 SAP Business Suite auf SAP HANA Die letzte Implementierungsoption ist die SAP Business Suite on HANA. Die In- Memory Technologie wird dabei als zugrunde liegende Datenbank für alle Business Suite Anwendungen implementiert, ähnlich wie bei BW on HANA. Diese Lösung bietet allerdings keine Möglichkeit die HANA-basierten Werkzeuge für Entwurf und Konfiguration, wie z.b. das HANA Studio, einzusetzen. Es müssen die nativen SAP-Anwendungen verwendet werden. SAP

hat eine Unterstützung für eine Vielzahl an Geschäftsprozessen zugesichert, die auf einer HANA-Plattform ausgeführt werden können (vgl. [Berg13], S. 83f.). 3.2 Migrationsstrategien Für die Migration eines bestehenden Systems (NetWeaver BW oder Business Suite) sind unterschiedliche Migrationsstrategien möglich und abhängig von Aufwandsabschätzung und verfügbaren Ressourcen durchführbar. 3.2.1 Neuinstallation Eine Neuinstallation ist nur für BW on HANA denkbar und bietet die Möglichkeit, statt einer Migration und schrittweisen Optimierung einzelner InfoProvider komplette Datenflüsse von Grund auf neu zu entwerfen und zu implementieren. 3.2.2 Side-by-Side Bei einer Side-by-Side- oder Sidecar-Implementierung werden schrittweise Teile des bestehenden Systems auf die neue Datenbankplattform migriert. Vor allem für Datenflüsse mit hohem Nutzen durch eine Migration können schnell Verbesserungen erzielt werden. Ein hoher Aufwand wird vermieden. 3.2.3 Komplettmigration Hierbei wird das gesamte System migriert und die bisherige Datenbank komplett ausgetauscht. (vgl. [Berg13], S. 97ff.) 4 Datenmodellierung in SAP HANA on BW Die beiden folgenden Kapitel 4 (Datenmodellierung) und Kapitel 5 (Performancemessungen) beziehen sich auf eine Implementierung von SAP HANA on NetWeaver BW. Kapitel 4 beschreibt Optimierungen und neue Objekte, die HANA on BW zur Verfügung stellt. Kapitel 5 präsentiert Ergebnisse durchgeführter Tests mit Echtdaten und beschreibt die realisierten Abbildung 5: Mögliche Architektur in SAP HANA on BW ([SAP13], S. 76)

Performancesteigerungen. Abbildung 5 gibt zunächst einen Überblick über die in SAP HANA on BW neu verfügbaren Provider und deren Datenflüsse. Die darin verwendeten Begriffe InfoCube, TransientProvider, CompositeProvider und VirtualProvider werden im Folgenden beschrieben. 4.1 HANA-optimierter InfoCube Die größte Neuerung für bestehende Objekte in NetWeaver BW stellt der HANA-optimierte InfoCube dar. SAP nimmt mit einer Umgestaltung des Speichermodells eine grundlegende Konzeptänderung vor. Bisher wurde eine von SAP abgewandelte Form des Snowflake-Schemas verwendet, die aus einer Faktentabelle und mehreren Dimensionstabellen besteht. Die Dimensionstabellen besaßen jedoch keine Daten, sondern verknüpften wiederum die Stammdaten-Identifier (SIDs). Das neue Konzept sieht vor, dass die SIDs direkt in die Faktentabelle geschrieben werden und keine Dimensionsschlüssel (DIM-IDs) mehr verwendet werden. SAP orientiert sich damit näher an einem klassischen Star-Schema. Das Modell mit Faktentabelle und Dimensionen wird jedoch logisch beibehalten und gruppiert Merkmale semantisch, da es sich bei der Modellierung und Erstellung für den Endanwender bewährt hat. Das Resultat der Konzeptänderung ist ein schnelleres Lesen und Laden der Daten. Gleichermaßen trägt die nur noch eine verbleibende Faktentabelle zur Vereinfachung bei. Bisher existierten zwei Tabellen: die F-Tabelle mit schreib- /löschoptimierter Partitionierung und die E-Tabelle mit leseoptimierter Partitionierung. SAP behält nur noch die F-Tabelle, was eine einfachere Verwaltung der Daten ermöglicht (vgl. [Berg13], S. 197ff.). Bestehende Standard InfoCubes können mit einer Transaktion schnell und einfach konvertiert werden. Neu erstellte InfoCubes werden automatisch HANAoptimiert modelliert und müssen nicht separat konvertiert werden (vgl. [SAP13], S. 60 f.). 4.2 TransientProvider / CompositeProvider Ein neu entwickelter Provider-Typ stellt der TransientProvider dar. Wie in Abbildung 5 deutlich wird, baut dieser Provider ausschließlich auf einem HANA Modell auf und nicht auf einem NetWeaver BW Objekt. Um ein HANA Modell zu erstellen, muss das neue SAP HANA Studio verwendet werden. Es greift dort zwar auf die gleichen Tabellen der BW Objekte zu, erstellt jedoch andere Sichtweisen auf die Daten. Der Vorteil hierbei ist, dass Berechnungen und Joins direkt auf dem HANA-Server ausgeführt werden und nicht auf dem Applikationsserver des NetWeaver BW. Dadurch können bei richtiger Modellierung hohe Performanceoptimierungen erreicht werden (vgl. [SAP13], S. 82 ff.). Ein TransientProvider kann im BW nicht weiter verwaltet oder editiert werden. Er wird dort nur veröffentlicht, um für die Verwendung in Abfragetools wie dem SAP BEx Query Designer zur Verfügung zu stehen. Die Merkmale und Kennzahlen sind nicht mit InfoObjekten aus dem BW verknüpft und können dort

Time in hours auch nicht weiter verwendet werden. Eine Ausnahme stellt der neue Composite Provider dar. Mit ihm ist es möglich, ein HANA Modell mit Objekten aus der BW-Welt zu verknüpfen, was den Vorteil bietet, dass Operationen direkt auf dem HANA Server performant ausgeführt werden (vgl. [SAP13], S. 89 ff.). 4.3 VirtualProvider Ein VirtualProvider verarbeitet ebenfalls wie der TransientProvider Daten aus einem HANA Modell und stellt sie für Abfragen zur Verfügung. Der Vorteil gegenüber einem TransientProvider ist die Möglichkeit zur weiteren Verwendung in NetWeaver BW. Dort wird nach vorheriger Erstellung des HANA Modells bei der Modellierung des VirtualProviders jede Kennzahl und jedes Merkmal aus dem HANA Modell mit einem InfoObjekt aus dem BW-System verknüpft. Anschließend verhält sich der VirtualProvider wie andere BW Objekte und kann zum Beispiel mit Transaktionen Fortschreibungen in einen InfoCube abbilden oder mit anderen Objekten in einem MultiProvider kombiniert werden (vgl. [SAP13], S. 78 ff.). 5 Performancemessungen Um die neue Technologie besser einschätzen zu können, wurden bei einem global agierenden DAX-Unternehmen Tests durchgeführt. Echtdaten aus dem dort produktiv im Einsatz befindlichen NetWeaver BW System (nachfolgend BIP genannt) wurden in ein Sandbox System (nachfolgend POC genannt) kopiert, auf dem ein SAP BW on HANA System installiert und konfiguriert wurde. Die Erfahrungen, die im Zusammenhang mit den Tests gesammelt werden konnten, werden im weiteren Verlauf kurz beschrieben und erläutert. Bei den Daten handelt es sich um reale Produktionsdaten, die bei der Herstellung von elektronischen Bauteilen generiert werden. Täglich fallen dabei circa 20.000 Datensätze an. Die Daten wurden über einen Zeitraum von 5 Jahren gespeichert und täglich in einen InfoCube geladen, der mittlerweile mit 32,9 Millionen Datensätzen gefüllt ist. 192 168 144 171:34:43 Data loadings 120 96 72 48 24 0 BIP, Standard InfoCube 7:32:28 5:04:39 POC, Standard InfoCube POC, HANA-optimized InfoCube Abbildung 6: Vergleich von Datenladungen (32.9 Mio Datensätze) SAP BW - SAP BW on HANA

Time in seconds In einem ersten Schritt wurden in dem POC-System zwei InfoCubes angelegt: Zum einen ein Standard InfoCube und zum anderen ein HANA-optimierter InfoCube. Die gemessenen Ladezeiten sind in Abbildung 6 dargestellt. Zum Vergleich wurden die Daten im BIP in einen temporären Cube erneut in einer 1:1-Fortschreibung geladen. Die dortige Ladezeit betrug 171 Stunden 34 Minuten. Während die Ladezeit mit einem Standard InfoCube im POC 7 Stunden 32 Minuten betrug, konnte die Ladezeit bei einem HANA optimierten InfoCube mit 5 Stunden 4 Minuten gemessen werden. Die benötigte Zeit für die Schreibvorgänge der HANA-internen Logdateien zur Datenwiederherstellung im Fehlerfall sind bereits mit inbegriffen. Vergleicht man schließlich das BIP mit einem HANA optimierten InfoCube, können Datenladungen also rund 33 Mal schneller ausgeführt werden. Neben den Ladezeiten wurde eine weitere Messung mit Abfragen an die drei erstellten InfoCubes durchgeführt. Dazu wurde eine Abfrage mit realem Anwendungsfall im BIP identifiziert, die eine Kennzahl der Materialbewegungen aggregiert. Zum Vergleich der unterschiedlichen Laufzeiten wurden Aggregationszeiträume mit zwei Wochen, einem Jahr und vier Jahren gewählt. Zusätzlich zu den InfoCubes wurde im POC außerdem ein HANA Modell erzeugt und darauf neue InfoProvider erstellt wie in Kapitel 4.2 und 4.3 beschrieben. Die Laufzeiten der Abfragen wurden mit einem ABAP-Programm standardisiert gemessen und mehrmals wiederholt ausgeführt. Die berechneten Durchschnittswerte der Messergebnisse visualisiert Abbildung 7. 20 18 16 14 12 10 8 6 4 2 0 19.34 Query performance 17.05 1.65 0.36 0.42 0.51 0.52 1.02 1.34 0.58 0.23 0.83 0.48 1.54 1.28 2 weeks 1 year 4 years Abbildung 7: Vergleich von verschiedenen Abfragen SAP BW SAP BW on HANA BIP POC, Standard InfoCube POC, HANAoptimized InfoCube POC, TransientProvider POC, VirtualProvider Die Auswertung der Ergebnisse ergibt eine deutlich verbesserte Abfragezeit generell für alle InfoProvider auf der HANA Plattform. Dort können jedoch signifikante Unterschiede festgestellt werden, die sich vor allem bei größeren Datenmengen auswirken. So kann mit der Konvertierung eines InfoCube in einen HANA-optimierten InfoCube eine um durchschnittlich 36 Prozent höhere Geschwindigkeit erreicht werden. Noch schnellere Abfrageergebnisse konnten teilweise nur mit einem TransientProvider gemessen werden. Eine Erklärung dafür wäre, dass kein Applikationsserver mehr direkt im Datenfluss beteiligt ist

und alle Datenbankoperationen wie Joins direkt auf dem HANA Server ausgeführt werden. Der VirtualProvider hingegen benötigt einen Applikationsserver, womit die Geschwindigkeitsverluste erklärt werden können. Im Vergleich zum derzeitigen BIP-System kann mit einem HANA-optimierten InfoCube eine um Faktor 19,6 höhere Geschwindigkeit erreicht werden. Man kann jedoch beobachten, dass sich der Anstieg der Geschwindigkeit bei allen Objekten auf der HANA-Plattform nur sehr moderat im Gegensatz zu einem NetWeaver BW System verhält. In [SAP13] (S. 10) wird deutlich, dass der Faktor des Performancegewinn bei komplexeren Abfragen und größeren Datenmengen noch weiter ansteigt. Nichtdestotrotz bilden die Testergebnisse nur einen kleinen Ausschnitt der Realität ab und können nur einzelne Anwendungsfälle prüfen. Um den Aufwand überschaubar zu halten, wurden bewusst nur einzelne Testfälle erstellt. 6 Fazit und Ausblick Zusammenfassend erweist sich SAP HANA als zukunftsweisende Technologie, die viele neue Erkenntnisse und technische Entwicklungen in ihrem Konzept vereint. Verweist man auf die Fragestellung, die zu Beginn gestellt wurde, kann SAP HANA alle Motivationspunkte Reaktionszeit, Hardware Trends und TCO zu ihrem Vorteil nutzen. Die Wartezeit kann selbst bei größeren Abfragen mit kleiner gleich einer Sekunde gemessen werden, neue Technologien sind der Fortschrittstreiber und Datenflüsse werden reorganisiert, um eine schlankere Modellierung zu ermöglichen. Bei einem Wechsel sollte jedoch unbedingt beachtet werden, dass HANA zwar eine hohe Performance ermöglicht, diese aber nur in vollem Umfang nutzbar ist, wenn einige Optimierungen manuell vorgenommen werden. Ebenso machen sich die derzeit hohen Investitionskosten erst nach einer Verschlankung des Systems im laufenden Betrieb durch geringere administrative Aufwände bemerkbar. Insbesondere komplexe Abfragen und Tabellen mit großen Datenmengen profitieren von den vielen Neuerungen und sollten deshalb in den Fokus der Nacharbeit gerückt werden. Mit HANA hat SAP ein leistungsfähiges Produkt entwickelt, das beachtliche Testergebnisse liefert. Allerdings sind bereits andere Technologien wie DB2 BLU von IBM oder 12c R2 von Oracle auf dem Markt, die ähnliche Konzepte aufweisen. An In-Memory Datenbanken wird man deshalb bei großen Datenmengen mittelfristig nicht mehr vorbei kommen.

Literaturverzeichnis [Abad08] [Berg13] [Chen01] [Färb12] [Garc92] Abadi, D. J.: Query Execution in Column-Oriented Database Systems. Ph.D. thesis, MIT (2008) Berg, B. und Silvia, P.: Einführung in SAP HANA. Galileo Press, Bonn, 2013 Chen, Z., Gehrke, J., Korn, F.: Query optimization in compressed database systems. In: SIGMOD, S. 271-282 (2001) Färber, F., May, N., Lehner, W., Große, P., Müller, I., Rauhe, H., & Dees, J. (2012). The SAP HANA Database - An Architecture Overview. IEEE Data Eng. Bull., 35(1), 28-33. Garcia-Molina, H., Salem, K.: Main memory database systems: an overview. In: TKDE 4, S. 509-516 (1992) [Geis13] Geist, F., Kluin, T., Ritz, H.: Self-Service Business Intelligence (SSBI) Nutzenpotenziale für einen verbesserten Austausch von Informationen im Unternehmen, In: AKWI-Tagungsband 2013, S. 47-58. [Lami68] [Many11] [Plat12] [SAP13] [Schw14] Laming, D.: Information Theory of Choice-Reaction Times. Academic Press, New York, 1968 Manyika, J., Chui, M., Brown, B., Bughin, J., Dobbs, R., Roxburgh, C., Byers, A. H.: Big data: The next frontier for innovation, competition, and productivity. McKinsey Global Institute, 2011. http://www.mckinsey.com/insights/business_technology/big_data_the_ next_frontier_for_innovation Plattner, H. und Zeier, A.: In-Memory Data Management. Technology and Applications. Springer Verlag, Berlin, 2012. SAP: BW362, SAP NetWeaver BW, powered by SAP HANA, Schulungshandbuch. SAP AG, 2013 Schwan, R.: Das Konzept des Total Cost of Ownership (TCO) in der IT: Eine betriebswirtschaftliche Gesamtkostenrechnung. Diplomica Verlag, 2014. Kontakt Oliver Neumann, B. Sc. Wirtschaftsinformatik Universität Regensburg Universitätsstraße 31, 93053 Regensburg oliver.neumann@stud.uni-regensburg.de Prof. Dr. Edwin Schicker Hochschule Regensburg Fakultät Informatik und Mathematik Postfach 102371, 93025 Regensburg edwin.schicker@hs-regensburg.de