Serverless Data Warehouse: (K)ein Widerspruch in sich?

Serverless Data Warehouse

(K)ein Widerspruch in sich?

Wegweisende Architektur für das Data Warehouse der Zukunft

SERVERLESS ARCHITECTUR

Serverless und Function as a Service (FaaS) sind in aller Munde. Bereits vor fünf Jahren hat Amazon AWS Lambda veröffentlicht, womit unter anderem Programme für den Amazon-Sprachassistenten Alexa erstellt werden können, die sogenannten Skills. Mittlerweile kann die Serverless-Architektur für die unterschiedlichsten Bereiche angewendet werden; beispielsweise als Technologieunterbau für maschinelles Lernen oder im Bereich der Data Integration.

Oft wird Serverless mit FaaS gleichgesetzt. FaaS sind zustandslose (engl. stateless) Dienste. Dass diese Technologie dennoch für ein Data Warehouse (DWH) genutzt werden kann, scheint paradox – immerhin gibt es kaum Systeme, die stärker zustandsbehaftet sind als ein DWH. In diesem Artikel wollen wir zeigen, dass ein Serverless Data Warehouse kein Widerspruch in sich ist, sondern große Vorteile gegenüber klassischen DWH-Systemen bietet.

Aber dafür muss zunächst geklärt werden, was Serverless und FaaS eigentlich sind.

Serverless

Der Begriff „Serverless“ wurde bereits 2012 u. a. von Ken Fromm geprägt. Damals noch auf Entwicklerbedürfnisse fokussiert, hat Fromm festgestellt, dass sich Entwickler vor der Cloud-Area häufig Gedanken über Hardware-Server machen mussten. Neben finanziellen Aspekten musste auch geplant werden, wie und wo diese aufgebaut, betrieben und gewartet werden. Hinzu kam die Schwierigkeit, dass die notwendigen Hardware-Server schlecht bis gar nicht skalierten und entsprechend auch Faktoren wie Standortwachstum häufig eine Rolle spielte. Durch Cloud-Computing wurde es mehr und mehr möglich, den Hardwarebedarf für Server durch Cloud-Dienste zu ersetzen, bis für die Entwicklungsabteilung eigene Server nicht mehr notwendig waren – man war „Serverless“.

Obgleich der Namen anderes vermuten lässt, laufen die Serverless-Dienste in der Regel auf Servern, die z. B. in den Rechenzentren der Cloud-Provider betrieben werden.

„Serverless“ ist heute nicht nur auf die Tools für die Softwareentwicklung beschränkt, sondern bedeutet, dass der Nutzer sich Server-Funktionalitäten wie zum Beispiel Authentifizierungsdienste oder Datenbanken nicht selbst bereitstellen muss, sondern als Dienstleistung gestellt bekommt. Neben möglichen Kosteneinsparungen muss der Kunde/Entwickler die Dienste auch nicht selbst pflegen. Das Installieren, Betreiben, Updaten, Lizensieren und Warten ist Aufgabe des Anbieters. Die Dienste sind zudem elastisch: Der Anbieter skaliert die Ressourcenkapazitäten entsprechend dem Bedarf und ohne weiteres Eingreifen des Kunden. Dieser zahlt nur für die Ressourcen, welche auch tatsächlich für die Durchführung benötigt wurden.

Function as a Service

Heutzutage wird der Begriff „Serverless“ oft mit Function as a Service (FaaS) gleichgesetzt, was jedoch etwas verkürzt und unsauber ist. FaaS ist ein Serverless-Konzept, bei dem zustandslose Anwendungsfunktionalitäten von einem Unternehmen bereitgestellt werden. Die meisten Cloud-Dienste fallen dabei unter die Kategorie Serverless, ohne FaaS zu sein. Entsprechend ist FaaS eine Teilmenge von Serverless und nicht komplett damit gleichzusetzen.

Serverless Beispiel-Architektur
Abb. 2: Serverless Beispiel-Architektur (Übersetzung von Nane Kratzke, “Serverless Architectures – Where have all the servers gone?”)

Im Gegensatz zu anderen Serverless- und Cloud-Modellen wie Platform as a Service (PaaS) ist FaaS nicht prozessbasierend. Eine Funktionalität wird mittels eines Events aufgerufen und liefert ein Ergebnis. Zur Implementation von Functions kann der Entwickler zwischen verschiedenen Programmiersprachen wählen, wie Node.js, Python und Java. In Abbildung 2 ist eine Serverless-Architektur am Beispiel einer Native Mobile App abgebildet.

Um eigene Serverless-Dienste bereitzustellen, können verschiedene Frameworks und Plattformen verwendet werden. Zu CloudDiensten gehören Amazon Lambda, Google Cloud Functions und Microsoft Azure Functions. Als On-Premises Frameworks kämpfen aktuell unter anderen OpenWhisk, Iron Functions, OpenFaaS, Kubeless, Nuclio, Fission und Googles Knative um die Vorherrschaft. Derzeit hat sich jedoch noch keines der Frameworks deutlich durchgesetzt.

Data Warehouse

Das Data Warehouse steht als zentrales System für die Sammlung und Auswertung von Unternehmenskennzahlen im Kern vieler Enterprise-Lösungen. Darin werden Daten aus vielen verschiedenen Bereichen und Datenquellen zusammengeführt und bereinigt. Zudem ist es die zentrale Schnittstelle für unternehmensweite Analysen und Auswertungen.

Trotz der offensichtlichen Vorteile von Serverless ist oft nicht klar, ob dieselben Vorteile auch für Enterprise-Data-Warehouse Anwendungen gelten und es für Unternehmen lohnenswert ist, DWH-Systeme serverless zu betreiben.

Big Data, Dynamic Scaling, Cost Management und Hochverfügbarkeit sind Schlüsselelemente hinter dem Erfolg einer Enterprise DWH-Plattform. Während der Arbeit mit diversen Extract, Transform, Load-(ETL)-Tools 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. ETL-Entwickler sollen Logiken in das Enterprise DWH-System implementieren und dabei die vorhandene Infrastruktur nutzen. Wenn man einen Blick auf die Vorteile von Serverless-Infrastrukturen wirft, steht ganz groß der Self-Service-Gedanke im Vordergrund. Serverless ist ein Schritt in Richtung der Entwickler und ermöglicht es ihnen, schnell und einfach ein Spark- oder Hadoop-Cluster, eine Datenbank oder einen S3-Storage zu nutzen, ohne sich um Faktoren wie Bereitstellung, Betrieb und Skalierung kümmern zu müssen.

Bash-ETL-Jobs laufen oft mehrmals am Tag. (Fast-)Echtzeit-Jobs werden nach Bedarf getriggert. Folglich treten häufig Lastspitzen auf. Zum Beispiel erzeugt ein ETL-Job, der stündlich Kassendaten diverser Einzelhändler abruft, nicht nur eine stündliche Lastenspitze, sondern ist im Laufe des Tages unterschiedlich stark ausgeprägt. In diesem Beispiel würde ein nächtlicher Job weniger Daten umfassen als einer, der tagsüber gestartet wird. Zudem überwachen Serverless-Plattformen durchgehend die Auslastung und die „Gesundheit“ des deployten Codes und skalieren entsprechend der Nutzung. Studien haben gezeigt, dass sich dank der Scale-to-Zero-Fähigkeit von Serverless-Architekturen bis zu 70 % der Kosten im Vergleich zu klassischen IaaS-basierten Deployments einsparen lassen [4]. Allerdings erfordert dies eine „verteiltere“ Service-of-Services-Architektur (eben eine Serverless-Architektur).

Dienstleister wie AWS, Azure und Google machen das Kostenmanagement für Enterprise-Systeme sehr übersichtlich. Bezahlt wird nur für den ausgeführten Code (Pay-as-you-go-Prinzip). Das reine Vorhalten von (kostenverursachenden) Ressourcen für hohe Lasten in eigenen Rechenzentren ist daher nicht notwendig. Dadurch können durch das dynamische Skalieren Ressourcenengpässe und verbundene Systemausfälle/-verlangsamung vermieden werden.

Beispiel Serverless-DWH-Architektur

Komponenten eines Serverless DWH
Abb. 3: Komponenten eines Serverless DWH

Eine Serverless-Architektur für ein Enterprise-DWH-System besteht aus mehreren Komponenten. Auch wenn die konkrete Wahl dieser Komponenten von firmenspezifischen Faktoren abhängt, wollen wir ein Beispiel aus der Praxis nehmen, um ein solches System zu verdeutlichen.

Wie in Abbildung 3 skizziert, besteht ein DHW aus mehreren Komponenten. Die Datenquelle (Datasource) soll hier nicht spezifiziert werden. Sie kann u. a. aus Datenbanken, Dateien, IoT-Streams etc. bestehen.

Talend Data Fabric
Abb. 4: Talend Data Fabric

Als Plattform für die Datenintegration eignet sich beispielsweise Talend Data Fabric (siehe Abb. 4). Die Plattform ermöglicht das Sammeln, Steuern, Transformieren, Teilen und Analysieren der Daten. Talend hat über 900 Verbindungs- und Transformationskomponenten und kann für Big-Data-, Batch- und Streaming-ETL-Jobs genutzt werden. Zudem werden verschiedene Cloud-Umgebungen unterstützt und die Plattform erfüllt alle Voraussetzungen für die Bewirtschaftung eines Enterprise-Data-Warehouse-Systems.

Als Datenbanksystem für ein DWH kann eine Exasol-Datenbank verwendet werden. Exasol ist eine In-Memory-Datenbank, die sich durch entsprechende In-Memory-Performanz und intelligentes, automatisches Indizieren auszeichnet. Als Objectstorage kann Minio S3 genutzt werden, da es als Hochleistungsspeicher für große private Cloud-Infrastrukturen konzipiert wurde und entsprechend Dateien verschiedenster Art in einem DWH speichern kann.

Als FaaS-Frameworks kann Iron Functions, aber auch andere Tools wie OpenWhisk und OpenFaaS genutzt werden. Die meisten FaaS Frameworks sind geeignet, in den gängigen Cloud-Umgebungen genutzt zu werden. Einige basieren auf einer ContainerPlattform oder müssen auf einer solchen, wie beispielsweise Kubernetes, betrieben werden.

Eine der grundlegenden Herausforderungen bei Serverless DWH ist es, die klassischen ETL-Jobs serverless zu gestalten. FaaS setzt im Idealfall auf kleine und gekapselte Funktionen, die eigenständig ausgeführt werden können. Klassische ETL-Jobs scheinen im ersten Moment diesem Ziel zu widersprechen, können jedoch auch als ETL-Jobs so gebaut werden, dass sie möglichst kleine, gekapselte Aufgaben erledigen und damit gut in das FaaS-Konzept passen.

Bei der Verwendung von Iron Functions werden die einzelnen ETL-Jobs in Container verpackt und durch entsprechende Trigger ausgelöst. Dadurch skalieren die Talend-DI-Jobs innerhalb der gesamten Infrastruktur ohne spezielle Konfiguration einzelner Nodes.

Die vorgestellte, konkrete Lösung für eine Serverless-Architektur eines Enterprise-Data-Warehouse-Systems ist nur eine von vielen Möglichkeiten, die je nach Bedarf angepasst werden können. Bedeutet dies nun, dass Serverless die Architektur der Wahl ist und alle Probleme im Bereich Data Warehouse löst? Die Antwort ist natürlich stark abhängig von der Organisation und deren spezifischen Anforderungen an das Data Warehouse.

Ein Serverless Data Warehouse basiert auf Diensten von Drittanbietern. Diese Dienste werden vom Anbieter vollständig verwaltet und helfen, die inhärenten Komplexitäten handhabbarer zu machen. Hochverfügbarkeit, Skalierung, Kostenoptimierungen und andere Faktoren werden von Drittanbieter-Diensten bereitgestellt.

Nachteile eines Serverless DWH

Durch das große Angebot an Cloud-Diensten und individuellen Anforderungen an das Enterprise Data Warehouse wird besonders für Architektur und Planung von Serverless DWH Expertenwissen benötigt. Dies kann eine nicht zu unterschätzende Herausforderung sein, besonders wenn man es selbst stellen möchte.

Ein weiterer Punkt ist die Abhängigkeit vom Dienstleister (sogenanntes Vendor Lock-In), welche durch die Verwendung von Provider-Diensten für ganz spezielle Aufgaben (wie z. B. BigQuery ML von Google oder Amazon EMR) schnell entstehen kann. Diese Problematik kann jedoch durch eine sinnvolle Wahl der Dienste und die Nutzung von Orchestrierungsplattformen wie OpenShift (basiert auf Kubernetes) oder Docker Enterprise Edition (nutzt Docker Swarm Mode und/oder Kubernetes) vermieden werden und stellt heutzutage kein Hauptproblem mehr dar.

Auch wenn bei Serverless-Diensten meistens nur für die tatsächlich genutzten Ressourcen gezahlt wird, gibt es bei unterschiedlichen Einzeldiensten unterschiedliche Kostenmodelle, die teilweise auch nicht ressourcenabhängige Positionen beinhalten.

Im Gegensatz zu Data-Warehouse-Lösungen, die aus einem „Guss“ bestehen, steigt durch die Verwendung von vielen verschiedenen Cloud-Diensten von teilweise unterschiedlichen Anbietern auch die Komplexität bei der Integration, insbesondere wenn auch Nicht-Serverless-Komponenten verwendet werden sollen.

Fazit

Ist die Serverless-Architektur für das Data Warehouse heute schon eine lohnende und sinnvolle Wahl? Eine pauschale Antwort ist nicht möglich, da es stark von den individuellen Anforderungen des DHW abhängt. Ein Serverless Data Warehouse hat jedoch großes Potential zur Kostenersparnis, auch im Vergleich zu einer Cloud-Lösung, da die einzelnen DI-Komponenten unterschiedlich großen Ressourcenbedarf haben und in der Umsetzung als FaaS Functions ressourceneffizienter – und dank des FaaS-Kostenmodells folglich auch kosteneffizienter – genutzt werden können (vgl. auch “Cost comparison of running web applications in the cloud using monolithic, microservice, and AWS Lambda architectures”).

[[Autoren sind die cimt IT-Berater S. Dahnke und P.-C. Quint. Der Original-Beitrag erscheint am 13. März 2019 im Online Themenspecial der ObjektSpektrum.]]

Ihr Kontakt

Bild
Rouven Homann
Management Partner
Tel.: +49.40.53302-0
E-Mail: bi-solutions@cimt-ag.de
div#stuning-header .dfd-stuning-header-bg-container {background-image: url(https://www.cimt-ag.de/wp-content/uploads/2017/10/home-start2_low.jpg);background-color: #848484;background-size: cover;background-position: center center;background-attachment: fixed;background-repeat: no-repeat;}#stuning-header div.page-title-inner {min-height: 300px;}div#stuning-header .dfd-stuning-header-bg-container.dfd_stun_header_vertical_parallax {-webkit-transform: -webkit-translate3d(0,0,0) !important;-moz-transform: -moz-translate3d(0,0,0) !important;-ms-transform: -ms-translate3d(0,0,0) !important;-o-transform: -o-translate3d(0,0,0) !important;transform: translate3d(0,0,0) !important;}