30.08.2015

Alles SAP HANA® - oder was?

In letzter Zeit vergeht fast keine Woche, in der wir nicht gefragt werden, ob unsere Datenextraktionssoftware dab:Exporter 3.0 mit SAP HANA® kompatibel ist.

Natürlich müssen und werden wir uns als Hersteller einer SAP®-spezifischen Datenextraktionslösung mit dem Thema auseinandersetzen und tun dies bereits auch. Allerdings gilt auch hier erstmal Ruhe bewahren und nicht gleich in hektisches Zappeln oder Schockstarre zu verfallen, sobald man die 4 Buchstaben HANA irgendwo liest oder hört.

Was ist SAP HANA® denn ei­gent­lich?

SAP HANA® (High Performance Analytic Appliance) ist eine In-Memory Datenbankplattform, die grundsätzlich mal völlig losgelöst von den SAP® Business Suite Applikationen (ERP, CRM, SRM usw.) existiert. Dabei ist SAP HANA® als Hybridspeicher in der Lage die Daten sowohl spalten- als auch zeilenbasiert abzuspeichern und zu verarbeiten. Auch die Dauerhaftigkeit der Daten wird mittels einer Persistenzschicht natürlich sichergestellt. Dies ist vor allem im Hinblick darauf wichtig, dass SAP HANA® strategisch ja auch als die Datenbank unter den transaktionalen SAP® Applikationen platziert werden soll und nicht nur als SAP® BW Ersatz bzw. Auswertungsplattform eingesetzt werden soll.

Der Computerwoche-Artikel „In-Memory-Konzepte im Vergleich“ von Susanne Franke aus April 2014 gibt einen ganz guten Überblick dazu ab.

Die Aus­wir­kun­gen kurz­fris­tig

Was das für die Welt der Big-Data-Analysen bedeutet, mag ich in diesem Moment noch nicht völlig beurteilen, stelle aber mal zwei Gedanken dazu in den Raum:

  1. Wenn man eine SAP HANA® Instanz als reine Analyseplattform zur Verfügung hat, steht man vor der Herausforderung, diese auch mit den Daten aus den transaktionalen Systemen zu füllen. Ob dies für Revisionszwecke immer zur vollen Zufriedenheit stattfinden wird, ist schwer zu sagen. So findet man ja auch heutzutage relativ selten die elementar wichtigen Informationen wie die SAP®-Änderungsbelege in den eigentlich zu Auswertungszwecken gedachten BW-Systemen. SAP HANA® als Analyseplattform für Revisionszwecke, wird also nur dann funktionieren, wenn ALLE notwendigen Datenbestände befüllt werden und diese auch in einer umfangreichen Historie dort vorhanden sind. Inwiefern der In-Memory-Effekt bei diesen Datenmengen dann noch zu Tragen kommt, bleibt abzuwarten.
  2. Wenn SAP HANA® als transaktionale Datenbank direkt unter den SAP® Business Suite Applikationen eingesetzt wird, wird das wohl hauptsächlich aus dem Grund geschehen, dass die Prozesse die dort abgebildet werden höchst zeitkritisch sind, extrem kurze Reaktionszeiten verlangen oder derzeitige Auswertungen und Aufbereitungen, die in den transaktionalen Systemen notwendig sind, signifikant beschleunigt werden sollen. In diesem Szenario stellt sich mir ein Anliegen der Revision oder anderer Geschäftseinheiten als recht „unerwünscht“ dar, indem wiederum große Datenmengen inkl. Änderungsbelege auf genau dieser kritischen Plattform direkt ausgewertet werden sollen. Das Thema mit der heiligen Kuh wird sich so meiner Meinung nach eher noch verstärken.

Wenn ich also ein kurzes Zwischenfazit ziehen darf: der Bedarf von interner Revision, Wirtschaftsprüfung und anderen Fachbereichen (z.B. Buchhaltung für Doppelzahlungsanalysen) an einer Datenextraktionssoftware und einem „eigenen“ Analysetool wird kurzfristig nicht weniger werden oder gar verschwinden. Aus diesem Grund ist es für uns wichtig, Gewissheit zu haben, dass der dab:Exporter auch mit SAP® Applikationen funktioniert, die eine SAP HANA® als Datenbank einsetzen.

Der dab:Ex­por­ter 3 und SAP HANA®

Wenn wir uns die Grafik „Zukünftige Annäherung“ im Computerwoche-Artikel ansehen, die meiner Meinung nach passend eine künftige Architektur widerspiegelt, dann stellen wir fest, dass SAP NetWeaver® als die zentrale Kommunikationsschicht zwischen Applikation und Datenbank bestehen bleibt – zumindest solange bis SAP® ERP komplett neu geschrieben wird (wann immer das sein wird).

Aus diesem Grund war ich immer relativ gelassen, was die künftige Kommunikation mit SAP®-Systemen betrifft, bei denen eine SAP HANA® unter der Motorhaube steckt. Und in der Tat haben wir bei ersten Kunden bereits erfolgreich zu SAP®-Systemen mit einer SAP HANA® verbunden und auch Daten aus diesen Systemen extrahiert. Die Extraktionsgeschwindigkeit war dabei zwar nicht „rasend“ schnell, aber doch signifikant schneller (gefühlt) als bei herkömmlichen Datenbanken.

Die Tabelle soll die Extraktionsgeschwindigkeiten verdeutlichen:

 

Tabelle
Anzahl Felder
Datensätze
Extraktionsdauer in s
CRMD_ORDERADM_H24320.04364
CRMD_ORDERADM_I27 1.714.228 349
BBP_PDBEI38 2.359.252 466
BBP_PDIGP146 2.430.9971052

Tabelle 1 - Downloadzeiten mit SAP HANA®

 

Obwohl Performances und Antwortzeiten von SAP® Systemen natürlich immer stark von der Situation abhängig sind, kann man meiner Meinung nach durchaus erkennen, dass die Extraktionszeiten ganz ordentlich sind. Mehr als 300.000 Datensätze in einer Minute trifft man als Messwert nicht bei vielen Systemen an und ich würde dies durchaus der SAP HANA® zuschreiben.

Performance-technisch werden wir das Thema sicher weiter beobachten und u.U. mal einen kompletten Benchmark posten, sobald wir belastende Zahlen und vor allem Nicht-SAP HANA®-Vergleichswerte haben.

Alles in allem sei allen Benutzern und Interessenten des dab:Exporter die gute Nachricht mit auf dem Weg gegeben: JA – wir können auch SAP HANA®!

Haben Sie noch Fragen oder Kommentare? Dann schreiben Sie uns doch einfach an info@dab-gmbh.de.


Kommentare (0)
Sei der erste, der diesen Blog-Beitrag kommentiert.
Blog Anmeldung

Sie sind nicht angemeldet. Bitte melden Sie sich an um diesen Blogbeitrag zu kommentieren.

anmelden