ETL-Prozesse sind ein essenzieller Bestandteil der Datenbewirtschaftung in Unternehmen und damit auch häufig ein zentraler Aufwandstreiber im Daten-Zeitalter. Diese Prozesse können recht einfach sein, zum Beispiel wenn bestimmte Tabellen zur besseren Verfügbarkeit oder Redundanz auf anderen Systemen gespiegelt werden sollen. Komplexere ETL-Prozesse setzen Data Warehouse-Konzepte um. Dies könnte der Ansatz der Slowly Changing Dimensions sein oder sie setzen beispielsweise die Historisierung von Daten, die Strukturierung nach dem Dimensionsmodell (Fakten- und Dimensionstabellen) oder die Kombination aus beidem um. Zur Implementierung und Ausführung der ETL-Prozesse werden vorwiegend spezifische ETL-Tools wie Talend, Informatica, Pentaho oder auch SAS bzw. PL/SQL verwendet. Diese nutzen grafische und/oder textuelle Ansätze mit eigenen Sprachen, um die Erstellung zu vereinfachen und komplexe ETL-Prozesse verständlich und wartbar zu machen.
Aus der Vogelperspektive betrachtet ist der große Vorteil der Spezial-Tools der Schatz an konfigurierbaren Komponenten, die wiederverwendbar sind. Damit begibt man sich in vorgefertigte Schemata – was Vor- und Nachteil sein kann. Es fallen aber auch spezielle Herausforderungen auf.
Probleme beim Einsatz von spezialisierten ETL-Tools
- Zuerst ist das Testen der ETL-Prozesse auf Korrektheit zu nennen. Tests stellen sicher, dass die eingesetzten Transformationen funktionieren und das erwartete Ergebnis auch eintritt. Diese Tests werden bei den ETL-Tools oft manuell durchgeführt und sind daher recht aufwendig. Die Entwickler müssen während der Entwicklung ständig überprüfen, ob die Ergebnisse der ETL-Schritte korrekt sind, indem sie die Ausgabedaten manuell prüfen. Eine Automatisierung von Regressionstests wäre an dieser Stelle wünschenswert. Automatische Tests finden jedoch vorwiegend nur auf technischer Ebene statt. Das heißt, die ETL-Prozesse werden auf einem Testsystem ausgeführt und auf auftretende technische Fehler hin überprüft. Qualitative bzw. fachliche Fehler fallen in diesem Schritt nicht auf und es bleibt zu hoffen, dass sie zumindest bei der manuellen Abnahme bemerkt werden. Zudem gilt: Generieren ETL-Tools als Zwischenschritt für die Ausführung Code wie bspw. Talend oder die grafischen SAS-Werkzeuge, macht dies ein Debugging oft schwer bis unwirtschaftlich.
- Ein weiterer Aspekt ist die Verfügbarkeit von Entwicklern. Zur Verwendung der spezialisierten ETL-Tools ist umfangreiches Vorwissen in Form von Trainings, Workshops, Zertifizierungen und Projekterfahrung notwendig. Dieses Spezialwissen macht es schwierig, ausreichend und schnell Entwickler für die Umsetzung von umfangreicheren Projekten zu finden. ETL-Werkzeugwissen ist definitiv Spezialistenwissen.
- Schließlich sind beim Einsatz eines ETL-Tools noch die Lizenzkosten zu nennen. Das beinhaltet natürlich die monetären Kosten selbst, betrifft aber auch die Flexibilität. Damit ist nicht nur der Wechsel von einem ETL-Tool zu einem anderen gemeint. Auch projektbedingte personelle Spitzen oder Änderungen in der Last- und Deployment-Situation ziehen bei den Spezialwerkzeugen oft Lizenz-Fragen nach sich.
These: Die Vorzüge moderner Java-Entwicklungs- und Betriebsumgebungen, der Prozesse und Werkzeuge für Daten-Operationen wie Spring Data oder Apache Camel, wiegen die Vorteile spezifischer ETL-Tools mittlerweile auf.
Bottom-up: ETL mit Java?
Eine Bottom-up-Umsetzung mit möglichst einfach nachvollziehbarem Java-Code und etablierten OpenSource-Komponenten löst unter gewissen Voraussetzungen die genannten Probleme. In Java können beispielsweise Unit Tests eingesetzt werden, um auch qualitative Tests zu automatisieren. Das steigert nicht nur die Effizienz und Korrektheit der Tests, sondern erleichtert auch die Wartbarkeit maßgeblich. Unit Tests ermöglichen eine feinere Granularität der getesteten Funktionen. Diese Tests zeigen durch Änderungen an dem ETL-Prozess beschädigte Funktionen direkt auf und machen eine Korrektur einfach. Continuous Integration, Git-Branches, Dependency Management und viele verschiedene Werkzeuge für statische Code-Analysen, die es für die ETL-spezifischen Werkzeuge in diesem Reifegrad nicht gibt, lassen auf eine verringerte Fehlerquote bei diesem Ansatz hoffen.Auch die Entwickler sind bei einem Java-Ansatz einfacher zu finden. Grundlegende Aspekte aus dem Bereich des Data Warehousing sollten bei den Java-Entwicklern geschult werden, aber spezielles Wissen für den konkreten Einsatz eines ETL-Tools ist nicht mehr notwendig, da zur Entwicklung allgemein bekannte Java-Techniken eingesetzt werden können. Falls die Java-Entwickler sogar aus der eigenen operationalen Entwicklung übernommen werden, kann ihr internes Wissen von den operativen Datenbanksystemen viel zur ETL-Prozess-Entwicklung beitragen, da diese meistens die operativen Datenbanksysteme als Datenquellsysteme nutzen. So wird das bestehende fachliche Domänenwissen zum Datenmodell, das ein Java-Entwicklerteam aufbaut, optimal genutzt. Damit können Teams universeller im Unternehmen eingesetzt werden und Erfahrungen aus dem Bereich des Software Engineerings (Tests, dezentrale Entwicklung, kontinuierliche Integration) auch auf die ETL-Domäne übertragen werden. Zudem ist eine DDD-Domäne auf diese Weise fachlich noch besser abgrenzbar, also die Idee, eine fachliche Domäne quer durch den Technologie-Stack einem definierten Team zu überantworten.
Auch ein „Rückkanal“ zu den Anwendungsdaten, durch den zum Beispiel Data Mining-Erkenntnisse auf Basis von DWH-Daten in Anwendungen zu integrieren sind, ist vermutlich immer häufiger zu erwarten. Hier mehrfach Personal und Basistechnik zu wechseln, erscheint nicht sinnvoll.
These: Anwendungsentwicklung und Datenbewirtschaftung werden sich zunehmend vermischen. Und das ist gut so!
Bezüglich etwaiger Lizenzkosten bietet Java die größtmögliche Flexibilität. Insbesondere Frameworks wie Spring können für die bessere Lesbarkeit des Java-Codes genutzt werden. Das hat den Vorteil, dass einmal entwickelte ETL-Prozesse in Java nicht neu geschrieben werden müssen, falls man sich dafür entscheiden sollte, auf ein spezialisiertes ETL-Tool umzusteigen. Vorhandene Java-ETL-Prozesse können weiterhin ausgeführt werden und neue ETL-Prozesse können dann auf dem neuen Ansatz aufbauen.
Lessons Learned für den Einsatz von Java für ETL
Um Erfolg bei der Umsetzung mit Java zu haben, sind einige Voraussetzungen zu erfüllen.- Zum einen ist es sinnvoll, dass das bereits angesprochene Grundlagenwissen zu Data Warehousing vorhanden ist. Fehlende Kenntnisse führen hier zu vermeidbaren Fehlern. Die Entwickler benötigen jedoch auch Erfahrung in der Umsetzung von performantem Code, da ETL-Prozesse oft festgelegte Zeiträume für die Ausführung vorgegeben haben (außerhalb der Arbeitszeit), in denen die Prozesse starten und abschließen müssen. Auch bei großen Datenmengen müssen die Prozesse entsprechend performant sein, um diese Vorgabe nicht zu verletzen. Bei großen Datenmengen müssen die Entwickler zusätzlich auch sicherstellen können, dass die Grenzen des Arbeitsspeichers respektiert werden, indem die Daten in Portionen verarbeitet werden oder gleich vollständig in der Datenhaltungsschicht verbleiben.
- Sinnvoll ist vor allem auch der Einsatz des Java Spring Data Frameworks, da die eingeführten Abstraktionen sehr zur Lesbarkeit des Programmcodes beitragen und den Umgang mit verschiedensten Datenquellen vereinheitlichen.
- Typische Datenbank-Operationen wie Joins oder Aggregationen sind in der Java-Welt nicht implementiert. Diese müssen direkt durch die Nutzung von Datenbank-Funktionalität sichergestellt oder bei Bedarf in Java umgesetzt werden, um auf Listen von Objekten statt auf Tabellen zu operieren. Das stellt einen Zusatzaufwand dar, der erst einmal geleistet werden muss – sich aber rentiert und mit den Java-Mitteln einfach wiederverwendbar wird. Spring, Apache Camel, Spark und das Hadoop-Ökosystem sind etablierte Komponenten, die vermuten lassen, dass die Welt der Application Integration und Big Data-Infrastrukturen ohnehin fest in Java-Hand sind.
These: Java ist die Sprache der Big Data-Tools – mit gängigen Datenmengen und Werkzeugen wird man hier mit ETL-Prozessen nicht schneller an Leistungsgrenzen stoßen als mit den spezifischen Werkzeugen.
- Relevant ist ebenfalls der Umfang des ETL-Prozesses. Ein Prozess sollte nicht zu viele Transformationen auf einmal enthalten, um die Komplexität handhabbar zu halten. Schwierig wird es aber bei komplexeren Aufgaben wie der Verwaltung von Slowly Changing Dimensions, die viele Schritte zur Umsetzung erfordern. Ausgereifte grafische ETL-Tools bieten dafür vorgefertigte Komponenten, die die Anzahl der Prozessschritte und damit die Komplexität stark verringern. Deren Einsatz wie auch die anderen Aspekte der Tools müssen jedoch erstmal erlernt werden, um den Vorteil nutzen zu können. Auch die Konfigurierbarkeit ist begrenzt. Demgegenüber stehen in der Java-Welt viel Erfahrung zur Modularisierung und die Möglichkeit, über Versionsverwaltung und Diffs feingranular Änderungen nachzuverfolgen und zu integrieren, was mit den grafischen Ansätzen im Allgemeinen problematisch ist.
Fazit
Wenn die nötige Erfahrung bei Java-Entwicklern vorhanden oder herstellbar ist, können viele der ETL-Prozesse sinnvoll mit Java-Mitteln abgebildet werden. Die dazu verfügbaren OpenSource-Werkzeuge sind auf hohem Niveau bzgl. Reifegrad und Performance.Das ermöglicht den Einsatz von Unit Tests und anderen Software Engineering-Techniken, um die Softwarequalität und Wartbarkeit zu erhöhen und eine agilere Entwicklung im Sinne der Eigenverantwortlichkeit in einer Domäne zu ermöglichen. Fehlende Datenbankoperationen in der Java-Welt erhöhen den initialen Aufwand, da sie erst einmal implementiert oder erlernt werden müssen.
Demgegenüber steht insgesamt eine deutlich erhöhte Flexibilität in technischer und vor allem organisatorischer Hinsicht.
Hinweis: Der Artikel fasst im wesentlichen Erkenntnisse aus Literatur-Recherche, eigenen Experimenten und Experten-Interviews aus der Master-Arbeit von Vitali Friesen an der WWU Münster 2018 zusammen.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
