Einführung in Business Intelligence mit Pentaho
Bevor ich nun groß einsteige, möchte ich vorweg noch eine Buchempfehlung aussprechen – Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL
.
Was bedeutet Business Intelligence?
In der Praxis versteht man unter „Business Intelligence“ meistens die Automatisierung des Berichtswesens (Reporting). Die in den verschiedensten Systemen (ERP, CRM, Buchhaltung, etc.) anfallenden Unternehmensdaten werden genutzt, um unter verschiedenen Blickwinkeln die Situation des Unternehmens zu analysieren und gegebenenfalls bewerten zu können. Sicherlich könnte man eine Analyse der Unternehmenskennzahlen auch “zu Fuß” mittels etlicher Excel-Sheets und dem Einsatz von Pivot-Tabellen vornehmen. Der Aufwand steht jedoch in absolut keinem Verhältnis zum Nutzen. Mit der Vielzahl der eingesetzten Software-Systeme für die unterschiedlichsten Zwecke steigt natürlich auch die Komplexität. Mit Excel gelangt man hier recht schnell an die Grenzen, zumal das auswertbare Datenvolumen durch Excel sowieso begrenzt ist.
Warum nicht mit Excel analysieren?
In der Regel verwenden Unternehmen eben nicht eine All-in-on-Softwarelösung sondern etliche Softwarelösungen parallel. Ich nenne diese Systeme im laufenden Text der Einfachheit halber fortan Quellsysteme. Um die Daten der Quellsysteme analysieren und bewerten zu können, müssen sie nicht selten vereint werden. Sofern die Analyse ohne eine BI-Suite durchgeführt wird, stellt sich diese Problematik natürlich ebenfalls. Im Falle von Excel sind auf die Quellsysteme unter Umständen erheblich komplexe Reporte auszuführen und in CSV-Dateien auszugeben. Die Performance der Quellsysteme kann dadurch dermaßen beeinträchtigt werden, dass ein Arbeiten nicht mehr möglich ist. Grundsätzlich ist es also keine so gute Idee, komplexe Reporte zum Zwecke der Analyse und Betrachtung von Unternehmenskennzahlen auf Quellsystemen aufzuführen. BI-Suiten verfügen über sogenannte “Staging Areas”, um die Quellsysteme so wenig wie nur notwendig zu belasten. Das nachfolgende Schaubild veranschaulicht den typischen Aufbau einer DWH-Architektur.
Eine Staging Area ist nichts anderes als ein Zwischenlager für Rohdaten. Die Staging Area wird auf einer von den Quellsystemen unabhängigen Hardware gehostet. Bei kleineren Data Warehouses wird sich die Staging Area unter Umständen direkt auf dem DWH-Server befinden. Die Organisation einer Staging Area kann vielfältig sein. In der Regel besteht das Herzstück aber aus einem Datenbankserver (z.B. MySQL). Auf diesem Datenbankserver können mehrere Datenbanken eingerichtet sein, welche allesamt dem Staging von Daten dienen oder eben auch nicht . Denkbar wäre beispielsweise eine Replikation eines Quellsystems in einer Datenbank und eine mittels ETL-Prozess (Extract -> Transform -> Load) befüllte Datenbank eines weiteren Quellsystems. Der Fantasie sind hier fast keine Grenzen gesetzt. Neben Datenbanken kann die Staging Area natürlich auch Rohdaten in Form von CSV, XML und so weiter beinhalten.
Doch wozu das Ganze? Damit die Quellsysteme beim Abfragen der Quelldaten so wenig wie nur nötig belastet werden, werden komplexe Abfragen (Joins etc.) auf den Quellsystemen in der Regel vermieden. Initial wird für die Analyse der Unternehmenskennzahlen in der Staging Area ein Abbild aller notwendiger Tabellen geschaffen. Anschließend werden mittels diverser Verfahren lediglich Veränderungen im Quellsystem (UPDATE, DELETE, INSERT) in die Staging Area übernommen. Man spricht hier von “changed data capture”. Folgende Verfahren kommen hierbei hauptsächlich in Frage:
- Timestamp
- Snaphost
- Trigger
- Replikation
Ohne detailliert auf die einzelnen Verfahren einzugehen, hat jedes dieser Verfahren Vor- und natürlich auch Nachteile. Eine detaillierte Betrachtung würde an dieser Stelle zu weit führen. Dennoch möchte ich euch folgende Gegenüberstellung nicht vorenthalten.
Zielstellung einer Staging Area ist also das “Zwischenlagern” von Quelldaten aus unterschiedlichsten Quellsystemen in unterschiedlichsten Formaten (ETL), die Aufbereitung der Quelldaten mittels Transformation (ETL) für das DWH und natürlich das Befüllen und Laden (ETL) der Daten in die DWH-Datenbank. Innerhalb der Staging Area können die transformierenden Prozesse aufwendig sein, wie sie wollen. Sie dürfen viel Zeit und viel Rechnerleistung in Anspruch nehmen (auch wenn das nicht ein Hauptziel darstellt). Die Belastung der Quellsyteme wird nur auf Minimum reduziert und das Tagesgeschäft kann ungestört weiter laufen.
Es wird also spätestens hier deutlich, das eine Analyse von Unternehmenskennzahlen mittels Excel eigentlich ein “NoGo” sein muss! Dabei habe ich noch nicht einmal die für den User sichtbaren Möglichkeiten eines Data Warehouses aufgeführt. Die Möglichkeiten einer gescheiten BI-Suite sind so gewaltig, dass ich sie hier nicht in Worte fassen kann und möchte. Vielmehr möchte ich mich in den nachfolgenden Artikeln dieser Reihe auf die Generierung von Output in Form von Dashboards (ja die schönen bunten Cockpits) konzentrieren.
Zusammenfassung
Ich habe euch einen groben Überblick über Business Intelligence gegeben. Diesen gilt es eigenständig zu erweitern. Zum einen lege ich euch das Buch Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL
sehr ans Herz. Insbesondere wenn ihr Pentaho in Verbindung mit MySQL einsetzen möchtet. Zum anderen bekommt ihr auf Wikipedia eine ganze Menge Begrifflichkeiten erklärt. Last but not least ist natürlich die Pentaho Seite eine hervorragende Quelle.
Weiterhin haben wir kennen gelernt, wozu eine Staging Area nützlich ist und das komplexe Reportings auf Quellsystemen unbedingt vermieden werden müssen. Excel als maßgebliches Analysetool von Unternehmenskennzahlen sollte spätestens nach Lesen dieses Artikels ein Artefakt, Überbleibsel, Auswechselkandidat, was auch immer sein.
Keine Kommentare
Noch keine Kommentare
RSS Feed für Kommentare zu diesem Artikel. TrackBack URI
