SQL Server Data Warehouse - Ein erster Entwurf

Eine Frage wird mir tatsächlich relativ selten gestellt: Was ist ein Data Warehouse?

Dabei ist das verblüffend. Denn für mich ist das gar nicht immer so klar.

Also stelle ich häufig die Frage: Was ist für Sie ein Data Warehouse und was gehört alles dazu? Und was ist besonders wichtig?

Die Antworten sind wiederum verblüffend. Jeder beantwortet die Frage nämlich anders. Wie hätte es auch sonst sein sollen.

Für den Einen ist es die “Dimensionale Modellierung der Daten”, für den Anderen “die Nutzung von ETL/ELT Werkzeuge wie Integration Services”. Für den Nächsten ist es die Verwendung einer analytischen Engine wie SQL Server Analysis Services. Nun ja, da sind wir ja eigentlich schon im Presentation Layer, oder?

Ich möchte heute den Anfang machen für einen generischen SQL Server Data Warehouse Entwurf. Mal schauen, wo wir am Ende damit landen.

Und was ist für mich das Wichtigste an einem Data Warehouse? Schwer zu sagen, dennoch hat sich gezeigt über die Jahre hinweg, dass eine gut durchdachte SQL Server Data Warehouse Infrastruktur eine gute Grundlage für ein erfolgreiches Data Warehouse ist!

Was verstehe ich unter einer DWH Infrastruktur? Für mich sind das die Funktionen im Hintergrund, die technologische Basis auf der alles später laufen soll. Was soll das schon groß sein? Ein SQL Server mit einer relationalen Engine. Passt schon, oder?

Nun ja, ganz so ist es doch nicht. In einem Enterprise Data Warehouse passieren schon viele spannende Sachen. Oft unabhängig voneinander, gleichzeitig und ständig. Das sind schon ernsthafte Herausforderungen.

Leicht wird aus einem Data Warehouse daher auch über die Jahre hinweg  ein “Big Ball of Mud”. Diesen beschrieben Brian Foote und Joseph Yoder als “…planlos strukturierter, weitläufiger, schlampiger, mit Klebeband fixierter und Ballenpressdraht zusammengeschnürter Spaghetti-Code Dschungel…”. Ähm, ja. So etwas habe ich schon mal im Kontext Data Warehouse erlebt. Frühzeitige Konzeptionierung hilft hier sicherlich weiter und verhindert eine solche Entwicklung.

Fangen wir mal an. Zuerst sollten alle verwendeten Technologien gekapselt werden, um Implementierungs- und späteren Betriebsaufwand zu reduzieren.

by the way, die Kapselung von Technologie ist für mich meist eh ein must-have in komplexeren Projekten, um die Power der einzelnen SQL Server Dienste voll und entspannt nutzen zu können.

Data Warehouse relevante Technologien
Dazu zählen für mich Themen wie (noch unvollständig):

Partitionierung & Indizierung
Wer möchte schon später für ein größeres Data Warehouse die gesamte Partitionierung und Indizierung über das SQL Server Management Studio managen oder dafür immer wieder Skripte anpassen?

Resource Governor
Auch hier gilt. Wer möchte die Workload Zuordnung im Betrieb später per Hand managen? Und Hand hoch, wer nutzt das überhaupt schon im DWH?

Security
Security spielt im Data Warehouse eine große Rolle und ist eine wesentliche Säule für die Nutzung des Resource Governors für die Zuordnung der Workloads. Des Weiteren ist das auch später die Grundlage für ein kontinuierliches Auditing der Umgebung.

Change Data Capture (CDC)
Oft ist die Herausforderung in Echtzeit Änderungen aus Vorsystemen zu übernehmen. Hier hilft gern CDC als Technologie, nur auch hier gilt. Volle Power bzw. Komfort gibt es durch Kapselung der Funktionalität im Data Warehouse Prozess.

Service Broker
Das ist wiederum die Basistechnologie für die oben genannten Punkte. Asynchrone Abläufe helfen bei der Skalierung der Prozesse. Dennoch sollte auch diese eine Kapselung erfahren, um “einfacher” genutzt werden zu können.

Wenn die wesentlichen Technologien gekapselt sind, kommt die nächsthöhere Schicht dran. Das sind die Standard Funktionen des Data Warehouses. Hier mal einige als Beispiel:

Protokollierung & Benachrichtigungen
Alle möglichen Komponenten und Schichten eines Data Warehouses produzieren ständig einen Strom an Meldungen (auch mal Fehler). Diese sollten zentral aufgenommen, verwaltet und zugestellt werden.

Historisierung
Immer wieder müssen Daten im Data Warehouse historisiert werden. Schön wäre es, wenn das nicht an jeder Stelle “neu” erfunden werden müsste.

Surrogate Keys
Auch hier gilt, brauchen wir immer wieder. Bitte nur einmal die Kern Logik implementieren! Verwaltet sich dann später auch gleich viel einfacher, ehrlich.

Deployment
Sobald ein größeres Data Warehouse läuft, wird das Thema Deployment relevant bis kritisch. Denn wie werden Änderungen in ein “laufendes” Data Warehouse eingepflegt? Spätestens hier kommt wieder das Bild vom “Big Ball of Mud” auf, oder?

Das wären schon mal ein paar erste Gedanken, um einen generischen SQL Server Data Warehouse Ansatz zu beschreiben. Wer nun fragt, wo denn die Integration Services (SSIS) geblieben sind? Recht hat er. Natürlich gehören die dazu. Mir war wichtig aufzuzeigen, dass ein Data Warehouse viel mehr als NUR der Einsatz von SSIS ist! Es gibt viele weitere Funktionen und Dienste des SQL Servers die in den Betrieb eines “sauberen” DWHs sicherstellen.