SAP Data Hub ist ein Werkzeug der SAP, mit dem Datenflüsse oder komplexe Datenverarbeitungsprozesse operationalisiert werden können. Dabei hat das Tool einen starken Fokus auf Big Data-, Data Science- und IoT-Lösungen. Wir haben uns die Version 1.0 SPS 03 in der Trial Edition angeschaut.
Überblick
SAP Data Hub besteht im Wesentlichen aus folgenden Komponenten:
- Pipeline Modeler: Entwicklung und Betrieb von Pipelines (Datenflüssen).
- Modeling Tool: Entwicklung und Betrieb von Workflows. Diese Workflows können u.a. Pipelines aufrufen.
- Distributed Runtime: die Prozesse der o.g. Komponenten werden zur Laufzeit auf einem Kubernetes Cluster ausgeführt. Damit können Laufzeit-Ressourcen bedarfsgerecht zugeteilt und skaliert werden.
Von diesen Komponenten ist der Pipeline Modeler sicherlich das zentrale Modul, weil hier die eigentliche Datenverarbeitung in Form von Pipelines entworfen wird. Wir beschreiben daher in diesem Blog ausschliesslich den Pipeline Modeler.
Pipelines
Pipelines werden im Pipeline Modeler selbst als Graphen bezeichnet. Es werden bereits 60 Graphen als Beispiele mitgeliefert, die meisten davon stammen aus dem Bereich Machine Learning. Zum Beispiel gibt es Graphen um digitale Ziffern aus Bildern mit handgeschriebenen Ziffern zu extrahieren. Das Beispiel implementiert das entsprechende TensorFlow Tutorial in zwei Pipelines.
Abb. 1: Mitgelieferte Beispiel-Pipelines
In der ersten Pipeline wird das Modell trainiert und im Repository von SAP Data Hub gespeichert:
Abb. 2: Pipeline TRAIN MNIST Model: Trainieren des TensorFlow-Modells
Im zweiten Pipleine wird das zuvor trainierte Modell angewendet: dabei werden in einer Endlosschleife Bilder aus einem Repertoire von 60.000 Beispiel-Bildern ausgewählt und darin die digitale Ziffer erkannt:
Abb. 3: Pipeline Infer MNSIT Str. Repo: Anwenden des TensorFlow-Modells
Die einzelnen Kästchen in einem Pipeline sind Operatoren, die die eigentliche Dateverarbeitungslogik enthalten. Der Datenfluss zwischen zwei Operatoren erfolgt über Ports an den Operatoren.
In einem realen Use Case würden die Ergebnisse dieser Pipeline nun am Ende der Verarbeitungskette an einen Abnehmer gesendet (z.B. über eine Streaming Engine oder in eine Datenbank-Tabelle als Zwischenspeicher). Zu Debug-Zwecken kann man auch einen Oprerator mit einem virtuellen Terminal in die Pipeline einbauen, um so zur Laufzeit die generierten Ergebnisse direkt überprüfen zu können:
Abb. 4: Anzeige der Ergebnisse der Ziffer-Erkennung im virtuellen Terminal
Operatoren
SAP Data Hub wird mit knapp 200 Operatoren ausgeliefert. Genau wie Pipelines kann man die meisten davon als Beispiele betrachten. Allerdings kann man diese Beispiele editieren und so für die eigens gebrauchte Funktionalität anpassen. Zum Beispiel benutzen die bereits erwähnten TensorFlow Pipelines TensorFlow Operatoren:
Abb. 5: Mitgelieferte Operatoren, z.B. TensorFlow Operatoren
Im Kontext einer Pipeline kann man dann den Operator konfigurieren oder die die Dokumentation des Operators aufrufen. Viele Operatoren implementieren die Funktionalität über Scriptsprachen wie Python, R oder Javascript. Konfigurationsparameter und die Skripte in diesen Operator können editiert werden, um so die Funktionalität an den eigenen Use Case anzupassen.
Abb. 6: Konfiguration eines Operators
Abb. 7: Konfiguration des Operators
Abb. 8: Dokumentation des Operators
Zur Laufzeit einer Pipeline läuft ein Operator immer innerhalb eines Docker Containers (und dieser im Kubernetes Custer in der Distributed Engine). Der oben gezeigte TensorFlow Evaluate MNIST Operator basiert auf einem Operator, der Python 2.7 und die TensorFlow Python Library tensorflow enthält, die vorrangig in der Python 2.7 Installation installiert wurde. Das bedeutet, dass dieser Operator über den Docker Container bereits alle notwendigen Installationen, Konfigurationen etc. enthält, damit das im Operator angegebene Python Skript sofort lauffähig ist und die TensofFlow-Funktionen nutzen kann.
Diese Architektur ist offensichtlich eine zentrale Funktionalität des Data Hub Pipeline Modelers: verschiedene, operative Use Cases benötigen evtl. unterschiedliche Versionen und Konfigurationen von Basis-Installationen wie z.B. Python oder R, sowie deren zusätzlichen Bibliotheken. In einer klassischen Umgebung können solche unterschiedlichen Konfigurationen auf einem Server unter Umständen nur schwer oder gar nicht gleichzeitig bereitgestellt werden. Mit der konsequenten Benutzung von Docker Containern im SAP Data Hub Pipeline Modeler bringt dagegen jeder Operator seine eigene notwendige Konfiguration mit, ohne dabei Seiteneffekte auf andere Operatoren zu haben.
Entwicklung neuer Operatoren
Um nun eine eigene Lösung im SAP Data Hub Pipeline Modeler zu betreiben müsste man in der Regel einen entsprechenden Operator entwickeln (ausser einer der mitgelieferten Beispiel-Operatoren bietet genau die benötigte Funktionalität). Es gibt drei alternative Möglichkeiten einen neuen Operator zu entwickeln:
- Ein neuer Operator wird erstellt, indem man einen der mitgelieferten Basis-Operatoren erweitert. Der SAP Data Hub Modeler bietet dafür folgende Basis-Operatoren an:
Abb. 9: Basis-OperatorenIm Anschluss würde man über sog. Tags definieren, welches der mitgelieferten Docker Images benötigt wird – in diesem Beispiel ein Docker Image mit Python 2.7 und der TensorFlow Python Bibiliothek in der Version 1.2.1.:
Abb. 10: Definition des selbst erstellten OperatorsDiese Methode, einen neuen Operator zu entwickeln ist sehr gut in folgendem Blog beschrieben: SAP Data Hub – Develop a custom Pipeline Operator from a Base Operator.Neben den Operatoren für Skriptsprachen wie Python, R, Javascript und Go gibt es auch einen Basis-Operator Docker. Damit kann man auch Docker Images benutzen, die man selbst ausserhalb SAP Data Hub entwickelt hat.
- Ein neuer Operator wird erstellt, der auf einem neuen Docker Image basiert. Das Docker Image wird innerhalb des SAP Data Hub Pipeline Modelers erstellt. Dazu können bereits im SAP Data Hub existierende Images verwendet werden. Das Tool unterstützt den Anwender bei der Erstellung des neuen Images. Diese Methode, einen neuen Operator zu entwickeln ist sehr gut in folgendem Blog beschrieben: SAP Data Hub – Develop a custom Pipeline Operator with own Dockerfile.
- Ein neuer Operator wird in C++ entwickelt. Dabei wird eine Shared Library kompiliert, die von der Distributed Runtime zur Laufzeit dynamisch eingebunden wird. Diese Methode ist in der Dokumentation beschrieben.
Konnektivität
Einige der mitgelieferten Operatoren implementieren Verbindungen zu externen Systemen, wie z.B. HTTP Server, Kafka (Streaming Engine), MQTT (Message Queues), etc. Daneben gibt es Konnektoren für folgende SAP Systeme und Speichersysteme:
- SAP VORA
- SAP HANA
- SAP BW
- HDFS (Hadoop)
- Azure Data Lake
- Azure Storage Blobs (WASB)
- Google Cloud Storage
- Amazon S3
Es fällt auf, dass Konnektoren für klassische Datenbanksysteme wie z.B. Oracle, SQL Server, Teradata etc. fehlen. In vielen Data Science Use Cases werden aber auch Stammdaten oder Bewegungsdaten aus Non-SAP Systemen benötigt (z.B. einem Data Warehouse oder operativen Systemen). In solchen Fällen könnten neue Operatoren entwickelt werden, um die Konnektivität zu diesen Systemen herzustellen. Alternativ könnten natürlich die Daten mit anderen Tools vorrangig auf eines der o.g. Systeme transferiert werden (hierfür gibt es in der anderen Komponente von SAP Data Hub – dem Modeling Tool – eine gewisse Unterstützung). Die SAP hat auf ihrer SAP Data Hub Road Map aber bereits Support für weitere Datenbanksysteme angekündigt.
Fazit
Die mitgelieferten Beispiele des SAP Data Hub Pipeline Modelers zeigen, dass die Einsatzbereiche des Tools primär in den Bereichen Big Data, Data Science und hier insbes. Machine Learning liegen. Allerdings werden die eigentlichen Lösungen aus diesen Bereichen nicht mit dem Pipeline Modeler entwickelt. Vielmehr würde ein Data Scientist zunächst eher prototypische Lösungen in vertrauten Entwicklungsumgebungen wie z.B. RStudio, IPython, Jupyter etc. entwickeln. Im Pipeline Modeler würde dann die Lösung operationalisiert und betrieben.
Die Implementierung von Operatoren in Docker Containern erlaubt den Pipeline Modeler universell einzusetzen. Für jede denkbare Technologie sollte es möglich sein, einen entspr. Operator zu entwickeln. Gleichzeitig entfallen durch die Verwendung von Docker Containern die klassischen Einschränkungen bzgl. inkompatibler Versionen oder Konfigurationen von systemnahen Softwarekomponenten.
Da ausserdem die Laufzeitumgebung durch einen Kubernetes Cluster bereitgestellt wird, sind die notwendigen Laufzeit-Ressourcen skalierbar. Die Kombination von Docker Containern und Kubernetes Cluster ermöglicht es somit, dass eine skalierbare Zahl von Use Cases mit diversen Technologien gleichzeitig auf derselben Plattform betrieben werden kann.
Als Tool der SAP wird der Pipeline Modeler bereits mit sehr guter Konnektivität zu anderen SAP Systemen ausgeliefert. Daneben gibt es auch Operatoren für die Anbindung an Cloud basierte und Big Data Speichersysteme. Es fehlen aber Konnektoren zu klassischen Non-SAP Datenbanksystemen, die aber gemäss Road Map zukünftig auch enthalten sein sollen.