Apache Hop – der nächste große Sprung in der Datenintegration
Seite 2: Verbesserung der Codequalität
In hochkomplexen Datenprojekten, in denen Daten aus verschiedenen Quellsystemen zusammenfließen müssen, ist Testen unabdingbar. Testen erfordert das Auseinandersetzen mit einigen wichtigen Fragen: Stehen überhaupt Testdaten zur Verfügung? Ist das Testdatenset zu groß oder zu klein? Muss man sich Testdaten selbst erzeugen? Welche Testanforderungen haben die einzelnen Stakeholder der jeweiligen Quellsysteme? Wie testet man einzelne Datenstrecken im Vergleich zu ganzen Datenbankbeladungen? Was passiert beim Zusammenführen von Daten aus verschiedenen Quellsystemen, wenn sich die Datenstruktur eines Quellsystems ändert und man Anpassungen vornehmen muss? Wie stellt man sicher, dass vorgenommene Änderungen auch keine Seiteneffekte haben oder andere Änderungen am Code Fehler erzeugen?
Mit Apache Hop-Unit-Tests lassen sich Daten in Form von Eingabedatensätzen simulieren und die Ausgabe anhand von "Golden-Datasets" validieren. Hop-Pipelines ermöglichen es, testgetrieben zu arbeiten, aber auch Regressionstests durchzuführen, um sicherzustellen, dass alte, bereits behobene Probleme nicht erneut auftreten.
Für das Erstellen eines Unit-Tests stehen in Apache Hop verschiedene graphische Actions zur Verfügung, die sich jederzeit verwenden lassen. Darüber hinaus lässt sich bei Bedarf ein neues Data-Set anlegen und sofort nutzen.
Die Ausgabe nach jedem absolvierten Unit-Test liefert alle relevanten Informationen zum Test. In einer Datenbank abgelegt, vervollständigt sie die Dokumentation. Sämtliche für ein Projekt erstellten Unit-Tests lassen sich regelmäßig automatisiert – beispielsweise über Jenkins – ausführen, um ein kontinuierlich, gründlich getestetes Projekt sicherzustellen.
Entwicklerinnen und Entwickler können die Tests selbst auf der Oberfläche erzeugen oder auf zuvor definierte Test-Data-Sets im Projekt zurückgreifen. Das trägt zu höherer Codequalität bei und stärkt Sicherheit sowie Vertrauen in den neu generierten Code. Tests helfen außerdem bei der schnellen Ermittlung von Seiteneffekten und erleichtern das Leben eines Dateningenieurs enorm.
Für den Fall, dass keine Testdaten zur Verfügung stehen, bietet Hop die "Fake-Data"-Aktion, mit der sich eigene Testdaten generieren lassen. Sie greift auf die Library JavaFaker zurück und ermöglicht das Erstellen verschiedener, zum Testen benötigter Attribute. Das beschleunigt die Entwicklung, da man nicht mehr externe Testdaten mit hohem Aufwand manuell einlesen muss. Auch wenn kein direkter Zugriff auf das Quellsystem besteht oder es zu lange dauert, an die Quelldaten zu gelangen.
Verbesserte Zusammenarbeit in verteilten Teams durch visuelle Codevergleiche
Heutzutage greifen (fast) alle Softwareprojekte auf Versionsverwaltungs-Tools wie Git zurück. Doch in Kombination mit grafischen ETL-Tools treten dabei häufig Probleme auf. Gerade bei der gemeinsamen Arbeit großer verteilter Teams an einem Datenprojekt kann es schnell zu Überschneidungen oder Codeänderung an den gleichen Stellen kommen – und in der Folge zu Merge-Konflikten. Auch lassen sich Änderungen, beispielsweise bei einem Code Review, nur schwer nachvollziehen, da sie in einem zeilenbasierten Vergleich nicht direkt ins Auge springen. Das kostet Teams sehr viel Zeit sowie Analyse- und Abstimmungsaufwand, der sich durch eine visuelle Anzeige der Änderungen im Code verringern ließe. Hier kommt die visuelle Änderungsanzeige von Hop ins Spiel, mit der sich die Änderungen zu allen gespeicherten Versionen im Versionsverwaltungstool vergleichen lassen, sodass auf einen Blick die Änderungen für jeden Schritt ersichtlich sind. Sie hilft bei eventuell notwendiger Fehlersuche, ist aber auch bei Codereviews und Abstimmungen mit anderen Entwicklern nützlich.
Wie alle anderen gängigen Git-Funktionen findet sich dieses Feature ebenfalls im File-Explorer von Apache Hop. Anhand der Farbe der Pipelines lässt sich der jeweilige Status der einzelnen Files ablesen. Zwar ist die Funktion in Datenprojekten nicht grundsätzlich neu, aber mit Hop entfällt für Entwicklerinnen und Entwickler der bisher übliche Wechsel des Tools. Sie können in ihrer gewohnten Oberfläche weiterarbeiten, ohne Störungen im Arbeitsfluss.
Individualisiertes und nachvollziehbares Logging
Für die meisten Data Engineers ist Logging kein spannendes Thema. Nach der persönlichen Erfahrung des Autors verfolgen viele Projekte einen Alles-oder-Nichts-Ansatz: Entweder protokollieren die Verantwortlichen gar nicht oder sie erfassen jede mögliche Metrik und speichern alles. Die sinnvolle Anforderung in Datenprojekten liegt aber meistens in der Mitte. Hop zeigt sich auch hier als echter "Game Changer":
Der minimalistische Ansatz besteht darin, nur die Start- und Stoppzeiten des Gesamtprozesses zu loggen. Das funktioniert allerdings nur bei Projekten, deren potenzielle Fehleranfälligkeit gering ist und deren Datenprozesse sich einfach wiederholen lassen, ohne dass es zu Duplikaten kommt.
Viele Projekte erfordern ein intensiveres Logging. Um zu erfassen, was in einem Ladeprozess vor sich geht, sollte es für jeden Prozess ein Step-by-Step-Logging geben. So ließen sich in einem idealen Design der Start, das Ende sowie alle weiteren erforderlichen Informationen wie Fehler, Ausnahmen und Prüfungsinformationen etc loggen.
Apache Hop bietet die Option, eine Logging-Anforderung pro Pipeline zu steuern. Dadurch lassen sich mehrere ETL-Strecken mit unterschiedlichen Anforderungen auch individuell behandeln. Die Logging-Details sowie das Intervall der Logs lassen sich detailliert konfigurieren, um nur so viel wie nötig und so wenig wie möglich zu loggen.
Zum Steuern dient ein eigener Metadaten-Typ: Pipeline Log. Er loggt die Interaktion einer Pipeline mit einer anderen und schreibt diese Informationen in eine beliebige Datenbank.
Häufig benötigen Data Engineers den Output einer Pipeline für die Steuerung der nächsten Pipeline. Dafür bietet Hop einen weiteren Metadatentyp: Pipeline Probe. Er streamt Daten von einer laufenden Pipeline zu einer anderen. Die empfangende Pipeline kann die Informationen dann beispielsweise für Datenqualität, Datenprofilierung, Datenherkunft usw. verarbeiten.
Die zu speichernden Log-Daten landen in vielen Projekten vollständig in einer Datenbank oder entsprechend riesigen Logfiles. Das kann sich als problematisch erweisen, wenn nicht dokumentiert ist, wo die Informationen zu finden sind, denn Logfiles müssen leicht zugänglich und verständlich sein. Durch große unleserliche Logfiles oder Datenbanktabellen mit Logdaten zu navigieren, ist vielen Usern nicht zuzumuten. Häufig müssen in Projekten nicht nur Datenbankadministratoren, sondern auch Helpdesk-Mitarbeiter, Geschäftsanalysten und Wirtschaftsprüfer einsehen können, was in den Protokollen steht – und jede dieser Gruppen hat unterschiedliche Erwartungen, wie sie an die Daten gelangt.
Mithilfe der Log-Pipeline lassen sich die Anforderungen der unterschiedlichen Nutzergruppen jederzeit und nachvollziehbar in geeigneter Form aufbereiten und in den zugehörigen Zielen bereitstellen. So lässt sich etwa das Logging einer Pipeline automatisiert für drei verschiedene Zielgruppen aufbereiten und zur Verfügung stellen.
Mehr Flexibilität dank Run Configurations
Eine essenzielle Frage vor jedem Datenprojekt ist, in welcher Umgebung die erstellten Daten-Pipelines laufen sollen. Die dafür notwendigen Entscheidungen lassen sich aber häufig noch gar nicht vor dem Projektstart treffen. Reicht es, die Pipelines auf einem lokalen Server laufen zu lassen? Wachsen die Daten so schnell, dass man gleich auf Apache Spark oder auf Google DataFlow setzen sollte? Viele Anforderungen ändern sich während eines Projekts. Gerade in der agilen Entwicklung kann es sich schnell als Problem erweisen, wenn man auf die falsche Umgebung gesetzt hat.
Apache Hop empfiehlt sich in dieser Situation aufgrund seiner Flexibilität. Data Engineers können auf der Plattform ihre Umgebungen frei wählen und jederzeit ändern. Über Run-Konfigurationen lassen sich sowohl die Fähigkeiten von Hop als auch anderer Plattformen wie Apache Beam und vergleichbaren nutzen. Datenteams entwerfen einmalig ihre gewünschten Hop-Workflows und -Pipelines und können diese anschließend überall dort ausführen, wo sich die zu verarbeitenden Daten am sinnvollsten anwenden lassen.
