Cloud-Entwicklung in SAP HANA

2 HANA-Plattform

In diesem Kapitel werde ich Ihnen die Architektur und die wichtigsten Funktionen der HANA-Plattform aufzeigen. Diese Grundlagen werden Ihnen helfen, die Plattform für Ihre eigenen Softwareprojekte optimal zu nutzen.

2.1 SAP HANA

Die SAP-Strategie, ausschließlich HANA als Datenbank für aktuelle SAP-Systeme zuzulassen und Produktinnovationen nur noch für HANA-basierte Systeme zur Verfügung zu stellen, hat den Vorteil, dass die Software nicht mehr wie früher eine Vielzahl von Datenbanksystemen unterstützen muss.

In den älteren SAP-Systemen – bis SAP ERP Central Component (ECC) 6.0 – hat der NetWeaver AS die Datenbankkommunikation gekapselt. Die Anwendung selbst brauchte die Unterschiede der Datenbanksysteme nicht zu berücksichtigen. Von der Nutzung spezieller Funktionen der einzelnen Datenbanken wurde aus technischer Sicht abgeraten, da sie bei Anpassungen des Datenbanksystems ggf. nicht mehr funktioniert hätten.

Durch die alleinige Nutzung von HANA als Datenbank können die spezifischen HANA-Funktionen aus den Anwendungen heraus vollumfänglich zum Einsatz kommen. Des Weiteren können bei der Entwicklung von Anwendungen sogar einige Teilfunktionen komplett in die HANA-Datenbank ausgelagert werden. In diesem Fall wird von einer nativen HANA-Entwicklung gesprochen.

2.1.1 In-Memory-Datenbank-Technologie

Ein weiterer Vorteil der HANA-Datenbank ist, dass sie alle relevanten Daten im Hauptspeicher, also »In-Memory«, hält. Kritiker sagen, dass dies auch andere Datenbanksysteme können. Diese Aussage stimmt natürlich, denn andere Hersteller von Datenbanken bieten ebenfalls eine In-Memory-Technologie für ihre Produkte.

Stark vereinfacht, geht es bei allen In-Memory-Datenbanken darum, die Zugriffszeiten auf die Daten zu optimieren. Auf Daten im Hauptspeicher kann deutlich schneller zugegriffen werden als auf Daten, die erst zeitintensiv von der Festplatte gelesen werden müssen.

Dauerhafte Speicherung der Daten

Auch bei In-Memory-Datenbanken werden die Daten im Arbeitsspeicher für eine dauerhafte Speicherung zusätzlich in das angebundene Dateisystem gespeichert. Dies ist notwendig, falls das System neu gestartet und dabei der Arbeitsspeicher geleert wird. Beim Systemstart der HANA werden die Daten dann wieder in den Arbeitsspeicher geladen. Dieser Prozess läuft vollautomatisch ab.

Die Stärken von SAP HANA sind allerdings nicht nur in der Datenbanktechnologie selbst zu suchen. Dass die Datenbank und die Anwendungen vom selben Hersteller stammen, bietet einen erheblichen Vorteil. Seit dem Beschluss, dass HANA zukünftig als alleinige Datenbank für SAP-Systeme verwendet werden soll, optimiert die SAP ihre Anwendungen Schritt für Schritt für eine Nutzung mit dieser Datenbanktechnologie. Dabei ist sie nicht mehr von den Funktionsangeboten anderer Datenbankanbieter abhängig.

Bei der von der SAP verfolgten HANA-optimierten Entwicklung spricht man vom Code Pushdown. Dessen Ziel ist es, Datenoperationen nicht mehr in einem Anwendungsserver durchzuführen, sondern direkt in der Datenbank. Die Programmlogik wird also in die Datenbank verlagert bzw. »gepushed«. Abbildung 2.1 stellt die Logik des Code Pushdown exemplarisch dar.

Abbildung 2.1: Anwendungen mit und ohne »Code Pushdown«

Anwendung 1 lädt die Datensätze 1 und 2 aus der Datenbank und führt die programmierte Logik auf diesen Daten aus. Gerade bei großen Datenmengen kann das Laden der Daten in den Applikationsserver einige Zeit in Anspruch nehmen.

Im Gegensatz dazu basiert Anwendung 2 auf dem Prinzip des Code Pushdown. Hier wird die Logik in der Datenbank selbst ausgeführt. Da dort alle Daten im Hauptspeicher gehalten werden, kann die Datenbank das Ergebnis schnell an die Anwendung zurückliefern.

Dieses Prinzip wird in allen modernen SAP-Produkten eingesetzt, um Datenoperationen zu optimieren.

2.1.2 Spalten- und zeilenorientierte Datenspeicherung

Neben der In-Memory-Technologie ist für Ihre Projekte noch ein weiterer Aspekt relevant, der dem besseren Verständnis für eine Nutzung der HANA-Datenbank-Technologie dient. Dies ist die Verwendung der spaltenorientierten (Column Store) oder zeilenorientierten Ablage (Row Store) der Tabellendaten.

Weitere spaltenorientierte Datenbanksysteme

Auch andere Hersteller, wie z.B. Oracle (12c mit In-Memory-Option) und Microsoft (SQL-Server 2012 mit dem Column Store Index Feature), bieten in ihren Produkten verschiedene Ablageoptionen. Die Technologie ist also nicht SAP- oder HANA-spezifisch.

Nachfolgend werde ich diese beiden Technologien kurz beschreiben und Ihnen die jeweiligen Vor- und Nachteile aufzeigen.

In der Vergangenheit haben die gängigsten Datenbanksysteme die Daten der Tabellen zeilenorientiert behandelt. Dabei erfolgen sowohl die Datenablage als auch der Zugriff auf die Daten zeilenweise. Im Gegensatz dazu steht die spaltenorientierte Organisation der abgelegten Daten. In der HANA-Datenbank kann sich der Entwickler je Tabelle entscheiden, welche der beiden Ablagemöglichkeiten er verwenden möchte; beide Verfahren werden unterstützt.

Um den Unterschied zwischen beiden Varianten zu verstehen, nehmen wir eine einfache Tabelle zu Hilfe. Diese betrachten wir zunächst als logische Struktur (Abbildung 2.2), wie wir sie beispielsweise aus Excel oder anderen Tabellenkalkulationstools kennen.

Abbildung 2.2: HANA-Tabelle – logische Struktur

Die Daten zur Einwohnerzahl rechts in der Tabelle sind vom Dezember 2019 [1]. Für unser Beispiel sind allerdings nicht die Daten an sich von Interesse, sondern die Art und Weise, wie diese in der Datenbank abgelegt werden. Die logische Struktur ist zweidimensional, die Ablage muss aber in eindimensionaler Form erfolgen.

Stellen wir uns die physikalische Ablage der Tabelleninhalte als eine Aneinanderreihung von Blöcken vor, bei dem jeder Block den Wert von genau einer Zelle aufnehmen kann.

Die oben gezeigte Tabelle wird bei einer zeilenorientierten Ablage wie in Abbildung 2.3 aussehen: Die Werte werden Zeile für Zeile untereinandergeschrieben.

Abbildung 2.3: HANA-Tabelle – zeilenorientierte Ablage (Row Store)

Im Gegensatz dazu speichert die spaltenorientierte Ablage jede Spalte als eigene physische Tabelle. In unserem Beispiel wären das die Tabellen Stadt, Bundesland und Einwohner.

Anschließend werden diese einzelnen Tabellen sowohl komprimiert als auch sortiert. Bei der Komprimierung werden Duplikate entfernt. In unserem Beispiel können bei den Bundesländern Blöcke eingespart werden, da NRW mehrfach vorkommt. Dies reduziert den für die Daten benötigten Speicher.

Durch die Sortierung der einzelnen Werte kann später schneller auf die Daten zugegriffen werden. Beide Schritte sehen Sie zusammengefasst in Abbildung 2.4.

Abbildung 2.4: HANA-Tabelle – spaltenorientierte Ablage (Column Store)

Tabelle 2.1: Vergleich zeilen- und spaltenorientierte Speicherung

Basierend auf dem gegebenen Beispiel, möchte ich die Vor- und Nachteile beider Speichervarianten exemplarisch zusammenfassen (siehe auch Tabelle 2.1).

Um zu entscheiden, welche Variante besser für ein gegebenes Szenario passt, sind zwei Kriterien wichtig:

 die Struktur der erwarteten Daten sowie

 deren spätere Verwendung.

Datenstruktur

In dem gegebenen Beispiel mit nur sehr wenigen Daten ergibt die Auswahl der Speichermethode keinen großen Unterschied. Stellen Sie sich dagegen deutlich größere Tabellen mit Millionen von Zeilen und sehr vielen Spalten vor. Die Wahrscheinlichkeit, dass in einigen dieser Spalten duplizierte Werte enthalten sind, ist, abhängig von der Datenart, recht hoch. Durch die Komprimierung kann viel Platz eingespart werden. Wenn die Tabelle allerdings nur sehr wenige Duplikate enthält, wäre der Vorteil bei der Speichernutzung der spaltenorientierten Variante äußerst gering.

Datenverwendung

Wenn die Tabelle für analytische Auswertungen genutzt werden soll, bietet sich eine spaltenorientierte Ablage an, da die Werte der einzelnen Spalten direkt miteinander in Verbindung gebracht werden können. Dadurch sind z.B. Aggregationen über viele Zeilen hinweg bei der spaltenorientierten Ablage deutlich effizienter umsetzbar als bei der zeilenbasierten Ablage.

Wird die Tabelle hingegen stark transaktional beschrieben, wie etwa bei Bestellungen, die über einen Online-Shop aufgenommen werden, kann eine zeilenorientierte Speicherung von Vorteil sein, da eine schnellere Ablage der Daten erfolgt.

Bei der Entwicklung des Datenmodells für Ihre Anwendung ist es auf jeden Fall wichtig, sich frühzeitig Gedanken zu machen, welche Daten abgelegt und wie die Tabellen genutzt werden sollen. Sie müssen sich pro Tabelle für eine der beiden Speichermethoden entscheiden.

Konfiguration der Speicherart für HANA-Tabellen

Wie Sie die Speicherarten für Tabellen innerhalb der HANA-Plattform festlegen, ist in den Beispielen des Kapitels 5 beschrieben.

2.1.3 HANA Processing Services

Durch die Einbindung verschiedener Processing Services in die HANA-Plattform hat die SAP den Funktionsumfang der Datenbankplattform stark erweitert. Mithilfe dieser Services können Sie unterschiedliche analytische Aufgaben direkt in einem Datenbanksystem ausführen. Neben den von der SAP angebotenen Produkten, die auf der HANA-Technologie basieren, können auch Ihre Entwicklungsprojekte von dem zusätzlichen Funktionsumfang der Processing Services profitieren.

Eine detaillierte Beschreibung der einzelnen Processing Services wäre für dieses Buch zu umfänglich. Aus diesem Grund möchte ich Ihnen an dieser Stelle nur einen Überblick über die aktuell integrierten Funktionen geben. Die nachfolgende Auflistung ist eine Momentaufnahme des aktuellen Stands der SAP-HANA-Plattform (Version 2.0 SPS 05) und kann sich im Laufe der Zeit gemäß der SAP-Produktstrategie verändern.

Spatial

Durch die Verwendung der Spatial-Funktionen können Anwendungen geografische Daten direkt verarbeiten. Auf diesem Weg werden Ihre Daten in einen räumlichen Zusammenhang gebracht, z.B. indem der Abstand zwischen zwei Punkten oder die Größe von Flächen berechnet wird.

Die HANA-Plattform unterstützt bei der Verarbeitung geografischer Daten offene Standards, sodass sich auch Daten von Fremdsystemen unkompliziert integrieren lassen.

Graph

Der Graph-Service ermöglicht die native Graphenverarbeitung innerhalb der HANA-Plattform. Durch ihn können Beziehungen zwischen Menschen, Orten und Dingen hergestellt werden. Das Ziel bei der Graphenverarbeitung ist die Analyse einer komplexen Realität hochgradig vernetzter Daten.

Die HANA-Plattform bietet Modellierungs- und Visualisierungstools, um Graphen zu erstellen und in diesen zu navigieren, Muster aufzudecken, kürzeste Wege zu berechnen und Beziehungen zu verstehen.

Series Data

Die Funktionalität Series Data von HANA kann Reihendaten entgegennehmen und direkt verarbeiten. Diese Daten werden z.B. über die Streaming Engine von Geräten oder Sensoren des IoT (Internet der Dinge) erzeugt und an SAP HANA gesendet.

SAP HANA verarbeitet Reihendaten, um Trends über einen bestimmten Zeitraum zu ermitteln. Sie können beispielsweise Preisschwankungen, saisonale Verschiebungen, Maschineneffizienz, Energieverbrauch oder Netzwerkflüsse überwachen, um Muster zu entdecken.

JSON Document Store

Der JSON Document Store ist in der HANA-Plattform ab Version 2.0 SP1 verfügbar und ermöglicht die Ablage sowie die Verarbeitung von verschachtelten JSON-Objekten.

Ein großer Vorteil der Datenspeicherung in JSON-Objekten gegenüber derjenigen in relationalen Tabellen ist die Flexibilität der Struktur. Das JSON-Dokument lässt sich flexibel und dynamisch auf die sich ändernden Bedürfnisse anpassen und ablegen. Bei einer relationalen Speicherung von Daten müssten für strukturelle Anpassungen erst die Datenbankstrukturen modifiziert werden.

Auf die JSON-Dokumente können Sie direkt mit SQL-Mitteln zugreifen. Sie werden also abgefragt, als wären sie in strukturierter Form (relationale Datenbank) abgelegt worden.

Search

Der Search-Service stellt besondere Funktionen für eine übergreifende Suche zur Verfügung. Er unterstützt für die Volltextsuche unterschiedliche Optionen wie »EXACT«, »LINGUISTIC« und »FUZZY«. Um die Suchfunktionen nutzbar zu machen, werden die Datenbankinhalte mittels Suchindizes speziell für Suchanfragen vorbereitet.

Da die Suchfunktionalität besonders häufig bei der Entwicklung eigener Software verwendet wird, habe ich bei den Beispielen des Kapitels 5 den Search-Service exemplarisch mit eingebunden.

Text Analytics

Die Textanalyse der HANA-Datenbank umfasst Funktionen für die Verarbeitung von natürlicher Sprache und die Extraktion von Entitäten mittels Funktionen wie Segmentierung, Stemming und Tagging.

Dadurch werden unstrukturierte Daten für eine Analyse in strukturierte Daten umgewandelt und in der Datenbank abgelegt. Des Weiteren werden zusätzliche Algorithmen für Text Mining und Stimmungsanalysen (Sentiments) zur Verfügung gestellt, um relevante Schlüsselwörter aus Dokumenten abzuleiten.

Streaming Analytics

Eine weitere Ergänzung zur Datenbank ist die Smart Data Streaming Engine. Mit ihr lassen sich Ereignisströme aus vielen Quellen in Echtzeit erfassen und verarbeiten. SAP HANA unterstützt eine SQL-ähnliche Verarbeitungssprache, um Streams mit kontextbezogenen Daten zu kombinieren und das Ergebnis direkt (on the fly) zu analysieren.

Für eine bessere Skalierbarkeit wird die "Streaming Lite"-Komponente bereitgestellt, die Sie vorab auf der Streaming-Datenquelle einsetzen können. Diese analysiert und filtert die Streamdaten, bevor sie SAP HANA erreichen.

Predictive

Mit der Predictive Analysis Library (PAL) wird ein großes Set (aktuell 93) direkt ausführbarer Algorithmen ausgeliefert. Diese gliedern sich in die Bereiche »Clustering«, »Classification«, »Regression«, »Association«, »Time Series«, »Preprocessing«, »Statistics«, »Social Network Analysis«, »Recommender System« und »Sonstige«. Die Auswahl der einzelnen Algorithmen basiert auf den folgenden Kriterien der SAP:

 Die Algorithmen werden für SAP-Anwendungen benötigt.

 Die Algorithmen werden, basierend auf Markterhebungen, am häufigsten verwendet.

 Die Algorithmen sind im Allgemeinen auch in anderen Datenbankprodukten verfügbar.

Business Functions

Die Business Function Library (BFL) liefert neben der Predictive Analysis Library ein ergänzendes Set an Algorithmen (aktuell 55), mit denen vorgefertigte parametergesteuerte Funktionen im Finanzbereich zur Verfügung gestellt werden.

Machine Learning

Machine Learning (ML) Services beinhalten ein umfassendes Set an Tools und Funktionen, mit denen sich intelligente Anwendungen erstellen lassen.

Das ML-Toolset ist in die folgenden Bereiche gegliedert:

 Eingebettete ML-Bibliotheken wie die bereits beschriebenen PAL und BFL. Ergänzend wird die Automated Predictive Library (APL) zur Verfügung gestellt, mit der die zuvor beschriebenen Vorhersagealgorithmen auch automatisiert verwendet werden können.

 Spezielle API-Schnittstellen für externe R-Programme (R Machine Learning API), Python-Programme (Python Client API for ML) oder SQL-Clients (SQL Client API)

 Integration externer ML-Server, wie »TensorFlow« oder »Rserve/R Runtime«, über die External Machine Learning Library (EML)

Welche der zuvor beschriebenen Processing Services Sie in Ihre Anwendungsentwicklung einbinden, entscheiden Sie je nach Anwendungsfall.

Informationen zu den HANA Processing Services

Weitere Details zu den einzelnen Diensten und dem jeweils darin enthaltenen Funktionsumfang erhalten Sie über die folgenden Internetseiten:

 Allgemeine Informationen: https://www.sap.com/products/hana.html

 Detaillierte Informationen: https://help.sap.com/viewer/product/SAP_HANA_PLATFORM

Die Technologien, die diesen Services zugrunde liegen, sind im Übrigen keine SAP-Erfindungen, sondern werden auch von anderen Herstellern in ähnlicher Form umgesetzt. Mit den unterschiedlichen Processing Services als Suchbegriff werden Sie diverse Internetquellen mit weiteren Details und Hintergründen finden.

Ein wichtiger Aspekt ist, dass die einzelnen Funktionen der hier dargestellten Services vollständig in die gemeinsame Plattform integriert sind. Demzufolge haben Sie die Möglichkeit, in einer Anwendung auch komplexe und Engine-übergreifende Anforderungen umzusetzen. Sie müssen für die Realisierung nicht auf unterschiedliche Systeme zurückgreifen, zwischen denen die Daten hin- und hertransferiert werden. Beispielsweise können Sie Zusammenhänge geografischer Daten (Spatial) mit Graph-Algorithmen auswerten und diese Erkenntnisse mit relevanten Geschäftsdaten kombinieren oder durch Machine-Learning-Algorithmen weiter analysieren. Die SAP spricht bei dieser Integration diverser Dienste von »Multi-Model Processing« und »Advanced Analytics Processing«, also der Verarbeitung verschiedener Modelle auf einer Plattform.

Ich werde in diesem Buch nicht weiter auf die Datenbankarchitektur oder die Detailfunktionen der Processing Services eingehen. In den weiteren Kapiteln werde ich die Softwareentwicklung auf der integrierten Plattform in den Mittelpunkt stellen. Wichtig ist, dass Sie für Ihre Eigenentwicklungen den gesamten Funktionsumfang der HANA-Plattform (entsprechend Ihrer Lizensierung) nutzen können.

2.2 Extended Application Services Classic

Wie bereits in der Einleitung beschrieben, wurde der Bedarf an einem leichtgewichtigen Web-Anwendungsserver in Verbindung mit der HANA-Datenbank sehr früh erkannt. Dieser erweiterte Funktionsumfang der Plattform war aus zwei Gründen wichtig: Zum einen konnte die SAP auf diesem Weg zusätzliche Plattform-Funktionen, wie beispielsweise die Generierung von OData-Schnittstellen, direkt auf dem Datenbanksystem zur Verfügung stellen. Zum anderen verhalf er Kunden dazu, die Datenbank auch für Eigenentwicklungen zu nutzen, ohne weitere Infrastrukturkomponenten aufbauen zu müssen.

XSC und XS Engine

Zum Zeitpunkt der Veröffentlichung der XSC wurde noch nicht zwischen Classic und Advanced unterschieden. Die Extended Application Services wurden anfangs als »XS Engine« bezeichnet. Erst mit der Einführung der »Advanced«-Variante (XSA) wurde die XS Engine in XSC umbenannt.

Mit der SAP HANA XS Engine musste kein separater Applikationsserver ergänzend zur Datenbank betrieben werden. Alle Komponenten standen in einem einzigen System und mit nur einer Installation direkt zur Verfügung.

2.2.1 XSC-Architektur

In Abbildung 2.5 erhalten Sie eine Übersicht über die Architekturen mit und ohne XS Engine.

Abbildung 2.5: Datenbankarchitektur mit und ohne integriertem Applikationsserver

Bei der Architektur ohne XS Engine (linke Seite) müssen Anwendungen mithilfe von speziellen Treibern (HANA Client Library) auf die Datenbank zugreifen.

Die XS Engine als Eigenentwicklung der SAP wurde mit dem Release HANA 1.0 SPS 05 eingeführt. Technisch betrachtet ist sie ein JavaScript-Applikationsserver, der auf der SpiderMonkey Engine von Mozilla basiert. Der XS-Engine-Prozess ist ein eigenständiger Prozess innerhalb der HANA-Datenbank, der allerdings direkt mit dem Index-Server verbunden ist.