Serverless und Data Warehouse: Wie kann das passen?

Serverless und Data Warehouse: Wie kann das passen?

Die Cloud ist am Wachsen - immer mehr Unternehmen bewegen Stück für Stück Ihre Infrastruktur in die Cloud und die Frage lautet nicht ob sie in die Cloud gehen, sondern wann. Mit einer modernen Data Warehouse (DWH)-Architektur im Sinne von Functions-As-A-Service (kurz FaaS) stehen Sie auf sicheren Beinen und können, sobald der Startschuss ertönt, in die Cloud sprinten.

Functions oder auch Funktionen stehen in der klassischen Programmierung für „stateless“, also für Zustandslosigkeit (siehe auch C. Wagenknecht, Programmierparadigmen, Springer, 2016) und damit nach genau dem, was ein klassisches DWH nicht sein sollte. Funktionen besitzen keinen beschreibbaren Zustand! Und genau hier setzt eine moderne, zukunftssichere Architektur an.

Big Data, Dynamic Scaling, Cost Management und Hochverfügbarkeit sind Schlüsselelemente hinter dem Erfolg einer Enterprise-DWH-Plattform. Bei der Arbeit mit diversen Daten Integrationsansätzen, entsprechenden ETL-Werkzeugen und analytischen Plattformen fällt auf, dass viele Entwickler nicht in der Lage sind, ein klassisches Spark- und Hadoop-Cluster aufzusetzen, da es nicht in ihren Hauptkompetenzbereich fällt. Vielmehr sollen Data Integration-Entwickler die bereits vorhandene Infrastruktur nutzen um entsprechende Logiken in das Enterprise DWH-System implementieren, ob diese nun ausreicht oder nicht. Wirft man einen Blick auf die Vorteile von Serverless-Infrastrukturen, steht der Self-Service-Gedanke ganz deutlich im Vordergrund. Serverless ist ein Schritt in Richtung Unabhängigkeit der Entwickler und ermöglicht ihnen, schnell und einfach ein Spark- oder Hadoop- Cluster, eine Datenbank oder einen Datenspeicher zu nutzen, ohne sich um Faktoren wie Bereitstellung, Betrieb und Skalierung kümmern zu müssen.

Eine Serverless-Architektur für ein Enterprise-DWH-System besteht aus mehreren Komponenten. Die Vielfalt und Komplexität der benötigten Komponenten ist nicht zu unterschätzen. Eine große Auswahl und die dazu gehörenden Vor- und Nachteile der einzelnen Dienste sollte auf Basis der der firmeneigenen Anforderungen evaluiert und passende Komponenten ausgewählt werden.

Speziell das Thema Vendor-Locking, also die Beschränkung einer Funktion auf einen Hersteller oder Dienstleister, entsprechende Einführungs- aber eben auch mögliche Austrittsstrategien sollten in Verbindung mit passenden Migrationsszenarien ebenfalls Bestandteil einer solchen Evaluierung sein. AWS Lambda-Funktionen lassen sich oft nur unter großen Entwicklungsaufwand in Google Functions migrieren. Wird der manuelle Aufwand für Migration der Funktionalität bei der Verwendung von OpenSource-Frameworks wie OpenFaaS, OpenWhisk und Knative zu hoch, gehen unter Umständen sogar die eigentlichen Kostenvorteile für FaaS verloren.

Auch wenn die konkrete Wahl dieser Komponenten immer von firmenspezifischen Faktoren abhängt, verdeutlicht der folgende Use-Case exemplarisch den möglichen Aufbau eines solchen Systems. Wie in der Abbildung (Abb.1) skizziert, besteht das exemplarische DHW aus den folgenden Komponenten: Datasource, Iron Functions, Object Storage und einer Datenbank.

Abb.1: Komponenten eines Serverless DHW

Details der Komponenten:

Die Datenquelle (Datasource), hier nicht näher spezifiziert, kann beispielsweise aus einen SAP- System, einer Datenbank, strukturierten oder unstrukturierten Dateien oder auch IoT-Streams bestehen.

Als Zielsystem, dem DWH, wird eine Exasol verwendet, der derzeit schnellste In-Memory Datenbank der Welt. Exasol bezeichnet ihr Produkt als NoOps-Datenbank (eine Datenbank, bei der kein dedizierter Datenbankadministrator notwendig ist) und ist speziell dank der enormen Geschwindkeit, der Schnittstellen und dem intelligenten, automatischen Indizieren eine ideale Lösung für Data Scientisten. In Verbindung mit einer Visualisierung über den eingebauten Tableau Turbo spielt die Exasol ihr volles Potential aus.

Minio S3 wurde als Object Storage verwendet, da es als Hochleistungsspeicher für große private Cloud-Infrastrukturen konzipiert wurde und entsprechend Dateien verschiedenster Art in einem DWH speichern kann.

Die Datenverarbeitung wird vollständig über Talend Data Integration (DI) Jobs abgebildet. Die Talend DI-Jobs werden dabei als Functions ausgeprägt und laufen auf einer entsprechenden FaaS-Plattform wie beispielweise Iron Functions. Als Open Source Plattform im Jahr 2016 gestartet, entwickelte sich die Plattform schnell zu einer ernstzunehmenden Lösung für FaaS (http://github.com/iron- io/functions).

Zusammegefasst werden Daten aus verschiedenen Datasources geladen, im S3-Storage persistiert und in einem Exasol-basierten DWH abgelegt.

Talend Data Integration erledigt die Anbindung verschiedenerer Quellen und Ziele spielend leicht und vor allem sehr schnell und effektiv. Die Herausforderung besteht vielmehr in der Integration der Talend DI Jobs in ein FaaS-Framework und diese gemäß Continuous Integration/Continuous Deployment (CI/CD) weitestgehend zu automatisieren. Schwerpunkt ist dabei die zu grunde liegende Architektur bestehender DI-Jobs für die Eignung auf eine Serverless-Umgebung zu analysieren. Dabei müssen die Talend ETL-Jobs so gebaut werden, dass sie möglichst kleine und gekapselte Aufgaben erledigen. Da dieses Design nicht dem klassischen ETL entspricht, kann eine vollständige Migration von bestehenden ETL-Strecken sehr aufwändig sein und ein grundlegendes Umdenken der ETL- Entwickler und damit der Entwicklungsrichtlinie bedeuten.

Einfacher ist es die einzelnen Talend-Jobs in einen Container zu verpacken, damit diese auf die FaaS- Plattformen deployed und durch spezielle Trigger ausgelöst werden. Dadurch können Talend-DI-Jobs innerhalb der gesamten Infrastruktur leicht horizontal skalieren, ohne vorher aufwendige und spezielle Konfiguration einzelner Nodes durchführen zu müssen.

Der „Trick“ des Serverless Data Warehouses ist die exklusive Nutzung von skalierenden on-Demand- Dienste. Die verwendete Technik ist einfach und genial, aber es gibt ein paar Grundsätze zu beachten:

  1. Der Container muss eine Java-Runtime enthalten um die eingebetteten Talend DI Jobs ausführen zu können. Nahezu jeder DI-Job kann in eine Funktion überführt und auf einer FaaS-Plattform deployed werden
  2. Die Komposition der DWH-Komponenten muss entsprechend der individuellen Anforderungen erstellt werden.
  3. Die Talend-ETL/ELT-Strecken müssen entsprechend der FaaS-Architektur konzeptioniert werden.

Ausgehend von diesen Ansätzen ist es mit vergleichsweise wenig Aufwand möglich, ein Serverless Data Warehouse auf zu bauen oder ein Legacy DWH in die Cloud unter Verwendung von AWS Lambda, Google Functions, Azure Functions oder einer Open Source FaaS-Plattformen zu migrieren.

Die Konzeption und Umsetzung der klassischen Datenbewirtschaftung in eine revolutionäre FaaS- Architektur kann eine echte Herausforderung werden. Die cimt AG mit mehr als 200 IT-Beratern unterstützt Sie gern auf Ihrem Weg in Richtung Zukunft. Mehr über die cimt ag unter: https://www.cimt-ag.de/leistungen/business-intelligence/ oder folgen Sie der cimt auf Twitter unter @cimtag.

An der Diskussion teilnehmen

0 Comments

Hinterlasse eine Antwort

Your email address will not be published. Required fields are marked *