Freitag, 4. Januar 2013

SQL Server Master Data Services Vortrag in der Hamburger SQL Server Usergroup PASS Deutschland e.V.

Am Mittwoch, den 9.1.2013, ist es wieder soweit. Das erste Treffen der Hamburger SQL Server Usergroup. Wir treffen uns wieder in der Hamburger Microsoft Niederlassung.

Thema sind die Master Data Services. Den Vortrag halte ich dieses Mal selbst. Hier der Abstrakt des Vortrags:

“In diesem Vortrag es um die Aktualität und Qualität von Daten im Unternehmen.

Mit den Master Data Services stellt Microsoft ein mächtiges Master Data Management Werkzeug zur Verfügung, welches quasi out-of-the-box eingesetzt werden kann für die Pflege von Daten.

Nur was ist Master Data Management? Was sind überhaupt Master Data? Stammdaten?

Wir betrachten sowohl operatives als auch analytisches MDM. Es wird die Arbeit mit den MDS vorstellt. Die Weboberfäche als auch das neue Excel Add-In betrachtet. Wie können MDM Prozesse manuell bzw. auch automatisiert durchgeführt werden? Wie werden Data Stewards in den Fachabteilungen effektiv eingebunden? Und welche Rolle spielt Security dabei?

Der Vortragende nutzt die MDS seit dem SQL Server 2008 R2, hat viele Erlebnisse als auch Erfahrungen aus zahlreichen Proof-of-Concepts für Microsoft Kunden sammeln dürfen, führt PASS Essentials Events zu den MDS durch und hat die MDS auch auf dem Kölner SQL Server 2012 Launch Event vorstellen dürfen.”

Wir treffen uns um 18:30 und haben bis ca. 20:30 Zeit um uns über das Thema auszutauschen. Hier noch mal die Koordinaten der Hamburger Microsoft Niederlassung:

Microsoft Deutschland GmbH
Geschäftsstelle Hamburg
Gasstraße 6a
22761 Hamburg

Kostenlose Parkplätze befinden sich hinter dem Gebäude. Der Parkplatz ist über die Rampe mit dem Schild „Microsoft Kunden“ erreichbar.

Nur wenige Minuten zu Fuß ist der S-Bahnhof Bahrenfeld entfernt (S1/S11).

Donnerstag, 3. Januar 2013

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.