Im Kern basiert das SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… Mehr HANA SQL Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… Mehr auf der SAP HANA Plattform. Diese Plattform besteht aus der SAP HANA Datenbank, dem SAP Extendes Application Services advanced model (kurz XSA) und der SAP HANA Deployment Infrastructure (kurz HDIHana Depoloyment Infrastruktur Container Mehr) sowie einigen weiteren Services, die wir an dieser Stelle außen vor lassen.
Inhaltsverzeichnis
2. Komponenten des SAP HANA SQL DWH
5. Build Server
6. ETL
7. Modellierung
8. Betrieb
9. Fazit
Die SAP HANA Plattform
Vereinfacht ausgedrückt stellen die HANA Datenbank, XSA und HDI die Schlüsseltechnologien für das SAP HANA SQL Data Warehouse. Weitere allgemeine Informationen zum SAP HANA SQL DWH erhalten Sie hier: https://isr.de/technologien/sap/hana-sql-dwh
Dazu muss jedoch erwähnt werden, dass es neben der von uns empfohlenen Lösung weitere Möglichkeiten gibt, ein HANA-basiertes DWH aufzubauen. Beispielsweise mit einem SQL-nativen Ansatz. Hier wird auf XSA und HDI verzichtet und stattdessen verstärkt auf der Datenbank gearbeitet. Auch HANA-spezifische Objekte wie Calculation Views können bei diesem Ansatz verwendet werden – unter Verwendung des SAP Extended Application Services Classic Model (kurz XSC). Aber Vorsicht, der SQL-native Ansatz ist zwar grundsätzlich möglich, kommt aber mit vielen Einschränkungen im Vergleich zum Ansatz mit XSA und HDI. Darunter sind die beiden folgenden Einschränkungen von zentraler Bedeutung:
- Entwicklungsobjekte liegen auf der Datenbank. Dadurch kann nur mit SAP-proprietären Entwicklungsumgebungen gearbeitet werden, kollaboratives, unabhängiges Arbeiten wird erschwert, und vor allem können Entwicklungsobjekte nicht mit Source Code Management-Werkzeugen wie GitGit stellt ein Softwarerepository da, welches in der Softwareentwicklung einen… Mehr verwaltet werden, wodurch sich weitere Einschränkungen für die Entwicklung, aber auch das Deployment ergeben. Unter Verwendung von XSA und HDI bestehen diese Einschränkungen nicht.
- Das Deployment ist unflexibel und stark manuell geprägt. Entwicklungsobjekte können zwar geordnet, im Umfang eines einizgen Deployments ausgeliefert werden. Hierzu werden sogenannte Delivery Units erstellt. Der Vorgang, diese zu erstellen und zu deployen kann jedoch nicht automatisiert werden. Mit XSA und HDI ist dieser Vorgang hingegen vollständig automatisierbar. Als Ziel kommen des Weiteren nur andere SAP HANA Datenbanken infrage. HDI bietet dagegen die Möglichkeit, zwischen On-Premise-Deployment und Cloud-Deployment zu wählen.
Aufgrund dieser Einschränkungen empfehlen wir das SAP HANA SQL DWH auf Basis der SAP HANA Plattform mit XSA und HDI aufzubauen. Im vorliegenden Artikel betrachten diese Plattform daher als feste Komponente.
Komponenten des SAP HANA SQL DWH
Abgesehen von der SAP HANA Plattform besteht das HANA SQL DWH aus weiteren Komponenten (siehe Abbildung 1). Diese sind: Eine Entwicklungsumgebung, ein Source Code Management System, ein Build Server, ein ETL-Werkzeug, ein Modellierungs-Werkzeug und Werkzeuge für den Betrieb des Data Warehouse.
Abbildung 1: SAP HANA SQL DWH Komponenten
All diese Komponenten sollten grundsätzlich vorhanden sein um eine effiziente Entwicklung und einen reibungslosen Betrieb des SAP HANA SQL DWH sicherzustellen. Bei der Ausgestaltung der Komponenten, insbesondere bei der Auswahl konkreter Werkzeuge besteht hingegen die Möglichkeit, in hohem Maß individuelle Entscheidungen für das eigene SAP HANA SQL DWH zu treffen.
Im Folgenden werden die einzelnen Komponenten kurz skizziert und jeweils eine Auswahl möglicher Anwendungen und Werkzeuge vorgestellt.
Entwicklungsumgebung
Eine Entwicklungsumgebung ist zwingend erforderlich für die Implementierung der Datenbankobjekte. Die Entwicklung eines SAP HANA SQL DWH funktioniert auf Basis von Designtime-Objekten, die erst beim Deployment zu Runtime-Objekten in der Datenbank werden. Damit unterscheidet sich die Entwicklung des SAP HANA SQL DWH deutlich von der Entwicklung klassischer SQL DWH auf anderen Plattformen. Dieser Unterschied sollte auch bei der Auswahl der Entwicklungsumgebung berücksichtigt werden.
Abbildung 2: Entwicklungsumgebung eines SAP HANA SQL DWH
Mit der SAP Web IDE bietet die SAP eine Entwicklungsumgebung an, die genau auf die Entwicklung von Anwendungen auf der SAP HANA Plattform zugeschnitten ist. Tatsächlich ist die SAP Web IDE selbst eine Applikation, die auf der Plattform als webservice läuft und von Entwicklern über einen Browser genutzt wird. Dadurch sind keine lokalen Installationen und Updates notwendig und Entwicklungsobjekte werden serverseitig gespeichert und versioniert, sodass Nutzer sich auf ihre eigentlichen Aufgaben konzentrieren können. Die Werkzeuge, die innerhalb der SAP Web IDE zur Verfügung stehen sind vielfältig. So besteht für die meisten HANA-nativen Objekte, wie beispielsweise Calculation Views, Flowgraphs oder CDS-Tabellen die Möglichkeit code-basiert oder mit Hilfe eines grafischen Editors zu arbeiten. Neben solchen Entwicklungswerkzeugen sind in die SAP Web IDE auch Werkzeuge integriert, die die Aktivierung der Designtime-Objekte und die Arbeit mit den Runtime-Objekten erleichtern. So lassen sich direkt aus der Entwicklungsumgebung die Designtime-Objekte „Builden“, das heißt mittels eines integrierten HDI-service in Objekte auf der HANA-Datenbank übertragen. Die auf diese Weise aktivierten Runtime-Objekte können wiederum mit Hilfe des sogenannten Database Explorers betrachtet werden. Hierzu kann über den Database Explorer wahlweise klassische SQL Schemata, aber auch einzelne HDI-Container anbinden.
Ebenfalls denkbar ist, keine SAP-proprietäre Entwicklungsumgebungen zu nutzen, wie Eclipse oder Visual Studio Code. Diese bieten vor allem den Vorteil, dass Sie von einer großen Nutzerschaft aus unterschiedlichen Softwareprojekten profitieren. So verfügen viele Entwicklungsumgebungen über ein großes Angebot von Erweiterungen, mit denen die Kernfunktionalität der Entwicklungsumgebung um spezifische weitere Funktionen erweitert werden kann. Verzichtet werden müsste jedoch auf grafische Editoren für HANA-native Datenbankobjekte sowie auf Werkzeuge für die Arbeit mit XSA und HDI.
Source Code Management
Die Besonderheit des HANA SQL DWH, dass es auf Basis von Designtime-Objekten entwickelt wird, wurde bereits mit Blick auf Entwicklungsumgebungen angesprochen. Vereinfacht ausgedrückt stellen Designtime-Objekte den Quellcode für die Runtime-Objekte. Um diesem Quellcode Herr zu werden ist es unabdingbar, ein Source Code Management-Werkzeug (SCM) zu verwenden. Mithilfe eines SCM-Werkzeugs kann die Entwicklung der Anwendung auf Ebene einzelner Codezeilen versioniert und auditiert werden. Das bedeutet, dass Veränderungen auf feinster Ebene vorgenommen und nachvollzogen werden können. Ein weiterer großer Vorteil von SCM-Werkzeugen ist, dass sie den Entwicklern ermöglichen, non-linear und verteilt zu arbeiten. Und zwar weil alle Entwickler auf ihren eigenen Kopien des Quellcodes arbeiten. Eines der populärsten SCM-Werkzeuge überhaupt, auf das all diese Beschreibungen zutrifft ist Git.
Abbildung 3: Git
Die wichtigsten Funktionialitäten, die Git zur Verwaltung von Quellcode verwendet, sind Commits und Branches. Commits (Kreise in Abbildung 3) sind Speicherstände des Quellcodes zu einem bestimmten Zeitpunkt. Der Quellcode entwickelt sich sozusagen von Commit zu Commit immer weiter. Branches (Development, Feature A, Feature B in Abbildung 3) sind notwendig, um mehrere Entwicklungen an ein und demselben Repository gleichzeitig voranzutreiben. Dies ist beispielsweise der Fall, wenn mehrere Bestandteile des Data Warehouse, in Git auch Features genannt, gleichzeitig entwickelt werden und wenn mehrere Entwickler gleichzeitig an diesen Features arbeiten.
Um Git kollaborativ zu verwenden, sollte das Git-Repository über einen speziellen Git-Server gemanaged werden. Hier stehen viele verschiedene Produkte zur Verfügung, die entweder on-premise oder in der CloudDer Begriff Cloud stammt aus dem Englischen, zu deutsch „Wolke“…. Mehr genutzt werden können: z.B. GitHub, GitLab und Bitbucket.
Neben Git gibt es noch weitere Source Code Management-Werkzeuge, die auch für die Entwicklung des SAP HANA SQL DWH genutzt werden können, wie BitKeeper und Subversion, um nur zwei Beispiele zu nennen. Wegen der guten Integration in die Entwicklungsumgebung SAP Web IDE sowie aufgrund weiterer Integrationsmöglichkeiten mit anderen third party Werkzeugen, der leichten Zugänglichkeit und der großen Nutzerschaft von Git sollte dieses jedoch grundsätzlich als erstes in Betracht gezogen werden. Die Verwendung von Git öffnet außerdem die Tür für eine Vielzahl von methodischen und technischen Best Practices, die aus der Softwareentwicklung entlehnt werden können. Darunter vor allem die Verwendung eines Build Servers, der in seiner Funktionsweise in der Regel stark mit Git verzahnt ist.
Build Server
Eine weitere Komponente, die für Entwicklung und Betrieb eines SAP HANA SQL DWH unbedingt vorhanden sein sollte ist ein sogenannter Build Server. Auch in diesem Fall ist es wichtig, sich vor Augen zu führen, dass für das SAP HANA SQL DWH Datenbankobjekte als Designtime-Objekte entwickelt und als Runtime-Objekte ausgeführt werden. Vereinfacht ausgedrückt wird der Build Server benötigt, um die Designtime-Objekte in die Runtime der Datenbank zu überführen. Er übernimmt die Ausführung des Builds und des Deployments des SAP HANA SQL DWHs. Beide Schritte müssten andernfalls manuell ausgeführt werden.
Abbildung 4: Build Plan
Die Prozesse, die ein Build Server ausführt, werden häufig als Build Pläne bezeichnet. Ein simpler Build Plan ist in Abbildung 4 zu sehen. Genau wie die Entwickler auch, greift der Build Server mit Hilfe des SCM-Werkzeugs, beispielsweise Git, auf die Designtime-Objekte zu. Nachdem der Build Server eine Arbeitskopie des Repositories mit allen Designtime-Ressourcen erstellt hat, wird der Build der Ressourcen gestartet. Das bedeutet im Kontext des SAP HANA SQL DWH, dass ein sogenanntes Multi-Target-Application-Archiv (kurz MTA-Archiv) erstellt wird. Dieses MTA-Archiv beinhaltet die Ressourcen sowie Metainformationen und Konfigurationen, die für das Deployment benötigt werden. Wenn das MTA-Archiv bereitsteht, wird das Deployment ausgeführt. Hierzu übergibt der Build Server das MTA-Archiv an die XSA, den Applikationsserver der HANA Plattform, und weist diese an, das Deployment auf Basis des MTA-Archivs auszuführen.
Die Vorzüge eines Build Servers zeigen sich auch darin, dass sich nicht nur Build und Deployment des DWH automatisieren lassen, sondern auch viele weitere Prozesse, die für Entwicklung und Betrieb des DWH von Nöten sind, wie beispielsweise:
- Designtime-Tests: Designtime-Objekte werden hinsichtlich vorgegebener Entwicklungsrichtlinien geprüft (Einhaltung von Namenskonventionen, korrekte Verwendung von Datentypen, etc.)
- Build-Tests: Designtime-Objekte werden auf ihre Lauffähigkeit getestet bevor sie deployed werden.
- Runtime-Tests: Runtime-Objekte werden hinsichtlich inhaltlicher Konsistenz getestet (z.B. Anzahl Datensätze, Durchschnittswerte, etc.)
Einer der populärsten Build Server ist sicherlich Jenkins. Weitere allgemeine Informationen zu diesem Aspekt finden Sie hier: https://isr.de/news/devops/. Daneben wächst aber auch stetig das Angebot anderer Anbieter – z.B. mit Atlassian Bamboo, GitLab CIContinuous Integration, bedeutet die kontinuierliche Zusammenführung von einzelnen Entwicklungsständen (Feature… Mehr/CD, JetBrains Teamcity und vielen mehr.
Abbildung 5: Grafische Oberfläche Build Pläne
Die Funktionsweise ist bei all diesen Werkzeugen ähnlich: Build Pläne, oder andere Prozesse, die automatisiert ausgeführt werden sollen, werden entweder mittels einer grafischen Oberfläche (siehe Abbildung 5) oder als ausführbare Skripte erstellt. Der Build Server liefert hierfür in aller Regel die Entwicklungsumgebung, aber auch die Infrastruktur für das Ausführen und Monitoren der Automationsprozesse.
ETL
Eine Voraussetzung, die nicht spezifisch für das SAP HANA SQL DWH ist, ist die Verwendung eines ETL-Werkzeugs. Ein ETL-Werkzeug wird gewöhnlicherweise für jede Form von Data Warehouse benötigt, um Quelldaten in die zentrale Persistenz des Data Warehouse zu bewegen. Im SAP Portfolio findet sich eine Reihe von ETL-Werkzeugen, die sich in ihrer Funktionalität teilweise überschneiden, zum Teil aber auch stark voneinander unterscheiden: SAP Data Services (DS) und SAP System Landscape Transformation (SLT) sind dabei nur zwei bekannte Beispiele. Mit Smart Data Integration (kurz SDISmart Data Integration, um Quellsysteme anzubinden, welche nicht JDBC/ODBC können,… Mehr) bietet die SAP nun seit einiger Zeit ein ETL-Werkzeug als XSA-Applikation an, das die Funktionen unterschiedlicher ETL-Werkzeuge der SAP vereinigt und auch erweitert.
Mittels SDI ist es möglich, nahezu jede Datenquelle an die HANA Datenbank anzubinden – ob SQL-Datenbank, NoSQL-Datenbank, verteilte Datenbanken à la Hadoop, Social Media-Webseiten oder Dateien. Hierzu steht standardmäßig eine große Auswahl von Konnektoren zur Verfügung, die herkömmliche Szenarien wie oben beschrieben abdecken. Für weitere Szenarien steht ein Software Development Kit zur Verfügung, mit dem individuelle Konnektoren erstellt werden können.
Abbildung 6: SAP Smart Data Integraion
Technisch ist SDI voll integriert in die SAP HANA Plattform. Zur Nutzung muss auf dem Quellsystem lediglich ein sogenannter Data Provisioning Agent installiert und mit dem entsprechenden Adapter angebunden werden. Anschließend kann der Data Provisioning Server der SAP HANA Plattform mit dem Data Provisioning Agent kommunizieren. Die größten Vorteile bietet SDI mit der uneingeschränkten Anbindung beliebiger Datenquellen und der umfassenden Integration in die Entwicklungsgebungen SAP Web IDE und SAP HANA Studio, mit denen komplexe ETL-Prozeduren, sogenannte Flowgraphs, mittels grafischer Oberflächen, erstellt werden können.
Wahlweise kann der Aspekt ETL für das SAP HANA SQL DWH aber auch vollständig ohne SAP-Produkte und stattdessen mit Werkzeugen anderer Anbieter abgedeckt werden, wie beispielsweise Talend oder Informatica. Voraussetzung ist lediglich, dass das Werkzeug der Wahl mit der SAP HANA-Datenbank kommunizieren kann – zum Beispiel über ODBC oder JDBC. Von Nachteil ist hier jedoch, dass die entsprechenden ETL-Entwicklungsobjekte nicht über das SCM-Werkzeug gespeichert und versioniert werden, sondern isoliert vom Rest des SAP HANA SQL DWH entwickelt werden. Potenziell verringert sich dadurch die Übersichtlichkeit der Entwicklung während sich die Komplexität des Deployments erhöht.
Modellierung
Das HANA SQL DWH wird modellgetrieben entwickelt. Das heißt, dass die gesamte Entwicklung ausschließlich auf der Basis von Modellen geschieht, die vorgeben welche Objekte auf welche Weise implementiert werden sollen. Damit ist es unerlässlich ein Modellierungswerkzeug einzusetzen.
Abbildung 7: SAP PowerDesigner
Bei der Auswahl eines geeigneten Modellierungswerkzeugs für das SAP HANA SQL DWH sollte der SAP PowerDesignerClientbasiertes Modellierungswerkzeug, welches ein Leistungsstarkes Modellierungswerkzeug darstellt. Hierbei können eine… Mehr in Betracht gezogen werden. Dieser zeichnet sich zum einen durch umfangreiche Modellierungsfunktionalitäten aus. So lassen sich unterschiedliche Modelltypen definieren (z.B. konzeptioelles, logisches, physisches Datenmodell), aber auch unterschiedliche Modellierungsnotationen. Zum anderen zeigt der PowerDesigner eine besondere Stärke durch umfassende Impact- und Lineage-Funktionalitäten, also Funktionalitäten, die es erleichtern den Überblick über komplexe Datenflüsse zu behalten, um beispielsweise nachverfolgen zu können welche Tabellen ein analytischer View konsumiert und mit welchen Quelldaten diese Tabellen bewirtschaftet werden. Darüber hinaus ist bei der Verwendung des PowerDesigners im SAP SQL DWH Kontext von Vorteil, dass Objekte HANA-nativ modelliert werden können, dass also beispielsweise statt klassischen SQL-Tabellen CDS-Tabellen und statt SQL-Views Calculation Views verwendet werden können. Für CDS-Tabellen bietet der PowerDesigner außer dem standardmäßig eine Generierungsfunktion, mit der sich einzelne Tabellen oder ganze Modelle als CDS-Dateien exportieren lassen. Für spezifischere Aufgaben, wie das Generieren von Synonymen oder ETL-Flowgraphs bietet der PowerDesigner keine Standardfunktionen an – dafür aber eine Visual Basic Script Schnittstelle, über die nahezu jede Aufgabe im PowerDesigner automatisiert werden kann.
Auf derlei Funktionalitäten, die eine engere Verzahnung zwischen Modellierung und Entwicklung des SAP HANA SQL DWH unterstützen, muss verzichtet werden, wenn die Entscheidung gegen den PowerDesigners getroffen wird. Mit Werkzeugen wie Erwin Data Modeler oder SQLDBM lassen sich zwar ebenfalls komplexe Modelle aufbauen und pflegen. Allerdings bieten diese und vergleichbare Werkzeuge keine Funktionalitäten für die Generierung von HANA-nativen Objekten und in den meisten Fällen weniger umfassende bis gar keine Impact- und Lineage-Funktionalitäten. Damit ist der PowerDesigner zwar immer noch nicht unverzichtbar, aber im Vergleich zu anderen Werkzeugen des SAP HANA SQL DWHs schwieriger, bzw. aufwendiger zu ersetzen.
Betrieb
Unter der Komponente Operation lassen sich eine Vielzahl unterschiedlichster Werkzeuge subsumieren, die den Betrieb des SAP HANA SQL DWH unterstützen. Dazu zählen beispielsweise Werkzeuge, die das zeitliche Einplanen und den planmäßigen Aufruf von Bewirtschaftungsprozessen übernehmen, Werkzeuge, die bei Instandhaltung und Monitoring des DWH unterstützen und viele weitere.
Abbildung 8: Werkzeuge SAP HANA Cockpit
Standardmäßig, unabhängig vom Einsatzzweck der SAP HANA lässt sich das System über eine lokale Installation des SAP HANA Studios oder über das modernere, browser-basierte Werkzeug SAP HANA Cockpit (siehe Abbildung 8) administrieren. Hier stehen dem Administrator viele Konfigurationsmöglichkeiten und detaillierte Systeminformationen zur Verfügung, wie beispielsweise CPU-Auslastung, Speicherauslastung, Laufende Prozesse, etc.
Ein Werkzeug-Paket, das die SAP speziell für den Zweck anbietet, Data Management für das SAP HANA SQL DWH effizienter zu gestalten, ist die SAP Data Warehousing Foundation (kurz DWF). Das Paket besteht dabei aus den folgenden Werkzeugen:
- Data Distribution Optimizer (DDO): Für die Organisation von verteilen SAP HANA-Landschaften
- Data Lifecycle Manager (DLM): Für das Speichermanagement
- Native DataStore Object (NDSOSQL Native DataStore Object, welche eine zentrales Persistenz Objekt darstellen,…): Persistenzobjekte mit Deltatechnik
- Data Warehousing Scheduler (DWS): Orchestrierung der Bewirtschaftung,
- Data Warehouse Monitoring (DWM): Überwachung der DWF-Prozesse
Mit SAP DWFData Warehouse Foundation ist ein Set aus Datenmanagement Tools um… Mehr verfolgt die SAP das Ziel bewährte Funktionalitäten aus dem SAP Business Warehouse (kurz SAP BW) für das SAP HANA SQL DWH zugänglich zu machen. Diese Bemühung ist grundsätzlich zu begrüßen, jedoch zeigen sich in der Umsetzung einige Schwächen. So eignet sich SAP DWF als Orchestrieungswerkzeug für die Bewirtschaftung (Data Warehouse Scheduler) vornehmlich für sehr einfache DWHs. Für komplexere Szenarien fehlen hingegen Konfigurationsmöglichkeiten und Funktionen, die durch die technische Architektur des SAP HANA SQL DWH mit XSA und HDI notwendig werden. Dasselbe gilt für die Verwendung des NDSOs. Mit steigender Komplexität ist jedoch die Nutzung des Data Distribution Optimizers (DDO) und des Data Lifecycle Managers (DLM) sinnvoll und empfehlenswert. Diese beiden Features können gerade bei der Arbeit mit verteilten Datenlandschaften und sehr hohem Speicherbedarf sinnvolle eingebracht werden.
Alternativ zu SAP DWF steht auf dem Markt eine Vielzahl unterschiedlichster Werkzeuge zur Verfügung, mit denen sich die Administrationsmöglichkeiten der SAP HANA erweitern lassen. Die SAP HANA Plattform ist grundsätzlich offen für unterschiedlichste Erweiterungen.
Fazit
Das HANA SQL DWH basiert auf der SAP HANA Plattform. Diese ist eine feste Komponente und kann nicht ersetzt werden. Darüber hinaus baut das SAP HANA SQL DWH auf weitere Komponenten, die vorhanden sein sollten, bei denen aber unterschiedlichste Technologien und Werkzeuge zum Einsatz kommen können. Hier besteht der Grundsatz der generellen Austauschbarkeit.
Durch die hohe technische Offenheit begünstigt die SAP HANA Plattform grundsätzlich sehr individuelle Lösungen – sodass beim Finden geeigneter Werkzeuge weniger die Frage der technischen Machbarkeit im Vordergrund steht, sondern die Auswahl anhand der inhaltlichen Eignung der Werkzeuge stattfinden kann.
Autor: Frederik Niemeyer
KONTAKT
Stefan Kahle
Senior Executive Manager
SAP Information Management
