Traditionell ist das SAP Business Warehouse (BW) die Data Warehouse (DWH) Lösung der Wahl. Für Unternehmen mit einem SAP ERP System ist dies, aufgrund der starken Integration, die naheliegendste Lösung für jegliche Reporting Anforderungen. Der AnyDB Ansatz im BW Umfeld verschwindet und weicht einem integrierten Ansatz mit der hauseigenen Datenbank der SAP: das SAP HANA Data Warehouse. Parallel ist eine Entwicklung von End-to-End Cloud Angeboten mit der Datasphere [früher bekannt unter dem Namen "Data Warehouse Cloud (DWC)"] und der HANA Cloud zu verzeichnen.
Mit steigendem Funktionsumfang der HANA steigen auch die Einsatzmöglichkeiten. So ist es nun seit wenigen Jahren mit HANA 2.0, der XSA und einigen Werkzeugen wie der Data Warehouse Foundation problemlos möglich, eine native Data Warehouse Lösung, also ohne eine zusätzliche Applikationsschicht wie dem BW, zu betreiben, sprich:
HANA SQL Data Warehouse bzw. HANA Native Data Warehouse
In diesem Artikel stellen wir den HANA SQL DWH Ansatz vor - eine performante und moderne Alternative zum herkömmlichen Business Warehouse. Wir analysieren die Unterschiede und Gemeinsamkeiten in Bezug auf SAP BW und beschreiben anschließend verschiedene Nutzungsszenarien je nach Unternehmenssituation, insbesondere im Bezug auf die empfehlenswerteste Data Warehouse Lösung.
Was ist ein HANA SQL Data Warehouse?
Ein HANA SQL DWH ist eine SQL basierte analytische Datenbank. So können Datenbankobjekte mittels SQL generiert und manipuliert werden. Dabei wird ein von der SAP konzipierter SQL Dialekt namens “SQLScript” verwendet, der den OpenSQL Standard um vielfältige Funktionen und u. a. imperative Logik erweitert. Zusätzlich dazu können ausgewählte Datenbank Objekttypen wie beispielsweise Calculation Views über ein grafisches Kontextmenü modelliert werden, was auch Entwicklern ohne SQL Knowhow ermöglicht, einen grundlegenden Umfang an Modellierungsszenarien darzustellen, welche die häufigsten Anwendungsfälle abdecken.
Durch den Einsatz von Extended Application Services Advanced Model, kurz XSA, verfügt SAP HANA zusätzlich über eine Plattform, die entscheidende Vorteile bringt.
So wird hierdurch eine grundlegende Teilung von Runtime und Devtime erreicht - eine technische Architektur, die in der herkömmlichen Softwareentwicklung seit Jahrzehnten gang und gäbe ist. Konkret erfolgt die Entwicklung nicht direkt auf der Laufzeit der Datenbank, sondern in einer dedizierten Entwicklungsumgebung (WebIDE). Hier werden die Datenbankobjekte definiert und anschließend erst in einem Deployment Prozess auf die Datenbank aufgespielt. Damit geht für die Entwicklung ein Wechsel von Befehlen zu Definitionen einher. Statt beispielsweise eine Tabelle mittels CREATE zu erstellen, wird sie mittels der CORE DATA SERVICES (CDS) Syntax definiert. Erst während des Deployments wird diese SOLL-Definition automatisch mit dem IST-Zustand der Datenbank verglichen und die nötigen SQL-Befehle ausgeführt, um die Änderungen zu realisieren.
Dieses Konzept resultiert in der XSA spezifischen HANA Deployment Infrastructure (HDI) und führt in Verbindung mit GIT als etabliertes Werkzeug für Versionierung und Kollaboration zu einer Reihe an Vorteilen in den Bereichen:
- Kollaboration
Eine Vielzahl an Entwicklern kann an denselben sowie an abhängigen Objekten arbeiten. Die Kombination von automatischer Erkennung von hieraus resultierenden Konflikten sowie Funktionalitäten zur Lösung dieser Konflikte minimiert den Aufwand der Harmonisierung.
- Versionierung
Eine etablierte und integrierte Lösung zur Historisierung aller Änderungen und simple Rollback Möglichkeiten werden bereitgestellt.
- Deployment
Die HDI Architektur ermöglicht ein plattformunabhängiges Deployment.
Unterschiede und Gemeinsamkeiten
Funktionsumfang
Die grundlegenden Funktionalitäten zur Modellierung von Standard Data Warehouse Szenarien sind sowohl im BW als auch auf einer nativen HANA Lösung gegeben.
Wo im BW ADSOs für das physische Speichern von Daten verwendet werden, finden Tabellen im HANA DWH Anwendung. Jegliche Art von interner Datenübertragung zwischen persistenten Objekten wird in HANA über Prozeduren bzw. Flowgraphs realisiert, BW nutzt hierfür Datentransferprozesse (DTP) und Transformationen. Composite Provider sind die virtuellen Objekte der Wahl im BW und finden vor allem im Reporting Layer Anwendung - das HANA DWH sieht für diesen Zweck Calculation Views vor.
Mit dem Release des Data Warehouse Foundation Toolsets für die HANA Plattform sind nun auch einige für das Data Warehousing essentielle Funktionalitäten - u.a. Request Handling, Scheduling und Delta Management - von der SAP geliefert worden, was zuvor nötige Drittanbieter-Tools ersetzt.
Abgesehen von diesen Gemeinsamkeiten bietet die HANA Plattform mit der PAL noch zusätzlich besonderen Support für Machine Learning Anwendungen, während SAP BW weitreichenden Business Content auf Basis von Jahrzehnten von Nutzung in verschiedensten Branchen anbietet. HANA SQL DWH hat keinen Business Content, jedoch sind erste Bemühungen der SAP in dieser Richtung mit Financial Services Data Management (FSDM), einem kompletten, vorkonfigurierten Datenmodell für die Bankenbranche, zu sehen.
Ein Vergleich von
SAP BW/ HANA Native/ SAP Datasphere
Time-to-Market
HANA bietet moderne Entwicklungstools frei von Altlasten. Jedes Datenbankobjekt kann rein durch Coding (SQL/CDS/XML) entwickelt werden. Die häufigsten Szenarien sind auch durch grafische Entwicklungstools abbildbar (Calculation Views, Flow Graphs). Zusammen mit den von der XSA Plattform gebotenen Funktionen zur Kollaboration, Versionierung und Deployment, bietet der HANA Native Entwicklungsprozess eine hohe Flexibilität und Effizienz.
BW wurde und wird zunehmend komplexer und unübersichtlicher durch die Notwendigkeit des Supports von Legacy Funktionalitäten und technische Altlasten. Die Entwicklung findet primär über grafische Entwicklungstools statt, während ABAP Coding in komplexen Szenarien Verwendung findet, die die grafischen Entwicklungsmöglichkeiten übersteigen.
Zusammenfassend ist der Entwicklungsprozess im HANA SQL DWH Umfeld gradliniger und zeitlich effizienter, was zu einer schnelleren Time-To-Market für Reporting Anwendungen führt.
Performance
Konzept des Code Pushdown
Das Konzept des Code Pushdown - rechenaufwendige Operationen sollten möglichst auf der Datenbankschicht ausgeführt werden, statt auf der Applikationsschicht - findet im HANA SQL DWH Umfeld zentrale Anwendung und ist das Standardszenario. So wird der performance limitierende technische Flaschenhals in Form des Input/Output (I/O) zwischen Datenbank- und Applikationsschicht umgangen. Weiterhin werden die zentralen Vorteile der HANA Datenbank gegenüber anderen Datenbanken ausgenutzt: das Column Store Konzept und die Nutzung von Arbeitsspeicher als zentrales Speichermedium. Im BW Umfeld wird dieses Konzept standardmäßig nicht ausgenutzt. Ersteres kann jedoch u.a. über ABAP Managed Database Procedures (AMDP) erzielt werden, letzteres wird in neuen BW Versionen im Hintergrund genauso gehandhabt.
Nutzungsszenarien
Basierend auf der individuellen Situation und technischen Systemlandschaft eines Unternehmens, bieten sich drei grundlegende Varianten für die Nutzung eines on-premise SAP Data Warehouse an:
- ausschließlich BW
Für Unternehmen mit bereits hohen technischen, personellen und monetären Investitionen in eine SAP BW Landschaft, bietet es sich an beim etablierten Konzept zu bleiben. Besonders wenn Time-to-Market neuer Reporting Entwicklungen keine zentrale Rolle spielt, der Business Content des Business Warehouse extensiv genutzt wird und die moderne Infrastruktur keine Synergien mit beispielsweise Machine Learning Anwendungen und UI5 Applikationen erkennen lässt.
Hierdurch wird auch ein Risiko im Bereich des Know-how umgangen, denn SAP BW und HANA SQL DWH haben diesbezüglich zwar Schnittpunkte, jedoch auch signifikante Lücken. Der Talentpool für Experten im SQLScript und HANA Native Bereich ist deutlich schmaler, als die Menge an BW und ABAP Experten auf die zurückgegriffen werden kann - sowohl intern im Unternehmen, als auch extern und im Bewerberpool. Andererseits bietet die Nutzung moderner Lösungen und Entwicklungsplattformen, wie im HANA SQL DWH Umfeld gegeben, einen nicht zu vernachlässigbaren Recruiting- und Weiterbildungsanreiz. Es besteht außerdem eine signifikante Schnittmenge zwischen HANA SQL Entwicklung und dem Know-how der traditionellen Datenbankentwicklung.
- eigenständige HANA Datenbank
Eine HANA Datenbank kann auch problemlos ohne BW System als zentrales Data Warehouse betrieben werden. Dieses Szenario eignet sich vor allem für eine Migration eines bereits vorhandenen analytischen SQL DWH eines anderes Anbieters (z.B. eines MSSQL Servers), mit dem Ziel die Werkzeuge der HANA Plattform und die Performancevorteile der Hardware und technischen Architektur zu nutzen sowie eine Konsolidierung der genutzten Software Anbieter vorzunehmen.
Genauso bietet sich diese Lösung für Unternehmen an, die sehr geringe Investitionen in ihre bisherigen Data Warehouse Plattform getätigt haben oder gerade ihr erstes Data Warehouse aufbauen. Die schlanke, moderne und flexible HANA Native Lösung ist hier deutlich anwendungsfreundlicher für einen Neuaufbau eines Data Warehouse.
Besonderes Augenmerk ist auch im Financial Services Sektor geboten, wo das SAP Financial Services Data Management (FSDM) angeboten wird. Dieses bietet ein vorgefertigtes Datenmodell für das HANA SQL DWH, welches die umfangreichen externen Berichterstattungsanforderungen von Banken abdeckt - ähnlich dem Business Content im BW.
- hybride Lösung
Erfahrungsgemäß um die verbreitetste Variante handelt es sich bei einer hybriden Lösung, sprich der Nutzung eines vorhandenen BW (on HANA bzw. BW/4HANA) Systems und zusätzliche Native Entwicklung auf der HANA Datenbankseite desselben Systems. Historisch gewachsene Unternehmen werden größtenteils bereits starke Investitionen in ihr BW System getätigt haben - für eine komplette Migration auf ein HANA SQL DWH überwiegen die Kosten den Nutzen um ein Vielfaches. Gleichzeitig ist das Upgrade auf eine on HANA bzw. BW/4HANA Version entweder bereits durchgeführt oder aufgrund des verhältnismäßig geringen Aufwands und starken Nutzens sowie der Vermeidung von Einschränkungen im Support ohnehin geplant. Daher bietet es sich für solche Unternehmen an, ein geringes Risiko einzugehen und kleinere Investitionen mit ersten Prototypen in einem HANA SQL DWH Umfeld zu tätigen. So können die Vorteile des HANA SQL DWH in den Anwendungen genutzt werden, wo Sie den größten Nutzen ausmachen und eine komplette Migration umgangen werden.
Denkbar ist auch die Nutzung zusätzlicher, eigenständiger HANA Datenbanken neben dem zentralen BW System.
Haben Sie Fragen zu diesem oder anderen Themen? Versuchen Sie das nötige Know-How in Ihrer Abteilung aufzubauen oder benötigen Sie Unterstützung bei einer konkreten Fragestellung? Wir helfen Ihnen gerne dabei. Fordern Sie noch heute ein unverbindliches Beratungsangebot an.
