Freitag, 13. Mai 2011

ShareCamp, ich bin auf dem Weg – Business Intelligence mit SharePoint

Langsam nähere ich mich Unterschleißheim. Dort ist ja am kommenden Wochenende das ShareCamp im HQ von Microsoft Deutschland.

Nachdem ich vorgestern ja noch beim PASS (SQL Server Usergroup) Treffen in Hamburg dabei war,  habe ich noch kurz Station gemacht in der PASS Regionalgruppe Hannover und dort einen Vortrag über “The Developer Side of Microsoft BI” gehalten. Hat großen Spaß gemacht! Sehr interessante Diskussionen. Besonders mit den drei Regionalgruppenverantwortlichen vor Ort: Christoph Seck, Artus Krohn-Grimberghe & Vladimir Stepa. Gerade die Diskussionen mit Vladimir, einem der Mitentwickler des berühmten MDX Studios, waren anspruchsvoll aber sehr auch inspirierend!

Danke, dass ich dabei sein durfte! Ich hoffe, dass für alle ein paar Anregungen dabei waren!

Heute geht die Fahrt weiter nach München.

Auf dem ShareCamp gibst dann von mir Einiges zum Thema BI mit dem SharePoint Server.

Auf Rückweg können wir uns dann noch in Köln am Montag Abend beim PASS Treffen im Microsoft RO begegnen. Da halte ich dann ja auch noch einen Vortrag.

 

ps:Sorry für die Verspätung des Posts, Blogger war teilweise down.

Samstag, 7. Mai 2011

SSIS (Integration Services) als ETL Lösung – Dynamisches SSIS? [Coaches’ Hell]

Eine häufige Frage an mich ist, warum ich überhaupt so viel Zeit investiere in die Entwicklung von projektspezifischen SSIS Generatoren. Schließlich lasse sich doch in SSIS fast alles über Expressions und den Mechanismus der Paket-Konfiguration von außen dynamisch steuern! Wozu also der ganze Aufwand?

Die Aussage mit den Expressions (Ausdrücken) und der Konfiguration ist für sich genommen natürlich korrekt und wird von mir bzw. meinen Kollegen in Projekten auch verwendet.

Wichtig ist aber die Einsicht, dass sich halt nur “fast” alles damit steuern lässt! Und aufgrund der Architektur der Integration Services lässt sich während der Laufzeit eines Paketes der Inhalt eines Datenflusstasks nicht verändern! Und gerade da setze ich häufig an, um die Erstellung und Wartung von SSIS Paketen weitestgehend zu automatisieren.

Oft sehe ich aber Ansätze von Kunden oder in der Community für dynamisches SSIS, welche so nicht funktionieren können. Um solchen Missverständnissen vorzubeugen, möchte ich heute mal ein Beispiel zeigen, was eben gerade nicht funktionieren kann. Den Ansatz brachte neulich ein Kunde zum SSIS Coaching mit.

Also, sein Ansatz sieht vor, dass er zwei Variablen hat. Eine für den Namen einer Tabelle und einen für die SQL Query.

image

Dann kommt er mit der Idee, die Eigenschaft “EvaluateAsExpression” der Variable “SQL” zu nutzen, um die Query zusammenzusetzen. Damit hat die Variable den Value, welcher sich aus der Expression ergibt.

image

Nun kommt in einem Datenflusstask eine OLE DB Quelle, in welcher die Variable “SQL” verwendet wird. Alles gut, wir sehen die Query unten. Das scheint zu passen.

image

Den Datenfluss erweitern wir nun um einen Multicast, damit er lauffähig wird. Multicast kann ja durchaus aus mal zum Testen von Paketen verwendet werden da es “auch” ein NULL-Ziel sein kann. Noch ein Blick auf die Metadaten, die sind ja das A&O eines Datenflusstasks. Sind auch da. Immer noch alles gut!

image

Und wir lassen das Paket mal laufen. Wenige Sekunden später. Es funktioniert. Also, wozu die ganze Aufregung?

image

Kommen wir zum eigentlichen Zweck der Variablen. Ändern wir die Variable für die Tabelle ab, um eine andere Tabelle als Quelle zu verwenden. Ich habe hier gerade noch die Demotabelle für meinen RDLInput liegen, nehmen wir einfach die.

image

Und wieder starte ich das Paket. Und was passiert? Ein Fehler kommt hoch! Hier ist nämlich der Denkfehler versteckt. Und zwar gibt es ein Problem mit den Metadaten.

image

Schließen wir die Meldung und öffnen mal unsere Quelle. Und wieder kommt eine Meldung hoch. Und zwar möchte uns die Quelle mitteilen, dass die SQL Query (in der Variable) und die Metadaten der Quelle nicht mehr synchron sind. Also nicht mehr übereinstimmen. Klar, wir wollten nun ja auch eine andere Tabelle haben und natürlich hat diese andere Spalten. Selbst das automatische Beheben des Fehlers würde nur die Quelle “heilen”, aber die weiteren Datenflusselemente hätten ebenfalls mit den Metadaten zu kämpfen. Also stände uns viel manuelles Doing bevor, um das alles wieder anzupassen. Die dynamische Konfiguration hat sich also nicht gelohnt.

image

Wie kommt es nun dazu?

Die Architektur der Integration Services sieht vor, dass die Metadaten eines Datenflusstasks zur Entwurfszeit bekannt sind, damit alle der Quelle folgenden Elemente korrekte Input & Output Spalten haben können. Wenn also während der Laufzeit in die Metadaten eingegriffen wird, wie zum Beispiel durch das Neusetzen einer Variable, welche eine Query enthält, dann schützen sich die SSIS und werfen sofort einen Fehler! Wenn Pakete mit den Microsoft Bibliotheken per Repository erzeugt werden, dann befindet sich das Paket in dem Moment ebenfalls im Entwurfsmodus und es können die Metadaten korrekt zugewiesen werden. Das ist die Magie eine SSIS Paket Generators gegenüber der Konfiguration.

Wo dieser Ansatz aber sehr wohl funktioniert, ist eine Umgebung, in der zwar der Tabellenname sich ändern kann, aber die Metadaten (Spalten) identisch bleiben. Selten, kann es aber auch geben. Häufiger kommt eigentlich vor, dass der Connectionstring einer Quelle und eines Ziels mittels Konfiguration geändert wird, damit man zwischen Entwicklungs-, Test- und Produktivumgebung wechseln kann. Das macht durchaus Sinn! :-)

Donnerstag, 5. Mai 2011

PASS, PASS, ShareCamp & PASS – Meine nächste Woche

So, jetzt ist es amtlich! Meine nächste Woche wird ein “wenig” Community-lastig…

Mittwoch, den 11.5., PASS Treffen Hamburg zum Thema “Denali” (da bin ich nur Co-Sprecher…) –> Dank an Markus Thomanek von Microsoft!

Donnerstag, den 12.5., PASS Treffen Hannover zum Thema “Developer Side of Microsoft BI” (mit mir als Sprecher)

Freitag, den 13.5., bis zum Sonntag, den 15.5., bin ich dann als Sponsor (& als Sprecher) auf dem ShareCamp 2011 in Unterschleißheim, München dabei

und weil es so schön in der Community ist…

Montag, den 14.5., PASS Treffen Köln zum Thema “Developer Side of Microsoft BI” (wieder mit mir als Sprecher).

Sehen wir uns? Bei der Tour gibt es fast keine Ausrede mehr! :-)

Mittwoch, 4. Mai 2011

SSIS (Integration Services) – ETL vs. ELT Lösung?

Und wieder war es ein Meeting, welches mich zu einen Blogpost animiert.

Wir sprachen über die Einführung eines Data Warehouses, ETL etc. pp. und dann kam da einer mit einer ganz tollen Frage: Was ist denn mit ELT und wo sei der Unterschied? Und ob das denn die Integration Services auch könnten? Ist doch die Zukunft des Integrationsprozesses, sagt doch der andere Hersteller. Also wäre ja zu erwarten, dass Microsoft solche Innovationen unterstützt. Der klassische ETL Prozess wäre ja quasi von gestern und mit ELT dann ja auch dazu noch überflüssig geworden.

Erwartungsvolle Gesichter in der Runde. Was ist denn nun ELT und kann das der SQL Server? Ich liebe meinen Job…

Also, klassisches ETL (Extract, Transform, Load) meint, stark vereinfacht ausgedrückt, dass Daten aus verschiedenen Vorsystemen extrahiert werden. Diese werden in der Regel in Form von “Datenpaketen” in einer sogenannten Landing Zone gesammelt. Von dort aus werden die Pakete i. d. Regel mehrstufig weiterverarbeitet, sprich transformiert. Der letzte Schritt ist das Laden der Daten in das relationale Data Warehouse, wobei dann noch die Historisierung von Daten durchgeführt werden kann. 

Was kann nun eine ELT Lösung dazu Innovatives beitragen? Das Offensichtliche zuerst. ELT steht für Extract, Load & Transform. Ok, ist halt vertauscht. Und? :-)

Die Idee dabei ist, dass Daten wiederum zuerst aus Vorsystemen extrahiert werden. Die Methoden, Konzepte, Ideen und auch Herausforderungen sind 100% identisch zur ETL Welt. Auch können diese Daten in Form von Datenpaketen organisiert werden. Nur dann kommt der wesentliche Unterschied! Die Daten werden beim ELT Ansatz gleich wieder in ein relationales Datenbanken System geladen. Häufig ist es das System, welches auch das eigentliche Data Warehouse hält. Und auf diesem System werden die Daten mittels SQL Statements transformiert. Das ist schon alles.

Ok, ok… wozu jetzt die ganze Aufregung? Dazu müssen wir noch ein wenig mehr ins Detail gehen beim ETL Prozess. Beim ETL findet häufig eine Verarbeitung der Daten außerhalb einer relationalen Datenbank statt. In der Regel werden die Daten zeilenweise verarbeitet. In den Integration Services wird das durch den konsequenten Einsatz der Datenflusskomponente und des RAW-Dateiformates erreicht. Ab einer sehr großen Datenmenge ist dieses Vorgehen deutlich schneller als die relationale Engine zu bemühen.

Bei ELT gibt es aber keine extra Verarbeitungsengine, sondern “alles” findet innerhalb einer relationalen Datenbank statt. Es wird damit eine Technologie “gespart”. Das ist der häufig ins Feld geführte Vorteil einer ELT Architektur. In der Praxis heißt das auch oft, dass ein extra System gespart wird.

Meine 2 Cent dazu sind:
ELT klingt gut, kann es sogar sein, ja wenn… die Rahmenbedingungen stimmen! Wenn ich keine wirklich komplexe und unübersichtliche Umgebung habe. Des Weiteren sollte die Anzahl der Vorsysteme überschaubar sein. Und, steht ja schon oben, die Datenmenge sollte auch gewisse Grenzen haben (und nein, da gibt es keine one-size-fits-all Antwort drauf!).

Die Wahrheit ist, dass es da draußen eine Unmenge an ETL Prozessen gibt, welche sehr wahrscheinlich ELT Prozesse sind. Und bisher hat es keinen gestört! :-)

Ach ja, und natürlich lassen sich auch ELT Integrationsprozesse mit dem Microsoft SQL Server abbilden. Alles eine Frage der Architektur!

Sonntag, 1. Mai 2011

SQL Server Reporting Services (SSRS) – Wofür können diese eigentlich alles genutzt werden?

Ein schon ein paar Tage zurückliegendes Meeting mit einem Kunden brachte mich auf die Idee für diesen Post.

Es ging dabei um einen Pitch für den SQL Server und all seine Möglichkeiten. Ihr wisst schon, diese “Zeigen Sie mal, was das kann…” Termine in 90Min. Also war wieder selektives & spontanes Highlights zeigen angesagt. Hat ja keiner die notwenigen 48h Zeit.

Ein echtes Highlight aus meiner Sicht sind die Reporting Services (SSRS). Aber ähnlich wie die Integration Services (SSIS), welche gerne mal nach wenigen Minuten mit “sagen Sie doch gleich Schnittstelle…” abgetan werden, sind die Reporting Services für viele einfach “ach so, Berichte, haben wir natürlich schon…” und liegen damit wohl verpackt in einer Schublade, die den Möglichkeiten einfach nicht gerecht wird.

Sofern Ihr auch mal in diese Situation kommen solltet, hier ein paar Anregungen (ohne den Anspruch auf Vollständigkeit) wofür die SQL Server Reporting Services noch alles genutzt werden können.

Berichtswesen (Enterprise Reporting) & Self-Service BI Tool
Klar, das ist DIE Domäne der Reporting Services und da muss sich das Produkt auch nicht vor Marktbegleitern verstecken. Neben den Möglichkeiten im eigentlichen Bericht (Tablix & co), sollte da aber immer auch auf die “Enterprise” Features eingegangen werden, wenn denn ein CIO im Raum ist. Denn Enterprise steht für mich als das Synonym für “Große, komplexe bis unübersichtliche Umgebungen”. Hier können die Reporting Services durch ihren Ansatz als zentraler hochverfügbarer Dienst punkten. Die Verwaltung lässt sich auch weitestgehend automatisieren.

Nur was kann jetzt noch kommen? Was können die Reporting Services nun noch außer Berichte erzeugen? Eine ganze Menge!

Dashboards
Auf Basis der Reporting Services lassen sich aussagekräftige Armaturenbretter (neudeutsch Dashboards) erstellen. Und dabei können diese von Tachometer (Gauge) bis hin zur Sparkline alle geschätzten Visualisierungsansätze verwirklichen. Diese können, sofern notwendig, sich sogar automatisch in quasi Echtzeit aktualisieren.

Benutzeroberfläche für die Endanwender einer Business Intelligence Lösung
Da ja der Microsoft Business Intelligence Stack keine “eigene” Oberfläche mitbringt, steht der geforderte Berater häufig in der Pflicht hier eine kompetente Aussage machen zu müssen. Die korrekte Antwort wäre hier sicherlich SharePoint, aber es gibt immer wieder Gründe, welche den spontanen Einsatz von SharePoint verhindern. Eigentlich schade, aber was dann? Hier können die Reporting Services helfen, da diese ganz hervorragend ein zentraler Anlaufpunkt für die Endanwender sein können. Des Weiteren bietet die Möglichkeit die RDLs untereinander zu verlinken, dem Endanwender ein geschlossenes Benutzererlebnis. Und Funktionen, welche nicht dabei sind, können in ASP.NET relativ leicht nachgereicht werden. Vielleicht sollte ich später mal mehr zu diesem Punkt schreiben.

Benutzeroberfläche für die ETL/Reporting/BI Prozess Verantwortlichen
Das geht dann natürlich auch, denn irgendjemand ist ja für die Prozesse im Hintergrund verantwortlich und möchte oder sollte sich nicht immer gleich aufs Management Studio stürzen müssen, um mal was nachzusehen. Und wo wir gerade in der IT unterwegs sind. Natürlich lassen sich da auch alle anderen IT Prozesse ganz hervorragend mit kapseln und, über die Möglichkeit klassische Hyperlinks dynamisch einzubinden, auch noch interaktiv steuern.

Export Schnittstelle, welche die Fachabteilungen selbst “pflegen” können (Self-Service Schnittstelle)
Die Reporting Services können ja nicht “nur” HTML, Excel, Word & PDF exportieren, sondern auch schnödes CSV & XML. Damit lassen sich sehr einfach zentral gesteuerte (Zugriffsrechte & co) Schnittstellen für Fachabteilungen aufsetzen, welche dann im Detail, wie zum Beispiel Spaltenwahl, vor Ort gepflegt werden können. Damit lässt sich die eine oder andere Access Installation vermeiden.

Datenquelle
Nun aber, die Reporting Services können nicht nur als Daten-Konsument herhalten, sondern mittels Data Feeds (& CSV s.o.) auch als Datenquelle für weitere Prozesse und Anwendungen. Das wohl mittlerweile prominenteste Beispiel dafür ist PowerPivot, welches sich direkt aus existierenden Reports bedienen kann.

Erzeugen von Images
Und hier noch der Hinweis auf ein häufig unterschätztes Feature der Reporting Services. Es können nämlich sehr einfach Images in fast allen benötigten Formaten (jpg, png etc.) erzeugt werden. Damit lassen sich einige sehr schöne Anforderungen umsetzen! :-)

Hier endet meine kleine Liste. Wichtig wären mir noch zwei Hinweise:

1. Berücksichtigt bitte immer, dass die Reporting Services auf unterschiedlichste Wege anzusteuern und einzubinden sind. Erweiterbarkeit und die Möglichkeit der Automatisierung sind meiner Meinung nach fast schon einzigartig für einen “Berichtsserver”. Kreativität zählt hier!

2. Habt bitte immer ein Auge auf die Lizenzierung der Umgebung! Also wer von den Ergebnissen Eurer Prozesse profitiert und damit lizenziert sein müsste usw. Bei Fragen zu Details dazu wendet Euch bitte einfach an Euren Ansprechpartner bei Microsoft! :-)