Die Krux mit der DWH Automatisierung

Da schnell das Problem auftritt, dass viele statische Jobs sich ähneln, wurde nach einer Lösung gesucht, die Jobs dynamisch zu erstellen. Beim simplen Migrieren, Zusammenführen und Teilen von Daten muss dann nicht für jede einzelne Tabelle ein ETL-Job erstellt werden.

Bei mehreren Projekten existierte das Problem, dass die Jobs nahezu identisch waren und teilweise bis zu fünfzig Tabellen geladen werden mussten. Eine Transformation wurde erstellt und mit Copy und Paste die weiteren kopiert und nur die variablen Parameter ausgetauscht. Ewiglange Ketten an Jobs und Transformationen waren die Folge.

Nicht lange ließen in unserer Zeit der agilen Entwicklung die ersten Änderungswünsche der Kunden auf sich warten. Diese mussten sehr oft bis fast immer an nicht einer Transformation, sondern bei allen durchgeführt werden, was eine repetitive und unnötig zeitintensive Aufgabe war.

Darum war es an der Zeit, sich mit den Möglichkeiten der dynamischen Jobs im verwendeten Tool auseinanderzusetzen. In diesem Fall mit dem Pentaho Data Integration Tool Spoon (ehemals Kettle).

Die Möglichkeiten dahingehend sind sehr begrenzt, da eher auf einen statischen Aufbau ausgelegt.

Es sollten die Standardfunktionen der offiziellen Version verwendet werden, um zukünftige Probleme mit der Kompatibilität von externen Plugins zu vermeiden. Auch war die Zeit sehr knapp, wodurch eine eigene Plugin-Entwicklung in Java für PDI-Steps ausgeschlossen war.

Die ausgeschlossene Eigenentwicklung hatte aber auch ihren Vorteil, da man sich intensiv mit den einzelnen Steps auseinandersetzen musste, um einen Workaround für bestimmte Funktionen zu bauen. Das erhöhte die Toolkenntnis immens.

Aus Zeitgründen konnte weder ausgiebig getestet noch ein größeres Konzept entwickelt werden. Dies ergab sich mit der Zeit und ist bis dato auch noch nicht abgeschlossen. Täglich kommen neue Erkenntnisse und Ideen, um die zukünftigen Projekte effizienter und schneller zu verwirklichen.

Die Projekte liefen gleichzeitig über einen längeren Zeitraum, aber mit mehreren Abgabeterminen der verschiedenen Jobs. Das jedoch ermöglichte, dass bei jeder Iteration neue Konzepte probiert werden konnten. Die Konzepte konnten dann bei den darauffolgenden Iterationen auf die jeweils anderen Projekte übertragen werden oder sie wurden verworfen.

Die einzelnen Transformationsvorgänge in separate wiederverwendbare Module zu packen, wie es in der Softwareentwicklung üblich ist, ist nur über Umwege möglich und hat Einbußen in der Performance zur Folge. Weitere Tests in der nahen Zukunft werden noch genauer zeigen, wie sehr sich die Performance zwischen statischen und dynamischen Jobs unterscheidet. Ebenso leidet aufgrund des Aufbaus der dynamischen Jobs in Spoon die Parallelisierung der untergeordneten Jobs.

Für die Zukunft ist es auf jeden Fall den größtenteils nur denktechnischen Mehraufwand wert, da so gut wie der gesamte Projekt- und Jobaufbau (auf dieses Tool bezogen) bei zukünftigen Projekten wiederverwendet werden kann und nur die spezifischeren untergeordneten Transformationen verändert werden müssen.

Autor: Stefan Endl