Geänderte Anforderungen an moderne Data WarehouseEin Data Warehouse ist für die Ausführung, Überwachung und Steuerung… Mehr Systeme bedeuten, dass Aspekte wie Agilität und Offenheit zur Integration mit anderen Lösungen deutlich wichtiger werden, und somit in der Architektur und Modellierung eben solcher Systeme inhärent berücksichtigt werden sollten.
Moderne Analytics bedeutet auch, dass Endanwender mittels Self-Service BI in die Lage versetzt werden, eigenständig auf die Daten des Data Warehouse zuzugreifen und diese zu analysieren und zu visualisieren. Klassischerweise war dies keine Stärke von SAP-Tools wie BEx oder Business Objects: in der Regel wurde hier unterschieden zwischen individueller Auswertung auf der einen Seite, welches eher auf Excel-Basis – BEx oder Analysis for Office – durchgeführt wurde, sowie Standard-Reporting auf der anderen Seite, welches mittels Lumira Designer, Dashboards, WebIntelligence o.ä. durch die IT erstellt und betreut wurde.
Inhaltsverzeichnis
2. Verbindung mit einem 3rd-Party-Frontend am Beispiel von Tableau
2.1 Einschränkung in der Verbindung von Tableau zu SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… Mehr BW (MDX)
2.2 Einschränkung in der Verbindung von Tableau zu SAP HANA (SQL/ODBC)
3. Architektur und Modellierung im Data Warehouse
4. Fazit
Während SAP mit Analytics CloudDer Begriff Cloud stammt aus dem Englischen, zu deutsch „Wolke“…. Mehr große Schritte in Richtung einfacher und skalierbarer Self-Service BI gemacht hat, wurden in vielen Unternehmen jedoch bereits Tools von Drittanbietern zu eben solchen Zwecken eingeführt. Ein Blick in die Gartner Magic Quadrants zeigt die großen Player hier: PowerBI, Tableau, Qlik etc. Ein modernes Data Warehouse muss daher eine Offenheit zur Integration solcher Analytics-Lösungen mitbringen.
In diesem Beitrag schauen wir uns an, warum BW/4HANA in dieser Hinsicht dem klassischen BW weit überlegen ist, und welche Anbindungsmöglichkeiten, und damit einhergehenden architekturellen Abwägungen, es gibt.
Weitere Informationen
Lesen Sie dazu auch: Vorteile durch BW/4 HANA
Hinweis
In diesem Beitrag soll der Fokus auf die funktionalen Aspekte der Anbindung von Tableau an ein SAP BW/4HANASAP BW/4HANA ist die aktuelle Data Warehouse Lösung basierend auf… Mehr gelegt werden.
Das Thema User- und Berechtigungsmanagement ist jedoch in einer solchen heterogenen Umgebung nicht zu vernachlässigen, will man nicht Rollen und Berechtigungen an drei Stellen (BW, HANA-Datenbank, Frontend) verwalten. Aufgrund der Komplexität und individuellen Ausgestaltung bleibt diese Betrachtung hier jedoch außen vor.
3rd-Party-Analytics
In der hybriden Modellierung können die Informationen des Data Warehouse grundsätzlich auf zwei verschiedene Arten an das Analytics-Frontend bereitgestellt werden:
- BW-seitig durch die Objekte und Schnittstellen des SAP BW. Dies sind insbesondere Composite Provider als (virtuelle) Data Marts, und BW Queries als Zugriffsschicht.
- HANA-seitig durch die Objekte und Schnittstellen der HANA Plattform. Dies sind insbesondere Calculation Views als virtuelle Data Marts und auch Zugriffsschicht.
Die Modellierung der Analytics-Bereitstellung auf HANA-Seite fällt damit schon mal schlanker aus als auf BW-Seite, da neben dem CalcView kein weiteres Objekt erforderlich ist.
Darüber hinaus ist je nach Szenario zu unterscheiden, ob die Bereitstellung an ein SAP Analytics Frontend, oder an ein 3rd-Party Analytics Frontend erfolgt:
Aus diesem Vergleich wird deutlich, dass die Bereitstellung an 3rd-Party Frontends über einen HANA SQL-Ansatz wesentlich besser unterstützt wird als durch einen BW-Ansatz. Grundsätzlich besteht auf Seite HANA kein wesentlicher Unterschied mehr zwischen einem SAP Analytics-Frontend, und einem 3rd-Party Frontend.
Eine gemischte (hybride) Architektur und Modellierung bietet sich daher an, wenn ein BW/4HANA Data Warehouse hinsichtlich Offenheit auch durch solche non-SAP-Frontends bestmöglich integrieren möchte.
Verbindung mit einem 3rd-Party-Frontend am Beispiel von Tableau
Tableau als 3rd-Party Analytics-Werkzeug unterteilt sich in mehrere Komponenten:
- Tableau Desktop – Frontend zur Entwicklung von Dashboards
- Tableau Server – Plattform für die Bereitstellung von Dashboards und Zugriff auf die darunter liegenden Datenquellen
- Tableau Data Prep – Ergänzung zum Desktop, ermöglicht über die Erstellung von Dashboards und Berichten hinaus auch eine Datenaufbereitung
Tableau kann sich, via Tableau Server, auf 2 verschiedene Arten mit dem Data Warehouse, hier SAP BW/4HANA, verbinden:
- Live Verbindung – Die Daten werden aus dem BW geholt, sobald der entsprechende Tableau-Bericht durch einen Anwender geöffnet (ausgeführt) wird. Jede Navigation innerhalb des Berichts führt zu einer neuen Abfrage an das BW. Diese Funktionsweise entspricht der, wie SAP-Frontends (Analysis Office, Business Objects) typischerweise arbeiten.
- Import Verbindung – Es werden periodische Snapshots der Daten geholt und auf dem Tableau Server persistiert. Der Bericht zeigt daher keine Live-Daten. Dafür ist i.d.R. die Performance besser. Die persistierte Datenmenge auf dem Tableau Server kann jedoch leicht sehr groß werden. Vor Einsatz der Importverbindung sollten lizenzrechtliche Rahmenbedingungen der BW/4 HANA Runtime Lizenz geprüft werden.
Zur Verbindung gegen das SAP BW/4HANA unterstützt Tableau die folgenden Verbindungsmöglichkeiten:
- SAP BW: als 3rd-Party Analytics Frontend steht nur die Möglichkeit zur Verfügung, via MDX sowohl BW Queries als auch optional BW InfoproviderInfoProvider sind Objekte, auf denen ein Reporting (z.B. Queries) ausgeführt werden kann…. Mehr direkt zu konsumieren.
- SAP HANA: Tableau unterstützt HANA-Verbindungen nur via generischer SQL/ODBC Schnittstelle. Damit können Calculation Views, SQL Views und auch Tabellen konsumiert werden.
Einschränkungen in der Verbindung von Tableau zu SAP BW (MDX)
Nicht alle Funktionalitäten des SAP BW stehen über die MDX-Verbindung in Tableau zur Verfügung. Darüber hinaus ist der Funktionsumfang auch davon abhängig, ob Tableau mit einer Live Verbindung oder einer Import Verbindung gegen das SAP BW verbunden wird. Die folgenden Funktionen sind u.U. eingeschränkt:
Einschränkungen in der Verbindung von Tableau zu SAP HANA (SQL/ODBC)
Tableau unterstützt SAP HANA mittels generischem ODBC-Treiber, und fragt die Daten grundsätzliche relational via SQL ab. Einige Funktionen der HANA stehen darüber jedoch nicht oder nur eingeschränkt zur Verfügung:
Wesentliche Unterschiede
- Tableau unterstützt bis Version 2019.3 Hierarchien derzeit nur via Live-Verbindung zu BW-Queries. HANA-seitige Hierarchien werden nicht unterstützt. Ab Version 2019.3 werden auch HANA-seitig definierte Hierarchien unterstützt.
- Die Performance auf Basis von BW Queries ist deutlich schlechter als die der SQL-Verbindung gegen HANA. Gründe sind die ineffiziente MDX-Schnittstelle des BW, sowie das BW-Queries seitens des BW OLAP-Prozessors deutlich langsamer sind als in-database Berechnungen mittels HANA Calculation Views.
- Die Limitationen in Anzahl Ergebniszeilen, Größe der Ergebnismenge und Detailgrad des Aufrisses sind bei BW Queries deutlich enger als HANA-seitig via SQL-Verbindung.
Architektur und Modellierung im Data Warehouse
Für eine optimale Architektur zur Bereitstellung von Informationen an ein 3rd-Party Analytics Frontend wie Tableau müssen einige Fragestellungen beantwortet werden, um festlegen zu können, welche Modellierung in welchen Fällen erforderlich ist:
- Welche Frontends müssen unterstützt werden
- Ist Tableau das einzige Frontend, oder müssen noch weitere Frontends unterstützt werden?
- Gibt es zwischen den eingesetzten Frontends eine Schnittmenge an Funktionalität, die mit einer Bereitstellung (bspw. HANA CalcViews) abgedeckt werden kann?
- Hierarchien im Reporting
- Basiert das Reporting auf unverzichtbaren Hierarchien, die auf jeden Fall verfügbar gemacht werden müssen?
Ja → BW-Queries bieten die einfachste Methode, Hierarchien zu verarbeiten und im Reporting zur Verfügung zu stellen.
Nein/unkritisch → Hierarchien können auch in HANA im Calculation View definiert werden (ab Tableau 2019.3 nutzbar), oder auch Tableau-seitig im Bericht selbst definiert werden.
- Basiert das Reporting auf unverzichtbaren Hierarchien, die auf jeden Fall verfügbar gemacht werden müssen?
- Real-time Datenanzeige im Bericht
- Muss der Bericht Real-Time („live“) Daten anzeigen?
Hierbei ist eher zu entscheiden, ob Tableau-seitig eine Live-Verbindung oder eine Import-Verbindung zur Anwendung kommt.
- Muss der Bericht Real-Time („live“) Daten anzeigen?
- Performance
- Granularität und Umfang der Ergebnismengen – HANA SQL-Verbindungen sind dabei BW MDX-Verbindungen deutlich überlegen.
Die optimale Möglichkeit, aus einem BW/4HANA Data Warehouse Informationen an Tableau als Analytics-Frontends bereitzustellen führt damit über die gemischte Modellierung – BW-Datenmodelle und Virtuelle Data Marts (Composite Provider), welche HANA Calculation Views (generiert auf Basis des BW Composite Providers) zur direkten Konsumierung via SQL-Verbindung bereitstellen.
Vorteile dieses Architekturansatzes sind dabei:
- Nutzung der BW-Modellierung mit allen Vorteilen und Vereinfachungen (InfoObjectsInfoObjects sind betriebswirtschaftliche Auswertungsobjekte, welche sich in Merkmale, Kennzahlen, Einheiten,…, virtuelle Datenmodelle, Flexible Dynamic Star Schema)
- Bereitstellung der (virtuellen) Data Marts über Calculation Views, die via HANA SQL-Verbindung von jedem 3rd-Party Frontend mittels SQL/ODBC genutzt werden können
- Als „Ausweg“, bspw für die bessere Unterstützung von Hierarchien, besteht noch die Möglichkeit, auf Basis desselben virtuellen Data Marts (Composite Provider) auch die Informationen als BW Query bereitzustellen.
HANA Calculation View sowie BW QUery sind dabei nur verschiedene Zugriffs- und Konsumierungsschnittstellen auf denselben Data MartEin Data Mart umfasst einen Teilausschnitt eines Data Warehouses und… Mehr, ohne hierbei Redundanzen zu schaffen.
Architekturüberblick mit BW- und HANA-seitiger Bereitstellung:
In den HANA Calculation Views sind dabei noch folgenden Anpassungen vorzunehmen, um diese für die Tableau-Konsumierung funktional gleichwertig zu den BW-Queries zu gestalten:
1. Zuordnung von Label-Spalten, um Schlüsselwerte dynamisch in der Anzeige zwischen „Schlüssel“, „Text“ sowie „Text und Schlüssel“ zu gestalten (wie man es auch von BW-Queries gewohnt ist).
Weitere Informationen
Siehe dazu auch unseren Beitrag: Zugriff von Frontends auf SAP BW Daten – Im Fokus Stammdatentexte
2. Zuordnung von Semantiken zu Datenfeldern: Kennzahlen, Einheiten, Datumssemantik für Datumsfelder.
Bei der Modellierung mit InfoObjects ist dies im generierten CalcView des Composite Providers schon korrekt abgebildet.
Bei der Modellierung auf Feld-Basis und Nutzung des Dynamic Flexible Star Schemas mit Assoziation von Stammdaten ist dies ggf. jedoch manuell vorzunehmen, da der Composite Provider diese Semantiken gar nicht kennt und somit auch nicht in den HANA CalcView generieren konnte.
Weitere Informationen
Siehe dazu auch unser Beitrag: Flexible Stammdatenassoziationen mit BW/4HANA – Möglichkeiten und Grenzen
3. Bereitstellung von Hierarchien durch Definition im HANA CalcView.
Ab Tableau 2019.3 können die im CalcView definierten Hierarchien durch Tableau genutzt werden, ohne dass Tableau-seitig eine erneute Definition erforderlich ist.
Dazu muss die Hierarchie jedoch im HANA CalcView entsprechend definiert werden:
Da solche Anpassungen im systemgenerierten CalcView nicht sinnvoll sind (sie würden bei erneuter Generierung überschrieben werden), ist architekturell jeweils ein eigener Reporting-CalcView auf Basis des genierten DataMart CalcViews zu definieren.
Durch Zuordnung der Reporting CalcViews zu individuellen HANA Packages kann damit außerdem das Berechtigungsmanagement unterstützt werden (alle systemgenerierten CalcView liegen im gleichen Package, in der Regel system-local.bw.bw2hana, während selbstdefinierte CalcViews zu beliebigen Packages zugeordnet werden können, auf welche dann über Berechtigungsrollen Zugriff erteilt werden kann.
Fazit
3rd-Party Analytics Frontends wie Tableau haben ihre Stärken im klassischen SQL-Bereich, und können daher hervorragend mit SAP HANA als Datenbank zusammenarbeiten. Im Hinblick auf die verfügbare Funktionalität gibt es wenig bis keine Unterschiede darin, ob die HANA Calculation Views durch SAP Frontends (wie Analysis for Office, oder auch SACDie SAP Analytics Cloud (SAC) ist die Cloud-basierte Frontend-Lösung der SAP, welche die… Mehr), oder durch 3rd-Party Frontends wie Tableau konsumiert werden.
Die BW-seitige Konsumierung von SAP-spezifischen Konstrukten, insbesondere BW-Queries, steht jedoch nur SAP-Frontends vollumfänglich und effizient zur Verfügung. Sämtliche 3rd-Party Analytics Lösungen tun sich hier schwer.
Für eine flexible und offene Data Warehouse Architektur empfehlen wir daher unbedingt, die Vorteile der hybriden Architektur und Modellierung mit SAP BW/4HANA zu nutzen. Durch die Architektur mit virtuellen Data Marts, welche die gleichen Daten redundanzfrei sowohl BW-seitig (via Queries) als auch HANA-seitig (via Calculation Views) zur Konsumierung bereitstellen, können auch Landschaften mit heterogenen Frontends optimal unterstützt werden.
Mit dieser Fähigkeit, eine solche moderne Architektur umzusetzen, hat SAP BW/4HANA einen großen Schritt in Richtung einer flexiblen und offenen Data Warehouse Lösung gemacht.
Unsere Leistungen
Wir unterstützen Sie in Ihren Herausforderungen zu einer modernen Architektur gerne! Lesen Sie auch unser Positionspapier: ISR LSA++ Architektur @ BW/4 HANA
KONTAKT
Christopher Kampmann
Senior Manager
SAP Information Management
