Freitag, 19. Oktober 2012

Columnstore Index Demo–120.000.000 Zeilen und mehr…

In der vergangenen Woche hatte ich ja mehrmals die Chance das SQL Server 2012 Feature Columnstore Index vorzustellen.

Hier kurz die Skript Fragmente, mit denen ich Adventure Works DW auf 120.000.000 Fakten Zeilen erweitert habe. Hatte ich ja versprochen zu bloggen.

select *
into demo.dbo.FactInternetSalesMuchMore
from [dbo].[FactInternetSales];

Hiermit lege ich eine Kopie der FactInternetSales an.

Und nun kommt nur noch.

declare @counter int  = 0
while @counter < 2000
begin
  insert into demo.dbo.FactInternetSalesMuchMore
  select *
  from [dbo].[FactInternetSales];
  set @counter = @counter + 1
end

Das ist nun wirklich keine Raketenwissenschaft, dennoch habe ich am Ende (bei mir nach ca. 45min…) eine relativ umfangreiche weitere Faktentabelle für Test Queries.

Und bitte bitte nicht auf produktiven Servern machen!!!! Versprochen?

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.

Montag, 15. Oktober 2012

Columnstore Index (xVelocity) Community Vorträge

In der letzten Woche hatte ich gleich zweimal die Möglichkeit der Community die xVelocity Technologie des SQL Server 2012 vorzustellen.

Zuerst war ich zu Gast auf der Deutschen Microsoft Partnerkonferenz in der Porsche Arena in Stuttgart. Dort hatte ich im Rahmen eines SQL Server Vortrags den Columnstore Index den Microsoft Partnern vorgestellt. Des Weiteren kam ich auch auf das sehr wichtige Thema Data Warehouse Infrastruktur zu sprechen.

In der zweiten Wochenhälfte war ich dann auf NRWConf in der Börse in Wuppertal. Dort habe ich in einer Session sowohl den Tabellarischen Modus der Analysis Services als auch die Arbeit mit Columnstore Indizes vorstellt. Die Themen Analysis Management Objects als auch das ein- und ausblenden von Partitionen (Switching) kamen nicht zu kurz.

Vielen Dank an die Organisatoren der NRWConf von Just Community e.V. !

Für meine Demos verwendete ich eine von mir leicht modifizierte Version der Adventure Works Beispieldatenbank von Microsoft. In meiner Variante hatte ich zwei weitere Versionen der FactInternetSales. Eine mit 12.000.000 Zeilen und eine mit 120.000.000 Zeilen. Noch nicht wirklich viel, dennoch hat es für die Präsentationen gereicht, um die Power hinter dieser Technologie zu demonstrieren.

Sonntag, 7. Oktober 2012

SQL Server Data Warehouse - Mehr als nur SSIS !

Immer wieder stelle ich fest, dass sowohl kaufmännische Entscheider als auch IT-Leiter in größeren Organisationen die Vorstellung haben, dass ein Data Warehouse auch ein extra Produkt einer Business Intelligence Umgebung sein müsste.

Gar nicht so selten sind Zitate wie: “Ach so, sie nutzen den SQL Server auch als Data Warehouse. Nun ja, interessant. Kann man wohl machen… Dennoch…”.

Da war das Marketing der Marktbegleiter einfach gut! By the way, bei denen ist das Data Warehouse auch eine relationale Datenbank. Also, ähm, wenn die denn eines einsetzen. Nur diese Diskussion sollten wir an anderer Stelle führen. Okay, ein Satz dazu. Sich gegen ein Data Warehouse zu entscheiden ist keine Frage der Auswahl eines BI Tool Anbieters, sondern eine Architektur Frage, welche gewissenhaft & seriös beantwortet werden muss. </Ende>

Nur kurz angemerkt. Wenn wir uns über wirkliche große Szenarien unterhalten, dann ist JEDE relationale Engine JEDER etablierten Datenbank irgendwann am Ende. Und aufgepasst, fast jeder Kunde (intern wie extern) ist der Meinung, dass er wirklich wirklich viele Daten hat. Mit “viele Daten” meine ich aber gerade gehobene Terabyte Mengen oder etwas in der Nähe von Petabytes. Dafür gibt es dann tatsächlich extra Produkte von Microsoft und auch anderen Herstellern. Nur, wer hat die Herausforderung schon? :-)

Zurück zum Thema.

Ein Data Warehouse zu betrieben ist weit mehr als nur ein Tool für den ETL/ELT Prozess einzusetzen und einen schönen Spaltenzuordnungsdialog (Mapping) zu haben. Auch das gilt für fast alle Hersteller. Nur wird das häufig bei der Auswahl einer Lösung übersehen.

Auch dafür ein Zitat: “Dafür setzen wir das ETL Tool von bla ein…”. Weil wenn das Tool stimmt, dann klappt das auch mit dem relationalem Data Warehouse. Dem ist nicht so.

Wo ich mit mir verhandeln lasse, sind DWH Frameworks, welche sich um die relationale Engine “legen”. Nur häufig sind diese recht überschaubar ausgelegt und unterstützen nicht durchgängig und in aller Konsequenz die Anforderungen an ein Enterprise Data Warehouse (Welche waren das noch gleich…). Dazu kommt, dass solche dann oft wieder geschlossene Lösungen sind. Software im Enterprise Umfeld muss offen sein. Nicht nur mit der herstellereigen Oberfläche zu bedienen sein. Integration ist das Stichwort und das ist für mich ein echtes unverhandelbares Merkmal für die Fähigkeit einer Software “Enterprise Ready” zu sein oder halt auch nicht.

Das Design einer Data Warehouse Infrastruktur ist auch immer Architekturaufwand. Vieles ist Best Practice. Es muss nur noch alles zusammengeführt werden, was benötigt wird.

Für mich immer wieder notwendige Funktionen der relationalen Datenbank Engine für den Betrieb eines klassischen Enterprise Data Warehouse sind:

  • Partitionierung
  • Komprimierung
  • Service Broker
  • Verschlüsselung
  • Resource Governor
  • Columnstore-Indizes (seit 2012)
  • Clustering / AlwaysOn Availability Groups (seit 2012)

Ähm, und ja, dafür braucht man die Enterprise Edition.

Natürlich kommt dann obendrauf noch die ganze Analyse- und Frontend-Nummer. Nur das ist dann wieder etwas ganz anderes als das eigentliche Data Warehouse, oder? :-)