SQL Server Data Warehouse – One Queue Pattern (OQP)
Letztes Jahr habe ich ja ein wenig über meine Erfahrungen beim Design von Data Warehouse Umgebungen auf Basis SQL Server geschrieben.
SQL Server Data Warehouse - Ein erster Entwurf
Dabei habe ich bereits auf Best Practices hingewiesen, welche sich beim Design und der Implementierung bewährt haben. Nun hatte ich zwischenzeitlich aufgrund laufender Projekte leider keine Zeit weiter ins Detail zu gehen. Das möchte ich nun schnellstmöglich nachholen, da mittlerweile eine ganze Reihe von Nachfragen diesbezüglich bei mir eingetrudelt sind.
Ein Punkt ist mir wichtig, daher wiederhole ich ihn nochmals gerne. :-)
Ich unterscheide ganz klar zwischen einem Data Warehouse und einem ETL/ELT Prozess. Das war und ist nicht das Gleiche oder gar das Selbe. Oft stelle ich in der Praxis fest, dass diese beiden “Komponenten” gerne in einen Topf geworfen werden. Zwar sind sie eng miteinander verwoben, dennoch müssen sie für eine erfolgreiche und verwaltbare Architektur klar voneinander getrennt werden!
Ein Data Warehouse hält Daten und mit ein wenig Glück und Planung auch Informationen.
Der ETL/ELT Prozess überführt Daten/Informationen in das Data Warehouse.
Daher spreche ich auch gerne von einer Data Warehouse Infrastruktur. Häufig wird das DWH nämlich dann “nur noch” als eine Sammlung von relationalen Tabellen und Datenbanken gesehen. Nur so einfach ist es dann leider in der Realität nicht, um mit einer solchen Architektur auch im Enterprise Umfeld bestehen zu können.
Damit komme ich endlich zum Punkt. :-)
Eine SQL Server Data Warehouse Infrastruktur besteht aus einer ganzen Reihe von Pattern (Entwurfsmustern), welche ich über die Jahre hinweg entwickelt und aus den Projekten als eine Art Best Practices heraus destilliert habe.
Ein zentraler Aspekt innerhalb eines Data Warehouses ist die Kommunikation aller beteiligten Komponenten. Sowohl für die Steuerung, die Rückmeldungen als auch für das Monitoring.
Dafür schlage ich gern mein One Queue Pattern (OQP) vor. Gern nenne ich es auch mal One Queue Only Pattern.
Das Konzept dahinter ist so einfach, dass es oft auf den ersten Blick gar nicht verstanden wird. Oder, das kommt auch mal vor, als viel zu komplex wahrgenommen wird durch den hohen Grad an Generik.
Es ist eine Warteschlange für alles. Wirklich für alles. Ja, alles…
Also eine Mischung aus Steuerungswarteschlange und Benachrichtigungssystem.
Prozesse schreiben Meldungen bzw. Steuerungsanweisungen in die Warteschlange. Und unterschiedliche Agenten konsumieren die Einträge in der Warteschlange und werten diese entsprechend ihrer Konfiguration aus. Und wenn etwas nicht berücksichtigt wird, dann fällt dieses sehr schnell auf. Nichts geht mehr verloren. Schon mal ein großer Vorteil!
Das automatische Löschen von Einträgen ist nicht vorgesehen. Also die Verarbeitung von Einträgen kann diese nicht gleichzeitig löschen. Erst spätere Wartungstasks sind per Definition dazu in der Lage.
Eine Meldung kann darüberhinaus von mehreren unterschiedlichen Agenten konsumiert werden. Damit ist u. a. die Verarbeitung und das Monitoring voneinander getrennt.
Die einzelnen Komponenten der ETL/DWH Lösung kommunizieren über diese Quere miteinander.
Des Weiteren kann eine Meldung über die Verarbeitung eines Agents das Einstellen/Versenden von weiteren Meldungen/Einträgen auslösen, um eine kaskadierende Abfolge von Aktionen zu starten. Damit müssen Aktionen nicht mehr direkt miteinander verbunden werden, sondern können durch eine übergeordnete Instanz orchestriert werden.
Dabei ist mir besonders wichtig, dass dabei die Prinzipen der Vereinfachung und Kontrollierbarkeit verfolgt werden. Nichts darf Selbstzweck sein, sondern muss klaren Prämissen folgen!
Vorteil ist, dass es nur einen Einstiegspunkt für eine ganze Reihe von Problemen im Betrieb gibt. Damit wird die Fehlersuche auch vereinfacht, wenn noch gar nicht ganz klar in welcher Komponente ein Fehler aufgetreten ist.
Dieses Pattern setze ich schon seit Jahren gerne für eine ganze Reihe von Herausforderungen ein. Einen Ansatz für die Steuerung von SSIS Paketen zeigte ich zum Beispiel während meines Vortrags auf den SQLBits in York, UK. Das Video ist hier zu finden: The Developer Side of the Microsoft Business Intelligence stack.
Für Fans die Info, dass das Ganze eine recht freie Interpretation des Vermittler Entwurfsmusters und des Beobachter Musters ist.
Die eigentliche Implementierung kann entweder mittels Service Broker stattfinden oder durch den Einsatz einer einzelnen Tabelle. Beide Ansätze sind durchaus valide und in Praxis genutzt worden. Wenn ich die Wahl habe, dann plädiere ich für eine Umsetzung mittels Service Broker, da dieser schöne SQL Server Dienst einem sehr viel vom Verwaltungsaufwand für die zentrale Warteschlange abnimmt und das wesentliche Element der Asynchronität bereits mitbringt.
