Live-Reporting auf SAP HANA für unterschiedliche Reporting Tools ermöglichen
Unser Kunde aus dem Finanzbereich wollte den Ad Hoc Berichtsanforderungen der Fachbereiche gerecht werden. Ziel war es, neben dem etablierten Standardreporting flexible Möglichkeiten für schnelle Analysen schaffen.
Das Setting
Der Kunde hatte mehrere Zuliefersysteme an eine SAP HANA angeschlossen. Diese wiederum gibt ihre Daten in ein Data Warehouse weiter. Aufgrund der Speichergröße (6TB), der angebundenen datenliefernden Systeme und der Performance sollte die SAP HANA als Reporting Platform für diese Analysen verwendet werden.
Herausforderung
Die Anforderung seitens des Kunden war die Implementierung einer generischen Schnittstelle dieser Reporting Platform, die von mehreren Tools verwendet werden konnte. Zusätzlich sollten über diese Schnittstelle nur die Objekte sichtbar sein, die für die zugreifende Person freigegeben waren.
Da viele Systeme an die Reporting Platform als Datenzulieferer angeschlossen waren, sollte die Schnittstelle auch für große Datenmengen und viele Abfragen optimiert werden. Und das unter optimaler Ausnutzung der Performance der HANA. Zuletzt musste sichergestellt werden, dass der Betrieb anderer, paralleler Anwendungen auf der HANA nicht beeinflusst wurde.
Lösung
Die schnellste Art des Zugriffs erfolgte über JDBC/ODBC Zugriffe. Da der Kunde die SAP HANA bereits als Umgebung für native HANA Entwicklung nutzte und so bereits ein Usermanagement für die HANA implementiert hatte, wurde dieser Ansatz gewählt. Die beim Kunden eingesetzten Frontendtools unterstützten alle diese Lösung.
Normalerweise ist in solchen Fällen zusätzlich ein ABAP System mit installiert. Hier jedoch handelte es sich um ein rein HANA Nativ genutztes System, welches bereits an die User Interface Schnittstelle des Unternehmens angeschlossen war. Zudem lief auf der Datenbank eine HANA Native Anwendung. Daher war sowohl das Wissen als auch die Technik bereits vorhanden.
Mit Privilegien auf unterschiedliche Datengruppen wurde der Datenraum je Nutzergruppe aufgeteilt und zugänglich gemacht. Dabei wurden sowohl allgemeine Rechte auf Tabellen als auch analytische Privilegien zur Reduzierung der bereitgestellten Daten auf Zeilenebene vergeben.
Um die Daten aus den Zuliefersystemen mit denen aus der HANA Nativen App zu verbinden, wurden Calculation Views benutzt. Zudem wurde auch dort für die Zugriffsteuerung mit Analytischen Privilegien gearbeitet. Eine weitere Nutzung der Calculation Views war der Aufbau von immer wieder verwendeten Datenräumen, die für Abfragen benutzt wurden. Durch die Calculation Views und deren Input Parameter, konnte die Berechnung des Ergebnisses auf der HANA durchgeführt werden und musste nicht durch die Frontendtools erfolgen. So konnte eine deutliche Performancesteigerung bei der Berichtsaktualisierung erzielt werden.
Von den unterschiedlichen Fachbereichen und den verwendeten Tools konnte unsere Schnittstelle gleichermaßen verwendet werden. Zum Beispiel Microsofts Power BI, R mit Shiny Apps sowie alle anderen Tools mit ODBC/JDBC Verbindungsmöglichkeit.
Die Größe der Reporting HANA mit 6TB reinem InMemory Speicher plus die zusätzlichen Cold Storages mit 4TB haben es ermöglicht, in der Pilotphase auf größere Eingriffe in das Workloadmanagement zu verzichten. Trotzdem sind Limits bei der Abfragegröße (hier 256GB) gesetzt worden. Das System wird laufend überwacht. Sollte eine steigende Auslastung festgestellt werden, werden die Workload Klassen aktiviert und somit auch die Systemstabilität weiterhin sichergestellt.
Alle Bilder auf dieser Seite © 2021. BIG.Cube GmbH. Alle Rechte vorbehalten.
Fazit
Durch unseren generischen Ansatz konnten alle Tools über die gleiche Schnittstelle Daten beziehen. Mit dem Aufbau der durch Calculation Views vorbereiteten Datenräume konnten über 90 Prozent der Anfragen schnell mit optimaler Ausnutzung der HANA verarbeitet werden. Zudem wurde durch die Verfügbarkeit des kompletten Datenhaushalts höchste Flexibilität für mögliche Abfragen geschaffen – ohne dass
die IT unterstützend tätig werden musste.
Verfasst von Daniel Fröhler
Beitrag teilen
Weitere spannende Themen aus unserem Newsroom
BIG.Cube ist ein Great Place to Work – Bayern und ITK
Die BIG.Cube wurde dieses Jahr von Great Place to Work...
Mehr lesenShortcuts für SAP BW in Eclipse
In diesem Blogbeitrag werden fünf einfache Shortcuts erläutert, mit denen...
Mehr lesenEisstockschießen mit der BIG.Cube
Die Mitarbeitenden der BIG.Cube waren gemeinsam nach der Arbeit Eisstockschießen....
Mehr lesen