DWH-Entwicklung im Umbruch

Immer mal wieder werde ich gefragt: Was muss ein guter Data Warehouse (DWH) Entwickler oder eine gute Entwicklerin können? Als ich vor über zehn Jahren in die DWH-Entwicklung einstieg, stellte ich die gleiche Frage. Die Antwort damals lautete: Lies mal die Bücher von Kimball (Stichwort „Dimensionale Modellierung“) und lerne SQL (SQL impliziert dabei auch Grundkenntnisse der relationalen Datenbanktheorie). Das sind beides ziemlich universelle Grundlagen, die auch heute noch zum Grundwortschatz eines jeden DWH-Entwicklers gehören sollten. In diesem Beitrag gehe ich der Frage nach, was im Jahr 2020 so alles von DWH-Entwicklern verlangt wird.

Nach wie vor ist das dimensionale Modell dasjenige, welches Fachanwender mit Abstand am einfachsten verstehen, wenn sie selber Auswertungen erstellen müssen. Selbst wenn im Core-DWH häufig auch eine 3NF oder Data Vault Modellierung zum Zuge kommt, spätestens auf Data Mart Ebene und damit dem üblichen Zugriffslayer für die Endbenutzer kommt das dimensionale Modell zum Tragen. Interessanterweise ist das dimensionale Modell nicht nur für uns Menschen gut verständlich, sondern auch optimale Grundlage für In-Memory-Datenbanken und darauf aufbauende BI-Werkzeuge (Weiterführende Infos mit Beispielen aus der Microsoft-Welt hier und hier).

SQL wiederum ist die universelle Basissprache, um DWH-Strukturen anzulegen, mit Daten zu beladen und diese wiederum abzufragen. Selbst wenn einem klassische ETL-Werkzeuge und DWH-Automationswerkzeuge viel Arbeit bei der händischen Entwicklung von SQL-Code abnehmen, so wird man den generierten Code mindestens lesen können und bei Bedarf optimieren müssen. Natürlich gibt es viele Variationen und Erweiterungen zum eigentlichen Standard, z.B. für Graph-Abfragen, aber gerade auch neue Datenbankanbieter wie Snowflake setzen voll auf SQL als Grundlage.

Insbesondere bei der Verwendung von webbasierten Quellsystemen und webbasierten Ziel-Datenbanken gibt es aber noch einen anderen „Sprachbedarf“ neben SQL: Shell-Programmierung, z.B. mittels PowerShell. Der Grund dafür liegt u.a. in der Nutzung von Dateischnittstellen. Um Daten zwischen webbasierten Systemen auszutauschen, werden diese oft in CSV, XML oder JSON Dateien exportiert und über FTP-Server, Data Lakes usw. verteilt. Zudem lassen sich viele Datenbanken schneller über einen Datei-basierten Bulk-Load befüllen, als einzelne Datensätze via SQL-Insert hinzuzufügen. Das Erstellen, zippen und kopieren der Dateien wird dann eben über eine Shell programmiert. Oder aber die Daten werden via REST und OData APIs ausgetauscht – oft ebenfalls unter Verwendung von Shell-Skripten, um Daten mindestens temporär in Dateien zwischenzuspeichern und dann ins DWH zu laden. Eine hervorragende Seite zum Erlernen und Nachschlagen von PowerShell in deutscher Sprache findet sich hier.

Shell-Skripte werden aber auch noch in einem weiteren Kontext benutzt: Continuous Integration und Deployment. Wie ich bereits andernorts ausgeführt habe, bedeutet mehr Agilität in BI-Projekten immer auch mehr Automation. Das gilt nicht nur für die DWH-Entwicklung als solches (vgl. dazu auch den letzten Abschnitt unten), sondern auch für den Transport von Artefakten z.B. von einer Entwicklungs- auf eine Test- und Produktionsumgebung. Auch wenn‘s für die Orchestrierung Werkzeuge mit graphischer Oberfläche gibt (Jenkins, Azure DevOps,…), so werden die einzelnen Schritte meist als Skripte programmiert.

Soweit so gut. Doch was brauchen DWH-Entwicklerinnen im Jahr 2020 neben den bisher erwähnten sonst noch so an Fähigkeiten? Ich beoachte eine Tendenz, dass wir uns einerseits stärker mit Prinzipien guter Softwarentwicklung auseinanderseiten müssen und andererseits ein hohes Mass an Abstraktionsvermögen benötigen. Dafür muss ich etwas ausholen und zwar zum Unterschied zwischen imperativer und deklarativer Programmierung. Ein umfassender Artikel dazu findet sich hier. Folgend versuche ich die zwei Ansätze anhand eines Beispiels aus der DWH-Welt zu beschreiben. Nehmen wir an, wir wollen eine Dimension mit SCD2-Historisierung erstellen. Wenn wir imperativ vorgehen, würden wir hingehen und den SQL-Code schreiben, welcher eine Serie von Arbeitsschritten ausführt: Zuerst legen wir die Dimensionstabelle mit ihren Feldern an. Dann erstellen wir eine Stored Procedure, um die Tabelle zu laden. Die Stored Procedure enthält Schritte, um zuerst neue Datensätze zu laden, danach überprüfen wir für bestehende Datensätze, ob sich etwas geändert hat. Falls ja, erstellen wir einen neuen Datensatz mit einem neuen „Gültig-Ab“ Datum. Imperativ bedeutet in diesem Kontext: Wir sagen der Maschine explizit, was sie tun soll. Im Gegensatz dazu abstrahiert ein deklarativer Ansatz die konkrete Anweisung: Anstelle von konkreter SQL-Programmierung definieren wir Metadaten und sagen der Maschine: Erstelle mir eine Dimension, welche gemäss dem Muster SCD2 historisiert wird. Danach übernimmt der Compiler bzw. ein Generator das Ausprogrammieren der benötigten Anweisungen auf SQL-Ebene. Es ist genau dieser deklarative Ansatz, welcher der Kategorie von DWH-Automationswerkzeugen zu Grunde liegt. Marktbekannte Vertreter sind z.B. WhereScape oder Timextender (eine gute Übersicht findet sich zudem hier). Und diese Werkzeuge verändern zunehmend die Arbeit des DWH-Entwicklers. Auf der einen Seite müssen er oder sie sich weniger um die Details der SQL-Programmierung kümmern sondern können sich vermehrt der fachlichen Problemlösung widmen – dort wo wirklicher Mehrwert geschaffen wird. Auf der anderen Seite braucht es Leute, welche die Generatoren programmieren können. Je grösser das Projekt, desto grösser auch die Chance, dass man die von einem Softwarehersteller vorgegebenen Muster erweitern oder anpassen will. Dabei muss man nicht zwangsläufig zur Softwareentwicklerin werden, jedoch helfen grundlegende Fähigkeiten in der Softwareentwicklung. Ich selber arbeite aktuell häufig mit WhereScape. Dieser Anbieter erlaubt es zum Beispiel, die bestehenden Generatoren zu erweitern oder gänzlich neue Muster abzubilden (ein Beispiel dazu haben mein Kollege Elgar Brunott und ich kürzlich hier beschrieben). Dazu sind im Wesentlichen drei Fähigkeiten gefragt: Erstens muss ich eine Vorstellung haben, wie das Resultat am Ende aussehen soll (da sind wir wieder bei den Modellierungs-, SQL- und Powershell-Fähigkeiten). Zweitens muss ich nun induktiv abstrahieren können, wie aus einem konkreten Beispiel eine allgemeine Regel formuliert werden kann. Drittens muss ich diese allgemeine Regel in der Sprache des verwendeten Werkzeugs ausdrücken können, im Falle von WhereScape ist das Pebble und sowie einer Regel-Engine.

Die DWH-Entwicklung ist im Umbruch – weg von der Fleissarbeit hin zu mehr „Engineering“. Datenmodellierung und SQL gehören nach wie vor zum Pflichtrepertoire der DWH-Entwickler und DWH-Entwicklerinnen. Aber wir müssen unseren Horizont auch erweitern und ergänzende Sprachen wie PowerShell mindestens in ihren Grundzügen kennen und anwenden können. Dazu kommt der steigende Konkurrenzdruck. Wer Lösungen deklarativ entwickelt und die eigentliche Code-Erstellung automatisiert, hat die Nase vorne!

*Der Beitrag spiegelt die Meinung des Autors wider und ist keine allgemeingültige Meinung des TDWI. Als TDWI bieten wir die Plattform, alle Themen und Sichtweisen zu diskutieren.*