Ich bin ein fauler Programmierer! Das war ein wichtiges Detail, das ich letzte Woche von Roelant Vos in seiner Schulung gelernt habe. Aber es gab noch viele andere interessante Themen. Eine persönliche Zusammenfassung eines 3-tägigen Kurses über Data Warehouse Design Patterns.
Letzte Woche hatte ich die Gelegenheit, den Kurs Data Warehouse Design Patterns von Roelant Vos zu besuchen. Ich habe Roelant in Präsentationen auf Datenmodellierungskonferenzen gesehen, und ich schätze seinen Blog mit vielen nützlichen Informationen über Data Warehouse Architektur und Data Vault Implementierung. Als ich dann von meinen Trivadis-Kollegen erfuhr, dass er eine Schulung in Zürich abhalten wird, nutzte ich die Chance, an diesem 3-tägigen Kurs teilzunehmen.
Ich werde in diesem Blogbeitrag keine detaillierte Besprechung des gesamten Kurses schreiben. Aber in den folgenden Zeilen finden Sie einige Anmerkungen zu drei Themen, die aus meiner Sicht in dieser Schulung wichtig waren: Pattern Based Design, Persistent Staging Area und Virtual Data Warehouse.
Eine typische Data-Warehouse-Architektur besteht aus mehreren Schichten zum Laden, Integrieren und Präsentieren von Geschäftsinformationen aus verschiedenen Quellsystemen. Die Anzahl und Namen der Schichten können in jedem System variieren, aber in den meisten Umgebungen werden die Daten mit ETL-Tools oder reinen SQL-Anweisungen von einer Schicht in eine andere kopiert. Bei einer guten Architektur sind die Muster zur Umwandlung und zum Laden der Daten in eine bestimmte Schicht immer ähnlich. Dies erleichtert (und beschleunigt) die Entwicklung der ETL-Prozesse, da die wiederholbaren Muster mit einem Data-Warehouse-Automatisierungstool (DWA) generiert werden können. Im Blog von Roelant finden Sie einen Überblick über sein Data Integration Framework. Code-Beispiele sind auf GitHub verfügbar.
Warum bin ich ein fauler Programmierer? Wie viele andere Entwickler mag ich es nicht, sich wiederholenden Code zu schreiben. Roelant ist auch ein fauler Programmierer. Deshalb hat er viel Zeit damit verbracht, Tools und Methoden zu entwickeln, um die Entwicklungsaufgaben zu beschleunigen, indem er den SQL-Code zum Erstellen und Laden von Data Warehouses generiert. Während des Kurses erklärte er viele Entwurfsmuster mit dem SQL-Generator VDW (Virtual Data Warehouse). Er kann kostenlos von seiner Website heruntergeladen werden und ist nützlich für schnelle Prototypen und Regressionstests von Musteränderungen.
Persistent Staging Area
Eine wichtige Schicht in der vorgeschlagenen Architektur ist die PSA (Persistant Staging Area). Obwohl dieser Bereich der Staging-Schicht optional ist, ist er sehr praktisch und sehr empfehlenswert, insbesondere wenn die geschäftlichen Anforderungen zu Beginn des Projekts noch nicht klar sind. Die PSA ist ein historisches Archiv der Daten aus den Quellsystemen und ersetzt die klassische volatile Staging Area. Die PSA wird entweder mit CDC (Change Data Capture) Mechanismen oder mit einer Delta-Erkennung zwischen Quellsystem und aktueller Version der PSA geladen. Die Persistent Staging Area ist die einzige Quelle zum Laden der Data Vault Tabellen (Hubs, Links und Satellites) im Integration Layer.
Der Vorteil einer Persistent Staging Area ist, dass nur die aktuell benötigten Teile der Informationen in die Data Vault Tabellen geladen werden müssen. Wir müssen uns nicht um zukünftige Anforderungen kümmern, da die ursprünglichen Daten immer noch im PSA verfügbar sind und bei Bedarf neu geladen werden können. Ich habe diesen Ansatz in mehreren Kundenprojekten gesehen und verwendet, und er ist eine gute Versicherung gegen unbekannte Geschäftsanforderungen.
Virtuelles Data Warehouse
Als ich Roelant Vos zum ersten Mal auf der Konferenz Data Modeling Zone 2017 in Düsseldorf sah, war ich sehr beeindruckt von einem interessanten Architekturansatz, den er erklärte: Die einzige persistente Schicht eines Data Warehouse ist das PSA, und alles andere wird auf den PSA-Tabellen mit Views implementiert. Das ist die konsequente Umsetzung eines Virtual Data Warehouse, das durch die VDW-Software von Roelant unterstützt wird. Ich habe dies in der Theorie und in einigen Präsentationen gesehen, aber noch nie in der vollen Form in einem realen Projekt.
Dieser „NoETL“ Ansatz hat mehrere Vorteile: 1. Es ist sehr einfach, die Transformationslogik zu ändern, ohne alle Schichten des Data Warehouse neu zu laden. 2. Sobald neue Daten in die PSA-Schicht geladen werden, sind sie sofort in allen nachfolgenden Schichten sichtbar. 3. Es handelt sich um eine Art Schema-on-read Data Warehouse, bei dem Sie zur Abfragezeit entscheiden können, wie die Quelldaten interpretiert werden sollen. Das klingt alles sehr schön, aber ich sehe immer noch die Herausforderung einer guten Abfrageleistung. Ich denke, in den meisten Situationen müssen zumindest die häufig verwendeten Daten persistiert werden. Mit dem View-Ansatz lässt sich das aber ohne großen Aufwand machen, zum Beispiel mit materialisierten Views.
Der 3-Tages-Kurs hat meine Erwartungen mehr als erfüllt. Obwohl ich einige der Konzepte bereits selbst angewendet habe (um ehrlich zu sein, war mir das meiste von dem, was Roelant erklärt hat, bereits bekannt), hat mir der schrittweise Aufbau einer Data-Warehouse-Architektur anhand vieler Code-Beispiele und Live-Demos sehr gut gefallen. Oder wie ich am Ende des Kurses als spontanes Feedback sagte: „Es hat Spaß gemacht“.