Die Menschen hinter den Produkten, Teil 5: Lukasz Pawlowski, Reporting Services

Lukasz Lukasz Pawlowski ist ein Program Manager im SQL Server Reporting Services Team. Wir unterhalten uns unter anderem über die neue Architektur, Optimierungen, Report Designer Controls und Web Services.

Hallo Lukasz, Du bist einer unserer großartigen Sprecher für die TechEd EMEA ITProfessionals, wenn Du mir endlich die Abstracts schickst die Du mir schon zweimal versprochen hast.

Wundervoll. Es ist eine Freude, Abstracts abzugeben, wenn auch verspätet wegen Zeitzonenverschiebungen, aber danke für die Ehre. Ich freue mich auf die TechEd EMEA.

Lukasz, kannst Du uns einen Überblick über das Reporting Services Team geben. Du weißt, ich bin in Building 35 bei den Leuten aus der relationalen Datenbank, und Ihr seid hier sozusagen die Vorstädte in Building 34.

Ja, wir sind jetzt die Vorstädte. Wir sind zu einer Größe gewachsen wo die Business Intelligence Teams in ein anderes Gebäude umziehen mussten. Reporting Services ist über die letzten Jahre kräftig gewachsen. Ganz am Anfang beim Start von Reporting Services waren wir zwischen 12 und 17 Leute. Das ist bis zur Veröffentlichung von SQL Server 2008 auf mehr als 80 Leute angewachsen. Dieses Team besteht aus einer Reihe von verschiedenen Bereichen. Ich arbeite am Server. Von uns stammt die Server-Infrastruktur, die Web Services, Konfiguration, Serververwaltung. Zu uns gehören Werkzeuge wie Management Studio (der RS Teil), Report Manager, das Konfigurationstool und die Skripting-Werkzeuge. Dazu der größte Teil der programmatischen Interfaces: Web Services, das URL-Interface, Erweiterbarkeit und so.

Es gibt andere Teile des Produkts wie die Reporterstellung (Report Creation Team). Dieses Team erstellt den Report Designer, Report Builder, den Modell-Designer. Alles, was den Benutzern die Report-Entwicklung einfacher macht. Dieses Team arbeitet eng mit dem Report Processing & Rendering Team zusammen. Das Report Processing & Rendering Team stellt sicher, dass wir Daten von einer Datenquelle abrufen und diese Daten korrekt transformieren und den Benutzern in verschiedensten gerenderten Formaten bereitstellen können. Sie sind auch für die Arbeit an der Report Definition Language (RDL) zuständig und was in RDL enthalten ist. Diese Arbeit an RDL wird dann vom Reporterstellungsteam genutzt. Es gibt auch ein recht neues Team im Produkt, das Data Visualization Team. Diese Gruppe ist dafür zuständig, dass unsere Charting-Technologie und unsere Report-Visualisierung sehr ansprechend sind (compelling – irgendwie schwer zu übersetzen). Die Neuerungen in 2008 in Bezug auf verbessertes Charting und die Möglichkeit, Gauges in Reports zu haben kommen aus dem Data Visualization Team. Das Visualization Team hat auch die Aufgabe, diese Komponenten für andere Microsoft-Technologien zur Verfügung zu stellen, damit diese Arbeit in Zukunft auch in anderen Produkten genutzt werden kann.

Eine der größten Neuerungen in SQL Server2008 ist, dass Reporting Services nicht mehr Internet Information Server (IIS) verwendet. Warum ist das so?

Erst mal – IIS ist fantastisch für das was es tut. Es ist ein universeller Webserver, der viele Webseiten an viele Benutzer ausliefert und viele Möglichkeiten bietet, diese Websites in die gesamte IT Infrastruktur einzubetten.

Reporting Services sind etwas anders. Es ist ein Anwendungsserver (application server) der Reporting macht. Es ist kein universeller Webserver. Einige der Optimierungen oder einige der Arten, auf die IIS arbeitet sind nicht unbedingt passend für das, was Reporting Services tut. Reporting Services hat ein eingebautes Web-Interface und stellt Webservices bereit. Um das zu tun haben wir unseren eigenen Web Service Endpoint, der die gemeinsame Schnittstelle im Betriebssystem – http.sys – verwendet. Wir sind kein eigener Webserver, http.sys ist der Webserver und wir registrieren dort einen Endpoint. Genauso wie IIS das tut.

Warum verwenden wir IIS nicht mehr? Wir haben im Verlauf unserer Reporting Services (RS) Versionen festgestellt, dass wir – weil wir ein Anwendungsserver sind – eine Anzahl von Konfigurationseinstellungen haben, die einfach korrekt gesetzt sein müssen. Als RS eine IIS-Anwendung war wurden wir häufig parallel zu anderen Anwendungen in IIS installiert. Das Ergebnis können Konfigurations-Albträume für unsere Benutzer sein. Die Konfigurationen von anderen Anwendungen werden auf RS angewendet oder Einstellungen, die generell getroffen wurden sind nicht für RS geeignet. Das Ergebnis war, dass viele Kunden, die Reporting Services 2000 oder 2005 verwenden in eine Vielzahl von Konfigurationsproblemen mit IIS gelaufen sind. Aus Skalierbarkeits- und Sicherheitsgesichtspunkten ist IIS perfekt. Aber für die Konfiguration der Reporting Services Virtual Directories war IIS ein großes Problem. In SQL Server 2008 haben wir unsere Virtual Directoires aus IIS entfernt und das Ergebnis ist einfachere Konfiguration.

Der zweite Teil der Antwort sind die zwei Dienste, die wir mit IIS benötigten. Wir hatten einen Web-Dienst mit einer Identität in IIS und wir hatten einen Windows-Dienst mit einer eigenen Identität, der alle zeitgesteuerten Vorgänge wie Berichts-Zustellung und Datenbankwartung und so erledigte. Diese Trennung machte es schwierig, die gesamte Reporting Services Installation zu verwalten. Dadurch, dass wir nicht mehr IIS verwenden konnten wir diese beiden logischen Teile in einen einzigen Dienst vereinigen. Dieser einheitliche Dienst ermöglicht uns einfacheres Management. Zum Beispiel haben wir neue Möglichkeiten der Speicherverwaltung, die es dem Administrator erlauben festzulegen, wie viel Speicher Reporting Services verwenden darf. Durch die zwei verschiedenen Dienste ließ sich das früher deutlich schwieriger in Einklang bringen. Wir bekommen also nicht nur einfachere Konfiguration, unser Dienst lässt sich insgesamt auch leichter managen.

Ein weiterer Grund ist der Technologiestack, den wir in der SQL Server Organisation haben. Der ist das Fundament für die relationale Datenbank. In diesen Technologiestack wurde viel investiert, insbesondere in das Threading-Modell, Speicherverwendung, Prozess-Hosting und so weiter. Wir haben mit SQL Server 2008 darauf gewettet, dass wir durch die Verwendung dieses gemeinsamen Stack in der Lage sein werden, in Zukunft schneller Features implementieren zu können. Einige Aspekte davon sieht man schon in SQL Server 2008, zum Beispiel baut die Speicherverwaltung auf einigen gemeinsamen Komponenten auf. Für die Zukunft hoffen wir, weitere gemeinsame Technologien darauf aufbauen zu können. Das Ergebnis wird zum einen die schnellere Implementierung von Features, zum anderen aber auch eine einheitlichere Konfiguration und Verwaltung zwischen SQL Server und Reporting Services im Verlauf einer Reihe von Versionen sein. Und das verbessert dann die TCO. Kunden, die beides verwenden können sie konsistent verwalten, ohne dass sie zusätzlich IIS lernen müssen.

Eine weiteres Thema, an das ich bei Reporting Services 2008 denke ist das folgende: Viele Kunden haben Probleme mit sehr großen Reports, Reports mit zehntausenden von Seiten. So etwas hat zu großen Problemen mit der Speicherverwaltung geführt. In 2008 habt Ihr viel daran getan. Kannst Du etwas dazu sagen?

Klar. Eine der Haupt-Missionen für die 2008er Version war die Adressierung von Themen rund um große Berichte. Das Thema Reportgröße kommt an zwei Stellen hoch. Die erste sind sehr sehr große Berichte. Berichte mit einer Million Zeilen oder mehr. Wie effizient kann das Produkt solche Reports generieren und wie kann es sicherstellen, dass diese Reports auch auf Maschinen mit knappen Ressourcen fertiggestellt werden können? Der zweite Aspekt beschäftigt sich mit Workloads. Wenn man auf einem System viele kleine Reports hat, die parallel verarbeitet werden und dann ein größerer Report verarbeitet wird, der viele Ressourcen benötigt. In Vergangenheit konnte das viele andere Berichte verlangsamen und in einigen Fällen sogar zu deren Fehlschlag führen. Wir wollten beide Probleme in der 2008er Version lösen.

Um das zu erreichen haben wir das Vorgehen bei der Verarbeitung von Reports geändert. In den Vorversionen haben wir als erstes alle Daten, die ein Bericht benötigt in den Speicher geladen. Dann haben wir alle Berechnungen ausgeführt. Dann haben wir die Seiten des Berichts gerendert. Die Folgeseiten wurden dann gerendert, wenn sie abgerufen wurden. Wir haben also erst alle Daten gelesen, dann jede Berechnung bis zur allerletzten ausgeführt und dann die erste Seite gerendert, während alle Daten im Speicher verblieben. Wenn der Benutzer dann die zehnte Seite sehen wollte mussten wir herausfinden, was alles auf den Seiten dazwischen erscheint.

In der 2008er Version haben wir das Vorgehen verändert. Wir laden zwar immer noch alle Daten, aber wir verarbeiten nicht alle Daten und alle Berechnungen. Wir machen das bei Bedarf. Das kann man sich so vorstellen: Wenn Du Seite 5 haben möchtest, dann berechnen wir nicht mehr alles von Seite 1-5, sondern nur noch das, was wir für Seite 5 brauchen. Zum Beispiel kann Gruppierungs-Infrastruktur herausfinden, welche Daten Einfluss auf die Werte auf Seite 5 haben; die Module für weichen und harten Seitenumbruch können herausfinden, welche Elemente auf Seite 5 angezeigt werden. Und dann sagen wir dem Renderer: „Erzeuge Seite 5“. Der Renderer fragt dann die Processing-Engine „Gib mir den Wert von diesem Feld“, weil das auf Seite 5 erscheint. Dann wird dieser Wert berechnet und dem Renderer übergeben.

Insgesamt berechnen wir also weniger Elemente, haben also größere Effizienz. Wir berechnen nicht mehr alles vorher, sondern nur kleine Bereiche wenn diese abgerufen werden. Zu einem gegebenen Zeitpunkt wird also weniger berechnet. Auch wird weniger Hauptspeicher für die Datenstrukturen benötigt. Und wir können das optimieren. Wenn zu viel Speicher verbraucht wird können wir Teile ins Dateisystem auslagern.

Wenn wir alle Daten laden, dann müssen wir alle Daten abrufen. Aber das bedeutet nicht, dass wir alle Daten im Speicher halten müssen. In SQL Server 2008 laden wir die Daten aus der Quelldatenbank und speichern die relevanten Daten für gewisse Zeit in eine Report Server Datenbank. Wenn diese Daten dann für Berechnungen gebraucht werden laden wir sie wieder in den Server. Dadurch brauche man niemals die gesamten Daten für einen Bericht im Hauptspeicher zu halten. Das Ergebnis ist, dass sehr große Reports erfolgreich sind. Sie können ein wenig länger brauchen weil Teile ins Dateisystem ausgelagert werden, aber sie schlagen nicht mehr fehl.

Gibt es Dinge, die Berichts-Designer in Betracht ziehen sollten um nicht gegen die Architektur zu arbeiten? Zum Beispiel ist es ja so, dass Seitenfelder wie „Seite 3 von 129“ ein Problem sein können, weil dann mehr Berechnungen erfolgen müssen um herauszufinden, dass es am Ende 129 Seiten sein werden. Gibt es solche Dinge, die man lieber nicht im Berichtsdesign verwenden sollte?

Ja, absolut. Wenn man eine Gesamt-Seitenzahl verwendet dann kann Reporting Services nichts anderes tun als alle Seiten des Berichts zu berechnen. Doppelte Datasets ist ein weiteres typisches Beispiel. Oft haben Reportdesigner ein existierendes Dataset für eine Datenquelle. Dann brauchen sie zusätzliche Daten, und sie erzeugen ein weiteres Dataset, das diese Daten abruft, obwohl sie einfach das bestehende Dataset erweitern könnten. Das Ergebnis ist, dass zweimal Daten abgerufen werden, zweimal die Berechnungen ausgeführt werden müssen. Auch sollte man sich anschauen, wie viele Daten wirklich im Bericht verwendet werden. Dann gibt es Themen rund um Gruppierung, Sortierung, Filterung – je komplexer und tiefer die sind umso schwieriger wird es und umso höher wird die Aufbereitungszeit, ebenso wie bei vielen Subreports.

Kannst Du etwas zu Report Builder sagen? Wir haben die modellbasierte Version seit RS 2005, und wir haben Report Builder 2.0, der nicht auf Modellen basiert. Was ist die Zukunft von Report Builder und von Berichtsmodellen?

Auf lange Sicht werden Berichtsmodelle zum Entity Data Model (EDM) und Entity SQL migrieren. Die heutigen Modelle sind ein erster Schritt auf dem Weg zu EDM. Report Builder in seiner ersten Version basierte auf Berichtsmodellen. Viele Kunden brauchen einen Endbenutzer-Reportdesigner der nicht Visual Studio ist. Visual Studio verängstigt nicht-Entwickler. Es wird also ein Berichts-Designwerkzeug gebraucht, das für Officeanwender optimiert ist. Das ist Report Builder 2.0. Ein komplettes Report-Designwerkzeug für beliebige Reports. In Zukunft werden Report Builder 1.0 und 2.0 zusammenwachsen. Viele der Möglichkeiten von Report Builder 1.0 werden in zukünftige Versionen von Report Builder 2.0 einfließen.

Gibt es Dinge in Deinem Bereich von Reporting Services die die Kunden vielleicht nicht kennen, aber kennen sollten? Ich nenne das „versteckte Perlen“ – Sachen, die zwar dokumentiert sind aber trotzdem benutzt sie keiner. Hast Du da was?

Klar. Reporting Services ist ein Serverprodukt. Aber wir bieten auch Technologien für Visual Studio, insbesondere die Report Viewer Controls. Diese Controls ermöglichen das Einbetten von Berichten direkt in eigene Anwendungen, sowohl in Winforms-Clientanwendungen als auch Webforms-Webanwendungen. Man kann einen Bericht damit direkt in die Anwendung einbetten und braucht nicht notwendigerweise einen Report Server. Man kann die Report Viewer Controls in „Local Mode“ ausführen. Die Anwendung gibt dem Control dann die Berichtsdefinition und die Daten für den Bericht und das Control zeigt den Bericht direkt an. Das ist eine großartige Möglichkeit, um hochwertige Visualisierung direkt in der Anwendung zu nutzen, ohne komplexen Code schreiben und warten zu müssen. Das erlaubt die Entkopplung der visuellen Repräsentation vom logischen Abruf der Daten und kann viel Zeit bei der Anwendungsentwicklung sparen. Optional kann man das dann mit einem Report Server verbinden. Damit erhält man viel Sicherheit, Skalierbarkeit, Performance-Vorteile durch die Verwendung eines Middle Tier Servers und dessen Rechenleistung. Die Report Viewer Controls und die Idee, Business Intelligence und Berichte in die Anwendung einzubauen erweitert das, was man mit Berichten tun kann.

Der andere Aspekt ist unser großartiger Webservice. Viele Kunden denken, dass die UI, die wir mitliefern alles ist. Dass Report Manager und das SharePoint-Interface alles sind, was man machen kann. In Wahrheit kann man mit dem Webservice sehr interessante Anwendungen schreiben, zur Verwaltung der Server oder zur Verwendung in eigenen Anwendungen. Man kann den Fakt, dass Reporting Services existiert gegenüber den Endbenutzern komplett verstecken.

Diese Schnittstellen können auch zum Scripting häufiger Kommandos mit Hilfe von rs.exe verwendet werden. Dadurch können Administratoren die Zeit, die sie für regelmäßige Aufgaben brauchen drastisch reduzieren. Viele Leute wissen das nicht.

Noch eine ähnliche Frage: Gibt es Dinge, die Du immer wieder bei Kunden siehst, die so nicht verwendet werden sollten? Features, die missbraucht werden?

Das häufigste Beispiel für Missbrauch ist: Die Kunden finden die Erstellung von Berichten einfach. Das ist wundervoll, wir wollen, dass es einfach ist. Aber manchmal verwenden sie diese Berichte auf ungeeignete Weise. Wenn man zum Beispiel Daten an eine andere Organisation weitergeben will, dann sehe ich es häufig, dass riesige Berichte erstellt werden, die im Wesentlichen ein „SELECT * FROM Tabelle“ enthalten und das in einer Tabelle im Bericht darstellen und diesen Bericht als Excel-Datei oder .csv an die andere Organisation weitergeben. Reporting Services ist aber kein ETL-Werkzeug. Für solche Aufgaben sollte man lieber SQL Server Integration Services verwenden. Das ist viel performanter und andere Berichte werden nicht durch diese als Bericht verkleidete ETL-Aufgabe behindert. Und ein SSIS Paket ist auch deutlich besser wartbar.

Jetzt etwas persönliches: Wie bist Du zu dieser Rolle gekommen? Warst Du schon zur Rosetta-Release da? (Rosetta: Interner Codename für Reporting Services 2000)

Ja, ich bin seit den ersten Anfängen im Reporting Services Team. Als Student war ich ein Intern im Exchange-Team und nach meinem Universitätsabschluss habe ich mich bei Microsoft beworben. Mein Manager im Exchange-Team wurde der erste Server Program Manager für das Rosetta/Reporting Services 2000 Team. Ich bin Stephen also in das Reporting Services Team gefolgt. Ein Version 1 Produkt von Grund auf anzufangen, in Version 2 aus den Fehlern zu lernen, in Version 3 noch mehr aus den Fehlern zu lernen und die Möglichkeit zu haben, mit der Organisation zu wachsen war für mich sehr faszinierend. Ich habe ein umfassendes Technologiegebiet, für das ich durchgehend verantwortlich bin und ich kann miterleben, wie eine Technologiegruppe ein Business in einer viel größeren Organisation erschafft und was die Konsequenzen daraus sind – im positiven, aber auch welche Hindernisse es gibt und wie man diese überwindet. Jetzt bin ich seit mehr als sieben Jahren dabei.