Latenz ist Herausforderung bei Real-time Data Provisioning

0
Posted 24. Oktober 2016 by Redaktion IT-Onlinemagazin in IT-Leiter

Mit SAP HANA kann man Geschäftsdaten in Echtzeit auswerten. Die Herausforderung besteht jedoch darin, die auszuwertenden Daten in der notwendigen Geschwindigkeit bereitzustellen. Welche Ansätze SAP dazu anbietet, beschreibt Christoph Schwer in einem Gastbeitrag.

 

 

 

SAP HANA ist seit einigen Jahren für Endkunden verfügbar und gewinnt zunehmend an Marktanteil. Neben dem Einsatz als SAP Business Suite on HANA findet die In-Memory-Datenbank aktuell vor allem im Analytics-Umfeld sehr regen Zuspruch. Viele Kunden von SAP Business Warehouse (BW) beschäftigen sich seit längerem mit dem Thema „Realtime-Reporting“. Durch die Datenhaltung im Speicher erfolgt die Auswertung von großen Datenmengen nahezu in Echtzeit. Gerade in diesem Anwendungsbereich nutzt SAP HANA die In-Memory-Technologie sehr effektiv. Allerdings stellt meist gerade die Bereitstellung von großen Datenmengen innerhalb kurzer Zeit oder gar in Echtzeit Administratoren und Systemarchitekten vor großen Herausforderungen. Denn nur was für SAP HANA verfügbar ist, kann in Windeseile ausgewertet werden.

 

Bewährtes auf den Prüfstand stellen

Ausgehend von der aktuellen Marktsituation verwenden viele Kunden seit Jahren SAP BW mit SAP Standard, entweder mit oder ohne Customizing oder sogar eigens entwickelten Extraktoren, um Daten aus SAP-Anwendungen oder externen Datenquellen in einem BW-Szenario zur Verfügung zu stellen. Nicht selten sind Datenflüsse und -modelle über lange Zeiträume gewachsen und wurden bereits verfestigt. Immer häufiger greifen Kunden auch auf die Business Intelligence Reporting Suite zurück, um Daten mittels Dashboards, Web-Intelligence oder eines der neuen Frontends, wie DesignStudio, endnutzerfreundlich aufzubereiten. Durch die Einführung der neuen Layered Scalable Architecture (LSA) mit SAP BW 7.4 on HANA und die damit verbundenen Änderungen sowie erweiterten Möglichkeiten, besteht nun die Herausforderung, historisch Gewachsenes und somit auch Bewährtes in die neue Technologie zu überführen.

Der klassische Analytics-Datenfluss findet sich in vielen Unternehmen weltweit und hat sich über Jahre bewährt. Selten ist dieser Ansatz jedoch mit dem Echtzeitgedanken zu vereinbaren. Bereits in der Zeit vor SAP HANA gab es erste Optionen, historische Daten mit zeitaktuellen zu kombinieren, um Daten live aus einem Quellsystem zur Laufzeit von BW-Queries abzufragen. Real-time-fähige InfoCubes und -DTPs, welche mit SAP BW 7.3 eingeführt wurden, waren ein erster Ansatz. Dies war jedoch selten mit einer zufriedenstellenden Performance verbunden. Deshalb gilt es, bestehende Prozesse auf den Prüfstand zu stellen, um Optimierungspotentiale zu identifizieren. Diese werden erfahrungsgemäß hauptsächlich im Staging mittels LSA und der damit verbundenen Datentransformation gefunden. Auch wenn SAP mit den neuen Modellierungsobjekten in SAP BW 7.4 versucht, das Staging zu vereinfachen und SAP HANA durch die Anwendung des In-Memory-Prinzips schon vieles Etablierte optimiert, so bleibt doch ein nicht unerheblicher Faktor an Zeit für die Extraktion und Aufbereitung von Daten, welcher mit anderen Ansätzen durchaus gemindert oder gar vermieden werden kann.

 

Erste Ansätze bietet SAP HANA selbst

Eines dieser neuen Modellierungsobjekte ist der Open ODS View. Dieser nutzt eine Funktionalität, welche ab Support Package Stack 6 für SAP HANA verfügbar ist: der sogenannte SAP HANA Smart Data Access ermöglicht den Zugriff auf externe Datenquellen in Echtzeit. In SAP BW 7.4 Szenarien können damit Daten aus unterschiedlichen Enterprise Data Warehouse-Landschaften zusammengeführt werden. SAP HANA Smart Data Access ermöglicht dabei den Zugriff auf externe Datenquellen ohne (oder auf Wunsch auch mit) Persistenz in der SAP HANA-Datenbank. Unterstützt werden unter anderem Quellen wie Teradata und Hadoop oder SAP- interne Lösungen wie Sybase ASE, Sybase IQ und natürlich auch SAP HANA selbst. In diesem Fall behandelt SAP HANA die Daten als wären sie lokale Tabellen in der Datenbank selbst. Eine automatische Datentypkonvertierung ermöglicht das Mappen von Datentypen der über SAP HANA Smart Data Access angeschlossenen Datenbanken auf SAP HANA Datentypen. Die Voraussetzungen für den Einsatz von SAP HANA Smart Data Access erscheinen dabei denkbar simpel. Benötigt werden die ODBC-Treiber der jeweiligen Quelldatenbank (SAP Hinweis 1868702) und die Quelle muss als Remote Source deklariert werden, wie im SAP HANA Admin Guide beschrieben.

Der Vorteil ist klar: Daten werden ähnlich den Real-time InfoProvidern zum Abfragezeitpunkt live in der Quelle abgefragt und auf Wunsch in die HANA-Datenbank repliziert. Diesen Vorteil bezahlt man jedoch mit dem Verzicht auf Datentransformationen, zumindest im Standard. Wenn das Businessszenario das Konsumieren von Rohdaten ermöglicht, kann Smart Data Access passende Szenarien merklich beschleunigen.

 

Es muss nicht immer SAP Business Warehouse sein

Wer nicht komplett auf Transformationen verzichten kann und Businessdaten in der SAP HANA dennoch in Sekundenschnelle benötigt, für den könnte der Einsatz des SAP LT Replication Servers (SLT) eine Lösung bieten. Basierend auf der SAP NetWeaver Technologie kann dieser ohne großen technischen Aufwand in ein bestehendes SAP NetWeaver basierendes System installiert werden. Diese Funktionalität implementiert man über die Installation des DMIS Add-On. Besitzt man eine entsprechende Lizenz, ist eine Real-time Replikation von Daten in SAP HANA verhältnismäßig einfach einzurichten: über die Konsolen wählt man Quelle, Ziel und natürlich die zu replizierenden Tabellen aus und den Rest erledigt der SLT. Basierend auf Datenbanktriggern werden alle Änderungen mitgeloggt und umgehend mittels RFC oder DB Verbindung in das Zielsystem repliziert. Als Quelle dient dabei neben SAP ABAP-Systemen auch jegliche von SAP NetWeaver unterstützte Datenbank. Für den geübten Anwender ist es dabei auch möglich, einfache Transformationsregeln eventbasiert auf Spalten oder Feldern zu definieren und anzuwenden.

Für komplexere Transformationen mittels ABAP-Coding wird allerdings ein separater Entwicklerschlüssel benötigt. Abhängig von der Komplexität lässt sich eine nicht unwesentliche Anzahl an SAP BW-Extraktoren auf diese Weise bereits nachbilden. Der SLT ermöglicht es somit, Daten in Echtzeit (eine bis zwei Sekunden Latenz) in SAP HANA zu replizieren und sogar einfache Business-Transformationslogik abzubilden. Damit ist es möglich, Daten für Reporting-Anwendungen, wie zum Beispiel SAP BusinessObjects, direkt in SAP HANA bereitzustellen. Diese Technologie nutzen bereits über 4.500 deutsche und internationale SAP-Kunden.

Am Beispiel eines großen deutschen Energieversorgers konnte durch den Einsatz von SLT eine deutliche Beschleunigung und Verschlankung im Prozess der Datenbereitstellung erreicht werden. Da nur eine eingeschränkte Zahl von BW-Extraktoren eine Delta-Fähigkeit besitzen, konnte durch die Ablösung von SAP BW-Extraktoren durch SLT das tägliche Datenvolumen um fast 95 Prozent reduziert werde. Ein nicht unerheblicher Kosten- und Zeitfaktor.

Ein weiteres internationales Kundenbeispiel aus der Energieversorgerbranche zeigt die Leistungsfähigkeit dieser Technologie. Der SAP LT Replication Server war in diesem Fall in der Lage, mehr als 20 Millionen Änderungen pro Stunde in einer angeschlossenen SAP HANA zu replizieren. In einem von der SAP durchgeführten Benchmark wurde sogar ein Datendurchsatz von fast 300 Millionen Datensätzen pro Stunde erreicht. Diese beeindruckenden Werte zeigen, dass der SAP LT Replication Server eine wahre Option im Bereich Real-time Data Provisioning darstellt. Doch auch dieser Technologie sind Grenzen gesetzt.

 

SAP Data Services – ein ETL Allrounder

Wer selbst mit den erweiterten Möglichkeiten des SAP LT Replikation Servers an seine Grenzen stößt, dem kann mit SAP Data Services weitergeholfen werden. Auch das auf BusinessObjekts Komponenten basierte Produkt ermöglicht es, Daten in Echtzeit von den verschiedensten Quellen in SAP HANA zu transferieren. Im Vergleich zum LT Replication Server erweitert sich so das Quellportfolio um die gängigen Big Data Lösungen, wie etwa Teradata oder Hadoop. Als separate Installation und rein Java-basiert bietet Data Services eine große Vielfalt an Transformationsmöglichkeiten. Darüber hinaus gibt es die Möglichkeit zusätzliche Funktionen, wie etwa Data Cleansing (z.B. zur Adressenbereinigung), über entsprechende Lizenzen zu nutzen.

Zwar sind den Transformationsmöglichkeiten kaum Grenzen gesetzt, nichtsdestotrotz sollte man sich der Konsequenzen dieser Modifikationen bewusst sein. Je komplexer die Modifikation, umso zeit- und ressourcenintensiver läuft die Verarbeitung ab. Das zeigen auch die Erfahrungen mit Kunden, welche SAP Data Services im Einsatz haben. Im Vergleich mit einem klassischen SAP BW ist eine Optimierung der Datenbereitstellung möglich. Speziell in Anwendungsfällen, für welche in einem SAP BW Umfeld Flatfile oder DB Connect bzw. UD Connect verwendet wurden, spielt Data Services seine Möglichkeiten voll aus und zeigte im Kundenbeispiel eines Versicherers aus Großbritannien deutliche Performancegewinne im Vergleich zur Flatfile Prozessierung in SAP BW.

 

Geschäftsszenario definiert optimale Lösung

Was alle hier aufgeführten Optionen gemein haben, ist eine sehr hohe Abhängigkeit von Hardwarekomponenten. Speziell die Leistungsfähigkeit von CPU und Netzwerk kann einen großen Einfluss auf die Performance haben. Jede der vorgestellten Varianten hat gewisse Vor- und Nachteile, entsprechend der einzelnen Geschäftsszenarien mehr oder weniger vorteilhaft und zutreffend. So kann es in bestimmten Konstellationen von Nutzen sein, verschiedene Optionen miteinander zu kombinieren.

Der SAP LT Replication Server zum Beispiel bietet die Möglichkeit, als Data Federator für das SAP BW Operational Data Provisioning (ODP) Framework zu fungieren. Somit ist es möglich, SAP BW-Extraktoren, welche für ODP geeignet sind, real-time-fähig zu machen. Gerade eine Kombination aus SLT und ODP Framework findet bereits bei einigen Kunden großen Anklang. Aus heutiger Sicht ist der Nachteil dieser Lösung allerdings der fehlende Support für ADSOs, welche derzeit noch nicht per Real-time DTP beladen werden können.

Um die optimale Lösung für den Einzelfall zu finden, bedarf es in jedem Fall einer genauen Analyse der Anforderungen sowie der detaillierten Möglichkeiten.

 

 

 

SchwerZum Autor

 

Christoph Schwer arbeitet als Senior Support Engineer bei der BIT.Group GmbH, einem mittelständischen IT-Dienstleister mit Hauptsitz in Bautzen und Niederlassungen in Dresden, Hannover und Shanghai. Mit mehr als fünf Jahren Erfahrung im SAP-Umfeld und insbesondere im Business Warehouse Management, arbeitet er als einer von mehreren Experten an Kundenprojekten zu Design und Planung von Real-time Reporting Konzepten.

Wir danken Ihnen, wenn Sie diesen Artikel jetzt weiterempfehlen:


Anzeige

Newsletter-Abo


Abonnieren Sie jetzt unseren IT-Onlinemagazin Newsletter.   Etwa zweimal pro Monat werden Sie kompakt und unterhaltsam mit wichtigen Nachrichten aus der SAP- und ERP-Community versorgt.

Anzeige