Technische Umsetzung von Business Intelligence Applikationen mit Open Source
Nach dem mein Kollege Peter Soth im ersten Teil dieser Blogserie die fachlichen Hintergründe sowie die generelle Motivation zur Verwendung von Open Source im Business Intelligence Umfeld beleuchtet hat, geht dieser Teil tiefer auf die technische Umsetzung ein.
Technische Basis
Wie bereits erwähnt wurde das Grails-Framework für die Implementierung der Business Intelligence Applikation verwendet. Da Grails eigentlich als Framework für Webapplikationen bekannt ist, werden hier zunächst Gründe aufgeführt, die zu dieser Auswahl geführt haben.
- Keine zusätzlichen Lizenzkosten für die Software
- Mitverwendung der bestehenden Server-Infrastruktur
- Die Umsetzung als Webapplikation ermöglicht eine einfache Integration in existierende Web-Applikationen (wie bspw. Portale) mit dem kundenspezifischen Look&Feel
- Verschiedene Ausgabeformate können einfach durch Plugins unterstützt bzw. selbst implementiert werden
- Die Programmiersprache Groovy ist die Basis von Grails. Groovy eignet sich auch hervorragend, zur Durchführung von Operationen auf Datenstrukturen, was beim Transformieren der zu importierenden Dateien benötigt wird. Des Weiteren können mit Groovy relativ einfach DSL’s realisiert werden.
Ein weiteres wichtiges Kriterium ist die Möglichkeit zur Unterstützung von Batch-Funktionalitäten für die Umsetzung des ETL-Prozesses. Hierfür wird das Batch-Launcher Plugin [1] eingesetzt. Das Plugin ermöglicht die Ausführung von Grails außerhalb eines Servlet-Containers, in dem die Anwendung als normale Java-Applikation über eine Main-Methode gestartet wird. Der Vorteil ist hierbei, dass der ETL-Prozess unabhängig von der Web-Applikation läuft und damit dort zu keinen Ressourcen-Engpässen führt.
Da es mehrere Batches in der Applikation gibt, die auch entsprechend überwacht werden müssen, wurde zusätzlich ein leichtgewichtiges Batchframework aufgesetzt. Kern dieses Frameworks ist eine Datenbanktabelle in der die Aktivitäten und der aktuelle Status protokolliert werden. Dadurch kann insbesondere verhindert werden, dass der gleiche Batch mehrfach angestoßen wird und es können Abhängigkeiten zwischen den einzelnen Batches geprüft werden.
Der ETL-Prozess im Detail
Wie in BI-Applikationen üblich werden auch in diesem Projekt die Daten über den ETL-Prozess [2] importiert und aufbereitet, so dass sie für Analysen in der Applikation vom Endanwender genutzt werden können.
Grundlage sind ca. 50 Dateien im CSV-Format, die monatlich von den verschiedenen Quellsystemen geliefert werden. Die CSV-Dateien enthalten Daten über mehrere Monate und sind auch vom Aufbau unterschiedlich. Diese Dateien liefern die Inhalte auf dem untersten Level, die in das Starschema importiert werden.
Aus fachlicher Sicht wurden drei Hauptbereiche für Analysen identifiziert, die jeweils über eine eigene Faktentabelle mit den zugehörigen Dimensionstabellen abgebildet werden. In den Dimensionstabellen finden sich unter anderem die zeitlichen Aspekte oder auch Wirkstoffe, da es sich um eine Applikation aus dem Pharmabereich handelt. Die drei Faktentabellen werden jeweils durch einen eigenen Batch mit Inhalten der verschiedenen CSV-Dateien gefüllt. Die Batches sind entsprechend parametrierbar, da die Anzahl der enthaltenen Monate sowie die Monate selbst variieren.
Da die Daten zwischen den verschiedenen Quellsystemen abgeglichen und auch gefiltert werden müssen, werden entsprechende Transformationen und Regeln benötigt. Ein hierfür nützliches Hilfsmittel sind Closures [4] in Groovy, um diese Verarbeitungsschritte relativ einfach umzusetzen. Nachfolgend ist eine sehr einfache Bedingung zur Filterung von CSV-Zeilen exemplarisch dargestellt.
def ignoreConditionGeneric = { name ->
return name && name != 'Summe'
}
Um für die 50 zu importierenden Dateien nicht unnötig viel ähnlichen oder gar doppelten Code zu erzeugen wurde eine Art DSL [5] entworfen, die für jede Datei die entsprechenden Eigenschaften definiert. Über die DSL wird z.B. definiert welche Spalten sich wiederholen und sich nur durch den Monat unterscheiden oder ob es sich bei den einzelnen Spalten um Beträge oder Namen handelt. Ändert sich die Struktur einer Datei kann somit schnell durch Anpassung der Konfiguration darauf reagiert werden.
Nachdem die Daten auf der untersten Ebene vorhanden sind, läuft für jede Faktentabelle ein weiterer Batch zur Aggregation der Daten. Hier werden beispielsweise auf der zeitlichen Dimension Daten quartalsweise oder jährlich summiert.
Die grafische Oberfläche
Eine fachliche Anforderung ist die Unterstützung von verschiedenen Ausgabeformaten. Die folgende Abbildung zeigt die verschiedenen Darstellungsformate exemplarisch für einen Report.
Neben der HTML-Oberfläche stehen Exporte nach CSV sowie PDF zur Verfügung. Diese drei Ausgabeformate werden für sämtliche Reports innerhalb der Applikation auf jeder Ebene angeboten. Dies bedeutet ein Anwender selektiert über entsprechende Auswahlboxen Kriterien und lässt sich für diese einen entsprechenden Report generieren.
Für den PDF-Report wird eine Open Source Version der itext-Bibliothek eingesetzt. CSV-Dateien werden mit Hilfe des Export-Plugins von Grails umgesetzt.
Zusätzlich zu den tabellarischen Reportdarstellungen gibt es grafische Aufbereitungen in Form von Diagrammen. Auch hier wird auf die Bibliothek itext zurückgegriffen.
Fazit
Mit dem hier vorgestellten Ansatz lassen sich kostengünstig Standardreports erstellen, die vor allen Dingen homogen in bestehende Unternehmens-Applikationen und Infrastrukturen integriert werden können. Applikationen dieser Art sind für Endanwender im Vergleich zu den speziellen BI-Werkzeugen sehr einfach zu bedienen und bieten trotzdem verschiedene Sichten mit entsprechenden Drill-Down Möglichkeiten auf den Daten.
Links
[1] Batch Launcher Plugin
[2] ETL-Process
[3] Star Schema
[4] Groovy Closures
[5] Domain Specific Language