ETL-Methodenhandbuch

Das ETL-Methodenhandbuch haben wir entwickelt, um die gängisten Vorgehensweise in der klassischen ETL-Entwicklung zu beschreiben und vor allem um teuere Fehler zu vermeiden.

Dieses kann als Entwicklungsleitfaden genutzt werden, aber auch um die eigenen Prozesse kritisch zu hinterfragen und evtl. zu optimieren.

Das Handbuch (im PDF-Format) kann über unser Kontaktformular bezogen werden und kostet einmalig 19,90 Euro (inkl. MwSt.).

Auszug:
„Wir brauchen ein DWH“.
Diese 4 Worte können einen Prozess auslösen, der oft erstaunlich komplex, fehlerbehaftet und sehr teuer sein kann. In meiner langjährigen Beratertätigkeit als ETL-Backend-Entwickler habe ich kaum ETL-Prozesse gesehen, die frei von Fehlern waren. Oft waren die Projekte dermaßen an die Wand gefahren, dass im Grunde der ganze ETL-Prozess nochmal entwickelt werden musste oder ein mühsames Refactoring anstand. Es lohnt sich also ETL-Prozesse im Vorfeld sorgfältig zu planen und Bestpractice-Methoden anzuwenden um schon frühzeitig grundsätzlich Fehler zu vermeiden, die das ganze Projekt zum Scheitern bringen können. Ein DWH ist kein „one time shot“, sondern muß auch nach Fertigstellung wartbar und skalierbar sein und dabei aber kontinuierlich die richtigen Zahlen liefern.

„Wir brauchen neue Zahlen“
Man sollte hier der Versuchung widerstehen, die auf Daten lauernden Fachabteilungen schnell zu versorgen zum Preis von am Ende kaum mehr beherrschbaren ETL-Prozessen die in gegenseitigen Abhängigkeiten stehen. Ist das DWH an diesem Punkt angekommen, kann man schon in die höchste Alarmstufe schalten, weil das System tatsächlich kurz vor dem Zusammenbruch steht. Heißt, jede Änderung wird extrem komplex, weil die Abhängigkeiten geprüft werden müssen. Um sich unabhängig von anderen Prozessen zu machen wird dann wieder ein Extra-Prozess gebaut der wiederum Extra gewartet werden muss usw.

„Das DWH liefert falsche Zahlen“.
Es gibt ein oberste Gebot in der ETL-Entwicklung: „Die erzeugten Daten müssen korrekt sein“.
Korrekt heißt hier, die Daten kamen so aus dem Quellsystem und wurden auch genau, wie angefordert verarbeitet.
Es muss also der Beweis geliefert werden, wie die Daten geladen und prozessiert wurden und es ist jederzeit nachvollziehbar, warum ein bestimmter Wert berechnet oder ein bestimmter Filter gegriffen hat. Ich nenne das „Forensik“. Nur mit einer guten Forensik kann man Beweise führen und nur dann hat ein DWH langfristig Vertrauen. Die Möglichkeit der Forensik muss man aktiv implementieren.

„Das DWH ist zu langsam“
Morgens um 8:00 Uhr will die Geschäftsführung die Daten vom Vortag auf dem Tisch haben. Das ist eine typische Anforderung an ein DWH bzw. die vorhergehenden ETL-Prozesse. Während der ersten Entwicklungsphase und kurz nach dem Rollout ist die Ladezeit noch im grünen Bereich. Aber wie sieht es perspektivisch aus?
Die Performance ist ein kritisches Thema. Sich nur darauf zu verlassen, dass die Hardware-Ausstattung sich verbessert, kann schnell ins Auge gehen. Wenn ein DWH mal in Betrieb genommen wurde, verlängern sich auch die Laufzeiten, weil die Datenmengen naturgemäß anwachsen und wahrscheinlich auch immer weitere Ladeprozesse integriert werden.
Es lohnt sich also, von Anfang an auf eine gute Performance zu achten damit die Laufzeiten im besten Fall nur logarithmisch, im immer noch guten Fall linear und nicht im schlechtesten Fall exponentiell anwachsen.
Dieses Buch soll helfen, grundsätzliche Fehler zu vermeiden. Es ist, wie der Titel schon sagt, sehr auf Methodik und nicht auf spezifische Datenbanken oder ETL-Tools ausgelegt. In jedem Kapitel sind Handlungsanweisungen beschrieben, die Ihnen dabei helfen sollen, spezielle Probleme bei der ETL-Entwicklung zu lösen und Ihre Prozesse zu optimieren. Idealerweise schon bei der Implementierung oder auch beim Refactoring von ETL-Prozessen.

Für wen ist dieses Handbuch gedacht?
Zuerst, es ist nicht gedacht für den absoluten Neuling in diesem Bereich, der bisher noch niemals mit einem ETL-Tool oder einer SQL-Datenbank gearbeitet hat. Wer allerdings noch nie in diesem Bereich gearbeitet hat, findet hier schon einen Leitfaden, welche Arbeiten auf einen zukommen können.
Das Buch richtet sich aber vielmehr an ETL-Entwickler, die gerade an einem ETL-Projekt arbeiten und über das eine oder andere Problem stolpern und einen Lösungsansatz brauchen. Genau hier setzt das Buch an. Hilfestellung bei spezifischen Problemen in der ETL-Entwicklung. Dafür ein kurzer Ausblick, welche Themen vertieft behandelt werden:

• Quelldaten sicher, effizient und performant einlesen
• Einen Stagingbereich aufbauen
• Daten richtig historisieren
• Eine Datenforensik aufbauen
• Auch mit schlechten Daten umgehen und nebenbei ein Qualitygate aufbauen
• Abgegrenzte ETL-Schichten aufbauen
• Einen ETL-Prozess robust und wiederaufsetzbar aufbauen
• Datenbank Performancebasics bei der ETL-Beladung
• Basics bei der DWH-Datenmodellierung
• Slowly-Changing-Dimensions implementieren
• Fakttabellen effizient aufbauen
• Guten und schlechte ETL-Entwicklungszyklen
• Eine ETL-Codeintegration aufsetzen
• Sinnvolle ETL-Dokumentation
• Ein ETL-Projekt organisieren

Auszug aus dem ETL-Methoden-Handbuch