Donnerstag, 12. August 2010

Business Intelligence Framework Vortrag auf der SQLBits 7 in York, UK

Diese Woche habe ich erfahren, dass ich auf der Konferenz SQLBits 7 (The 7 Wonders of SQL) eine Session halten darf!

Die SQLBits ist wohl mit die größte SQL Server Konferenz, welche man auf dieser Seite des Atlantiks finden kann und findet in UK statt. Dieses mal geht es nach York an die York University. Die Konferenz findet vom 30.9. – 2.10. statt. Weitere Details hier –> www.sqlbits.com . Vielleicht treffe ich ja den einen oder anderen von Euch dort!!?

Meine Session dreht sich um Business Intelligence und den sinnvollen Einsatz von Developer Tools für die Bereitstellung einer BI Middleware bzw. eines BI Frameworks, welches die Dienste des SQL Server ein wenig fester verbindet.

The Developer Side of the Microsoft Business Intelligence stack

The Microsoft SQL Server provides a complete library of programmatically accessed objects for all Business Intelligence relevant services. With this set of functions almost any customer challenge can be solved without the need to purchase additional products. This possibility is often underestimated in projects.
We will explore the ways how to create powerful solutions with Integration Services, Reporting Services and, of course, Analysis Services. This session provides many samples and .net sourcecode to demonstrate the possibilities of creating your own tools with Windows Forms and Silverlight for your daily work. Many manual clicks and tasks can be automated, really!
Finally we build a complete Business Intelligence Middleware as a blueprint for your own projects.

 

SQLBits Logo

 

Die Themen, welche ich dort in 60 Min anreißen werde, gibt aber auch noch mal im Detail und zwar ganze drei Tage lang mit Hands-on von mir auf dem PASS Camp 2010 R2 in Mettmann bei Düsseldorf!

Freitag, 6. August 2010

Die Website für die Anmeldung zum PASS Camp 2010 (R2) ist online!

Hier nur “kurz” die Meldung, dass die Website für die Anmeldung zum PASS Camp 2010 (R2) online gegangen ist!

Ihr erinnert Euch vielleicht, da bin ich dieses Mal als Sprecher dabei und werde Euch mein absolutes Lieblingsthema drei Tage am Stück nahebringen: Microsoft Business Intelligence für Entwickler!

Hier gehst zum PASS Camp 2010!

Das ist die Agenda für meinen Track:

Dienstag, 19.10.2010

  • Einleitung - Warum überhaupt programmieren?
    Der Microsoft SQL Server bietet eine ganze Reihe von äußerst mächtigen Diensten und Werkzeugen für die Erstellung von Business Intelligence Lösungen. Warum sollte sich dann überhaupt ein BI Berater mit den Möglichkeiten der Programmierbarkeit des SQL Servers beschäftigen? Weicht er damit nicht vom Standard ab? Und warum sollte sich ein Programmierer mit BI befassen? Sind die BI relevanten Dienste vom SQL Server etwa nicht fertig?
    Die Wahrheit ist, dass eine wesentliche Stärke des SQL Servers, neben den bekannten Werkzeugen, die Verfügbarkeit von diversen sehr gut dokumentierten APIs ist. Diese APIs können sehr gut im Rahmen von BI Projekten genutzt werden und die Integrationsfähigkeit einer BI Lösung um ein vielfaches erhöhen. Alle in diesem Workshop vorgestellten Schnittstellen sind offiziell von Microsoft beschrieben worden und werden in zukünftigen Versionen unterstützt werden.
    Vor dem Einsatz von Technologie kommt aber immer die zielgerichtete Konzeption der Lösung. Es wird gezeigt, wann und wie sich der Einsatz von Programmierung in BI Projekten tatsächlich rechnet und welche Voraussetzungen dafür erfüllt sein müssen.
    Ein ganz wesentlicher Punkt aus der Erfahrung heraus ist die Nutzung der Abstraktion der Anforderungen und der Technologie als Architekturansatz im Design von Business Intelligence Lösungen.
  • Einführung mittels Crashkurs in die Entwicklung mit dem Visual Studio 2010
    Damit alle mit den gleichen Voraussetzungen starten können, gibt es nach dem ersten Brocken Theorie, einen Crashkurs für die Nutzung des Visual Studios 2010.
    Anhand von Labs wird die grundlegende Handhabung des Visual Studios vermittelt und in die Programmierung mit dem .net Framework eingeführt.
    Dabei werden folgende Themen erläutert:
    - Command Line Tools
    - PowerShell (CmdLets)
    - Entwicklung von einfachen GUIs
    - XML-Files als Parameter verwenden
    - Nutzung von ADO.NET für den Zugriff auf den SQL

Mittwoch, 20.10.2010

  • SQL Server Analysis Services
    Nun kommen die Analysis Services an die Reihe. Zunächst beschäftigen wir uns kurz mit ein wenig MDX Grundlagen, um dann mittels ADOMD.NET OLAP Cubes direkt abzufragen. Damit haben wir die Grundlage für eigene OLAP Clients geschaffen.
    Als nächstes beschäftigen wir uns mit den Analysis Services Management Objects (kurz AMO), um die Erstellung von OLAP Cubes entweder teilweise oder gar vollständig auf der Basis von Metadaten zu automatisieren. Wir erstellen Dimensionen und Measures. Des Weiteren schaffen wir die Grundlagen für einen eigenen KPI Designer für Cubes. Diese Technologie lässt sich ganz hervorragend kombinieren mit unseren neuen Kenntnissen vom Vortag über dynamisches SSIS.
  • SQL Server Reporting Services
    Mit den Reporting Services geht es weiter. Wir entwickeln zuerst eigene Berichtselemente. Des Weiteren beschäftigen wir uns mit der Flexibilität der Reporting Services bei der Umsetzung von Anforderungen für die Integration von Berichten in vorhandene Umgebungen.
    Zwischendurch schauen wir uns noch den Ansatz an die Reporting Services als Benutzeroberfläche zu verstehen und BI entsprechend zu konzeptionieren.
    Auch bei den Reporting Services wenden wir uns zum Abschluss den Möglichkeiten zur automatischen Erstellung und Wartung zu. Wir erstellen gemeinsam Werkzeuge mit denen RDL Dateien (aka Reports) auf Basis von Metadaten erstellt als auch inventarisiert werden können.
  • Weboberflächen mit ASP.NET / Ajax
    Zeit sich intensiver mit der Entwicklung von Benutzeroberflächen und Visualisierungen zu beschäftigen. Es gibt Grundlagen für die Erstellung von Weboberflächen mit ASP.NET / Ajax und der Kommunikation mit den SQL Server Diensten via Web Services und WCF. Dann aber experimentieren wir gemeinsam mit GDI+, um erste alternative Visualisierungen umzusetzen.
    Da wir ja nicht alles selbst schreiben wollen, schauen wir uns auch noch das Chart Control des .net Frameworks ein wenig genauer an.

Donnerstag, 21.10.2010

  • Silverlight
    Heute kommt noch mehr Interaktivität ins Spiel. Mittels Expression Blend entwerfen wir erste Entwürfe für moderne Benutzeroberflächen (RIA) und beschäftigen uns dabei mit der Beschreibungssprache XAML.
    Dann drehen wir das Ganze um und steigen in die Steuerung einer Silverlight Anwendung vom Code aus ein. Nun nehmen wir unsere Erkenntnisse über SSIS, SSRS, ADOMD.NET und AMO und binden diese in unsere Silverlight Anwendungen ein. Damit haben wir auf der einen Seite sehr dynamische Oberflächen und auf der anderen Seite einen Zugriff auf die Dienste des SQL Servers für den Zugriff auf Daten (ADOMD.NET) und die Steuerung der Prozesse zur Verarbeitung (SSIS & AMO) dieser.
    Abschließend entwickeln wir gemeinsam die Grundlagen für einen universellen OLAP Client unter Silverlight, welcher sich flexibel an Anforderungen in Projekten anpassen lässt.
  • Erweiterungen für Office & SharePoint 2007/2010
    Nach soviel Neuem wenden uns nun wieder unserem alten Freund Excel zu und erweitern diesen um selbsterstellte Aufgabebereiche für den Zugriff auf Daten und unsere erstellten Dienste.
    Zum Abschluss des Workshops werfen wir noch einen Blick auf den SharePoint Server. Wir entwickeln eigene Webparts, welche wiederum auf unsere Daten und Dienste zugreifen werden. Und wo wir gerade dabei sind, werden wir die SharePoint Search Funktionalität für unsere BI Lösungen zu nutzen lernen.

Mittwoch, 4. August 2010

Microsoft Visual Studio LightSwitch (managed Access?)

Bin ja sonst nicht mehr so der Fan von Product-Placement, aber das hier scheint ein paar Zeilen wert zu sein!

Hier kommt ein neues Visual Studio (Codename Kittyhawk), welches u. a. für den ambitionierten und kreativen Endanwender gedacht sein wird. LightSwitch ist damit das langerwartete “managed Access”!?!

Es macht einen durchdachten Eindruck, wie da in den Demos SQL Server, SQL Azure, SharePoint usw. mittels einer wirklich einfachen Oberflächen zusammengebracht werden. Ohne es bisher selbst in den Händen gehabt zu haben, kann ich mir trotzdem vorstellen, dass es einen deutlichen Drive in die Entwicklung von diesen kleinen fiesen aber geschäftskritischen Anwendungen bringen wird, welche in diesem Paralleluniversum neben dem ERP System existieren!

http://www.microsoft.com/visualstudio/en-us/lightswitch

Die Beta soll ab dem 23. August verfügbar sein.

Schön ist auch der Claim: “THE SIMPLEST WAY TO BUILD BUSINESS APPLICATIONS FOR THE DESKTOP AND CLOUD”

We are all in! :-)

Dienstag, 3. August 2010

Nutzung eines Jobpools in Business Intelligence Umgebungen

Da ich vor ein paar Tagen ja über Repositories in Data Warehouse Umgebungen geschrieben habe, hier noch ein paar weitere Gedanken dazu. Im Rahmen der European PASS Conference 2009 habe ich zwei Vorträge gehalten. In dem einen ging es primär um dynamisch erstellte SSIS Pakete. Eine äußerst leistungsfähige Technologie, wenn in umfangreicheren Projekten eine größere Menge an SSIS Tasks und Paketen benötigt wird, welche auf Basis von Metadaten erzeugt werden sollen. Ein sekundärer Aspekt dieser Session, welcher ein wenig unterging, war die Nutzung eines Jobpools innerhalb eines Repositorys.

Damit sind wir wieder beim Thema. Es geht mir dabei um die Arbeit mit einer großen Menge an einzelnen Paketen und Jobs, welche zum Beispiel im Rahmen einer Datenbewirtschaftung eines Data Warehouses verarbeitet werden müssen. Natürlich gibt es eine ganze Reihe von Abhängigkeiten, welche bei der Abarbeitung berücksichtigt werden müssen! Als Lösung für eine solche Herausforderung wird gerne die Ablaufsteuerung von SSIS verwendet. Mit dieser lassen sich Abhängigkeiten zwischen einzelnen Paketen sehr leicht visuell modellieren. Dabei werden Jobs in immer der identischen sequentiellen Reihenfolge bzw. parallel abgearbeitet.

Blog Repository Folien1

Ein Nachteil dieser Vorgehensweise ist aber die Handhabung in sehr großen Umgebungen, welche auch noch zum Teil dynamisch sind. Wenn dann noch der Wunsch nach automatischer Lastverteilung, Skalierbarkeit und Ausfallsicherheit an die Umgebung gestellt wird, dann kann es schon äußerst komplex werden!

Als eine mögliche Lösung für dieses Szenario setze ich gerne auf einen sogenannten Jobpool. Dabei werden die einzelnen Aufgaben bzw. Jobs zentral in einem Pool abgelegt. Von “außen” greifen nun sogenannte Agents auf diesen Pool zu und “suchen” sich die Pakete, welche sie verarbeitet werden dürfen.

Blog Repository Folien2

Ob ein Paket aus dem Pool genommen werden darf und verarbeitet werden kann, wird auf Basis von Regeln entschieden. Zum Beispiel kann eine sehr einfache Regel sein, dass erst alle Pakete der Gruppe “ExtraktionCRM” fertig sein müssen, bevor mit der Verarbeitung der “Dimension Kunde” begonnen werden kann. Dabei ist es aber nicht entscheidend, in welchen Reihenfolge die Pakete der Gruppen “ExtraktionCRM” ausgeführt werden.

Wenn nun ein neuer Job dem Pool hinzugefügt wird, dann muss dieser nicht mit anderen Jobs “verdrahtet” werden, sondern er wird einem Regelsatz zugewiesen. Die Agents, welche die Pakete bzw. Jobs verarbeiten, können für unterschiedliche Aufgaben zur Verfügung stehen. Zum Beispiel dem einfachen Ausführen von SSIS Paketen oder dem Verarbeiten von AMO Anweisungen für den Aufbau von Cubes. Die Agents können über mehrere Server verteilt werden. Dadurch ist eine Lastverteilung und Skalierbarkeit gegeben, ohne, dass eine Ablaufsteuerung manuell an die neue Hardware (welche auch gern virtuell sein kann) angepasst werden muss. Der Ausfall eines Server ist zwar bedauerlich, da seine Leistung fehlt, aber führt nicht mehr zum Abbruch der gesamten Verarbeitung!

 Blog Repository Folien

Wichtig ist mir die Abgrenzung, dass ein Jobpool erst in größeren Umgebungen Sinn macht! In einer überschaubaren Umgebung ist die SSIS Ablaufsteuerung mit ihren Möglichkeiten wesentlich sinnvoller. Der Moment über einen Jobpool nachzudenken ist gekommen, wenn der Verantwortliche für die Datenbewirtschaftung erst ein paar Minuten braucht, um die vermeintlich richtige Stelle in einem Paket zu finden, um einen neuen Job hinzuzufügen. Auch Anforderungen wie Skalierbarkeit, Lastverteilung und Ausfallsicherheit können Treiber für diesen Ansatz sein.

Sonntag, 1. August 2010

Die verwendeten Spalten und Tabellen einer beliebig komplexen SQL Query ermitteln

Mein letzter Blogeintrag zum Thema Repository im Data Warehouse scheint einige Fragen aufgeworfen zu haben!

Neben dem eigentlichen Thema “Repository”, danke für die Rückmeldungen, kam oft die Frage, wie ich denn nun aus einer SQL Query die in dieser verwendeten Spalten der Quelltabellen auslese und was der Queryplan damit zu tun hat. Daher hier jetzt ein paar mehr Informationen dazu.

Die Vorgehensweise ist ein Abfallprodukt aus der Entwicklung eines Performancetuning Tools in einem Projekt.

Kurz zur Sicherheit erwähnt, wofür ich sowas in Projekten überhaupt benötige. Es geht um die Aufgabenstellung, dass ich hunderte von Queries habe und sehr gerne “auf-Knopfdruck” sehen möchte, welchen Einfluss eine Änderung am Datenmodell auf eben diese Queries hätte. Woher habe ich diesen Berg Abfragen? Entweder aus einem Profiler Trace einer OLTP Anwendung oder aus RDL-Dateien. Auch schon gemacht, daher hier als möglich aufgezählt, die Quellen in SSIS Paketen und Analysis Services Projekten. Auf jeden Fall sind die von einer Lösung verwendeten Queries immer gute Kandidaten in einem entsprechenden Repository gespeichert zu werden.

Gerne empfehle ich ISVs auch ein solches Repository als Grundlage einer Dokumentation zu führen und vor Änderungen am Datenmodell wie hier beschrieben vorzugehen. Damit fängt ein gutes Qualitätsmanagement doch erst an. Das Performancetuning kann dann gleich “daneben” gepflegt werden. So sah übrigens das ursprüngliche Projekt aus.

Die Aufgabenstellung nach den verwendeten Spalten hatte ich schon oft, aber häufig ist der erste Gedanke der Kunden, dass man dafür doch einen separaten SQL Parser bräuchte. Nun ja, sicherlich machbar, also mit entsprechend Zeit usw., aber nutzen wir doch den SQL Server als Tool dafür!

Nehmen wir mal eine einfache Query für das AdventureWorksDW2008

select SUM(salesamount) as summe
from dbo.FactInternetSales f
left join dbo.DimCustomer c on f.CustomerKey = c.CustomerKey
where c.HouseOwnerFlag = '0'

Mittels SET SHOWPLAN_XML ON bringe ich den SQL Server dazu, dass dieser…

a.) die Query nicht ausführt
b.) mir den geschätzten Ausführungsplan im XML Format liefert

image

Schon mal total toll. Nur bringt es mich überhaupt nicht weiter, da ich den Prozess ja automatisieren möchte. Also Management Studio zu, Visual Studio auf und ein wenig C#.

SqlConnection con = new SqlConnection(<ConnectionString>);
con.Open();
SqlCommand showplan_on = new SqlCommand("set showplan_xml on", con);
showplan_on.ExecuteNonQuery();

SqlCommand query = new SqlCommand(<Query>, con);
SqlDataReader showplan_results = query.ExecuteReader();
if (showplan_results.Read())
    tbOutput.Text = showplan_results[0].ToString();
showplan_results.Close();

SqlCommand showplan_off = new SqlCommand("set showplan_xml off", con);
showplan_off.ExecuteNonQuery();
con.Close();

image

Und schon habe ich den geschätzten Ausführungsplan erhalten und zwar ohne, dass meine Query ausgeführt wurde!

Mit so einem Ausführungsplan kann man nun sehr spannende Sachen machen, aber für unseren Fall hier interessieren uns nur die Elemente mit dem Namen ColumnReference. Da stecken nämlich unsere Spalten drin. Wie kommen wir da nun ran? Der Ausführungsplan ist bereits geladen. Aber er ist noch als String verpackt. Das kann das .net Framework aber besser, daher nix wie ab in eine XML Datenstruktur und die Elemente gesucht.

XmlDocument dom = new XmlDocument();
dom.LoadXml(tbOutput.Text);

XmlElement root = dom.DocumentElement;

XmlNamespaceManager nsmgr = new XmlNamespaceManager(dom.NameTable);
nsmgr.AddNamespace("bk", "
http://schemas.microsoft.com/sqlserver/2004/07/showplan");

XmlNodeList nodelist = root.SelectNodes("//bk:ColumnReference[@Database]", nsmgr);

Und wir haben eine NodeList mit unseren Elementen! Diese können wir nun ausgeben.

xn.Attributes.GetNamedItem("Database").InnerText + "." + xn.Attributes.GetNamedItem("Schema").InnerText + "." + xn.Attributes.GetNamedItem("Table").InnerText + ".[" + xn.Attributes.GetNamedItem("Column").InnerText + "]"

Da haben wir unsere Spalten! War doch ganz einfach, oder?

image 

Und das funktioniert dann natürlich nicht nur mit SELECT Statements! Hier mal ein Beispiel für ein UPDATE Statement mit Unterabfragen.

image 

Ergibt folgende Ausgabe:

image 

Mit dieser Vorlage sollte sich eigentlich jeder sein eigenes Tool für diese Art von Fragestellung bauen können. Viel Spaß damit!