In the Code: Data Pipe­line auto­mati­siert erstellen

Simon Hefti beschreibt, wie man mit Automatisierung die Hürden der klassischen Verfahren zur Gewinnung von Daten überwindet.
 
Allen ist klar: Daten enthalten Wert, und diesen Wert zu nutzen ist ein betriebswirtschaftliches Muss. Aber der Prozess, die vorhandenen Daten in einen nutzbaren Zustand zu bringen, ist aufwändig und langwierig. Es gilt, die Daten in den verschiedenen Silos zu identifizieren und zu verstehen, die allfälligen Synonyme, Homonyme und Duplikate zu bereinigen, und Daten schlechter Qualität auszusortieren. Mit anderen Worten: es braucht eine Data Pipeline.
 
Der Bau einer solchen Data Pipeline ist lange Zeit von Hand erfolgt. Das Stichwort heisst ETL und steht für Extract – Transform – Load. Diese Kurzformel besagt, dass Daten aus dem Quellsystem extrahiert, danach in die Zielform überführt (transformiert) und schlussendlich ins Zielsystem geladen werden müssen.
 
ETL-Strecken haben einen angeschlagenen Ruf: zwar erledigen sie ihre Arbeit gut und zuverlässig, aber ihr Aufbau ist schwerfällig und aufwändig. Und natürlich ist die manuelle Arbeit fehleranfällig. Was zur Folge hat, dass Anpassungen und Erweiterungen der Data Pipeline nur zögerlich in Angriff genommen werden.
 
Hier bricht ein Zielkonflikt auf: um Wert aus Daten schaffen zu können, müssen die Daten aktuell, genau und umfassend sein. Das Bereitstellen der Daten über eine ETL-Strecke leistet dies zwar, braucht dafür aber zu lange. Entsprechend wird mit verschiedenen Ansätzen versucht, die benötigten Daten schneller bereitzustellen.
 
Ein Ansatz, der auf der Hand liegt, ist die Automatisierung des Baus der ETL-Strecke.
 
Potentielle Vor- und Nachteile der Automatisierung
Bevor wir in dieses Thema eintauchen: was wären denn die Vor- und Nachteile der Automatisierung?
 
Natürlich hat die Automatisierung Nachteile, wie alle wissen, die sich an Model Driven Programming erinnern.
 
Einer der grössten Stolpersteine sind Fehler in der Konfiguration. Die gibt es natürlich immer. Das Problem: das debugging kann aufwändig sein, insbesondere, wenn der Zyklus bis zur Ausführung des generierten Codes lang ist. Hier spielen die aufkommenden Werkzeuge ihren Trumpf aus, in dem sie den Entwicklungsprozess unterstützen und Hilfsmittel bereitstellen, die solche Fehler bereits während dem Erfassen der Konfiguration aufzeigen.
 
Ein anderer Nachteil ist, dass sich die Automatisierung in der Regel nicht nachrüsten lässt. Dies liegt an den technischen Vorgaben, die der Automat verlangt – allen voran der Data Vault. Natürlich ist "kompletter Neubau" nur selten eine Option. Dagegen lässt sich die Automatisierung ergänzen, so dass die Erweiterung eines bestehenden Systems um neue ETL-Strecken möglich ist.
 
Die Vorteile der Automatisierung liegen auf der Hand. Zum einen wird die Bauzeit für die ETL-Strecke massiv verkürzt, da repetitive Arbeit wegfällt. Gleichzeitig kann die Konfiguration archiviert und versioniert werden, was Nachvollziehbarkeit und die erleichterte Wartung ermöglicht.
 
Schlussendlich lässt sich die ETL-Strecke sehr einfach dokumentieren - die relevante Information ist ja vorhanden – was insbesondere für die bekannte Frage "woher kommen diese Daten?" sehr hilfreich ist. Mit anderen Worten: die data lineage ergibt sich sozusagen als Neben-Produkt aus dem Bau der Data Pipeline und ist nachvollziehbar und dokumentiert.
 
Neben der Automatisierung gibt es weitere Ansätze, um den Zielkonflikt aufzubrechen, die in Kombination mit der Automatisierung eingesetzt werden können. Stichworte sind Data Lake und ELT (also das Ausführen der Transformations-Operations so nahe an den Daten wie möglich). Dazu mehr in einem späteren Aufsatz.
 
So baut man eine automatisierte ETL-Strecke
Also, wie lässt sich der automatisierte Bau von ETL-Strecken nun tatsächlich realisieren?
 
Der Grundgedanke liegt darin, an so vielen Stellen wie möglich Meta-Informationen zu nutzen, statt die benötigte Information von einem ETL-Programmierer abzufragen. Ein Beispiel: Der Load-Schritt kann so gestaltet werden, dass der ETL-Entwickler die Quell-
Abbildung: Drei Wege zum Mapping von Daten.
und die Zieltabellen graphisch dargestellt hat und er die gewünschten Attribute mit der Maus verbindet und so die ETL-Strecke aufbaut. So funktionieren die ETL-Werkzeuge der ersten Stunde. Oder: die ETL-Strecke wird auf Grund der bekannten Strukturen der Quell- und die Zieltabellen von einem Programm automatisch erstellt. Der Effizienzgewinn dieser Variante ist offensichtlich: deutlich geringerer Entwicklungsaufwand, massiv tieferer Wartungsaufwand und schnellere Durchlaufzeiten.
 
Ein Schlüsselelement für diese Automatisierung ist der Data Vault.
 
Dabei handelt es sich um ein System zur Datenmodellierung, das auf drei atomaren Einheiten aufbaut: Hub, Satellit und Link. Ein einfaches Beispiel: die Aufgabe ist, einen Kunden, einen Vertrag und deren Beziehung abzubilden. Im Data Vault Modell gibt es dazu zwei Hubs: customer und contract. Rund um diese Hubs gibt es verschiedene Satelliten, die Eigenschaften des Kunden und des Vertrags tragen, zum Beispiel den Vornamen oder die Vertragsnummer. Schlussendlich gibt es eine Link-Tabelle, die die Verbindung zwischen Kunden und Vertrag herstellt.
 
Aber das ist doch kompliziert?!
 
Tatsächlich ist diese Modellierung aufwändiger als die klassische relationale Modellierung. Diese würde die Attribute auf den Entitäten abbilden (Vorname bei Person, Vertragsnummer beim Vertrag) und eine direkte Beziehung zwischen den Tabellen herstellen.
 
Trotzdem bietet der Data Vault wichtige Vorteile – allen voran die Erweiterbarkeit. Verändert sich im Laufe der Zeit das Datenmodell, so fügt der Data Vault einfach einen weiteren Satelliten hinzu. Ein zweiter wichtiger Vorteil ist die parallele Beladbarkeit. Das bedeutet, dass die einzelnen Tabellen unabhängig voneinander befüllt werden können. Im beschleunigten Geschäftsumfeld (Stichwort Near Realtime) ein wichtiger Faktor.
 
Der Grund für die parallel Beladbarkeit liegt übrigens daran, dass die einzelnen Einträge an Hand von intrinsischen Schlüsseln miteinander verknüpft werden, an Schlüsseln also, die sich aus dem Inhalt des Eintrags ergeben, zum Beispiel durch die Berechnung eines MD5-Hashes. Typische Hash-Keys sind der Business Key Hash (BKH), der Foreign Key Hash (FKH) und der Full Record Hash (FRH).
 
Schlussendlich ermöglicht der Data Vault die volle Auditierbarkeit, da jede Änderung lückenlos mitgeschrieben wird – oft sogar im "insert only" Modus.
 
Im Kontext der automatisierten Erstellung von ETL-Strecken bietet der Data Vault gerade durch den simplen und mechanischen Aufbau enorme Vorteile. Das Grundrezept ist das Folgende:
  • Erstelle für jedes Geschäftsobjekt aus einem Quellsystem einen Hub.
  • Erstelle für jedes Attribut (oder jede Attributgruppe) dieser Geschäftsobjekte einen Satelliten.
  • Erstelle für jede Beziehung zwischen Geschäftsobjekten im Quellsystem einen Link.
Mit diesem Ansatz geht es "ziemlich geradeaus", um die Daten aus den Quellsystemen an einem Ort zusammenzuführen. Einfach brauchbar sind die Daten damit aber natürlich noch nicht.
 
Die nächsten Schritte – das Zusammenführen der Daten aus verschiedenen Quellen, das Deduplizieren und Bereinigen – brauchen natürlich zusätzliche Information: das eigentliche Mapping.
 
Dabei gibt es verschiedene mögliche Wege. In der Figur in der Abbildung werden drei wichtige Wege schematisch gezeigt:
  • Im einfachsten Fall werden die Daten eins-zu-eins abgebildet. Dann gibt es keine Mapping-Aufgabe zu erledigen.
  • Im schwierigsten Fall ist das Mapping so komplex, dass es ausprogrammiert werden muss.
  • Dazwischen liegen der Fall der Unification, also des Zusammenzugs von Daten aus verschiedenen Systemen (Vertrag im Vertragssystem, Preis im Preissystem).
Unterdessen in der Praxis erprobt
Dass dieser Ansatz tatsächlich funktioniert und die ETL Strecke automatisiert erstellt und gepflegt werden kann, zeigt das Aufkommen von Tools, die diesen Prozess unterstützen, wie zum Beispiel WhereScape oder AnalytiX DS, aber auch spezifische Entwicklungen, wie wir sie bei D ONE verwenden.
 
Der Grundgedanke ist immer der Gleiche: die ETL-Strecke soll durch Konfiguration definiert werden. Der Rest soll der Automat übernehmen.
 
Es ist klar, dass die Zeiten der manuellen Definition von ETL-Strecken vorbei sind. Die Nachfrage nach zuverlässigen Daten ist hoch, ebenso wie der Zeitdruck für deren Bereitstellung. Und es ist auch klar, dass ein Minimum an Struktur notwendig ist, die im Data Lake der einfachsten Form fehlt. Denn wie in anderen arbeitsteiligen Prozessen ist der Lego-Gedanke essentiell, also die Möglichkeit, (Daten-)Zwischenprodukte verwenden und weiter veredeln zu können.
 
Die automatisierte Bereitstellung von ETL-Strecken auf Grund von Konfiguration bietet einen praxiserprobten Weg, der den bisherigen Ansatz konsequent weiterführt und geschickt erweitert. (Simon Hefti)
 
Über den Autor
Simon Hefti ist Gründungspartner von D ONE, dem Beratungsunternehmen für datenbasierte Wertschöpfung. In seiner Dissertation hat er den Ursprung des Sonnenwindes erforscht. Als Unternehmer und Business Scientist begleitet er Kunden aus unterschiedlichsten Branchen in technischen, konzeptionellen und organisatorischen Fragen.