Coaches’ Diary: Wie finde ich ganz einfach und schnell in einem Analysis Services Projekt alle Attribute, welche keinen Integer als Key haben…

Hier ein kleiner Kniff aus der Coaching Praxis!

Da erkläre ich einem Kunden im Coaching lang und breit in Farbe und 3D, dass Attribute das A bis Z in einer multidimensionalen Datenbank sind und, ganz ganz wichtig, bitte als Keys bitte nur Integer Spalten verwendet werden sollten. So von wegen Performance und so! Ok, haben die meisten von Euch wohl auch schon von gehört bzw. gelesen. Ist bei größeren und komplexeren Umgebungen wirklich wichtig! Ehrlich!

Natürlich kommt vom Kunden die Aussage, dass sie das ganz sicher bedacht hätten. Ich hatte da so meine Zweifel, aber keinerlei Tools zur Hand bzw. auf dem Kundenserver, um das nun kurz mal zu überprüfen. Alternative wäre ein manuelles Suchen gewesen. Da fiel mir etwas ein! Mit der Power der Kommandozeile lässt sich das nämlich herausfinden!

Es folgt dieses magische Kommando:

dir *.ksstore /s

Und schon werden alle Attribute & die Dimensionen angezeigt, welche einen String im Key haben! Da ich die Kundendatenbank nicht nehmen kann, hier die AdventureWorks2008R2 als Beispiel:

image

Der Befehl ist im jeweiligen Ordner auf der Server abzusetzen, in welchem die SSAS DB liegt. Also hier beim Beispiel für ADW2008R2..

image 
Wenn nicht klar sein sollte, wo die Datenbanken liegen, dann die SSAS Eigenschaft DataDir anschauen im Management Studio.

image 
Natürlich könnte das DIR auch eine Ebene höher ausgeführt werden, dann würden wir für alle Datenbanken alle Attribute mit Strings im Key sehen.

Ein schönes Beispiel in Adventure Works 2008 R2 ist in Geography das Attribute City! Hier unser Output.

image

Und hier die Eigenschaften des Attributes im Projekt:

image

Ach ja, und was ist jetzt ein *.ksstore?

Relativ einfach zu sagen. Im Gegensatz zur relationalen Engine, wo wir ja "nur" mdf, ndf's und ein ldf pro Datenbank haben, zerlegt SSAS die Datenbank in Tausende von Dateien. Mehrere Dateien pro Attribute zum Beispiel. Allein für den Key eines Attributes gibt es eine *.kstore (Key Store) und eine *.khstore (Key Hash Store). Nun ja, und NUR für den Fall, dass der Key aus Strings besteht auch noch eine *.ksstore (Key String Store)! Die ist sozusagen optional!  :^)

SQL Server Analysis Services Synchronization fürs Deployment mit SSMS, SSIS & ADOMD.NET

Im Rahmen der von mir durchgeführten Coachings & Trainings für die SQL Server Analysis Services stelle ich immer wieder fest, dass sich viele Anwender/Entwickler damit zufrieden geben einen "Cube" auf einem Server zu verarbeiten und diesen von dort aus zu nutzen bzw. die Anwender darauf zugreifen zu lassen. In vielen Umgebungen ist dieses Vorgehen, um die Anforderungen zu erfüllen, völlig ausreichend. Für komplexere Umgebungen und mit mehr Last und/oder keinem echten Wartungsfenster sind die Anforderungen aber deutlich höher. Die Arbeit mit mehreren SSAS Instanzen wird dabei durchaus in Betracht gezogen, aber das Deployment der SSAS DB wird häufig manuell durchgeführt bzw. es wird "nur" das Projekt verschoben. Resümee ist, dass multidimensionale Datenbanken häufig auf jedem Server aufs Neue verarbeitet werden. Dabei hat Microsoft den SSAS einige sehr nützliche Funktionen auf den Weg gegeben, um genau das zu vermeiden.

Eine davon ist die Synchronisation von SSAS Datenbanken. Hierbei wird vom Ziel-Server ausgehend eine Datenbank (aka Cubes) von einem Quell-Server übertragen. Dieses Feature kann sowohl in der GUI des SQL Server Management Studios (SSMS) durchgeführt werden, als auch in Integration Services und in .NET Code. Es gibt sicherlich noch weitere Möglichkeiten wie PowerShell etc., aber das sprengt dann irgendwann den Rahmen. :-)

In dem folgenden kleinen Cast demonstriere ich einige der Möglichkeiten, um den Synchronisationsprozess anzustoßen. Auf Details wie Remote Partitionen gehe ich bewusst nicht ein, da dafür noch ein wenig mehr Theorie für die Nutzung notwendig ist. Liefere ich aber bei Zeiten nach!

Viel Spaß mit dem Cast! Bei Fragen, Kommentaren, Anregungen und gar Wünschen für weitere Themen.-> einfach melden!

 

Landing Area (Zone) im SQL Server Data Warehouse

Noch ein wenig was zum Thema Data Warehouse Design.

Diese Woche hatte ich u. a. ein Meeting, bei dem erwähnt wurde, dass der Begriff Landing Zone bzw. Landing Area im Zusammenhang mit Data Warehouse Architekturen bisher den Teilnehmern nicht bekannt war. Für mich ist die Nutzung einer Landing Area in einer Data Warehouse Umgebung ein wesentliches Element, um eine beherrschbare Lösung zu erstellen. Ihr erinnert Euch vielleicht, dass für mich die spätere "Beherrschung" der Business Intelligence Lösung ein elementarer Punkt ist und mir meist wichtiger ist, als irgendwelche technischen Spielereien auf der "Bit-Ebene.". Und daher hier kurz eine Erläuterung meiner Sicht auf eine Landing Zone, welche gerne auch mal Landing Area heißt.

Die Aufteilung eines ETL Prozesses in sogenannte Stages ist mittlerweile relativ bekannt. Also die Daten, welche für das Data Warehouse benötigt werden, durchlaufen im Datenbewirtschaftungsprozess diverse Schritte (Stages) zur Überprüfung und Verarbeitung, bevor sie im finalen Load-Prozess ins DWH geladen werden.

Die Landing Zone setzt nun auf der gegenüberliegenden Seite an! Hier fängt der ETL Prozess an. Wichtig ist die Erkenntnis, dass der ETL Prozess eigentlich aus diversen voneinander getrennten Prozessen/Jobs/Paketen/What-ever besteht. Es gibt u.a. diverse Extract-Prozesse (das E in ETL), welche die Daten aus den Vorsystemen "einsammeln". Nun gibt es aber auch noch den häufigen Fall, dass die Vorsysteme die Daten von sich aus automatisch liefern. Wohin also mit diesen gepushten Daten? Das ist die ursprüngliche Idee hinter der Landing Zone. Hier laden die Vorsysteme Ihre Daten ab. Entweder Deltas, Transaktionslog, Backups, Flats usw. Meist ist die Landing Area aus technischer Sicht eine Ordnerfreigabe auf einem Server. Aus dieser holen sich dann die Prozesse des ETL Jobs die dort "gelandeten" Daten ab und verarbeiten diese weiter. Natürlich kann es auch vorkommen, dass Datenpakete abgewiesen werden, weil die Datenqualität nicht die Geschäftsregeln erfüllen oder einfach was fehlerhaft ist im Format.

Meine Nutzung der Landing Zone geht noch ein wenig weiter, da ich einfach (ich mag einfache Lösungen bei komplexen Herausforderungen) alle Extract Prozesse ihre Ergebnisse in die Landing Zone ablegen lasse. Auch die Jobs, welche klassisch exportieren. Dazu nutze ich i. d. R. beim SQL Server die Integration Services (SSIS) und lasse die Daten im Rohdatenformat (RAW Format) in der Freigabe ablegen. Die weiteren Prozesse nehmen dann diese Dateien als Quelle auf und verarbeiten sie entsprechend weiter.

Der Vorteil einer Landing Area ist u.a., dass der ETL Prozess nicht direkt an den Vorsystemen hängt, sondern von diesen losgelöst ist. Eine asynchrone Verarbeitung zahlt sich auch hier aus, wenn das Ganze ein wenig unübersichtlicher von der Anzahl der Quellen und Prozesse wird. Des Weiteren kann der Inhalt der Landing Area, welcher im übrigen immer nur temporär dort liegt, ganz hervorragend mit einem Komprimierungstool in Paketform historisiert werden. Die Historisierung führe ich gerade bei ganz frischen Data Warehouse Umgebungen gerne durch, um noch evtl. Fehler in der Verarbeitung durch einen "Reset" des DWHs zu kompensieren ohne eine Datenverlust in der Historisierung zu haben. Daher gehört für mich eine Landing Area zu jedem komplexeren Data Warehouse!

Der Presentation Layer im Allgemeinen und speziell in einem SQL Server Data Warehouse

In meinem letzten Blogpost habe ich ja ein wenig über Vorschläge für den Entwurf von Data Warehouse Umgebungen im Kontext SQL Server geschrieben. Und mir war klar, dass ich polarisieren werde. Hab es ja so gewollt. Gab dann ja auch schön Feedback von der Community zurück. Daher hier nun weitere Erläuterungen zu dem Thema.

Ein Punkt, welcher Inhalt des Feedbacks an mich war, ist das Thema Presentation Layer im Data Warehouse. Dazu wird viel in der begleitenden Literatur geschrieben und ich habe auch schon viel PowerPoint dazu gesehen. Teilweise wird sowohl in Form eines Prozesses von einem Presentation Layer gesprochen wird als auch bei einer statischen Architektur. Da sehe ich aber durchaus einen Unterschied!

Hier zur Visualisierung ein paar Beispiele:

Bei der Prozessdarstellung kommt der Presentation Layer meist "am Ende" des Prozesses, als der Teil, welcher dann von "Außen" sichtbar sein wird. Der Presentation Layer wird zum Beispiel im Rahmen eines ETL Prozesses am Ende "erzeugt".

image 

Dann gibt es den Ansatz bei einer Architektur vom Presentation Layer zu sprechen. Ich habe also diverse´Ebenen in meiner Architektur und wieder ist nur eine von "Außen" sichtbar.

image

Jetzt kann natürlich diskutiert werden, wo denn nun der Presentation Layer anfängt? Im Data Warehouse oder sind Cubes in den Analysis Services erst der Presentation Layer? Dann hätte das Data Warehouse in dem Sinne gar keinen Presentation Layer, sondern die OLAP Cubes erfüllen diese Rolle. Das käme dem Prozessbeispiel auch wieder nahe, da die Cubes ja erst am Ende des Datenbewirtschaftungsprozesses "entstehen". Die Cubes wären dann so etwas wie Data Marts.

image

Kommen wir zu meinen Anregungen aus meinem Blogpost. Dort schlug ich ja vor, dass das Schema des Data Warehouse für sich bereits diverse Abstraktionen enthalten dürfte, sofern diese die Entwicklungs- und Betriebsprozesse unterstützen und den Anwendern nicht im Weg stehen. Dabei ist mein Vorschlag, dass auch einzelne Objekte wie Attribute, Dimensionen, Hierarchien etc. gerne jeweils ihre eigene Abstraktion haben dürfen und sich auch gegenüber den anderen Objekten nur durch diese "mitteilen". Im Hintergrund gibt es dann ein Meta-Universum, welches die Objekte zusammenhält. Das mag der eine oder andere aus der objektorientierten Programmierung kennen.

Nur von den Faktentabellen lasse ich in der Regel die Finger was Abstraktionen angeht, da diese bei echten Massendaten äußerst kontraproduktiv wären!

Hier also ein Beispiel für einen Ansatz, bei dem die Objekte jeweils Ihren eigenen Presentation Layer für eine Abstraktion haben. Das darf dann gerne auch mehrmals geschachtelt sein, wenn es denn die Prozesse genügend unterstützt.

image

Es ist immer zu klären, ob sich der Aufwand und die Komplexität, welche die Arbeit mit Abstraktionen mit sich bringt, auch wirklich rentiert. Die IT ist voll von Beispielen für positive als auch negativen Ansätzen. Das muss im Einzelfall jeweils mit dem Kunden diskutiert werden.

Im Zweifel ist aber das Ziel der Suche nach dem Presentation Layer immer eine Definitionsfrage! :-)

Die reine Lehre vom SQL Server Data Warehouse Entwurf…

Heute Abend ist zwar schon wieder ein Treffen der Hamburger SQL Server Community (PASS Chapter), aber ich kam noch gar nicht dazu das letzte Treffen zu reflektieren. War ein super Treffen, viele Leute, gute Diskussionen und eine klasse Lokation!

Bei dem Treffen habe ich eine lockere Liste von Punkten vorgestellt, welche aus meiner Sicht wichtig für den Erfolg von komplexeren Data Warehouse & Business Intelligence Projekten sind. Ein Punkt dabei war, dass ich vorgeschlagen habe, beim Entwurf für ein Data Warehouse ganz bewusst zwischen dem Presentation Layer und der eigentlichen technischen Implementierung in der Datenbank zu unterscheiden. Ich ging dabei soweit, dass ich vorschlagen habe für die physische Modellierung der Dimensionen sogenannte Key-Value-Tabellen einzusetzen. Dabei geht mein Ansatz wieder vom Attribut als Mittelpunkt aus. Das löste natürlich Diskussionen aus!

Wobei ich immer sage, dass es ja KEINE Silver Bullet gibt! Also eine universelle wirklich für jeden passende Lösung! Habe ich ja schon oft drauf hingewiesen. Und auch dieser Ansatz passt bei weitem nicht auf jedes Projekt.

Mir ist nur über die Jahre hinweg aufgefallen, dass sich langsam die Meinung durchsetzt, ein Data Warehouse muss sowohl logisch als auch physisch dem klassischen Star-Schema folgen. Und viele Herausforderungen, oder heute nenne ich sie mal bewusst Probleme, entstehen da heraus, dass sich die DWH Entwickler fast ein Bein ausreißen dieser Linie zu folgen.

Achtung! Ich meine nicht, dass wir auf Dimensionen und Fakten verzichten sollen! Ganz im Gegenteil. Bin immer wieder fasziniert bis entsetzt, was so als Dimension oder Fakt durchgeht. Diese Aufteilung (und der restliche theoretische Background eines Kimball etc.) macht auf jeden Fall Sinn! Nur halt nicht immer wirklich auf der physischen Ebene.

Natürlich stellt sich dann die Frage: Warum geht der Trend in diese Richtung? Ich kann mich noch durchaus an Zeiten erinnern, da waren Data Warehouse Systeme noch hoch komplizierte Werke, welche kein Reporting (bzw. OLAP)Tool   dieser Welt wirklich nutzen konnte. Da ist eine Orientierung in Richtung Star-Schema natürlich von Vorteil. Des Weiteren scheinen die heute verfügbaren Werkzeuge die DWH Entwickler dazu zu motivieren, gleich in Dimensionen und Fakten zu denken. Zweischneidig das Ganze.

Das nimmt auch die Integration Services des SQL Servers (SSIS) nicht aus. Gerade die Integration Services geben dem DWH Entwickler äußerst leistungsfähige Komponenten an die Hand, welche unmoderiert leicht über das eigentliche Ziel hinausschießen. SSIS Komponenten für SCDs tun da ein übriges.

Jegliche Abstraktion bleibt dabei auf der Strecke und wer meinen Empfehlungen und Vorträgen ein wenig gefolgt ist, weiß ja schon wie sehr ich eine gute und saubere Abstraktion in Systemen schätze! :-)

Die Frage nach den Vorteilen ist da natürlich gerechtfertigt und lässt in der Regel auch nicht lange auf sich warten:

- Anreicherung der Strukturen im Hintergrund durch Metadaten
- Integration von Data Quality Informationen und Prozessen
- Anbindung an ein Master Data Management System (wie z.B. Master Data Services)
- Nutzung eines Repositorys (wen hätte es gewundert.)
- etc.

Wenn ich das Thema bringe, dann weht mir natürlich oft gleich ne steife Brise ins Gesicht. Nur solange die Argumentation in die Richtung "Darum!" oder "Weil man das halt so macht." geht, dann läuft da was falsch und das Thema muss mal sachlich diskutiert werden

Und um eventuelle Bedenken bezüglich der Performance auszuräumen, möchte ich an dieser Stelle die Indizierung von Views als Feature der Wahl vorstellen. Damit lässt sich so eine Umgebung dann auch durchaus zügig nutzen, also sofern nötig.

Ein weiterer Punkt ist meiner Meinung nach zu erwähnen: Der Presentation Layer hat nichts im Data Source View (DSV) der Analysis Services zu suchen!

Und ja, ich möchte an dieser Stelle durchaus polarisieren! :-)