SAP HANA Smart Data Integration und andere HANA Provisioning Tools im Überblick

(Last Updated On: 1. Juni 2017)

Es gibt mittlerweile eine Vielzahl von Integrationstechnologien, um Daten in Ihre SAP HANA Instanz zu bekommen.  Der Fachterminus für die Übertragung von Daten in eine SAP HANA Instanz ist „SAP HANA Data Provisioning“. Um mal kurz einen kleinen Fundus der verfügbaren Technologien aufzuzählen, wären da etwa die Data Services (DS), Smart Data Access (SDA), SAP HANA Direct Extractor Connection (DXC), der SAP LT Replication Server (SLT),  SAP Replication Server (SRS, vormals Sybase), SAP HANA System Replication, den HANA Cloud Connector u. v. m. In diesem Beitrag wollen wir uns explizit der SAP HANA Smart Data Integration (SDI)  widmen, können jedoch den Einstazzweck dieser Technologie nur festmachen, wenn wir uns zuvor mit dem aktuellen Datenreplikationsportfolio der SAP auseinandersetzen.

Welche Arten von Replikationstechnologien gibt es?

Bei der Replikation von Daten in eine SAP HANA Datenbank kategorisiert man die verfügbaren Replikationstechnologien folgendermaßen

• trigger-basierte Replikation wird beispielsweise vom SAP LT Replication Server verwendet. Die Replikationstechnologie installiert Trigger. Im Falle des LT Replication Server auf Datenbankebene, die beim Ausführen von bestimmten SQL Statements (INSERT INTO, UPDATE, DELETE) ausgeführt werden. Diese Trigger signalisieren dem LT Replication Server dann, dass sich etwas an der zu replizierenden Datenbanktabelle im Quellsystem geändert hat. Der LT Replication Server prüft dann sogenannte Logging Tabellen im Quellsystem auf die Änderungen und „holt“ sich dann vom Quellsystem nur das Delta zum aktuellen Datenbestand im Zielsystem. Das heißt trigger-basierte Technologie minimiert die zu übertragende Datenmenge vor dem Transport, was einer der Hauptvorteile der trigger-basierten Replikation ist. Dadurch eignet sich diese Art der Datenreplikation exzellent für Near-Real Time Data Replication, also die beinahe Echtzeitübertragung von Daten in ein Zielsystem.
• ETL-basierte Replikation wird eingesetzt, wenn die Daten aus dem Quellsystem vor der Übertragung in das Zielsystem (Ihre SAP HANA Instanz) in ein Zielformat konvertiert werden müssen, etwa weil sich die Anzahl der Attribute bzw. Tabellenspalten in der Zieltabelle ändert, oder der Datentyp einer Spalte. Auch wenn beispielsweise der LT Replication Server dazu in der Lage ist, simple Transformationen an Tabelleninhalten durchzuführen, bevor diese übertragen werden, sollte man lieber für diesen Anwendungszweck dediziert vorgesehene Technologien einsetzen. Häufig wird diese Art der Replikation eingesetzt, um Daten bestimmter Geschäftsperioden mehrerer Systeme zu Analysezwecken in eine HANA zu laden
• Extraktor-basierte Datenübertragung ist ziemlich straight-forward einfach die Extraktion von Daten und der anschließende Import der Datenmodelle in SAP HANA. Die von SAP vorgeschlagenen Technologien wie der DXC extrahiert die Daten dabei schon in einem für SAP HANA abgestimmten Zielformat. Dadurch reduziert sich der händische Transformationsprozess auf ein Minimum.

Wann nutze ich welche Übertragungstechnologie für SAP HANA?

Wenn Sie sich konkret die Frage stellen, wann Sie welche Integrations- oder Replikationstechnologie für SAP HANA verwenden sollen, ist dieses Kapitel vielleicht ein kurzer Wegweise für Sie. Konkret hat jede Integrationstechnologie eine gewisse Stärke, und somit ein Optimalszenario, in welchem es verwendet wird, so verwendet man etwa

• den LT Replication Server für trigger-basierte Echtzeit-Replikation von Tabelleninhalten (diese Replikation ist nicht objektorientiert). Durch die trigger-basierte Replikation wird das zu übertragende Datenvolumen schon im vornherein reduziert. Jedoch Vorsicht: Die Replikation des LT Replication Server ist nicht objektorientiert bzw. transaktionsorientiert.Das heißt wenn Sie etwa für eine „Purchase Order“ den Inhalt von vier verschiedenen Tabellen aus dem Quellsystem replizieren müssen, kann es sein, dass der Inhalt von 2 Tabellen zum Zeitpunkt X im Zielsystem angekommen ist, jedoch der Inhalt der anderen vier Tabellen noch nicht. Der LT Replication Server ist also nicht transaktionsorientiert, sondern überträgt in jedem Replikationszyklus immer nur den aktuellen Inhalt einer Tabelle. Sie haben hier somit keine Garantie auf objektorientierte Konsistenz im Zielsystem. Entweder leben Sie mit dieser Unschärfe im Zielsystem oder Sie nutzen eine objektorientierte Replikation für diese Art von Daten.Derzeit arbeitet die SAP an der Implementierung der objektorientierten Replikation für den LT Replication Server, jedoch noch für SAP Objekte. Für non-SAP Objekte müssen Sie derzeit eine andere Technologie bemühen oder eine eigene Anwendungslogik zwischen schalten.
• den HANA Cloud Connector zur einmaligen Stapel-Kopie von Datenbanktabellen in eine HANA Instanz in der Cloud. Selbstverständlich ist es möglich, Daten beispielsweise auch in Echtzeit über den LT Replication Server in eine HANA-Cloud-Instanz zu übertragen. Der HANA Cloud Connector ist im Endeffekt nur eine Alternative für die stapelweise Übertragung von Daten bei niedrigen Kosten (low TCO). Wenn Sie also Ihre Daten nicht in Echtzeit, sondern nur intervallweise in Ihrer Ziel-HANA benötigen, ist der HANA Cloud Connector die Technologie Ihrer Wahl.
• den SAP Replication Server nutzen Sie, im Gegensatz zum SAP LT Replication Server, wenn Sie transaktional konsistente Datenreplikation brauchen. Der SAP Replication Server stellt also, im Gegensatz zum SAP LT Replication Server, sicher, dass Änderungen einer Datenbank immer so repliziert werden, wie Sie innerhalb einer Datenbank-Transaktion geändert werden.Werden also innerhalb einer Datenbank-Transktion (im SQL-Statement alles, was bis zu einem „Commit“ passiert) Änderungen auf beispielsweise 5 miteinander durch Fremdschlüssel-Beziehungen verbundene Tabellen geschrieben werden, werden im SAP Replication Server alle diese 5 Tabellen gleichzeitig aktualisiert.Das bedeutet wiederum: Hier haben Sie im Gegensatz zum LT Replication Server etwa Ihre „Purchase Order“ immer konsistent zum Zeitpunkt X im Zielsystem. Der Nachteil hierbei ist, dass der SAP Replication Server hierfür jede Transaktion einzeln übertragen muss, ergo, dass der SAP Replication Server wesentlich mehr Daten über die Leitung schaufeln muss als der LT Replication Server, der immer nur der aktuellen Stand einer Tabelle repliziert, egal wie viel dazwischen transaktionsmäßig passiert ist.Ein weiterer Vorteil von transaktional orientierter Datenreplikation ist, dass Sie die Zieldatenbank genau so fein granular über Point in Time Recovery wiederherstellen können wie die Quelldatenbank. Das heißt wenn in der Quelldatenbank versehentlich ein Datensatz mit falschen Daten überschrieben wurde und sie den alten Datenstand dieses Datensatzes wiederherstellen müssen, können Sie einfach in der Zieldatenbank ein Point in Time Recovery auf den zuletzt konsistenten Stand durchführen und dann die Daten in die Quelldatenbank exportieren, um den gewünschten Stand wiederherzustellen. Das wäre mit einer per LT Replication Server replizierten Datenbank nicht möglich (oder nur mit Glück).
• die SAP HANA System Replication nutzen Sie, wenn Sie transaktionsorientierte Datenreplikation brauchen, Quell- und Zielsystem jedoch beiderseits eine SAP HANA-Instanz ist. Das heißt während beim SAP Replication Server das Quellsystem in der Regel eine AnyDB ist, binden sie in der SAP HANA System Replication als Quellsystem ebenfalls eine SAP HANA Datenbank an. Die SAP HANA System Replication hat im Gegensatz zum SAP Replication Server den Vorteil, dass Sie auf die HANA-to-HANA Übertragung optimiert ist und neben den bloßen Daten auch noch beispielsweise die Systemkonfiguration, HANA-Datenbankbenutzer und andere HANA-Objekte wie Calculation Views etc. replizieren kann. Wenn Sie mehr über die SAP HANA System Replication erfahren wollen, lesen Sie meinen Beitrag zu SAP HANA Tailored Data Center Integration (SDI).

Was sind typische Use Cases für die verschiedenen  SAP HANA Data Provisioning Technologien?

Der SAP LT Replication Server

Der SAP LT Replication Server ist, wie wir gelernt haben, eine nicht transaktions- oder objektorientierte Data Provisioning Technologie. Da in Finanzbuchhaltungssystemen beispielsweise eine transaktionale Konsistenz gewährleistet sein muss, eignet sich der SAP LT Replication Server also beispielsweise nicht für die Live-Übertragung von Finanzdaten an zwei Standorte, wenn zu jeder Zeit eine transaktionale Konsistenz in Quelle und Ziel notwendig ist.

Der SAP LT Replication Server wird häufig genutzt für Szenarien, in denen er glänzen kann. Das „LT“ im SAP LT Replication Server steht für Landscape Transformation. Das heißt das Haupt-Einstazzenario von SLT ist die Konsolidierung mehrerer SAP-Anwendungssysteme gleicher Art in ein einziges System, um die Systemlandschaft zu verknappen. So wird der SAP LT Replication Server etwa häufig genutzt, um mehrere Company Codes zusammenzuführen. Dazu transformiert der LT Replication Server die Felder der Tabellen von einem Company Code in den anderen und repliziert die Daten somit unter dem neuen Company Code in das Zielsystem. Da der SAP LT Replication Server keine transaktionale Konsistenz bietet, sollte hierzu in beiden Systemen eine Downtime eingeplant werden. Das ist aber nicht schlimm, weil diese Konsolidierung von Systemen ohnehin meist im Rahmen einer Migration oder eines Upgrades auf ein neues Release gemacht wird. Somit war ein Downtime-Fenster also von vornherein fest eingeplant.

Desweiteren eignet sich der SAP LT Replication Server optimal für die Konsolidierung von Daten mehrerer Quellen an ein Ziel, um sie für analytische Zwecke zur Verfügung zu stellen oder eine Suchbasis auf Daten mehrerer Systeme bereitzustellen. Denn hier wird häufig keine transaktionale Konsistenz vorausgesetzt. Stattdessen werden einfach nur zum Zeitpunkt X diejenigen Objekte analysiert oder im Suchtrefferbild angezeigt, die eben gerade repliziert wurden. Dabei akzeptiert der Benutzer bewusst den Unschärfegrad durch zum Zeitpunkt X noch nicht komplett replizierte Objekte, die nicht angezeigt werden können bzw. in die Analyse nicht mit einfließen können. Häufig werden mit SLT also beispielsweise Data Lakes gebaut, um Daten für Analysesoftware wie QlikView, SAP Lumira und Tableaut oder für Suchmaschinen zur Verfügung zu stellen.

 

Wann und wie kommt SAP HANA Smart Data Integration (SDI) ins Spiel?

SAP HANA Smart Data Integration ist ein riesiges Buzzword in der SAP-Welt. Die Fachmessen reden sich den Mund fusslig. Was verbirgt sich hinter diesem Wunderkind?

SAP HANA Smart Data Integration hat das Ziel, die Vorteile der oben erläuterten verschiedenen Tools für HANA-optimierte Einsatzzenarien zu verbinden. Einfach gesagt: Die weiter oben vorgestellten Data Provisioning Technologien haben weiterhin ihre Daseinsberechtigung in Szenarien, in denen sie besonders glänzen (etwa das Zusammenführen von Company Codes mit dem SAP LT Replication Server oder die Sicherstellung der Hochverfügbarkeit einer SAP HANA Instanz durch die SAP HANA System Replication). Jedoch soll es dem Kunden mit Smart Data Integration möglich sein, mit nur einem einzigen Werkzeug möglichst viele der Datenreplikationsszenarien für SAP HANA abbilden zu können. Smart Data Integration soll also der „Black&Decker Sammel-Werkzeugkoffer“ für das SAP HANA Data Provisioning werden, was jedoch nicht heißt, dass der Profi auf das Zukaufen von speziellen Maul- und Schraubenschlüsseln verzichten kann. Aber zumindest ist es allein mit SAP HANA Smart Data Integration (SDI) möglich, Data Federation mittels Smart Data Access (SDA), Echtzeit-Datenreplikation und komplexe Datentransformationen durchzuführen. SDI ist  Software-Bestandteil jeder HANA-Datenbank und muss also nicht gesondert heruntergeladen werden.

Data Federation mit SAP HANA Smart Data Integration (SDI)

Was SAP HANA Smart Data Integration (SDI) zudem neu macht ist die verbesserte Unterstützung von Data Federation Prozessen. Es ist möglich lokale on-Premise Quelldatenbanken sowie einen Hadoop-Storage per SDI an die HANA-Datenbank anzubinden. Danach kann man die Daten über virtuelle so ansprechen, als wären diese direkt in der SAP HANA Datenbank gespeichert, obwohl die Daten in Wahrheit weiterhin in ihren eigentlichen Quellsystemen vorliegen, also nicht in SAP HANA kopiert oder gar in den Arbeitsspeicher der HANA-Instanz geladen werden. Damit ist SDI also auch eine Art Enabler für die Anbindung von Datenquellen als Near-Line Storage (NLS).

Aber die Data Federation über virtuelle Tabellen hat noch andere Use Cases. So ist es beispielsweise mit Smart Data Integration so einfach wie nie, Daten aus Social Media, News-Seiten und anderen Datenquellen aus dem Web 2.0 auszulesen, zu transformieren und in die HANA-Datenbank zu persistieren. Gerade in Verbindung mit Master Data Management (MDM) etwa wird es immer wichtiger, Daten aus den sozialen Netzwerken von Kunden, Lieferanten und Partnern abzugreifen und diese mit den selbst gespeicherten Informationen zu vereinigen. Und auch die Analyse von Märkten und dem eigenen Unternehmens-Image wird mit der Analyse von Presseseiten immer einfacher. Gerade das Abgreifen von externen Quellen mit Hilfe von Smart Data Integration ist ja gerade DAS Vorzeige-Szenario für SAP HANA in einem Big Data Szenario. SAP HANA Smart Data Integration(SDI)  ist also ein wesentlicher Enabler von SAP HANA, wenn es um die Verwendung als Big Data Appliance geht.

Was macht Smart Data Integration hier zum Tool der Wahl? Das sogenannte Realtime-Feature. Wenn Sie bisher beispielsweise dem RSS Feed einer Seite gefolgt sind, mussten Sie eine Logik programmieren, um diesen RSS Feed regelmäßig auf Änderungen zu prüfen und die Einträge in diesem Feed neu abtasten. Unter Smart Data Integration setzen Sie einfach nur das Häkchen „Realtime“ und können somit den Änderungen des Feeds in Echtzeit folgen. Diese Abtastung sollte nicht von der SAP HANA Instanz selbst, sondern von einem SAP HANA Data Provisioning Agent erfolgen, der auf einem separaten System läuft. Der Provisioning Agent steht außerhalb des internen Netzwerks und leitet die Informationen an die SAP HANA Datenbank  im internen Netz weiter, was aus Security-Sicht der Architektur einer demilitarisierten Zone (DMZ) entspricht.

Technische Basis für SDI ist die Smart Data Access Technologie, hat aber bis auf den ähnlichen Namen nicht viel damit zu tun. Das ist ungefähr so wie Sybase ASE, Sybase iQ und der TREX die technische Basis für die HANA Datenbank darstellen. Die Inhalte der Echtzeit-Subscriptions werden abgetastet, beispielsweise also der XML-Code eines RSS-Feeds, und wird in eine virtuelle Tabelle umgewandelt. Das heißt die XML-Tags im RSS-Feeds werden Spalten in einer virtuellen Tabelle, und mit dieser virtuellen tabelle kann ich dann ETL-Prozesse auf die eigentliche HANA anwenden und beispielsweise die transformierten Informationen in der HANA oder im Near-Line-Storage bzw. im Hadoop speichern.

Data Replication mit SAP HANA Smart Data Integration (SDI)

Wie wir weiter oben gelernt haben, ist Data Federation mit SAP HANA also die Grundlage dafür, Daten von anderen Quellen über virtuelle Tabellen für die SAP HANA Datenbank zur Verfügung zu stellen. Mit der Data Replication hingegen replizieren wir in Echtzeit Daten von Quell-Datenbanken wie Oracle 12, DB2, Microsoft SQL Server, Teradata etc. in die HANA. Diese Daten liegen dann also auch wirklich auf dem Storage der HANA-Instanz und haben somit das Potential, in den Hauptspeicher geladen und in-Memory vorgehalten zu werden. Nicht nur Datenbanken, sondern auch Twitter als Social Media-Datenquelle kann repliziert werden. Änderungen in diesen Datenquellen werden in Near-Real Time in die SAP HANA Datenbank repliziert. Auch Datei-Quellen wie Excel-Sheets, Flat Files oder ein OData-Service können als Quelle verwendet werden.

SAP HANA Smart Data Integration (SDI) hat das Potential, dem SAP LT Replication Server in einem Szenario den Rang abzulaufen. Hierbei handelt es sich um das Szenario, dass Daten aus verschiedenen Quellen (Hadoop, SAP iQ, Excel-Sheet, Hadoop, Flat Files) in Near-Real Time in eine SAP HANA DAtenbank repliziert werden können. Denn SDI bietet den Vorteil der Data Flows, mit denen wesentlich komplexere Daten-Transformationen (siehe unten) auf die Quelldaten angewendet werden können als mit SAP LT, bevor diese in der SAP HANA Datenbank im Zielformat persistiert werden. Trotzdem ersetzt SDI den LT Replication Server beispielsweise nicht in einem ABAP-to-ABAP Szenario, in welchem sich zwei SAP-Systeme über RFC-Verbindungen unterhalten, um eine Replikation anzustoßen.

Data Transformation mit SAP HANA Smart Data Integration (SDI)

Mit den Data Transformation Capabilities ist es möglich, Daten zu transformieren, bevor diese im Zielformat in der HANA entweder als virutelle Tabelle oder direkt in der HANA referenziert bzw. gespeichert werden. Diese Transformationen können die Gestalt simpler SQL-Operationen wie Joins, Where-Filter oder Aggregatfunktionen haben, oder die Anwendung von Pivots (Zeilen in Spalten umwandeln oder umgekehrt) oder CASE-Transformationen haben.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!