SAP-HANA

SAP HANA Überblick

Bei SAP HANA handelt es sich um eine von der SAP AG im Jahr 2010 vorgestellte Datenbank, die auf der In-Memory-Technologie basiert. Bei der In-Memory-Technologie werden die gesamten Daten im Arbeitsspeicher gehalten, wodurch im Vergleich zur Speicherung auf magnetischen Festplatten ein sehr großer Performancevorteil erreicht werden kann.

Funktionsweise

SAP HANA ist eine relationale In-Memory Datenbank, die auf SQL basiert. SAP HANA kann entweder als Appliance, eine Kombination von Hardware und Software oder in der Cloud verwendet werden. Die Datenbank verwendet SUSE-Linux als Betriebssystem. Mit SAP HANA ist es möglich, große Datenmengen schnell in Echtzeit zu analysieren. Sie kombiniert spaltenorientierte und zeilenorientierte Datenbanktechnologien und ist auf paralleles Ausführen von Prozessen durch Verwendung mehrkerniger CPU-Architekturen optimiert. Zur Administration der Datenbank und für die Entwicklung wird das auf Eclipse basierende "SAP HANA Studio" verwendet. Des Weiteren können aus verschiedenen Datenquellen wie aus SAP ERP oder SAP BW Daten nach SAP HANA extrahiert werden.

SAP HANA Architektur

Zur Kommunikation mit dem Datenbank Management System (DBMS) verwendet SAP HANA ODBC und JDBC Schnittstellen. Der Index Server im SAP HANA stellt die Hauptkomponente dar. Hier werden u.a. sämtliche Daten gespeichert. Desweiteren liegen hier auch die Engines für das Verarbeiten von Daten. Mit SAP HANA SQLScript wird eine eigene Scriptsprache verwendet, um imperatives Entwickeln (z. B. Erstellung von Prozeduren) zu ermöglichen. Zusätzlich wird die Programmiersprache R für statistische Auswertungen unterstützt.

Quelle: SAP HANA Developer Guide S. 17

SAP HANA Studio

Das SAP HANA Studio ist ein auf Eclipse basiertes Entwicklungs- und Administrationstool für die SAP HANA Datenbank. Mit der Verwendung des SAP HANA Studio können Entwicklungs-Objekte, wie Datenmodelle oder „server-side code files“ erstellt und mit anderen Entwicklern durch Nutzung des SAP HANA Repository geteilt werden. Das Repository ermöglicht es, dass Entwicklungsteams gleichzeitig auf den gleichen Entwicklungsobjekten arbeiten.

Quelle: SAP HANA Developer Guide S. 19

Durch ein „checkout“ können Repository-Objekte auf den lokalen Rechner geladen, bearbeitet und anschließend durch ein Commit wieder in das Repository geladen werden. Im SAP HANA Studio können unterschiedliche Perspektiven aufgerufen werden:

Modeler: Wird verwendet, um unterschiedliche Arten von Views zu erstellen und Berechtigungen zu verwalten.

SAP HANA Development: Wird für die Entwicklung von Anwendungen verwendet. Es können z.B. Projekte oder Entwicklungsobjekte erstellt werden.

Debug: Wird verwendet um z.B. SQLScript Code zu debuggen. Es können Breakpoints an beliebigen Stellen im Quellcode eingefügt werden.

Administration: Hier können Änderungen an den Systemeinstellungen vorgenommen werden, zusätzlich wird ein Systemmonitor zur Verfügung gestellt.

Spaltenorientierte Speicherung

Eine relationale Datenbanktabelle ist zweidimensional konzipiert. Die Daten werden in Zeilen und Spalten abgebildet. Im Gegensatz hierzu, ist der Computer-Arbeitsspeicher als lineare Struktur organisiert. Eine zeilenorientierte Speicherung speichert eine Tabelle als eine Sequenz von Einträgen. Bei der spaltenorientieren Speicherung werden die Daten nebeneinander in die Speicherzellen geschrieben und können so besonders schnell aufgerufen werden. SAP HANA unterstützt beide Speicherverfahren, ist jedoch für die spaltenorientierte Speicherung optimiert.

Quelle: SAP HANA Developer Guide S. 12

Spaltenorientierte Speicherung ermöglicht insbesondere bei sortierten Spalten, eine sehr effiziente Datenkompression. Des Weiteren verwendet SAP HANA Kompressionsmethoden wie z.B.„dictionary encoding“.Bei der „dictionary encoding“ – Methode werden Spalten als Integer-Werte gespeichert. Bei einer Suche oder bei Join-Operationen wird auf die Integer Werte zugegriffen, welches viel schneller ist, als beispielsweise String Werte zu vergleichen. Des weiteren können somit Daten vom Arbeitsspeicher schneller zur CPU zur weiteren Verarbeitung übertragen werden.

Durch die spaltenorienterte Speicherung kann auch auf die Verwendung von zusätzlichen Index Strukturen verzichtet werden. Die Suche innerhalb von Spalten ist durch die Speicherung im Arbeitsspeicher und die hohe Kompression sehr performant. Aus diesem Grund kann auf weitere zusätzliche Indexe verzichtet werden, welches wiederum Aufwand zur Definition und Pflege von Metadaten entfallen lässt.

Parallele Verarbeitung

SAP HANA wurde konzipiert, um verschiedene Prozesse, wie analytische Joins, Suchen oder Aggregationen parallel durchzuführen. Hierbei werden die verschiedenen Vorgänge auf die einzelnen Prozessorkerne verteilt ausgeführt. So können beispielsweise Suchen in Form eines Arrays umgesetzt werden, wobei die einzelnen Werte nebeneinander im Arbeitsspeicher abgelegt werden. Hierfür muss spaltenorientierte Speicherung angewendet werden. Bei der Verwendung von zeilenorientierter Speicherung ist derselbe Vorgang viel langsamer, da die Daten über den gesamten Arbeitsspeicher verteilt sind.

Quelle: SAP HANA Developer Guide S. 13

Replikation[1]

Geschäftsdaten müssen zur weiteren Analyse und für das Reporting aus einem Quellsystem in die SAP HANA Datenbank repliziert werden.

Hierfür gibt es in SAP HANA drei unterschiedliche Methoden:

  • Trigger-Based-Replication
  • ETL-Based Replication
  • Extractor-Based Data Acquisition

Quelle: SAP HANA Technical Operations Guide S. 28

Trigger-Based-Replication

Bei der Trigger-Based Methode, wird SAP Landscape Transformation (LT) für die Replizierung verwendet.

Quelle: SAP HANA Technical Operations Guide S. 29

Zunächst wird im SAP HANA Studio ein Initial Load angestoßen. Die Daten werden anschließend aus dem Quellsystem über SAP Landscape Transformation in die SAP HANA Datenbank geladen. Während des Initial Load werden jegliche weitere Änderungen durch das SAP Landscape Transformation geloggt und mit in die SAP HANA Datenbank repliziert. Nachdem der Initial Load abgeschlossen ist, werden jegliche weiteren Änderungen über Delta Loads in Echtzeit in die SAP HANA Datenbank repliziert.

SAP HANA Direct Extractor Connection (DXC)

Bei der Extractor- Based Data Acquisition –Methode, wird das in SAP Business Suite enthaltene “Embedded BW” System für die Replizierung verwendet. Zunächst werden die Geschäftsdaten aus dem Quellsystem (z.B. SAP ERP oder SAP CRM) in DataSources extrahiert und in das Embedded BW geladen. Anschließend können Batch-Jobs eingeplant und die DataSources vom BW-System nach SAP HANA über eine HTTP Verbindung transportiert werden.

Quelle: SAP HANA Technical Operations Guide S. 31

ETL-Based Replication

ETL (Extraction-Transformation-Load) basierte Daten Replikation verwendet das SAP Business Objects Data Services Tool. Bei dieser Methode werden die Daten auf der Applikation Ebene gelesen. Zunächst müssen im Designer die Datenflüsse definiert werden. Anschließend werden im Job Server die Replikations Jobs ausgeführt. Es wird ein zusätzliches Repository für die Speicherung der Metadaten und die Jobdefinitionen verwendet.

Quelle: SAP HANA Technical Operations Guide S. 32

Vor und Nachteile:

Der große Vorteil an der SAP HANA Datenbank ist, dass durch die In-Memory Technologie, die spaltenorientierte Speicherung und durch den Einsatz von Kompressionsverfahren, eine sehr hohe Performance erreicht werden kann. Ein Nachteil ist jedoch, dass durch die Verwendung des Arbeitsspeichers als flüchtiges Medium, die Daten bei einem Systemausfall verloren gehen und somit die Persistenz für erfolgreich abgeschlossene Transaktionen verletzt ist. Um die Daten bei einem Systemausfall wiederherstellen zu können, werden in regelmäßigen Abständen Snapshots der Datenbank geschossen und Änderungen an der Datenbank in Protokolldateien geschrieben. Hiermit wird die Möglichkeit geboten, durch Verwendung von Snapshot und protokollierter Datenbankänderung den letzten Zustand der Datenbank wiederherzustellen.

[1] Mit "Replikation" ist hier die Extraktion von Daten aus Quellsystemen in das SAP HANA gemeint und nicht die redundante Speicherung von Daten an mehreren Standorten.

Quellen:

Kategorie: InMemory-DB, Spaltenorientierte-DB