Case Study: SAP HANA als Re­porting Plat­form

Die schnellste Art des Zu­griffs er­folgte über JDBC/ODBC Zu­griffe. Da der Kunde die SAP HANA bereits als Um­gebung für native HANA Ent­wicklung nutzte und so bereits ein User­management für die HANA imple­men­tiert hatte, wurde dieser Ansatz gewählt. Die beim Kunden ein­ge­setzten Frontend­tools unter­stützten alle diese Lösung.

Normaler­weise ist in solchen Fällen zu­sätzlich ein ABAP System mit installiert. Hier jedoch handelte es sich um ein rein HANA Nativ gen­utztes System, welches bereits an die User Inter­face Schnitt­stelle des Unter­nehmens ange­schlossen war. Zudem lief auf der Daten­bank eine HANA Native An­wendung. Daher war sowohl das Wissen als auch die Technik bereits vor­handen.

Mit Privi­legien auf unter­schiedliche Daten­gruppen wurde der Daten­raum je Nutzer­gruppe aufge­teilt und zu­gänglich gemacht. Dabei wurden sowohl all­gemeine Rechte auf Tabellen als auch ana­lytische Privilegien zur Redu­zierung der bereit­gestellten Daten auf Zeilen­ebene vergeben.

Um die Daten aus den Zu­liefer­systemen mit denen aus der HANA Nativen App zu ver­binden, wurden  Calculation Views benutzt. Zudem wurde auch dort für die Zugriff­steuerung mit Analytischen Privilegien ge­arbeitet. Eine weitere Nutzung der Calculation Views war der Aufbau von immer wieder ver­wendeten Daten­räumen, die für Ab­fragen benutzt wurden. Durch die Calculation Views und deren Input Parameter, konnte die Be­rechnung des Er­gebnisses auf der HANA durch­ge­führt werden und musste nicht durch die Front­end­tools erfolgen. So konnte eine deutliche Performance­steigerung bei der Berichts­aktualisierung er­zielt werden.

Von den unter­schied­lichen Fach­bereichen und den ver­wendeten Tools konnte unsere Schnitt­stelle gleicher­maßen ver­wendet werden. Zum Bei­spiel Microsofts Power BI, R mit Shiny Apps sowie alle anderen Tools mit ODBC/JDBC Verbindungs­möglich­keit.

Die Größe der Re­porting HANA mit 6TB reinem InMemory Speicher plus die zu­sätzlichen Cold Storages mit 4TB haben es er­möglicht, in der Pilot­phase auf größere Ein­griffe in das Work­load­mana­gement zu ver­zichten. Trotzdem sind Limits bei der Ab­frage­größe (hier 256GB) ges­etzt worden. Das System wird laufend über­wacht. Sollte eine steigende Aus­lastung fest­gestellt werden, werden die Workload Klassen aktiviert und somit auch die System­stabilität weiter­hin sicher­ge­stellt.