Ein Unternehmen verfügt über eine Vielzahl von Datenquellen, die für ein Data Lakehouse interessant sein können. Diese Systeme sind in der Regel enorm heterogen. Mal hat man als Kunde Zugriff auf eine REST-Schnittstelle, mal bietet das System einen Datenbankzugriff, mal auch nur eine Export Funktion für Dateien. Sehr häufig kann man sogar Systeme komplett ohne systemische Zugriffsmöglichkeiten finden.
Um diesem Chaos Herr zu werden, gibt es mehrere Möglichkeiten, die wir uns gemeinsam im Folgenden Blog Artikel ansehen werden.
ETL und ELT
Diese Begrifflichkeiten sind Dir sicherlich schon einmal begegnet, wenn Du Dich mit Datenvereinnahmung beschäftigt hast. Es handelt sich um Abkürzungen für die zwei Datenvereinnahmungsparadigmen „Extract – Transform – Load“ und „Extract – Load - Transform“.
Grundsätzlich verwenden wir im Data Lakehouse Kontext immer zweiteren Ansatz. Warum? Ganz einfach, weil wir uns so die Flexibilität bewahren die Daten später in unserem Data Lakehouse auf eine andere Weise zu bearbeiten als ursprünglich geplant und die Last auf unserem Quellsystem reduzieren. Stelle Dir vor, Du brauchst HR-Daten in verschiedenen Reports, die alle anderen Anforderungen haben könnten.
Gemäß dem ETL-Paradigma müssten die Daten entsprechend separat für jeden Report geladen werden – das ist nicht effizient!
Ein Beispiel für ein ETL-Tool ist PowerQuery, das sowohl in Excel als auch in Power BI integriert ist. Für jeden Bericht wird dabei eine eigene Pipeline erstellt, die unabhängig von anderen dezentral ausgeführt wird. Das ist nicht sehr effizient! Interessanterweise setzt Microsoft PowerQuery aber auch in seinen Data-Warehouse- und Lakehouse-Produkten ein. In Fällen, in denen die Daten nicht vorab transformiert werden, kann PowerQuery daher auch als ELT-Tool genutzt werden. Somit lässt sich festhalten, dass jedes ETL-Tool auch als ELT-Tool eingesetzt werden kann – der umgekehrte Fall ist jedoch nicht möglich, da diesen Tools die Transformations-Möglichkeit fehlt.
Möglichkeiten zur Datenanbindung
Es gibt eine Menge Produkte und Möglichkeiten, die Unternehmen dabei helfen, verschiedenste Daten an ihr Lakehouse anzubinden. Im Folgenden werfen wir einen Blick auf eine Auswahl dieser.
File Basiert
Alle gängigen Data Lakehouses können Daten aus verschiedensten Dateien, wie csv, json oder Excel laden. Diese müssen dafür nur in einem angebundenen S3 Speicher oder ADLS abgelegt werden. Der große Vorteil dabei ist, dass die Daten auf diese Weise direkt historisiert sind und die Speicher mit sehr vielen Systemen kompatibel sind. Allerdings ist der Speicherbedarf hier auch höher als bei dem im Data Lakehouse verwendeten parquet Files und die Frage, wie die Dateien abgelegt werden können wird auch nicht beantwortet. Hierbei müssen weitere Tools wie Azure Data Factory o.ä. in Betracht gezogen werden.
Integriert
Manche Data Lakehouse Anbieter bieten ein integriertes Tool zum Laden von Daten. Ein Beispiel hierfür wäre das noch nicht veröffentlichte Lakeflow Connect Feature von Databricks, dass direkte Verbindungen z.B. zu Workday oder verschiedenen Datenbanken aufbauen kann. Der große Vorteil besteht darin, dass die Systeme sehr wartungsarm sind und einfach ohne Programmierkenntnisse in wenigen Minuten Einsatzbereit sind. Allerdings sind diese Systeme unflexibel – wenn ein System nicht unterstützt wird, muss man auf eine andere Methode setzen.
Azure Data Factory
Azure bietet mit Data Factory (ADF) ein sehr reifes Tool zum Aufbau von Data Pipelines. ADF kann an einige Systeme und Datenbanken (auch on Premise) angebunden werden und kann Daten Extrahieren, transformieren und in Dein Data Lakehouse laden.
ADF kann dabei sogar nachfolgende Prozesse in Databricks steuern und ist hervorragend integriert. Selbst selbstgebaute Skripte kann man direkt in ADF ausführen. Allerdings handelt es sich hier um ein weiteres Tool, das außerhalb von der Data Lakehouse Plattform betrieben, gewartet und verwaltet und bezahlt werden muss.
AWS und GCP bieten hier Konkurrenzprodukte die ähnlich funktionieren, wenn Du nicht auf Azure setzen willst.
Externe ELT-Tools
Noch einfacher geht es, wenn man auf einen externen Service Anbieter setzt, der sich speziell auf Datenvereinnahmung in Data Warehouses oder Lakehouses spezialisiert hat. Zu nennen sind hier im speziellen Fivetran und Airbyte. Bei Fivetran handelt es sich um ein SaaS Produkt, das Datenpipelines mit wenigen Klicks ermöglicht und die Daten unverändert von Quell- ins Zielsystem lädt. Das ist allerdings etwas kostspielig – zum Zeitpunkt dieses Artikels kosten 1 Mio. Zeilen ca. 1.000 Euro pro Monat, wobei die Kosten bei höheren Volumina etwas sinken.
Günstiger geht das mit Airbyte, wenn man es selbst hostet. Hier fallen theoretisch nur die Gebühren für Hosting und Wartung an. Man hat allerdings keinen Support an den man sich wenden könnte – diesen kann man jedoch gegen Aufpreis dazu buchen.
Wenn Zeit ein kritischer Faktor ist, und man Pipelines gut und schnell ohne viel Know-How aufsetzen möchte, führt an diesen Tools kein Weg vorbei.
Selbstgebaute Skripte
Was die oben genannten Tools leisten, ist alles andere als Magie. Ein Programmierer, der weiß was er tut, kann wiederverwendbare Pipelines für alle Tools bauen, die angebunden werden sollen. Der Vorteil liegt auf der Hand – die Skripte tun genau das was sie sollen und der Programmierer hat volle Kontrolle über das Handling der Daten und wie sie im Zielsystem ankommen.
Auch hier gibt es verschiedene Tools wie Meltano oder DLT-Hub, die dem Programmierer das Leben vereinfachen. Diese sind auch in der Regel kostenlos.
Das Monitoring läuft dabei wie bei allen anderen Pipelines in Deinem Data Lakehouse. Allerdings ist der Aufwand im Aufbau höher und der Programmierer sowie alle, die diese Pipelines warten müssen, sollten ein entsprechendes Know-How in Python, Spark und dem verwendeten Data Lakehouse mitbringen.
Change Data Capture (CDC)
Sehr häufig arbeiten wir im Data Lakehouse Kontext mit Datenbanken, die eine enorme Größe aufweisen. Ein Vollabzug dieser, würde jeweils sehr lange dauern und einiges kosten. Von der Last auf das Quellsystem und das Netzwerk ganz abgesehen.
Hier kann man Change Data Capture verwenden, um bei jeder Aktualisierung nur die Änderungen zu übertragen. Hier muss aber sowohl das Quellsystem, als auch das verwendete ELT-Tool mitspielen.
Am einfachsten geht das, wenn eine Datenbank z.B. eine Spalte in jeder Tabelle aufweist, die einen Zeitstempel der letzten Änderung angibt, oder eine Schnittstelle eine Delta-Funktion anbietet. Hier müssen z.T. Systemspezifisch Strategien entwickelt werden, die die Datenvereinnahmung entsprechend ermöglichen.
Ist das nicht möglich, bieten häufig Datenbanken eine eingebaute Funktion, die einen Changelog übertragen können.
Fazit
Datenvereinnahmung gehört bei einem Data Lakehouse aufgrund der Vielzahl von heterogenen Systemen zu den komplexesten Aufgaben eines Data Engineers.
Eine einfache One-Size-fits-all Lösung gibt es hier nicht und jedes System muss separat betrachtet werden.
