Entwicklung eines Benchmarks für die Performance von In-Memory

Danksagung

Mein Dank geht an dieser Stelle an Alle, die mich im Laufe meiner Studienzeit un-terstützt, gefördert und gefordert haben. Ein ganz besonderer Dank geht an Prof.Dr. Uwe Haneke, der mich in der Wahlpflichtveranstaltung „Business Intelligence“für diese Thematik begeistern konnte und ohne den diese Master-Thesis sicherlichnie entstanden wäre. Bedanken möchte ich mich auch bei der Jedox AG, die mir imvergangenen halben Jahr ermöglicht hat, meine Abschlussarbeit zu schreiben undmir auch viele interessante Einblicke gewährt hat. Und wenn ich nun auch allenKorrekturlesern danke sagen möchte, dann gilt dies ganz besonders für Dr. TobiasLauer, durch den das Thema dieser Arbeit erst zustande kam und der mir über diegesamte Dauer ein kritischer und engagierter Ansprechpartner war.

Nicht zuletzt danke ich auch meiner Familie und speziell meinen Eltern, diemir es letztlich doch immer ermöglicht haben, dass ich meinen Weg gehen konnte.Auch in schwierigen Zeiten konnte ich mir eurer Unterstützung immer sicher seinund ich weiß, dass ich es eigentlich viel zu selten sage: Danke!

„Je mühsamer der Aufstieg, desto befreiter erreichen wir das Ziel.“

Angelika Mack

Eigenständigkeitserklärung

Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig und ohne an-dere als die angegebenen Quellen und Hilfsmittel verfasst habe. Die aus fremdenQuellen direkt oder indirekt übernommenen Gedanken sind als solche gekenn-zeichnet.

Freiburg im Breisgau, den 28. Oktober 2010

Kurzzusammenfassung

Business-Intelligence-Systeme haben sich als wichtiger Teil der modernen Unter-nehmenssteuerung etabliert und längst nutzen nicht mehr nur große Konzerne,sondern zunehmend auch kleine und mittelständische Unternehmen die sich bie-tenden Möglichkeiten. Trotzdem hat die Business Intelligence „die Massen nochnicht erreicht“ [FMB+10, Seite 14]. Mittelfristig geht der Trend dahin, nicht nur demTop-Management, sondern auch dem mittleren Management sowie den Sachbear-beitern den Zugang zu BI-Lösungen zu ermöglichen. Die Performance spielt dabeigleich in doppelter Hinsicht eine Rolle. Zum Einen ist für die Akzeptanz durch denEndnutzer ein ausreichend schnelles System nötig, zum Anderen benötigt eine sol-che Erweiterung des Anwenderkreises auch ein entsprechend skalierendes System,wobei die Skalierbarkeit ihrerseits eng mit der Performance korreliert.

Auch wenn im BI Survey 9 die Datenqualität erstmals größtes Problem von BI-Anwendungen ist, so bleibt die Performance auch weiterhin das mit Abstand drin-gendste produktbezogene Problem. Für Anwender ist es aber in Ermangelung ei-nes herstellerübergreifenden Vergleichs aufgrund der Unterschiede der Systeme so-wie unüblicher Proof-of-Concepts unter Realbedingungen nahezu unmöglich, Al-ternativen im hinsichtlich der Performance miteinander zu vergleichen.

Diese Master-Thesis versucht, eine objektive Vergleichbarkeit zu schaffen undmehrere OLAP-Server – Kern und zentraler Datenspeicher jeder BI-Anwendung– einander gegenüberzustellen. Betrachtet werden nur Produkte, die auf die In-Memory-Technologie setzen. Diese letzte „Revolution“ [Com06] im BI-Bereich sorgtfür die Datenhaltung im Hauptspeicher. Mit den schnelleren Zugriffszeiten lässtsich den aufgrund wachsender Datenvolumen und höherer Ansprüche der Benut-zer stetig steigenden Performance-Anforderungen begegnen. Dabei gibt es signifi-kante Unterschiede der OLAP-Server in den Bereichen ETL, Analyse und Planung.

Abstract

Business Intelligence systems established itself as an important part of modern cor-porate management. Both huge and small or medium-sized companies are usingthe provided possibilities. Nevertheless business intelligence „has not reached themasses yet“ [FMB+10, page 14]. One of the current trends is to provide access on BIsystems not only to the top management but also to the middle management andthe clerks. Performance thereby is an issue in two different ways. On the one handa sufficiently fast system is necessary to be accepted by the users and on the otherhand the system has to scale very well to expand to new user groups. That meansscalability and performance are related very tight.

Even if data quality has become the biggest problem of BI applications in BI Sur-vey 9, performance still is the most urgent product-related problem. However it isvery difficult for end-users to compare different systems regarding the performan-ce because there is no cross-vendor benchmark. Unfortunately proof-of-conceptsunder real conditions are unusual yet.

This Master’s Thesis tries to create an objective comparability of different OLAPservers which are core and central data storage of every BI application. Only pro-ducts that are using In-Memory technology are regarded within this benchmark.In-Memory technology has been the latest big „revolution“ [Com06] in businessintelligence and means, that all data is stored in the main memory. Thereby fasteraccess times are possible to face the growing performance requirements and hig-her claims of the users. As the results will show, there are significant differencesbetween the OLAP servers in the areas of ETL, analysis and planning.

5

Inhaltsverzeichnis

1 Entwicklung und Bedeutung von Business-Intelligence-Systemen 12

1.1 Begriffsdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 Entwicklung von Business-Intelligence-Systemen . . . . . . . . . . . 151.3 Status quo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.4.1 Technische Innovationen . . . . . . . . . . . . . . . . . . . . . . 181.4.2 Fachliche und betriebswirtschaftliche Entwicklungen . . . . . 191.4.3 Organisatorische Strukturen . . . . . . . . . . . . . . . . . . . 20

2 OLAP und Einordnung in die BI-Referenzarchitektur 21

2.1 Begriffsdefinition OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.1 Varianten von OLAP . . . . . . . . . . . . . . . . . . . . . . . . 232.1.2 Typische Operationen . . . . . . . . . . . . . . . . . . . . . . . 252.1.3 Abgrenzung zu OLTP . . . . . . . . . . . . . . . . . . . . . . . 27

2.2 Einordung von OLAP in die BI-Referenzarchitektur . . . . . . . . . . 292.2.1 Die BI-Referenzarchitektur nach Bauer und Günzel . . . . . . 29

2.3 In-Memory-Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Vergleichbarkeit von OLAP-Systemen 33

3.1 Analytic Processing Benchmark . . . . . . . . . . . . . . . . . . . . . . 343.1.1 Testumfang und -ablauf . . . . . . . . . . . . . . . . . . . . . . 353.1.2 Veröffentlichung der Testergebnisse . . . . . . . . . . . . . . . 383.1.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Transaction Processing Performance Council Benchmark™ H . . . . 403.2.1 Testumfang und -ablauf . . . . . . . . . . . . . . . . . . . . . . 413.2.2 Veröffentlichung der Testergebnisse . . . . . . . . . . . . . . . 423.2.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6

Inhaltsverzeichnis 7

3.3 Rückschlüsse für die eigene Arbeit . . . . . . . . . . . . . . . . . . . . 44

4 Typische Szenarien im OLAP-Einsatz 48

4.1 Analyse von Kundenanwendungen aus der Praxis . . . . . . . . . . . 484.1.1 Kunde 1: Debitoren-Controlling und Umsatzanalyse . . . . . 484.1.2 Kunde 2: Umsatzanalyse und -planung, Finanzcontrolling . . 494.1.3 Kunde 3: Kreditcontrolling . . . . . . . . . . . . . . . . . . . . 494.1.4 Kunde 4: Komplette Unternehmenssteuerung . . . . . . . . . 504.1.5 Kunde 5: Debitoren-Controlling . . . . . . . . . . . . . . . . . 514.1.6 Kunde 6: Projektabrechnung . . . . . . . . . . . . . . . . . . . 514.1.7 Kunde 7: Analyse von Umsatz, Projekten und Personal . . . . 52

4.2 Die „typischen“ Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . 53

5 Entwicklung des OLAP-Benchmarks 56

5.1 Marktübersicht und Auswahl der Testkandidaten . . . . . . . . . . . 565.2 Die Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.3 Testszenarien und Datenmodelle . . . . . . . . . . . . . . . . . . . . . 59

5.3.1 Datenmodell für die Umsatzanalyse . . . . . . . . . . . . . . . 605.3.2 Datenmodell der Personalplanung . . . . . . . . . . . . . . . . 625.3.3 Datengenerierung . . . . . . . . . . . . . . . . . . . . . . . . . 645.3.4 Abfragen innerhalb der Umsatzanalyse . . . . . . . . . . . . . 665.3.5 Aktionen innerhalb der Personalplanung . . . . . . . . . . . . 66

6 Durchführung des OLAP-Benchmarks 67

6.1 Palo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.1.1 Benchmark des ETL-Prozesses . . . . . . . . . . . . . . . . . . 676.1.2 Benchmark der Umsatzanalyse . . . . . . . . . . . . . . . . . . 696.1.3 Benchmark der Personalplanung . . . . . . . . . . . . . . . . . 72

6.2 Infor PM 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.2.1 Benchmark des ETL-Prozesses . . . . . . . . . . . . . . . . . . 746.2.2 Benchmark der Umsatzanalyse . . . . . . . . . . . . . . . . . . 756.2.3 Benchmark der Personalplanung . . . . . . . . . . . . . . . . . 77

6.3 Cognos TM1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.3.1 Benchmark des ETL-Prozesses . . . . . . . . . . . . . . . . . . 796.3.2 Benchmark der Umsatzanalyse . . . . . . . . . . . . . . . . . . 81

Inhaltsverzeichnis 8

6.3.3 Benchmark der Personalplanung . . . . . . . . . . . . . . . . . 836.4 Zusammenfassung und Bewertung . . . . . . . . . . . . . . . . . . . . 84

6.4.1 ETL-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.4.2 Umsatzanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.4.3 Personalplanung . . . . . . . . . . . . . . . . . . . . . . . . . . 896.4.4 Drei Teilbereiche, drei OLAP-Server, drei unterschiedliche Ge-

winner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7 Fazit 92

A Statistiken der Kundenanwendungen 94

A.1 Kunde 1 aus Kapitel 4.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . 94A.2 Kunde 2 aus Kapitel 4.1.2 . . . . . . . . . . . . . . . . . . . . . . . . . 95A.3 Kunde 3 aus Kapitel 4.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . 96A.4 Kunde 4 aus Kapitel 4.1.4 . . . . . . . . . . . . . . . . . . . . . . . . . 97A.5 Kunde 5 aus Kapitel 4.1.5 . . . . . . . . . . . . . . . . . . . . . . . . . 98A.6 Kunde 6 aus Kapitel 4.1.6 . . . . . . . . . . . . . . . . . . . . . . . . . 99A.7 Kunde 7 aus Kapitel 4.1.7 . . . . . . . . . . . . . . . . . . . . . . . . . 100

B Ergebnisse der Performancemessung 101

B.1 Palo OLAP-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101B.1.1 Umsatzanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 101B.1.2 Personalplanung . . . . . . . . . . . . . . . . . . . . . . . . . . 106

B.2 Infor PM 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108B.2.1 Umsatzanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 108B.2.2 Personalplanung . . . . . . . . . . . . . . . . . . . . . . . . . . 111

B.3 Cognos TM 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113B.3.1 Umsatzanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 113B.3.2 Personalplanung . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Literaturverzeichnis 118

Abbildungsverzeichnis

1.1 Enges, analyseorientiertes oder weites BI-Verständnis? . . . . . . . . 131.2 Informationspyramide . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3 Historie von entscheidungsunterstützenden Systemen . . . . . . . . 16

2.1 n-dimensionaler Hyperwürfel . . . . . . . . . . . . . . . . . . . . . . . 222.2 Slicing und Dicing in einem multidimensionalen Datenwürfel . . . . 252.3 Drill-Down und Roll-Up - Aggregation und Aufschlüsselung der Da-

ten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4 Neue Sicht auf die Daten durch Pivotierung . . . . . . . . . . . . . . . 272.5 Ein OLAP-Join verbindet Datenwürfel mit gleichen Dimensionen . . 272.6 Referenzmodell für die Architektur von Data-Warehouse-Systemen . 30

3.1 Struktur und Zusammenhänge zwischen den vom APB-1 generier-ten Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Das Datenmodell des APB-1 als Snowflake-Schema . . . . . . . . . . 373.3 Datenschema des Benchmarks TPC-H . . . . . . . . . . . . . . . . . . 42

4.1 Die Anwendungszwecke der Jedox-Kunden . . . . . . . . . . . . . . 54

5.1 Datenfluss von der Datenintegration über die -aufbereitung bis hinzur -analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2 Datenmodell der Umsatzanalyse . . . . . . . . . . . . . . . . . . . . . 615.3 Datenmodell des Szenarios „Personalplanung“ . . . . . . . . . . . . . 63

6.1 Entwicklung der Ladeperformance des OLAP-Servers Palo . . . . . . 686.2 Performance des OLAP-Servers Palo bei der Umsatzanalyse . . . . . 706.3 Performance des OLAP-Servers Palo bei der Umsatzanalyse mit 4

GPUs im Vergleich zur Umsatzanalyse ohne GPU-Unterstützung . . 716.4 Performance des OLAP-Servers Palo im Planungsszenario . . . . . . 73

9

Abbildungsverzeichnis 10

6.5 Entwicklung der Ladeperformance von Infor PM 10 . . . . . . . . . . 756.6 Performance des OLAP-Servers Infor PM 10 bei der Umsatzanalyse . 766.7 Performance des OLAP-Servers Infor PM 10 im Planungsszenario . . 786.8 Entwicklung der Ladeperformance von IBM Cognos TM1 . . . . . . 806.9 Performance des OLAP-Servers IBM Cognos TM1 bei der Umsatz-

analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.10 Performance des OLAP-Servers IBM Cognos TM1 im Planungssze-

nario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.11 Die Performance der OLAP-Server beim ETL-Prozess im direkten

Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.12 Die Performance der OLAP-Server in der Analyse im direkten Ver-

gleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.13 Die Performance der OLAP-Server bei der Planung im direkten Ver-

gleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Tabellenverzeichnis

2.1 Unterschiede zwischen OLTP und OLAP . . . . . . . . . . . . . . . . 28

4.1 Die Anwendungszwecke von BI-Lösungen bei Kunden der Jedox AG 53

5.1 Zusammenfassung der Kundenanwendungen mit Umsatzanalyse . . 605.2 Personalplanung aus der analysierten Kundenanwendung . . . . . . 625.3 Größe der Dimensionen innerhalb der Umsatzanalyse . . . . . . . . . 655.4 Größe der Dimensionen innerhalb der Personalplanung . . . . . . . . 65

6.1 Benötigte Zeit zum Laden der Daten in den OLAP-Server Palo . . . . 686.2 Performance des OLAP-Servers Palo bei der Umsatzanalyse . . . . . 696.3 Performance des OLAP-Servers Palo bei der Umsatzanalyse mit 4

GPUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.4 Performance des OLAP-Servers Palo im Planungsszenario (1. Aufruf) 726.5 Performance des OLAP-Servers Palo im Planungsszenario (2. - 10.

Aufruf) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.6 Benötigte Zeit zum Laden der Daten in den OLAP-Server Infor . . . 746.7 Performance des OLAP-Servers Infor PM 10 im Analyseszenario . . 766.8 Performance des OLAP-Servers Infor PM 10 im Planungsszenario . . 776.9 Benötigte Zeit zum Laden der Daten in den OLAP-Server IBM Co-

gnos TM1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.10 Performance des OLAP-Servers IBM Cognos TM1 im Analyseszenario 826.11 Performance des OLAP-Servers IBM Cognos TM1 im Planungssze-

nario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.12 Relativer Anteil der einzelnen Abfragen bei 64 Mio. Datensätzen . . 886.13 Relativer Anteil der einzelnen Operationen bei 3,2 Mio. Datensätzen 90

11

Kapitel 1

Entwicklung und Bedeutung von

Business-Intelligence-Systemen

Der Begriff „Business Intelligence“ entstand bereits im Jahre 1958 während der For-schungen zur selektiven Verbreitung von Informationen durch den IBM-MitarbeiterHans Peter Luhn und wurde ab 1989 von Howard Dresner, seinerzeit Analyst beimUS-Marktforschungsunternehmen Gartner, aufgegriffen und geprägt. Ebenso un-terschiedlich wie die Anbieter und deren Produkte sind aber bis heute auch dieInterpretationen des Begriffs „Business Intelligence“.

Auf den folgenden Seiten will ich deshalb zunächst versuchen, eine adäquateDefinition des weit verbreiteten und dennoch so unterschiedlich interpretierten Be-griffs zu finden. Dem historischen Abriss folgt die Betrachtung des Status quo undder aktuellen Herausforderungen sowie der Themen, die den BI-Markt in der na-hen Zukunft beschäftigen werden.

1.1 Begri�sde�nition

Auch wenn der Begriff „Business Intelligence“ in der Wirtschaft schon fast allge-genwärtig und die Notwendigkeit sowie der Nutzen von BI-Systemen unumstrit-ten ist, fehlt es bis heute an einer allgemeingültigen und durchgängig akzeptiertenDefinition. Wie die Abbildung 1.1 zeigt, gibt es drei unterschiedliche Sichtweisenvom engen über das analyseorientierte bis hin zum weiten BI-Verständnis. Diesekonkurrierenden Definitionen haben zu einer Verwässerung des Begriffs geführt.

12

Kapitel 1 Entwicklung und Bedeutung von Business-Intelligence-Systemen 13

Abb. 1.1: Enges, analyseorientiertes oder weites BI-Verständnis? (In Anlehnung an[Zim08])

Hinsichtlich des Prozessschwerpunkts schwankt der Fokus zwischen der Ver-arbeitung der Rohdaten im Rahmen des ETL-Prozesses und der Anzeige der Er-gebnisse. Die Aspekte sind dabei teilweise sehr technisch orientiert, teilweise aberauch ganz auf die Anwendung hin ausgerichtet. Bei einer solch großen Hetero-genität wundert es kaum, dass Peter Mertens in [Mer02] sieben unterschiedlicheEinsatzzwecke von BI-Anwendungen identifizieren konnte:

• BI als Fortsetzung der Daten- und Informationsverarbeitung

• BI als Filter der Informationsflut

• BI = MIS (Management Information System), aber besonders schnelle undflexible Auswertungen

• BI als Frühwarnsystem („Alerting“)

• BI = Data Warehouse

• BI als Informations- und Wissensspeicher

• BI als Prozess: Symptomerhebung→ Diagnose→ Therapie→ Prognose→ Therapiekontrolle


Um im weiteren Verlauf die OLAP-Technologie und ihre Bedeutung innerhalbder Business Intelligence einordnen zu können, soll das weite BI-Verständnis ver-treten werden. So versuchten auch Humm und Wietek in [HW05, Seite 4] die un-terschiedlichen Anwendungen unter einer Definition zusammenzufassen:

„Business Intelligence umfasst ein breites Spektrum an Anwendun-gen und Technologien zur entscheidungsorientierten Sammlung, Auf-bereitung und Darstellung geschäftsrelevanter Informationen.“

Ohne technische Details der Implementierung vorwegzunehmen, werden diedrei Hauptaufgaben von BI-Systemen deutlich:

• Sammlung,

• Aufbereitung und

• Darstellung

von Daten. Ganz im Sinne der Informationspyramide (siehe Abb. 1.2) ist das Pri-märziel eines BI-Systems, aus Daten Informationen und Wissen zu generieren unddieses zur richtigen Zeit dem richtigen Personenkreis zur Verfügung zu stellen.Nur mit dem anforderungsgerechten Wissen lassen sich richtige Entscheidungentreffen, wobei vom konkreten Einsatzzweck abhängt, welche Informationen rele-vant sind.

Abb. 1.2: Informationspyramide [SM04, Seite 195]


Vor dem erfolgreichen BI-Einsatz steht deshalb zunächst konzeptionelle und in-haltliche Arbeit, im Zuge derer die konkreten Ziele definiert werden müssen. Dasich die Rahmenbedingungen immer wieder ändern, ist dies keine einmalige Auf-gabe. Vielmehr bedarf es kontinuierlicher Kontrolle und Anpassungen. Es ist des-halb angebracht, Business Intelligence als einen hochdynamischen „analytischenProzess [zu betrachten], der Unternehmens- und Wettbewerbsdaten in handlungs-gerichtetes Wissen [...] transformiert“ [HW05, Seite 4].

Aufgrund der Dynamik des Marktumfelds sollte dieser Prozess von stetiger Wei-terentwicklung geprägt sein („think big – start small“). Die Zeit zwischen dem Kaufder Software und dem ersten Einsatz hängt auch eng mit der Anzahl der auftreten-den Probleme zusammen (vgl. [FMB+10, Seite 118]). Eine BI-Lösung ermöglichtdemnach im Idealfall nicht nur die schnelle und flexible Reaktion auf Veränderun-gen, sondern verringert damit auch gleichzeitig Probleme.

1.2 Entwicklung von Business-Intelligence-Systemen

Die Informationsverarbeitung ist so alt wie die Entwicklung von Computern selbst.Von Anfang an ging es darum, Daten zu verarbeiten und die dabei generierten In-formationen zu nutzen. Nichts Anderes machen im Prinzip auch die heutigen BI-Anwendungen, obgleich die Aufgaben sehr viel komplexer und die Datenmengensehr viel größer geworden sind.

Mit der fortschreitenden Entwicklung und zunehmenden Verbreitung von Com-putern wuchs auch die Datenmenge stetig. Das Moorsche Gesetz lässt sich auchauf die Datenmengen anwenden, die Datenmenge „verdoppelt sich [demnach] alle12 bis 18 Monate“ [LPS10, Seite 351]. Insbesondere im Management wird es im-mer schwieriger, aus der Datenflut die gewünschten und benötigten Informatio-nen zu filtern. Mit dem Ziel einer übersichtlichen und adäquaten Informations-versorgung von Managern und Entscheidern entwickelten sich in den 60er-Jahrenmit den Management Information Systems (kurz: MIS) die Vorläufer heutiger BI-Systeme. Während die Basisdaten transparent im Hintergrund blieben, bekam derAnwender nur wenige wichtige und aussagekräftige Kennzahlen präsentiert. Mit


zunehmender Reife wurde dabei auch „das Maß der Integration von Daten und dasNiveau der Entscheidungsunterstützung permanent verbessert“ [HW05, Seite 3].

Die Abbildung 1.3 zeigt wie immer neue Funktionen integriert, das Unterstüt-zungsniveau fortlaufend verbessert und auch die Bezeichnung immer wieder ge-ändert wurde. So war in den 70er-Jahren von Decision Support Systems (DSS) dieRede, später von Executive Information Systems (EIS) bevor in den 90er-Jahren derBegriff des Data Warehousing (DWH) aufkam. Data Warehousing ist mittlerweilenicht mehr als eigenständig zu verstehen, sondern als eine Teiltechnologie – wennauch die vielleicht wichtigste – innerhalb der Business-Intelligence-Umgebung.

Abb. 1.3: Historie von entscheidungsunterstützenden Systemen [HW05, Seite 4]

1.3 Status quo

Der weltweite Markt für Business Intelligence ist in den vergangenen Jahren starkgewachsen und auch die Wirtschaftskrise sorgte entgegen dem allgemeinen Trendnicht für Umsatzeinbrüche, sondern sogar für Wachstum (vgl. [iMfpI09]). Laut demUS-Marktforschungsunternehmen Gartner Group lag der Umsatz 2009 weltweitbei 9,3 Mrd. US-Dollar nach 8,9 Mrd. im Jahr zuvor (vgl. [Püt10]). Der größte Teildavon entfällt auf die USA, während Deutschland mit einem Volumen von 800 Mil-lionen Euro in 2008 nur einen sehr kleinen Anteil einnimmt (vgl. [Pel10]).


Mit SAP, Oracle, SAS Institute, IBM und Microsoft sind es nur fünf große Anbie-ter, die bereits 71 % des weltweiten BI-Marktes unter sich aufteilen (vgl. [Püt10]).Auch in Deutschland können die „großen Fünf“ bereits 61 % des BI-Markts auf sichkonzentrieren. Die restlichen Marktanteile gehen an kleinere Anbieter mit bran-chenspezifischen Lösungen oder speziellen Funktionen und Technologien. So konn-te beispielsweise die Firma QlikTech, neben Applix einer der ersten Anbieter derIn-Memory-Technologie (siehe Kapitel 2.3) in Deutschland, im Jahre 2008 ein Um-satzwachstum von über 47 % aufweisen (vgl. [Sar10]). Andere Firmen punkten mitder Planungs-Funktion, denn „mehr denn je besteht die Notwendigkeit, analysie-ren und planen zu können, um ein Unternehmen zu steuern“ [Sar10].

Bei vielen Kunden war in der Vergangenheit sicherlich die Integration in diebestehenden Systemlandschaften ein wichtiges Entscheidungskriterium für großeInvestitionen in komplexe und umfangreiche BI-Lösungen. Allerdings hat auchhier ein Umdenken hin zu kleineren Projekten und Budgets stattgefunden. DieserSchwenk in der Investitionspolitik der Unternehmen trifft die großen Anbieter här-ter, weil sich diese zu „lange Zeit auf das Großgeschäft konzentriert“ [Sar10] haben.

Ursprünglich waren Business-Intelligence-Anwendungen zumeist IT-getriebenund dem oberen Management – und damit wenigen Anwendern vorbehalten. Zu-nehmend stehen die Anwendungen nun aber auch Benutzern des mittleren undunteren Managements zur Verfügung, was höhere Anforderungen an die Anwen-derfreundlichkeit stellt. Auch hier sind kleinere Anbieter im Vorteil, da sich nur13 % der Microsoft- und sogar nur 6 % der SAP-Kunden aus Gründen der Anwen-derfreundlichkeit für die jeweilige Lösung entschieden haben (vgl. [Sar10]). Nebendem Usability-Trend sind es aber vor allem neue Entwicklungen und technologi-sche Fortschritte, die in Zukunft wichtig sein werden. Die Interessantesten davonsollen im folgenden Abschnitt kurz vorgestellt werden.


1.4 Ausblick

Da sich die BI-Branche laufend den sich ändernden Rahmenbedingungen anpassenmuss, ist eine Aussage über die Richtung der Entwicklung nur schwer zu treffen. Esgibt aber einige Themen, die von Kundenseite stark nachgefragt und deshalb auchdie Anbieter beschäftigen werden. Entwicklungen und Innovationen im hochdy-namischen BI-Umfeld lassen sich in drei Bereiche unterteilen:

• technische/technologische Innovationen

• fachliche/betriebswirtschaftliche Entwicklungen

• organisatorische Strukturen

1.4.1 Technische Innovationen

Um den explodierenden Datenmengen und immer weiter steigenden Performance-Anforderungen gerecht zu werden, bedarf es neuer technischer Entwicklungen.Zunächst einmal wird es eine Verschiebung nach oben in der Speicherhierarchiegeben, wie auch Carsten Bange auf dem 10. Europäischen TDWI-Kongress im Juni2010 zu verstehen gab: „Disks are tomorrows tapes. SSD and RAM are tomorrowsdisks.“ Neben den schnelleren Zugriffszeiten auf Daten im Arbeitsspeicher sowieauf SSDs, lassen sich durch neue Kompressionsalgorithmen Speicherplatz sparenund damit auch Energiekosten einsparen.

Eine weitere Herausforderung betrifft die Möglichkeiten des Zugriffs auf BI-Sys-teme. Mit der zunehmenden Verbreitung mobiler Endgeräte und der zunehmen-den Selbstverständlichkeit des Überall-Internets wachsen auch die Anforderungenhinsichtlich des mobilen Zugriffs. Anwender wollen auch unterwegs auf Unter-nehmenskennzahlen und Analysen zugreifen. Aufgrund der Einschränkungen dermobilen Endgeräte, wie geringere Leistungsfähigkeit, kleinere Displays sowie dieBedienung ohne Maus, müssen optimierte Mobil-Versionen zur Verfügung gestelltwerden. Im Vorteil sind Anbieter, die auch bisher schon den Zugriff über den Brow-ser ermöglicht haben. Darüber hinaus muss vor allem auch die IT-Sicherheit beimZugriff auf oft geschäftskritische Informationen gewährleistet werden.


1.4.2 Fachliche und betriebswirtschaftliche Entwicklungen

Aufgrund größerer Datenmengen und immer höheren Ansprüchen an die Daten-aktualität sind auch die Performance-Anforderungen stark gestiegen. Während frü-her die nächtliche Befüllung normal und akzeptiert war, sind diese bis zu 24 Stun-den alten Daten mittlerweile in vielen Fällen nicht mehr ausreichend. WährendBusiness Intelligence ursprünglich vergangenheitsorientiert und damit reaktiv aus-gerichtet ist, wird unter dem Schlagwort Operational BI die „direkte und zeitnaheVerbindung der dispositiven und operativen Systemwelten“ [GKS09] immer wich-tiger. Unter Operational BI versteht man die Verknüpfung der „vorhandenen undetablierten Business-Intelligence-Technologien mit den Anforderungen des aktuel-len Tagesgeschehens in den Unternehmen“ [GKS09]. Anstatt erst rückwirkend imReporting Probleme zu erkennen, kann bereits im Verlauf eines Prozesses korrektiveingegriffen werden. Dadurch besteht das „Potential, Unternehmensprozesse mas-siv zu verbessern“ [Rog08].

Sowohl bei traditioneller als auch bei operativer Business Intelligence gilt abergleichermaßen, dass jede Entscheidung nur so gut sein kann wie die zugrundelie-genden Daten. Eine ausreichende Menge an korrekten Daten ist aus diesem Grundeobligatorisch. Leider steht die „Datenmenge oft im Widerspruch zur Datenquali-tät“ [Sch06, Seite 17], die sich primär auf die Korrektheit sowie die Vollständigkeitder Daten bezieht. Lückenhafte, inkorrekte oder widersprüchliche Daten führen zufalschen Ergebnissen und Erkenntnissen. Die Unternehmen haben das Problem er-kannt und versuchen nun zunächst die Qualität ihrer Daten zu quantifizieren. Nurwenn die Qualität messbar ist, lässt sich auch der Erfolg von Qualitätssicherungs-maßnahmen kontrollieren und steuern. Als zweiten Aspekt muss beim Thema derDatenqualität auch die Aktualität der Daten betrachtet werden, schließlich könnenauch veraltete Daten Fehlentscheidungen zur Folge haben. Da hohe Anforderun-gen an die Datenaktualität auch höhere Ansprüche an die Performance stellen, ste-hen Datenqualität und Performance indirekt miteinander in Beziehung.

Daten von hoher Qualität sind nicht nur innerhalb der Analyse wichtig, sonderninsbesondere bei der Planung muss auf qualitätsgesicherte Informationen zurück-gegriffen werden können. Nach der klassischen vergangenheitsorientierten Analy-


se und dem Einbeziehen aktueller Daten bei operativer Business Intelligence wer-den für die Unternehmenssteuerung auch Forecasts und die Planung immer wich-tiger. Planung und Prognose wichtiger Kennzahlen werden dabei oft auch in Zu-sammenhang mit den Schlagworten „Business Performance Management“ (BPM)oder „Corporate Performance Management“ (CPM) erwähnt. Da die Planungs-Komponente in vielen BI-Lösungen aktuell noch nicht vorhanden ist, gibt es indiesem Bereich noch viel Potential und Nachholbedarf.

1.4.3 Organisatorische Strukturen

Da Business Intelligence abteilungs- und kompetenzübergreifend ist, etablieren sichin den Unternehmen zunehmend Business Intelligence Competency Center (BICC)– „interdisziplinäre Teams zur Förderung des effektiven Einsatzes von BI“ (vgl.[GTS10, Seite 13]), die sich aus Mitarbeitern der verschiedenen involvierten Fach-abteilungen sowie der IT zusammensetzen. Je nach Unternehmensgröße handelt essich dabei um echte Organisationseinheiten oder um virtuelle Organisationen.

Die wichtigsten Ziele eines Business Intelligence Competency Centers sind dieFormulierung und Kontrolle der unternehmensweiten BI-Strategie. Das BICC zeich-net somit für die Einführung und Weiterentwicklung dieser Strategie verantwort-lich. Oftmals gilt es dabei, historisch gewachsene und abteilungsfokussierte BI-Lösungen zu vereinheitlichen und zu konsolidieren, um damit für die „aktive undzukunftsorientierte Gestaltung der BI-Systeme“ [GTS10, Seite 13] zu sorgen. In die-se Arbeit finden zunehmend auch agile Methoden Einfluss, um einen schnellenund geregelten Arbeitsablauf zu gewährleisten, wenn es darum geht, auf geänderteRahmenbedingungen zu reagieren. Agile Entwicklungsmethoden haben schon inder Software-Entwicklung zu erheblichen Verbesserungen hinsichtlich Projektma-nagement, Change-Management und auch bezüglich der Produktqualität geführt.

Kapitel 2

OLAP und Einordnung in die

BI-Referenzarchitektur

Nachdem erläutert wurde was generell unter „Business Intelligence“ zu verstehenist, geht es nun um einen Begriff, der untrennbar mit Business Intelligence verbun-den ist: OLAP. Zunächst soll die Abkürzung erläutert werden, bevor es um dieAufgaben und die Bedeutung von OLAP innerhalb von BI-Systemen geht.

2.1 Begri�sde�nition OLAP

OLAP ist die Abkürzung für „On-Line Analytical Processing“ und wurde 1993 vomDatenbanktheoretiker Edgar F. Codd (d 2003) geprägt. Da der Begriff alleine nichtsdarüber aussagt, warum man OLAP-Tools einsetzen sollte und was ein OLAP-Toolüberhaupt leistet, definierte Codd zwölf (später folgte die Erweiterung auf 18) Re-geln, denen ein Datenbanksystem entsprechen muss, um als OLAP-System zu gel-ten. Aufgrund ihrer Vielzahl erschienen die Coddschen Regeln schon bald als unge-eignet für die Definition von OLAP-Systemen und wurden von Nigel Pendse undRichard Creed im OLAP Report 1995 in der FASMI-Definition konsolidiert (vgl.[Pen08]). Die Übereinstimmung mit diesem Anforderungskatalog stellt sicher, dass„Nutzern mit OLAP-Systemen ein schneller (Fast) analytischer (Analysis) Zugriffim Mehrbenutzerbetrieb (Shared) auf kontextrelevante multidimensionale betrieb-liche Informationen (Multidimensional Information)“ [Man08b] möglich ist.

Fast Die Geschwindigkeit findet sich bereits in dieser Definition als eine der wich-tigsten Anforderungen an ein OLAP-System wieder. Einfache Abfragen dür-fen maximal fünf Sekunden dauern, komplexen Abfragen werden maximal20 Sekunden zugestanden.

21

Kapitel 2 OLAP und Einordnung in die BI-Referenzarchitektur 22

Analysis Dem Anwender muss es auf einfache und intuitive Weise möglich sein,ohne Programmieraufwand komplexe Anfragen an das System zu stellen.

Shared Das System erlaubt den parallelen Zugriff mehrerer Benutzer, ohne dass eszu Konflikten oder Seiteneffekten kommt.

Multidimensional Die Daten werden multidimensional gespeichert, sodass sich je-der Wert genau einem Basiselement einer Dimension zuordnen lässt. Inner-halb der Dimensionen können die Basiselemente zu aggregierten Elementenzusammengefasst werden.

Information OLAP-Datenbanken können unabhängig des Datenvolumens sowieder Dimensionalität aus Daten Informationen generieren. Die Datenherkunftbleibt für den Nutzer dabei transparent.

OLAP ist damit ein Überbegriff für ein Konglomerat aus Software- und Hard-ware-Komponenten zur Durchführung komplexer Analysen. OLAP ist auch ein„Synonym für die abfrageoptimierte Verarbeitung für multidimensionale Daten-strukturen“ [Sch06, Seite 23]. Um die Daten aus unterschiedlichen Perspektivenbetrachten zu können, werden diese “aus den Datenquellen in einem multidimen-sionalen Datenwürfel zusammengefasst und dann in Berichten mit Tabellen undGrafiken präsentiert“ [Man08a].

(a) 3 Dimensionen (b) n-dimensionaler Hyper-würfel

Abb. 2.1: n-dimensionaler Hyperwürfel (Quelle: www.2cool4u.ch via [Man08c])

Jede Dimension des Würfels (engl. Cube) kann man sich dabei räumlich als eineAchse vorstellen, was aber die menschliche Vorstellungskraft ab der vierten Di-


mension übersteigt. Damit sind Konstellationen bis hin zum n-dimensionalen Hy-perwürfel (siehe Abbildung 2.1) möglich, wobei die Dimensionalität theoretischunendlich groß sein kann.

2.1.1 Varianten von OLAP

Da sich OLAP anhand der fünf Kriterien der FASMI-Definition definiert, gibt estechnisch gesehen einen hohen Freiheitsgrad. Insbesondere die Art der Speiche-rung und des Zugriffs sind nicht festgelegt und unterscheiden sich zwischen denSystemen teilweise grundlegend. In der Praxis haben sich unterschiedliche Kon-zepte entwickelt, von denen die nachfolgenden heute von Bedeutung sind.

ROLAP

Für Relational OLAP werden relationale Datenbanken eingesetzt, die speziell fürden Einsatz in Data-Warehouse-Umgebungen optimiert wurden. Aufgrund ihrerlangen Existenz bieten relationale Datenbanken eine sehr hohe Stabilität und sindin hohem Maße skalierbar. Kennzahlen werden in ROLAP-System zur Laufzeit be-rechnet. Eine hohe Normalisierung der Daten wirkt sich allerdings nachteilig aufdie Performance aus, da für bei Abfragen viele Verbundoperationen nötig sind.

MOLAP

Beim Multidimensional OLAP werden die Daten in multidimensionalen Daten-strukturen gespeichert. Aggregierte Kennzahlen können bereits bei der Erstellungdes Datenwürfels berechnet und persistent gespeichert werden, um den späterenZugriff zu beschleunigen. Dies würde aber auch den Speicherbedarf gegenüber re-lationalem OLAP erhöhen. Insbesondere bei Einsatz der In-Memory-Technologieverzichten die Anbieter aber oft darauf und berechnen alle Kennzahlen ausschließ-lich bei Bedarf. In jedem Fall aber handelt es sich um proprietäre Lösung vonSpezial-Anbietern, die für den Einsatz von MOLAP nötig und deshalb in der Regelauch mit höheren Investitionen verbunden sind.


HOLAP

Hybrid OLAP stellt das Konglomerat aus ROLAP und MOLAP dar und versuchtdie Vorteile von ROLAP und MOLAP zu verbinden. Um allerdings die optimaleund stabile Kombination beider Konzepte zu erreichen, benötigt es eine komplexeund damit auch fehleranfällige Architektur.

Weitere Varianten mit geringer Bedeutung

Darüber hinaus gibt es noch weitere Kategorisierungsmöglichkeiten für OLAP-Systeme. Diese dürfen nicht für sich alleine betrachtet werden, sondern treten oft inKombination mit den bereits vorgestellten OLAP-Varianten auf oder stellen einenSpezialfall Letzterer dar.

Desktop OLAP (DOLAP) DOLAP ist eine Abwandlung von MOLAP. Auch hierwerden die Daten multidimensional abgelegt, allerdings nicht auf einem Ser-ver, sondern direkt auf dem Endgerät. DOLAP hat mit denselben Nachteilenwie MOLAP zu kämpfen, wobei sich der Performance-Flaschenhals aufgrundder im Normalfall schwächeren Hardware-Ausstattung des Endgeräts nochverschärfen kann. Allerdings lässt sich bei DOLAP auch dann noch arbeiten,wenn die Internetverbindung einmal nicht vorhanden sein sollte.

Web-Based OLAP (WOLAP) Gemeint ist hierbei die Verlagerung der Analyse-Oberfläche ins Internet. Der Zugriff erfolgt ausschließlich per Webbrowser,was impliziert, dass auf dem Endgerät weder spezielle Software installiertsein muss noch Berechnungen durchgeführt werden.

Real-Time OLAP (RTOLAP) RTOLAP beschreibt die Echtzeitanforderung an BI-Anwendungen. Die Informationen aus den Vorsystemen sollen nicht nur inverhältnismäßig langen Zyklen aktualisiert, sondern quasi sofort berücksich-tigt werden. Damit ist Real-Time OLAP auch eng verbunden mit OperationalBI. Die In-Memory-Technolgie, die im Fokus dieser Arbeit steht und in Kapi-tel 2.3 noch im Detail vorgestellt wird, kann hierfür einen wichtigen Beitragleisten. Durch die Datenhaltung im Arbeitsspeicher und die daraus resultie-renden schnellen Zugriffe sowie die Aggregationen in Echtzeit, lassen sich diehohen Performance-Anforderungen erfüllen.


2.1.2 Typische Operationen

Die Datenwürfel lassen sich mit Hilfe spezieller Reporting-Programme auswer-ten und analysieren. Bei dieser Analyse – egal ob Standard-Reports oder AdHoc-Reporting – kommen einige OLAP-typische Operationen zum Einsatz.

Dicing

Beim Dicing bleibt die Dimensionalität des Datenwürfels erhalten, es wird aber in-nerhalb einzelner Dimensionen die Wertemenge eingeschränkt. Das Ergebnis istein Teilwürfel mit weniger Daten, auf dem aber weiterhin alle Abfragen möglichsind, die auf dem ursprünglichen Datenwürfel ausgeführt werden konnten.

Slicing

Das Slicing ist eine eigenständige OLAP-Operation, lässt sich aber auch als Spezi-alfall des Dicing betrachten. Beim Slicing wird eine Scheibe aus dem Datenwürfelausgeschnitten, was sich auch als Dicing interpretieren lässt, bei dem in einer Di-mension die Menge der Elemente auf genau ein Element beschränkt wird. Klassi-scher Anwendungsfall sind Produktmanager, die nur die Verkaufszahlen der Pro-dukte sehen dürfen, für die sie zuständig sind. Ebenso dürfte ein Bezirks-Verkaufs-leiter nur die Umsatzzahlen seines Bezirks analysieren.

Abb. 2.2: Slicing und Dicing in einem multidimensionalen Datenwürfel (Quelle: Lehr-stuhl für Wirtschaftsinformatik, Universität Bamberg via [Man08b] )


Drill-Down und Roll-Up

Wie bereits gesehen, geht es in Business-Intelligence-Systemen primär darum, an-hand weniger Kennzahlen Entscheidungen zu treffen. Diese Kennzahlen auf obers-ter Ebene ergeben sich aus zahlreichen Kennzahlen niedrigerer Konsolidierungs-stufen. Mit dem Drill-Down wird eine aggregierte Kennzahl in ihre Bestandteilezerlegt, womit man eine Konsolidierungsstufe tiefer steigt.

Abb. 2.3: Drill-Down und Roll-Up - Aggregation und Aufschlüsselung der Daten (Quel-le: Lehrstuhl für Wirtschaftsinformatik, Universität Bamberg via [Man08b] )

Die umgekehrte Richtung beschreibt Roll-Up. Hier geht es darum zu sehen, wel-chen Einfluss eine Kennzahl auf die nächsthöhere Kennzahl hat. Durch stetigesRoll-Up lässt sich damit der Einfluss vom untersten Beleg bis hin zu Kennzahlenauf oberster Stufe verfolgen.

Pivotierung

Unter Pivotierung versteht man das Rotieren eines Datenwürfels um die eigene Ach-se. Bei gleichen Daten erhält der Anwender damit eine neue Sicht auf die Daten.Bekannt ist dieses Verhalten auch von den sogenannten Pivot-Tabellen in Tabellen-kalkulationen wie Microsoft Excel.


Abb. 2.4: Neue Sicht auf die Daten durch Pivotierung (Quelle: Lehrstuhl für Wirtschafts-informatik, Universität Bamberg via [Man08b] )

OLAP Join

Der OLAP Join verbindet unterschiedliche Datenwürfel mit gleichen Dimensionen.Damit lassen sich aus den Kennzahlen der einzelnen Datenwürfel neue Kennzahlenberechnen, ohne dass sich die Struktur des Datenwürfels ändert.

Abb. 2.5: Ein OLAP-Join verbindet Datenwürfel mit gleichen Dimensionen (Quelle:Lehrstuhl für Wirtschaftsinformatik, Universität Bamberg via [Man08b] )

2.1.3 Abgrenzung zu OLTP

Klar abzugrenzen sind OLAP-Systeme von OLTP-Systemen (On-Line TransactionProcessing), die im Bereich der relationalen Datenbanken zum Einsatz kommen.OLTP ist eine zu OLAP komplementäre Technologie, welche vor allem in den ope-rativen Systemen zum Einsatz kommt und dort versucht „eine möglichst exak-te Repräsentation der betreffenden Miniwelt“ [Lau08] abzubilden. Typischerweise


kommen dabei im Produktivbetrieb kurze und verhältnismäßig einfache Transak-tionen zum Einsatz, die nur eine kleine Teilmenge der Daten betreffen. OLAP ist imGegensatz dazu analysegetrieben, operiert auf multidimensionalen Datenwürfelnund benötigt aus diesem Grunde weitaus komplexere Operationen. Datenmanipu-lationen sind ursprünglich nicht vorgesehen, stattdessen werden die Daten histori-siert und nicht-flüchtig gespeichert.

OLTP (transaktional) OLAP (analytisch)

Anfragen

Fokus Lesen, Schreiben,Modifizieren, Löschen

Lesen, periodischesHinzufügen

Transaktionsdauer und-typ

kurze Lese-/Schreibtransaktionen

lange Lesetransaktionen

Anfragestruktur einfach strukturiert komplex

Datenvolumen einerAbfrage

wenige Datensätze viele Datensätze

Datenmodell anfrageflexiblesDatenmodell

analysebezogenesDatenmodell

Daten

Datenquellen meist eine mehrere

Eigenschaften nicht abgeleitet,zeitaktuell, autonom,dynamisch

abgeleitet, konsolidiert,historisiert, integriert,stabil

Datenvolumen Megabyte - Gigabyte Gigabyte - Terabyte

Zugriffe Einzeltupelzugriff Bereichsanfragen

Anwender

Anwendertyp Ein-/Ausgabe durchSachbearbeiter

Auswertungen durchManager, Controller,Analysten

Antwortzeit ms - s s - min

Tabelle 2.1: Unterschiede zwischen OLTP und OLAP [BG09, Seite 10f]


2.2 Einordung von OLAP in die

BI-Referenzarchitektur

Wie soeben gezeigt wurde, kommt dem On-Line Analytical Processing in einemBusiness-Intelligence-System – unabhängig von dessen expliziter Architektur – ei-ne ganz spezielle Aufgabe zu, es „ist in gewisser Weise die BI-Rechenmaschine“[Sch06, Seite 23] und obligatorischer Bestandteil eines jeden Systems. Da es bereitsunterschiedliche Definitionen eines BI-Systems gibt (siehe Kapitel 1.1), ist ebensoumstritten, welche Architektur-Komponenten für dieses obligatorisch sind. In derFachliteratur gibt es zahlreiche Versuche, die Architektur auf einen gemeinsamenNenner zu bringen, wie beispielsweise jene nach Bauer und Günzel.

2.2.1 Die BI-Referenzarchitektur nach Bauer und Günzel

Mit ihrem erstmalig im Jahre 2000 erschienenen Buch „Data Warehouse Systeme –Architektur, Entwicklung, Anwendung“ schufen Holger Günzel und Andreas Bau-er ein Standardwerk, wenn es um die Architektur von BI- und Data-Warehouse-Systemen geht. Zu einer Zeit, in der sich die BI-Systeme, wie wir sie heute ken-nen, erst noch entwickelten, entwarfen sie eine Referenzarchitektur (vgl. [BG09,Seite 38]). Diese teilt das BI-System in einen Datenbeschaffungs- und einen Auswer-tebereich. Daneben existieren noch assistive Komponenten, die den Ablauf koordi-nieren. Das Referenzmodell ist eine idealtypische Darstellung, von der BI-Systemein der Praxis mehr oder minder stark abweichen. Im Produktivsystem können des-halb einzelne Komponenten fehlen, ohne dass das System seinen Typus als Data-Warehouse-System verliert.

Datenbescha�ungsbereich

Als Synonym für die Datenbeschaffung hat sich die Abkürzung ETL (Extract, Trans-form, Load) etabliert. Gemeint ist damit die Überführung von Daten aus heteroge-nen (und meistens externen) Datenquellen in das Data Warehouse. Im Zuge dessenwerden die Daten bereinigt, vereinheitlicht, mit anderen Daten angereichert undteilweise auch schon aggregiert, bevor sie in einer Basis-Datenbank1 oder direkt im

1 Alternativ wird auch der Begriff „Staging-Datenbank“ verwendet.


Abb. 2.6: Referenzmodell für die Architektur von Data-Warehouse-Systemen (Quelle:[BG09, Seite 38])

Data Warehouse abgelegt werden. Dieser zentrale Datenspeicher ist Single Point ofTruth und Basis für alle Auswertungen. Es leuchtet deshalb ein, dass der Daten-qualität (siehe auch Kapitel 1.4.2) eine besondere Bedeutung zukommt und diesespätestens im Rahmen des ETL-Prozesses sichergestellt werden muss.

Auswertebreich

Auf den zentral gespeicherten Daten können schließlich die OLAP-Analysen durch-geführt werden. Aus den Daten im Data Warehouse werden multidimensionaleDatenwürfel generiert, auf denen letztendlich die Abfragen ausgeführt werden.Die Referenzarchitektur zeigt ebenso, dass auch der Paradigmenwechsel hin zur


In-Memory-Technologie (dazu gleich mehr) das Modell nicht zum Kippen bringt,weil dieses logischer Natur ist. Die Abbildung 2.6 zeigt die Einordnung der Analy-se innerhalb des BI-Systems – unabhängig von der technischen Realisierung.

Assistive Komponenten

Zum Betrieb und zur Steuerung des Data-Warehouse-Systems werden noch weitereKomponenten benötigt. Als zentrale Komponente zeichnet der Data-Warehouse-Manager für die Initialisierung und Steuerung des Systems verantwortlich undüberwacht die Prozesse von der Extraktion über die Transformation und das La-den bis hin zur Analyse. Die zur Durchführung dieser Aufgaben nötigen Infor-mationen werden vom Metadaten-Manager bereitgestellt, ein Monitor ist für dieÜberwachung der Datenquellen verantwortlich.

2.3 In-Memory-Technologie

Die letzte „Revolution“ (vgl. [Com06]) bei OLAP-Systemen war „die Ablösungvon traditionellen Datenbanksystemen durch effiziente In-Memory-Technologien“(vgl. [BHvdD09]). Ursprünglich wurden die Daten ausschließlich auf der Festplat-te gespeichert und auch bei Abfragen von dort gelesen. Mit dem Einsatz der In-Memory-Technolgie werden die Datenwürfel nun entweder direkt im Arbeitsspei-cher erstellt oder beim Programmstart aus einem zentralen Data Warehouse vonder Festplatte komplett in den Hauptspeicher geladen.

Durch die Datenhaltung im Arbeitsspeicher beschleunigen sich die Abfragenund typische OLAP-Operationen wie Slicing und Dicing erheblich. Der Zugriff aufDaten im Hauptspeicher ist gegenüber einer Festplatte durchschnittlich um denFaktor 1 000 (vgl. [Wik10]) schneller. Dadurch, dass die (komplexen) Analysen nä-her an die Daten rücken, sinken auch die Anforderungen hinsichtlich der Server-und Netzwerk-Infrastruktur (vgl. [She10]). Die Datenanalyse im Arbeitsspeichersorgt für eine deutliche Reduktion der Lesezugriffe auf den Festplatten. Komple-xe Analysen sollen damit erschwinglicher, skalierbarer und schneller werden (vgl.[She10]). Da keine vorberechneten Kennzahlen existieren, ist auch der benötigteSpeicherplatz geringer, die für das Netzwerk merklich geringere Belastung sorgt


für geringere Anfangsinvestitionen in die Infrastruktur und die frühere Erreichungdes Return on Investment (ROI) (vgl. [Fel09]).

Nachdem die Technologie zunächst von kleinen Anbietern wie QlikTech2 oderauch Jedox genutzt wurde, haben in der Zwischenzeit auch die großen Anbie-ter wie SAP oder Cognos erkannt, dass es keine andere Alternative gibt, um denheutigen und zukünftigen Herausforderungen, wie steigenden Datenmengen undimmer höheren Performance-Anforderungen, zu genügen. Überhaupt ist die „Per-formance eines der größten Hindernisse eines umfassenderen BI-Einsatzes“ (vgl.[Jai10]), dem mit In-Memory OLAP-Systemen begegnet werden kann.

Die In-Memory-Technologie war auch schon vor ihrem Einsatz im BI-Umfeldbekannt. Allerdings gab es lange Zeit technische und finanzielle Hindernisse, dieden Produktiveinsatz in größeren Umgebungen verhinderten. Erst der anhaltendePreisverfall für Speicherplatz und Arbeitsspeicher (vgl. [Blo10]) sowie die zuneh-mende Verfügbarkeit von 64-Bit-Systemen, die mehr Arbeitsspeicher adressierbarmachen3, haben dieser neuerlichen Nutzung geführt.

Da die zu analysierenden Daten komplett im Hauptspeicher liegen, stellt dessenGröße hardwareseitig die Grenze der maximal möglichen Datenmenge dar. Die-se Grenze lässt sich aber nicht genau quantifizieren, da der Arbeitsspeicher einer-seits immer auch von anderen Prozessen mitbenutzt wird und andererseits jedesBetriebssystem nach eigenen Algorithmen irgendwann beginnt, Daten aus demArbeitsspeicher auf die Festplatte auszulagern. Um die Vorteile der In-Memory-Technolgie ohne Einschränkung nutzen zu können, ist ein ausreichend großer undauf die zu erwartende Datenmenge abgestimmter Arbeitsspeicher obligatorisch.

2 www.qlikview.com3 In 32-Bit-Systemen können maximal 4 GB Arbeitsspeicher adressiert werden. Bei 64-Bit liegt

die theoretische Grenze der Adressierbarkeit bei 16 Exabyte (Exa = 1018 = Trillionen).

www.qlikview.com

Kapitel 3

Vergleichbarkeit von OLAP-Systemen

Die Performance ist ein oft erwähntes Problem beim Betrieb von OLAP-Systemen,wie auch Nigel Pendse in einem Interview im Januar 2010 auf die Frage nach denerfolgskritischen Faktoren in Business-Intelligence- und OLAP-Projekten feststellte(siehe [Rit10]). Allerdings ist es für Firmen im Vorfeld einer Investitionsentschei-dung sehr schwer, die Performance unterschiedlicher Systeme zu bestimmen unddie Alternativen dadurch miteinander vergleichbar zu machen.

Um Systeme direkt miteinander vergleichen zu können, müssten Vergleichzah-len unter identischen Rahmenbedingungen zustande gekommen sein. Innerhalbeines Benchmarks4 müssten alle Unterschiede bezüglich der Hardware sowie derDatenmenge eliminiert werden. Für den Empfänger der Ergebnisse müsste zudemnachvollziehbar sein, wie die Zeit gemessen wurde und wie sich der Benchmarkzur Verifikation reproduzieren lässt.

Ein derartiger Versuch für OLAP-Systeme wurde Ende der 90er Jahre mit demAnalytic Processing Benchmark (kurz: APB-1) unternommen. Allerdings war dieserschon bei seiner Veröffentlichung umstritten (vgl. [com96]) und ist heute quasi be-deutungslos, ohne dass es Alternativen gibt. Das letzte Release erfolgte im Novem-ber 1998, weitere unter [Cou98a] angekündigte Benchmarks5 wurden nie veröffent-licht.

4 Der Begriff Benchmark (engl. für „Maßstab“) kommt aus der Vermessungstechnik und bezeich-net dort einen fixen Punkt, an dem sich andere Punkte orientieren. In der Informatik und derBetriebswirtschaftslehre hat sich der Begriff als Synonym für die Möglichkeit etabliert, Produk-te und Dienstleistung oder auch Technologien und Prozesse miteinander zu vergleichen.

5 Die Zahl 1 in der Abkürzung APB-1 sollte ursprünglich dafür stehen, dass es sich um denersten von mehreren Benchmarks handelt.

33

Kapitel 3 Vergleichbarkeit von OLAP-Systemen 34

Mit dem Transaction Processing Performance Council Benchmark™ (kurz: TPC) exi-tiert ein zweiter Benchmark, der ursprünglich für den Vergleich von OLTP-Syste-men entwickelt wurde. Aufgrund der gravierenden Unterschiede zwischen OLAPund OLTP (siehe Kapitel 2.1.3) würde er sich bereits damit für die detaillierte Be-trachtung disqualifizieren. Allerdings besteht der Benchmark aus mehreren Tei-len, von denen sich der TCP-H speziell an Decision-Support-Systeme (DSS) richtet,also an die Vorgänger der heutigen Business-Intelligence-Systeme. Im Kern führ-ten Decision-Support-Systeme bereits jene Auswertungen durch, für welche heu-te OLAP-Systemehauptsächlich eingesetzt werden und bei denen die Performanceein immer wichtigerer bis hin zum geschäftskritischen Faktor ist. Die Vorstellungdes TCP-H erfolgt aus diesem Grunde im Kapitel 3.2.

3.1 Analytic Processing Benchmark

Der letztmalig im November 1998 aktualisierte Analytic Processsing Benchmarkwurde vom amerikanischen OLAP Council6 gefördert und hatte das Ziel, die Ge-samt-Performance eines OLAP-Systems zu bestimmen. Die Teilaufgaben werdendabei im Hinblick auf ihre Performance nicht separat bewertet, sondern zu einerGesamtzeit aufsummiert (vgl. [Cou98b]). Um im Rahmen des Benchmarks eine all-gemeine Aussage über die Performance eines OLAP-Systems treffen zu können,wurden im APB-1 die folgenden typischen Anwendungsfälle identifiziert:

• umfangreiche Daten aus externen und internen Datenquellen laden• inkrementelles Laden von Daten aus operativen Systemen• Aggregationen innerhalb einzelner Dimensionen• Berechnung neuer Kennzahlen• Zeitreihenanalysen• AdHoc-Abfragen sowie Abfragen mit einem hohen Komplexitätsgrad• Drill-Down innerhalb von Dimensionen

6 Das OLAP Council wurde 1995 gegründet und stand allen Unternehmen offen, die OLAP-Anwendungen entwickelten oder sich in anderer Weise damit auseinandersetzten. Vorausset-zung für die Mitgliedschaft war die Zustimmung zu den Grundsätzen des OLAP Council, dieOLAP als essentiell und geschäftskritisch für IT-Anwendungen ansahen und insbesondere diePerformance sowie die Datenkonsistenz in den Fokus rückten. Zuletzt gehörten dem OLAPCouncil die Firmen Apllix/TM1, Business Objects, IBM, Hyperion, Management Science Asso-ciates, NCR, Oracle, Platinum Technology und Sun Microsystems an (vgl. [Cou97]).


3.1.1 Testumfang und -ablauf

Der vollständige Prozess zur Bestimmung der Gesamtperformance des OLAP-Sys-tems besteht aus sechs Teilen, die in folgender Reihenfolge durchlaufen werden:

1. Generierung der Daten für das initiale Befüllen

2. Initialisierung der OLAP-Datenbank, Laden der historischen Daten und op-tional Durchführung von Vorberechnungen (wenn von der OLAP-Datenbankunterstützt)

3. Generierung der Daten für das inkrementelle Update

4. Inkrementelles Update und optional Durchführung von Vorberechnungen

5. Generierung der Abfragen

6. Ausführung der Abfragen

Datengenerierung

Die Datengenerierung erfolgt mit einem frei zugänglichen Generator7. Dadurch istes nicht nötig, zur Reproduktion große Datenmengen zu übertragen. Die Bandbrei-te war insbesondere zu Zeiten der Veröffentlichung des Benchmarks noch eine sehrknappe Ressource und sollte auch heute nicht unnötig verschwendet werden. DerDatengenerator enthält ausschließlich Berechnungsvorschriften und generiert Da-ten, die immer statistisch gleichen Mustern entsprechen und damit auch jeweilszum gleichen Benchmark-Ergebnis führen. Die Daten liegen zunächst in Flat Filesvor und müssen auf dem Zielsystem zunächst in die benötigte multidimensiona-le OLAP-Datenbank geladen werden. Der Generator arbeitet dreistufig. Zunächstwerden die Daten für das initiale Befüllen des OLAP-Cubes generiert. Der zweiteund dritte Aufruf liefert die Daten für das inkrementelle Update beziehungsweisedie Abfragen.

Das Programm steht nur als EXE-Datei für die Ausführung unter Windows zurVerfügung, eine Portierung auf andere Betriebssysteme gibt es nicht.

7 Download unter http://www.olapcouncil.org/research/bmarkly.htm.

http://www.olapcouncil.org/research/bmarkly.htm


Abb. 3.1: Struktur und Zusammenhänge zwischen den vom APB-1 generierten Dateien

Datenstruktur

Die generierten Daten zeigen ein fiktives Szenario zur Analyse von Verkaufsdaten.Die logische Datenstruktur besteht aus sechs Dimensionen, in drei davon existierenHierarchien:

• Customer (Aggregationen: Store→ Retailer→ Top)• Product (Code→ Class→ Group→ Family→ Line→ Division→ Top)• Channel (Base→ Top)• Time• Scenario• Measures

Die Dimension Measures enthält insgesamt zehn Kennzahlen. Neben den fünfabsoluten Kennzahlen Units Sold (verkaufte Einheiten), Dollar Sales (Umsatz), In-ventory (Bestand), Product Costs (Einzelkosten) und Shipping Cost (Vertriebskosten)werden fünf weitere Kennzahlen berechnet:

• Average Price (durchschnittl. Verkaufspreis) =Umsatz

verkaufte Einheiten

• Costs (Kosten) = verkaufte Einheiten ∗ (Einzelkosten + Vertriebskosten)


• Margin (Gewinn) = Umsatz−Kosten

• Margin Percent (Rendite) =GewinnUmsatz

• Smoothes Sales (6-Monats-Durchschnitt der Einnahmen)

Die Daten lassen sich nach dem Snowflake-Schema, wie in Abbildung 3.2 zu se-hen, darstellen. Die Dimension Measures wird dabei zur Faktentabelle, mit der dieanderen fünf Dimensionen verknüpft sind.

Abb. 3.2: Das Datenmodell des APB-1 als Snowflake-Schema

OLAP-Abfragen

Der letzte und wichtigste Schritt des APB-1 ist die Ausführung der Abfragen. Esgibt insgesamt zehn verschiedene Abfragetypen, die mit unterschiedlicher Gewich-tung in den APB-1 Benchmark eingehen:

• Channel Sales Analysis (Gewichtung: 10%)• Customer Margin Analysis (10%)• Product Inventory Analysis (15%)• Time Series Analysis (3%)


• Customer Budget (5%)• Product Budget (5%)• Forecast Analysis (15%)• Budget Performance (20%)• Forecast Performance (15%)• Ad Hoc (2%)

3.1.2 Verö�entlichung der Testergebnisse

Aufgrund der vielen Variablen bei der Durchführung des APB-1-Benchmarks, for-dert das OLAP-Council bei der Veröffentlichung von Ergebnissen die vollständigeOffenlegung der folgenden Informationen:

• Audit-Report• Datenbankschema• benötigter Code zum Laden der Daten sowie für Vorberechnungen• Anzahl der Nutzer• Größe jedes einzelnen Benchmark-Datenfiles• Datenbankgröße• Datenbank-Serversoftware und -Tuning-Parameter• Betriebssystem und Hardwareausstattung (CPU, Speicher)

Das Ergebnis des APB-1 wird als Performance-Metrik AQM (Analytical Queriesper Minute) angegeben, in die neben den Zeiten der einzelnen Teilaufgaben auchdie Anzahl der verarbeiteten Abfragen einfließt. Das OLAP-System ist demnachumso besser, je größer das Ergebnis ist.

Gesamtzeit für das inkrementelle Laden der Daten+ Gesamtzeit für Vorberechnungen (wenn benötigt)+ Gesamtzeit für die Ausführung aller Abfragen= Gesamtzeit für die AQM-Messung

AQM =Anzahl ausgeführter Abfragen ∗ 60Gesamtzeit für die AQM-Messung


3.1.3 Bewertung

Obwohl es ursprünglich ein guter Ansatz war, ist der APB-1 heute praktisch be-deutungslos. Trotz seines Potentials zu einem Hersteller-übergreifenden Standardzu werden, ist der Benchmark an zahlreichen Problemen und nicht zuletzt an denHerstellern selber gescheitert. Bereits die Entwicklung zielte darauf ab, Produktevon allen Herstellern auszuschließen, die nicht Mitglied im OLAP Council waren(vgl. [FMB+10, Seite 162]). Kritik gab es auch am Datenmodell, das „nicht repräsen-tativ [war] und keine ‘komplizierten‘ Abfragen“ [FMB+10, Seite 162]) enthielt. Dadie Entstehung des Datenmodells undokumentiert ist, liegt die Vermutung nahe,dass es mehr oder minder frei erfunden ist und/oder dabei bereits Eigenheiten derProgramme von Mitgliedern des OLAP-Councils berücksichtigt wurden.

Die Performance-Kennzahl AQM ist nur bedingt sinnvoll, da lediglich einfacheAbfragen für den Benchmark definiert wurden. In der Praxis kommen aber auchdeutlich komplexere Abfragen vor, weshalb eine Aussage über die durchschnitt-liche Abfragezeit größere Aussagekraft besitzen würde. Die Anzahl Anfragen proMinute ist lediglich in Mehrbenutzer-Systemen von Relevanz, da viele parallele Be-nutzer die Performance spürbar beeinträchtigen können. Darüber hinaus werdenunterschiedliche Teildisziplinen zu letztlich einer einzigen Kennzahl zusammenge-fasst, wobei zwar die Zeiten für inkrementelle Ladevorgänge mit eingehen, die Zeitfür das initiale Befüllen des OLAP-Cubes aber unberücksichtigt bleibt. Besser wärees, die Teildisziplinen einzeln zu bewerten, um dem Anwender die Möglichkeit derGewichtung nach seinen individuellen Ansprüchen zu ermöglichen. Schließlich istdie Performance des inkrementellen Ladens irrelevant, wenn das Data Warehouseimmer komplett neu befüllt würde.

Auch der Datengenerator für die einfache und komfortable Generierung der Da-ten war ein guter Gedanke, der aber letztlich unbefriedigend umgesetzt wurde. Dader Generator ausschließlich für Windows-Betriebssysteme nativ zur Verfügungsteht, ist die plattformunabhängige Datengenerierung nicht möglich. Vielfach wer-den aber Linux-Derivate als Server-Betriebssystem eingesetzt, auf denen sich dieDaten nicht direkt erzeugen lassen und von extern eingespielt werden müssen.


Hinzu kommt die lange Liste an Informationen, die bei der Veröffentlichung ei-nes Testergebnisses angegeben werden muss. Die hohe Anzahl der Variationsmög-lichkeiten macht den direkten Vergleich zweier Systeme nahezu unmöglich. So wa-ren bereits mehrere Durchläufe eines Anbieters nicht vergleichbar, da zwischen denAusführungen zu viele Veränderungen vorgenommen wurden.

Die einzige Veröffentlichung von Oracle hatte demnach reine Marketing-Gründe.Die genannten Kritikpunkte haben letztlich dazu geführt, dass der APB-1 nie anBedeutung gewinnen konnte, dem Endbenutzer keinen Nutzen brachte und nebenweiteren Veröffentlichungen auch die weiteren geplanten Benchmarks niemals er-schienen sind.

3.2 Transaction Processing Performance Council

Benchmark� H

Auch hinter diesem Benchmark steht mit dem Transaction Processing PerformanceCouncil8 (kurz: TPC) eine Organisation, der sich einige namhafte Unternehmen derIT-Branche angeschlossen haben, darunter Branchengrößen wie Dell, IBM, Micro-soft sowie die Prozessoren-Hersteller AMD und Intel. Das Konsortium wurde 1988als Zusammenschluss von zunächst acht Firmen gegründet, die zwei Ziele hatten:

1. Veröffentlichung guter Benchmarks

2. Einführung eines guten Prozesses, um diese zu rekapitulieren und zu über-wachen

In der Folge wurden mehrere Benchmarks veröffentlicht, die leicht unterschiedli-che Teilbereiche adressierten und die Probleme der Anwender verdeutlichten. JederBenchmark war auf diese Weise zugleich Indikator und Ansporn für die Weiterent-wicklung durch die Anbieter. Von den im Laufe der Zeit entstandenen Benchmarkssind heute noch der TPC-C9, der TPC-E10 sowie der TPC-H relevant.

8 siehe www.tpc.org9 allgemeiner Leistungsvergleich von Datenbank-Servern unterschiedlicher Bauweisen10 Simulation der Belastung eines OLTP-Systems am Beispiel eines Broker-Systems mit vielen

simultanen Lese- und Schreib-Zugriffen

www.tpc.org


Ziel des im Jahre 1999 veröffentlichten TPC-H-Benchmarks ist die Vergleichbar-keit entscheidungsunterstützender Systeme auf Basis von OLTP-Systemen. Trotzder grundsätzlichen Unterschiede zwischen OLAP und OLTP (siehe Kapitel 2.1.3)geht es bei diesem Benchmark um exakt jene Analysen, die heute mit Hilfe vonBusiness-Intelligence-Systemen durchgeführt werden. Während die Daten heute inOLAP-Datenbanken multidimensional für die Analysen vorgehalten werden, wa-ren sie damals noch in klassischen relationalen Datenbank-Management-Systemen(RDMS) gespeichert. Die im TCP-H dargestellten Anwendungsfälle – Geschäftspro-zesse und Datenmodelle eines Handelsunternehmens – haben sich bis heute nichtgrundlegend verändert, allerdings werden hierfür mittlerweile zumeist OLAP-Sys-teme eingesetzt.

Anders als der Analytical Performance Benchmark werden für TPC-H auch heu-te noch regelmäßig neue Ergebnisse veröffentlicht11. Hersteller der betroffenen Sys-teme wie IBM, HP, Sun oder Sybase nutzen die Ergebnisse vorrangig als Vertriebs-argument gegenüber Wettbewerbern. Der TPC-H gruppiert die Ergebnisse dabeiin Datenbankgrößen von 100 GB, 300 GB, 1 000 GB, 3 000 GB, 10 000 GB sowie30 000 GB. Vergleiche sind nur innerhalb einer solchen Gruppe sinnvoll.

3.2.1 Testumfang und -ablauf

Zur Abbildung des fiktiven Anwendungsfalls werden acht Tabellen benötigt, die,wie in Abbildung 3.3 zu sehen, miteinander in Verbindung stehen. Wie schon beimAPB-1 gibt es auch für den TPC-H einen Datengenerator12, der sowohl die Test-daten als auch die Abfragen für die Durchführung der Leistungstests generiert.Diese Daten müssen wiederum zunächst in die Datenbank geladen werden, bevordie Abfragen und Operationen durchgeführt werden können. Auch der TPC-H be-zieht die Performance des Ladevorgangs nicht mit ein, sondern konzentriert sichausschließlich auf die Abfragen und Datenmanipulationen.

11 Die aktuellen Benchmark-Ergebnisse finden sich unter www.tpc.org/tpch/results/tpch_

last_ten_results.asp.12 Download unter www.tpc.org/tpch/default.asp.

www.tpc.org/tpch/results/tpch_last_ten_results.asp

www.tpc.org/tpch/results/tpch_last_ten_results.asp

www.tpc.org/tpch/default.asp


Abb. 3.3: Datenschema des Benchmarks TPC-H [Cou10, Seite 12]

Der TPC-H umfasst 22 Ad-Hoc-Abfragen sowie zwei Operationen zur Daten-manipulation. Ad-Hoc bedeutet in diesem Fall, dass die Abfragen aus Sicht derDatenbank „zufällig“ sind und keine speziell darauf optimierten Datenstrukturenoder vorberechnete Werte existieren. Die Abfragen sollen typische und praxisrele-vante Anwendungsfälle simulieren.

3.2.2 Verö�entlichung der Testergebnisse

Zur Veröffentlichung des Testergebnisses müssen neben den Messergebnissen zahl-reiche Informationen zum System und Messvorgang im sogenannten Full Disclos-ure Report (FDR) angegeben werden, um die Rahmenbedingungen zu dokumen-tieren. Dieses Dokument ermöglict später auch einem vom TPC zertifizierten Au-ditor, das Ergebnis zu validieren. Neben der Topologie und Ausstattung des Sys-tems sind vor allem die Parameter der Software/Datenbank relevant, da Änderun-


gen an den Standard-Einstellungen bereits erhebliche Performance-Unterschiedebewirken können. Veröffentlicht werden müssen unter anderem 13:

• Executive Summary (Kurzzusammenfassung)• Hardware-Ausstattung, Konfigurationen und Topologie• Einstellungen und Parameter der Software/Datenbank• Quelldateien und Skripte, die für die Reproduktion benötigt werden• Angaben zu Preisen und Verfügbarkeit des Systems

Wie schon der APB-1 definiert auch der TPC-H eigene Metriken, welche die Sys-teme miteinander vergleichbar machen sollen:

QphH@Size � Abfragen pro Stunde (query-per-hour) Die Kennzahl gibt an, wieviele Abfragen das System innerhalb einer Stunde verarbeiten konnte. Da sichdie Teilergebnisse der einzelnen Abfragen teilweise erheblich unterscheiden,ist diese Kennzahl letztlich als Durchschnittswert zu verstehen.

$/QphH@Size � Preis-Leistung Aufbauend auf der ersten Kennzahl und den Kos-ten des Systems werden die tatsächlichen Durchschnittskosten berechnet, diepro Berechnung anfallen.

3.2.3 Bewertung

Nachdem der TPC-H wie alle Benchmarks des Transaction Processing Council ur-sprünglich sehr Endbenutzer-orientiert war und die tatsächlichen Probleme undHerausforderungen deutlich herausstellte, hat zwischenzeitlich ein Wandel stattge-funden, im Zuge dessen die Leistungstests immer mehr von den großen Hardware-Anbietern beeinflusst wurden.

Die Benchmarks werden mittlerweile auf Systemen durchgeführt, die mit ihrenriesigen Mengen an Speicherplatz und Arbeitsspeicher sowie den daraus resul-tierenden Kosten so in der Praxis wahrscheinlich nie zum Einsatz kommen. Ausdiesem Kräftemessen der Hardware-Anbieter untereinander hat sich mittlerweileauch Teradata als einer der größten Data-Warehouse-Anbieter zurückgezogen, was

13 Die vollständige Liste der Anforderungen findet sich unter [Cou10].


ein deutliches Indiz dafür ist, dass das TPC „seine Relevanz im Data-Warehouse-Sektor verloren hat“ [Sto09, Seite 15]. Zudem läge insbesondere dem TPC-H einschlechtes Datenschema zugrunde, das auch immer nur in Ausschnitten und vonkeiner Abfrage komplett abgefragt würde. Zusammen mit der Ignoranz der Per-formance beim (initialen) Ladeprozess hat dies dafür gesorgt, dass der Benchmarkhinsichtlich des Vergleichs unterschiedlicher Alternativen „kaum noch relevant fürirgendeine alltägliche Problemstellung ist“ [Sto09, Seite 15].

Die zunehmende Größe und Komplexität der Systeme, die in den TPC-H-Besten-listen auftauchen, haben auch dazu geführt, dass die ebenfalls überladenen FullDisclosure Reports – ein aktueller FDS von Hewlett Packard14 vom November 2009bringt es auf einen Umfang von 131 Seiten – sowohl als Grundlage für Investi-tionsentscheidungen als auch für den Vergleich zweier Alternativen unbrauchbargeworden sind. Auf der Transaction Processing Performance Council Technology Con-ference, die in Lyon 2009 erstmal stattfand, fasste Michael Stonebraker vom Massa-chusetts Institute of Technolgy in Cambridge zusammen, dass das TPC „seinen Wegverloren hat“ [Sto09, Seite 11] und immer langsamer und schwerfälliger gewor-den sei. Um nicht vollkommen in der Versenkung zu verschwinden, müsse sichdas TPC jetzt neu definieren, sich an seine Wurzeln zurück erinnern und wiederdie Alltagsprobleme und -anforderungen der Anwender adressieren, die da wärenPerformance, Skalierbarkeit und Einfachheit.

Allerdings wird der TPC-H auf Herstellerseite immer noch herangezogen, umdie Performance der eigenen Datenbanken zu überprüfen und die Abfragen zuidentifizieren, die nicht besonders schnell bearbeitet werden können. Mit diesenErkenntnissen lassen sich Optimierungen und die Weiterentwicklung gut steuern.

3.3 Rückschlüsse für die eigene Arbeit

Nach Betrachtung der beiden Benchmarks lassen sich einige Rückschlüsse für denim weiteren Verlauf dieser Arbeit zu entwickelnden OLAP-Benchmark ziehen. Die

14 Download unter http://www.tpc.org/results/FDR/tpch/HP_BladeSystem128P_090603_

TPCH_FDR_v2.pdf

http://www.tpc.org/results/FDR/tpch/HP_BladeSystem128P_090603_TPCH_FDR_v2.pdf

http://www.tpc.org/results/FDR/tpch/HP_BladeSystem128P_090603_TPCH_FDR_v2.pdf


dargelegten Kritik- und Schwachpunkte sollen nach Möglichkeit beseitigt und dieguten Ansätze weiterentwickelt werden.

Ladegeschwindigkeit berücksichtigen

Der Hauptfokus beider Benchmarks lag auf der Performance bei Abfragen undinkrementellen Updates. Unberücksichtigt blieb aber in beiden Fällen der Lade-prozess, obwohl auch die Zeit zum Laden neuer Daten sowie für eventuell not-wendige Neuberechnungen oder Reaggregationen der OLAP-Datenbanken einenicht zu verachtende Performance-Metrik darstellt (vgl. [FMB+10, Seite 160]). Dain der Praxis oft sehr große Datenmengen verarbeitet und teilweise auch OLAP-Cubes täglich innerhalb bestimmter zur Verfügung stehender Zeitfenster komplettneu befüllt werden müssen, ist die zu erwartende Dauer eine wichtige Informa-tion für Unternehmen. Eine schlechte Lade-Performance kann deshalb bereits einAusschlusskriterium sein.

Repräsentatives Szenario

Beide Benchmarks verwenden das Szenario eines fiktiven Handelsunternehmens.Auch wenn diese Art Szenario im BI-Umfeld oft verwendet wird, so findet sich lei-der keine Information über dessen Entstehung. Vielfach wird Software in der Pra-xis anders genutzt als vom Anbieter ursprünglich angedacht. Der Anwendungsfallsollte demnach möglichst repräsentativ sein und sich aus tatsächlichen Kundenan-wendungen im Produktivbetrieb ergeben.

Planungskomponente

Eine zunehmend an Bedeutung gewinnende Aufgabe im BI-Umfeld ist die Pla-nung. Während dieses Thema zu den Zeiten, in denen der APB-1 und der TPC-Hentstanden sind, noch irrelevant war, so sind die Planung und Konsolidierung derTeilbereich innerhalb der Business Intelligence, der überdurchschnittlich wächst(vgl. [Bec09]). Nach der Performance beim Lade- und Analysevorgang muss des-halb auch berücksichtigt werden, inwieweit die OLAP-Systeme bereits die Planungund damit das Zurückschreiben der Daten unterstützen und wie ausgereift dieseFunktion mittlerweile ist.


Trennung der einzelnen Teilbereiche

Der zu entwickelnde OLAP-Benchmark soll grundsätzlich die drei Teilbereiche La-den, Analyse und Planung unterscheiden und die einzelnen Performance-Kenn-zahlen nicht vermischen. Je nach Anwendungsfall ist es dem potentiellen Anwen-der damit möglich, die Schwerpunkte entsprechend seinen spezifischen Anforde-rungen zu setzen. Ein System, das in einem weniger wichtigen Teilbereich versagtaber dafür in der entscheidenden Disziplin überzeugen kann, ist schließlich immernoch besser als eines, das überall nur mittelmäßig abschneidet.

Programm für Datengenerierung essentiell

In beiden Benchmarks generiert ein kleines Programm die Testdaten, um die Über-tragung großer Datenmengen zu vermeiden. Trotz des immer günstigeren Spei-cherplatzes bleibt die zur Verfügung stehende Bandbreite oftmals ein Flaschenhals.Der OLAP-Benchmark soll deshalb auch einen (Daten-)Generator enthalten.

Bliebe noch die Frage nach dem passenden Datenformat. Der APB-1 benutzt einFile Positional15, bei dem die Zuordnungsvorschrift zwingend bekannt sein muss.Darüber hinaus wären die Formate CSV (Comma Separated Values) und XML mög-lich. Beide Formate sind textbasiert und können bereits mit einem einfachen Texte-ditor bearbeitet werden. Für den OLAP-Benchmark sollen CSV-Dateien verwendetwerden, da dabei der geringstmögliche Daten-Overhead anfällt.

Vergleichbarkeit über unterschiedliche Hardware hinweg schwierig

Es hat sich gezeigt, dass der Vergleich von Systemen auf unterschiedlicher Hard-ware schwierig ist. Neben der Tatsache, dass es nahezu unendlich viele Konfigura-tionsmöglichkeiten gibt, wirken sich auch Änderungen an der Hardware in vielfäl-tiger Weise aus.

15 In einer solchen Textdatei steht jedem Wert eine fest definierte Anzahl Zeichen zur Verfügung.Wird diese Anzahl nicht benötigt, so müssen am Anfang oder am Ende Leerzeichen ergänztwerden damit der Folgewert wieder an seiner designierten Stelle beginnt. Zwischen zwei Wer-ten steht anders als bei CSV-Dateien kein Trennzeichen mehr.


Aus diesem Grunde soll der OLAP-Benchmark keine Bedingungen an die Hard-ware-Ausstattung stellen, sondern nur die Datengrundlage und den Ablauf defi-nieren. Zum direkten Vergleich zweier Alternativen müssen diese auf identischerHardware installiert und den Benchmark unter den identischen Voraussetzungendurchgeführt werden. Die Erkenntnisse sind dann eindeutig und bieten keinen In-terpretationsspielraum. Wenn Firmen den Benchmarks im Rahmen eines Proof ofConcept auf den späteren Zielsystemen durchführen, zeigen sich auch direkt Eng-pässe und mögliche Probleme. Und zuletzt werden dadurch auch unrealistischeHardware-Konfigurationen verhindert, was ein großes Problem des TPC-H hin-sichtlich der Praxisrelevanz ist.

Wenige klare Informationen

Die soeben angesprochene Abstraktion von der Hardware bedeutet auch noch beider Veröffentlichung der Ergebnisse eine signifikante Verbesserung. Bei einem Ver-gleich mehrerer Alternativen unter gleichen Hardware-Voraussetzungen muss dieKonfiguration – wenn überhaupt – nur ein einziges Mal angegeben werden. Auchdie Anzahl der Benchmark-Kennzahlen kann erheblich reduziert werden. Einfachgesagt sollten sich für jedes getestete System Antworten auf Fragestellungen ge-funden werden, die da wären: Wie lange dauert das Laden oder die Analyse von 1,2 oder 4 Millionen Datensätzen?

Wie alle Reports und Analysen einer BI-Lösung muss auch der Benchmark diewesentlichen Ergebnisse mit wenigen Informationen deutlich machen. Die Ergeb-nisse müssen so aussagekräftig sein, dass keine Fragen offen bleiben.

Zusammenfassung

Die genannten Punkte lassen schon den groben Rahmen des In-Memory OLAP-Benchmarks erkennen. Bevor dieser in Kapitel 5 entwickelt wird, geht es im nächs-ten Kapitel zunächst um die Identifizierung eines repräsentativen Szenarios, dasnicht aus den Köpfen der Entwickler, sondern aus der Praxis kommt. Hierzu wer-den Anwendungen von Kunden der Jedox AG analysiert, die im Produktivbetriebeingesetzt werden.

Kapitel 4

Typische Szenarien im OLAP-Einsatz

Bei den beiden bisher betrachteten Benchmarks war einer der Kritikpunkte, dass eskeine Informationen über die Herkunft oder die Entstehung der verwendeten Sze-narien und Datenmodelle gibt. Beides soll im Rahmen dieser Arbeit repräsentativsein. Hierfür werden im ersten Schritt Anwendungen von Kunden der Jedox AGanalysiert, um die häufigsten und typischen Anwendungsfälle herauszuarbeitenund auch zu sehen, wie komplex – bezogen auf die Anzahl Dimensionen sowie dieAnzahl Datensätze – die Datenmodelle sind. Anhand dieser Informationen werdensich im Kapitel 4.2 die Szenarien für den späteren Benchmark ergeben.

4.1 Analyse von Kundenanwendungen aus der

Praxis

Bei der Analyse von Kunden-Anwendungen aus der Praxis soll der Funktionsum-fang kurz umrissen werden. Die Details – Anzahl und Größe der verwendeten Di-mensionen sowie die Anzahl der Aggregationen – finden sich im Anhang.

4.1.1 Kunde 1: Debitoren-Controlling und Umsatzanalyse

Die Palo BI Suite wird in dieser Anwendung (detaillierte Statistik des Datenmodellsim Anhang A.1) zur Analyse der Debitoren sowie der Umsatzdaten eingesetzt. Eineder zentralen Fragen bei der Debitoren-Analyse ist die nach dem jeweiligen Wert-beitrag. Anhand der Verkaufserlöse, Rabatte und Skonti, des Wareneinsatzes sowiedes resultierenden Deckungsbeitrags kann zwischen guten (große Gewinnspanne)und schlechten (geringer Gewinn) Debitoren unterschieden werden.

48

Kapitel 4 Typische Szenarien im OLAP-Einsatz 49

Neben dem Wissen über die Deckungsbeiträge der Debitoren ist auch wichtigzu wissen, welche Artikel und Artikelgruppen sich wie erfolgreich verkaufen. Beidieser Analyse wird derselbe Datenwürfel verwendet, die Daten werden nun aberaus einem anderen Blickwinkel betrachtet.

4.1.2 Kunde 2: Umsatzanalyse und -planung, Finanzcontrolling

Auch bei diesem Kunden ist die Umsatzanalyse nach Regionen und Sparten Teilder BI-Anwendung, wobei das Datenmodell (siehe Anhang A.2) sehr einfach ge-halten ist. In jeder Analyse findet sich der Vergleich der aktuellen Werte mit denPlanzahlen sowie mit Vorjahreswerten, was auch die Betrachtung der historischenEntwicklung ermöglicht. Neben der Umsatzanalyse werden je Sparte und späterauch für den Gesamtkonzern die Umsätze (brutto und netto) sowie die Deckungs-beiträge berechnet. Den aktuellen Zahlen und der Hochrechnung für das aktuelleGeschäftsjahr stehen auch hier die Planzahlen und Vorjahreswerte gegenüber.

Der eigentliche Fokus liegt allerdings auf einem Kennzahlen-System für das Fi-nanzcontrolling, in dem sich der Großteil der insgesamt 87 Kennzahlen (37 davonsind berechnete Werte) wiederfinden. Ausgehend vom Nettoumsatz werden Kenn-zahlen wie der EBITDA16, das Betriebsergebnis oder auch das Wachstum sowie dieRendite berechnet. Weitere wichtige Kennzahlen sind die freien Cash-Flows, wel-che die Liquidität des Unternehmens repräsentieren.

4.1.3 Kunde 3: Kreditcontrolling

Bei dieser Anwendung liegt der Fokus darauf, den Finanzstatus des internationaloperierenden Unternehmens stets unter Kontrolle zu haben. Da sich das Geschäfts-gebiet über Ländergrenzen hinweg erstreckt und auch die Kreditbeschaffung in-ternational erfolgt, sind die zu analysierenden Finanzdaten wie Kredite, Bankgut-haben und Zinsen nach Ländern und Währungen untergliedert. Das vollständigeDatenmodell findet sich im Anhang A.3.

16 Das EBITDA ist eine wichtige betriebswirtschaftliche Kennzahl zur Profitabilität eines Unter-nehmens. Es ist die Abkürzung für den englischsprachigen Ausdruck „Earnings Before Inte-rests, Depreciation and Amortization“, also Gewinn vor Zinsen, Steuern, Abschreibungen aufSachanlagen und Abschreibungen auf immaterielle Vermögensgegenstände.


Die Steuerung der Kredite und des Bankguthabens ist von elementarer Bedeu-tung, um das Unternehmen stets liquide zu halten. Allerdings soll dies mit demgeringstmöglichen Bankguthaben erreicht werden, um die Opportunitätskosten soniedrig wie möglich zu halten. Kredite werden deshalb bei Fälligkeit mit neuenKrediten refinanziert. Die Herausforderung besteht darin, zu jedem Zeitpunkt denKredit mit den bestmöglichen Konditionen aufzunehmen. Es ist deshalb essentiell,immer den Überblick sowohl über die Konditionen von über 250 unterschiedlichenFinanzdienstleistern als auch das eigene Kreditportfolio mit verschiedenen Kredi-ten mit unterschiedlichen Volumina, Konditionen und Laufzeiten zu behalten.

4.1.4 Kunde 4: Komplette Unternehmenssteuerung

Bei dieser Filialkette deckt die BI-Anwendung nahezu alle Aufgabenbereiche derUnternehmenssteuerung ab. Die Analysen reichen von der Warenstatistik über dieTagesauswertungen (unternehmensweit und nach Filialen) bis hin zur Personalkos-tenabrechnung und Budgetplanung. Aufgrund der sehr unterschiedlichen Analy-sezwecke der einzelnen Datenwürfel gibt es drei voneinander unabhängige Kenn-zahlen-Dimensionen, wie auch im Anhang A.4 zu sehen ist.

Die Personalkosten müssen insbesondere bei einem derart weit verzweigten Fi-lialnetz mit Bezirksebenenen ständig kontrolliert werden. Insbesondere anhand derHochrechnungen ist es möglich, ausufernde Personalausgaben frühzeitig zu er-kennen. Da sich höhere Personalausgaben in einzelnen Filialen mit einem höherenUmsatz durchaus rechtfertigen lassen, ist auch dieser als Kennzahl vorhanden undkann in Relation zu den Durchschnittslöhnen sowie den Öffnungszeiten gesehenwerden. Über die Jahre hinweg lässt sich die Kostenentwicklung überblicken undes lassen sich auch die Personalkosten für neue Geschäftsjahre planen.

Den Personalkosten als eine der größten Ausgabe-Postionen steht der Waren-verkauf gegenüber. Diese Statistik hilft dabei, den Überblick zu behalten und jeneProdukte zu identifizieren, die sich besonders gut oder schlecht verkaufen. Damitlassen sich regionale Unterschiede erkennen, um die Produktpalette zu optimierenund auch durch rechtzeitiges Eingreifen Ausverkäufe zu vermeiden.


Eng verbunden mit der Warenstatistik sind auch die Tagesauswertungen, nurdie Sichtweise ist in diesem Fall eine andere. Im Vordergrund stehen nun die Ta-gesumsätze der einzelnen Filialen und Bezirke. Diese erscheinen täglich kumuliert,sodass für jeden Monat direkt ersichtlich ist, welchen Umsatz die ersten sieben oderdie ersten 14 Tage einbrachten.

4.1.5 Kunde 5: Debitoren-Controlling

Die folgende Anwendung hat nur einen einzigen Einsatzzweck: das Debitoren-Controlling. Die Kunden verteilen sich weltweit, weshalb innerhalb der Kunden-dimension entsprechende Hierarchien existieren. Die heterogene Kundenstrukturimpliziert auch, dass in unterschiedlichen Währungen gerechnet werden muss (sie-he Anhang A.5). Aus den offenen Forderungen und dem Zahlungsverhalten derKunden lassen sich Forecasts ableiten, um die zu erwartenden Zahlungseingängein den nächsten Quartalen zu quantifizieren.

4.1.6 Kunde 6: Projektabrechnung

Wie dieser Kunde zeigt, lässt sich die Palo-Software auch zur Projektabrechnungeinsetzen. Die wichtigsten Fragen dabei betreffen die Art sowie den Umfang derArbeit einzelner Mitarbeiter in bestimmten Projekten. Verschiedene Projekte beiunterschiedlichen Kunden haben zudem oft variierende Tagessätze, die verwaltetwerden müssen.

Neben diesen offensichtlichen Anforderungen an ein Projekt-Controlling ist auchdie Zuordnung zwischen Kunden und Mitarbeitern mit Hilfe eines zweidimensio-nalen Datenwürfels abgebildet – die 1 steht für seine Zuständigkeit, ansonsten stehtdie 0 –, gleiches gilt für den Kundenstatus – aktiv oder nicht. Beides sind keine An-wendungsfälle für BI-Systeme, sondern eher ein Fall für relationale Datenbanken.Allerdings sind die Daten somit in einem einzigen System abgelegt, wodurch sichÄnderungen unmittelbar auf alle aufbauenden Analysen auswirken.

Um später Leistungen in Rechnung stellen zu können, sind alle Tätigkeiten derMitarbeiter erfasst. Für jeden Zeitraum ist ersichtlich, welche Tätigkeiten für wel-


chen Kunden in welchem Projekt geleistet wurden. Neben Arbeitsbeginn und -endesowie der daraus resultierenden Arbeitszeit können auch noch darüber hinaus ent-standenen Kosten wie etwa Fahrtkosten erfasst werden. Auch gegebenenfalls ab-weichende tatsächlich zu verrechnende Arbeitszeiten lassen sich separat erfassen.

4.1.7 Kunde 7: Analyse von Umsatz, Projekten und Personal

In dieser letzten Anwendung werden mit einer Erfolgsrechnung, einer Personalpla-nung, einer Projektabrechnung sowie einer Verkaufsanalyse vier unterschiedlicheund größtenteils voneinander unabhängige Analysezwecke bedient, was auch einentsprechend komplexes Datenmodell (vgl. Anhang A.7) zur Folge hat.

Darin abgebildet ist zunächst ein einfaches Finanzcontrolling, innerhalb dessensich die Daten nach Kunden und Geschäftseinheiten sowie zeitlich filtern lassen.Darüber hinaus ist die Gegenüberstellung von Plan- und Ist-Zahlen möglich. Ähn-lich simpel fällt auch die Personalkostenanalyse aus, die sich Dimensionen mit demFinanzcontrolling teilt und mit Personal-spezifischen Kennzahlen ergänzt.

Innerhalb der Projektabrechnung sind die zeitlichen Filtermöglichkeiten sowieder Vergleich von Plan- und Ist-Zahlen zentraler Bestandteil. Darüber hinaus las-sen sich die Daten nach Projektstatus filtern. Neben den tatsächlich entstandenenKosten sind für jedes Projekt auch der Ertrag sowie betriebswirtschaftliche Kenn-zahlen rund um den Profit angegeben, womit der einfache und schnelle Überblicksowie das Monitoring der unterschiedlichen Projekte möglich ist.

Zuletzt findet auch die schon fast obligatorische Umsatzanalyse Anwendung.Die zeitlichen Filtermöglichkeiten sind dabei noch erweitert, sodass die Unterschei-dung nach Wochentagen, Samstagen und Sonntagen möglich ist. Die Produkt-Di-mension enthält eine 3-stufige Hierarchie. Darüber hinaus lässt sich die Auswahlbeispielsweise nach dem Geschäftsgebiet einschränken.


4.2 Die �typischen� Szenarien

Die vorherigen Seiten haben gezeigt, dass die Business-Intelligence-Lösungen aufBasis von Jedox Palo für sehr unterschiedliche Zwecke eingesetzt werden. Auchwenn die Auswahl von sieben Kunden aus einer Referenzliste von über 300 zahlen-den Kunden-Firmen17 nicht den Anspruch auf uneingeschränkte Repräsentativitäterheben kann, so zeigen sich doch schon in dieser Stichprobe klare Tendenzen, diedie Abbildung 4.1 sowie die Tabelle 4.1 zusammenfassen.

Um

satz

anal

yse

Fina

nzco

ntro

lling

Pers

onal

anal

yse

Proj

ekta

brec

hnun

g

Um

satz

plan

ung

Pers

onal

plan

ung

Proj

ektp

lanu

ng

Analyse Planung

Kunde 1 • •Kunde 2 • • •Kunde 3 •Kunde 4 • • • • •Kunde 5 •Kunde 6 • • •Kunde 7 • • • • •Zusammenfassung 4/7 6/7 3/7 2/7 2/7 1/7 2/7

Tabelle 4.1: Die Anwendungszwecke von BI-Lösungen bei Kunden der Jedox AG

Die häufigsten Anwendungen im Analyse-Bereich betreffen das Finanzcontrol-ling sowie die klassische Umsatzanalyse. Darüber hinaus zeigt sich auch, dass sichproblemlos die Personalausgaben und sogar Projekte verwalten lassen. Es ist anzu-nehmen, dass auch die Business-Intelligence-Lösungen anderer Anbieter in ähnli-cher Weise eingesetzt werden.

17 Stand: Oktober 2010


Abb. 4.1: Die Anwendungszwecke der Jedox-Kunden

Neben der Analyse als klassische Business-Intelligence-Anwendung bietet Pa-lo zusätzlich noch die integrierte Möglichkeit der Planung, was von den Anwen-dern immer häufiger genutzt wird. Durch die technische Möglichkeit des Rück-schreibens von Daten in den Datenwürfel finden die Daten nicht mehr ausschließ-lich über Datenintegrationsprozesse den Weg ins Data Warehouse, sondern könnenauch über das Frontend eingegeben und geändert werden. Einige Kunden machenvon dieser Möglichkeit bereits Gebrauch und planen Projekte oder Personalaus-gaben. Insbesondere die Verfügbarkeit des Web-Frontends Palo Web macht dieseFunktion zu einem mächtigen Feature, da neue Daten in Echtzeit und dezentral er-fasst werden können, ohne dass E-Mails oder Dateien verschickt werden müssen.Die neuen Daten stehen unmittelbar danach für Auswertungen zur Verfügung. Wiein Kapitel 1.4 beschrieben handelt es sich bei der Planungsfunktion um einen deraufkommenden Trends im BI-Bereich, bei dem in den kommenden Jahren mit ei-nem überdurchschnittlichen Wachstum gerechnet wird (vgl. [Zim09]).

Im nächsten Kapitel werden die genauen Rahmenbedingungen für den OLAP-Benchmark festgelegt. Neben der technischen Basis müssen dafür zunächst die Da-tenmodelle definiert werden. Die vorherigen Seiten haben klare Tendenzen hin-


sichtlich der tatsächlichen Nutzung des Palo OLAP-Servers gezeigt, weshalb es fürden Benchmark jeweils eine Analyse- und ein Planungsanwendung geben soll:

Umsatzanalyse Die Umsatzanalyse ist die klassische BI-Anwendung und soll ausdiesem Grunde als Szenario für den OLAP-Benchmark dienen. Im Gegensatzzum Finanzcontrolling weisen die Umsatzanalysen der besprochenen Kun-denszenarien große Ähnlichkeiten auf. Beim Finanzcontrolling sind die Kenn-zahlen und Kennzahlensysteme dagegen historisch gewachsen und in ihremAufbau sowie Umfang und ihrer Komplexität sehr unterschiedlich. Auch weildie Datenmodelle einer Umsatzanalyse schnell sehr groß werden können, bie-tet sich dieses Szenario für den Benchmark an.

Personalplanung Die Personalplanung ist ein ebenso allgemeingültiges Szenario,das in nahezu jeder Firma vorhanden ist und dabei auch immer sehr ähnli-che Strukturen aufweist. Da die Personalkosten insbesondere in Hochlohn-ländern wie Deutschland einen sehr großen Kostenblock darstellen, ist ihneneine hohe Aufmerksamkeit zu widmen. In Planungsszenarien werden oft un-terschiedliche Modelle durchgerechnet, um die Auswirkungen von Änderun-gen zu simulieren. Solche Tests dürfen auch bei komplexen Datenstrukturennicht zu lange dauern.

Wie die Datenstrukturen der beiden Szenarien im Detail aussehen sollen, wirdim folgenden Kapitel erarbeitet. Neben der Definition der Datenstrukturen geht esdort auch um die Beschreibung der (technischen) Rahmenbedingungen, der Daten-generierung sowie des Testablaufs.

Kapitel 5

Entwicklung des OLAP-Benchmarks

Nach der Analyse einiger Kundenanwendungen geht es nun um die praktischeUmsetzung des Benchmarks für In-Memory OLAP-Systeme sowie der dafür nöti-gen Vorarbeiten. Zunächst müssen die OLAP-Server ausgewählt werden, hardwa-reseitig gilt es die nötigen Rahmenbedingungen zu klären sowie die Datenmodelleund -strukturen für die beiden Testszenarien Umsatzanalyse und Personalplanungim Detail zu definieren.

5.1 Marktübersicht und Auswahl der

Testkandidaten

Wie bereits erwähnt, ist die In-Memory-Technologie eine der wichtigsten Entwick-lungen im BI-Umfeld, die es erst ermöglicht, die steigenden Performance-Anfor-derungen zu erfüllen (vgl. Kapitel 2.3). Außerdem ist sie das primäre Kriteriumbei der Auswahl der OLAP-Server für den Benchmark, wie bereits der Titel die-ser Arbeit impliziert. Während sich der allgemeine BI-Markt aus vielen kleinenund großen Anbietern mit noch mehr unterschiedlichen Produkten zusammen-setzt, gibt es bisher nur eine sehr überschaubare Menge an OLAP-Systemen, diedie In-Memory-Technologie einsetzen:

Palo Der OLAP-Server Palo der Jedox AG ist seit dem ersten Release im März 2006das Kernstück des BI-Produktportfolios. Von Anfang an setzt Palo auf diemultidimensionale Speicherung (MOLAP) sowie die In-Memory-Technologieund ist sowohl unter einer Open-Source-Lizenz als auch in einer funktionser-weiterten Version unter kommerzieller Lizenz verfügbar. Seit dem Frühjahr

56

Kapitel 5 Entwicklung des OLAP-Benchmarks 57

2010 gibt es eine weitere Palo-Variante, die mit GPU-Unterstützung die Per-formance von OLAP-Analysen deutlich erhöhen soll.

IBM Cognos TM1 Das vormals eigenständige Cognos wurde Anfang 2008 vonIBM übernommen, nachdem sich Cognos kurz zuvor die Firma Applix mitihrem OLAP-Server einverleibt hatte. Nicht erst seit der Übernahme durchden IBM-Konzern ist Cognos einer der großen Wettbewerber am BI-Marktund bietet ein weitreichendes Produktportfolio für Business Intelligence, Pla-nung, Performance Management sowie Unternehmenskonsolidierung.

Infor PM OLAP Server (ehemals MIS Alea) Der OLAP-Server ist die Kernkom-ponente der Performance-Management-Suite Infor PM 10 und damit die Basisfür Analyse, Reporting und Planung. Der Infor PM OLAP Server speichert dieDaten multidimensional und erlaubt auch das Zurückschreiben der Daten.

Mondrian Auch der OLAP-Server Mondrian ist quelloffen und er ist in den BI-Suiten von Jaspersoft, Pentaho und SpagoBI enthalten, die allesamt auch inOpen-Source-Versionen verfügbar sind.

MIK-OLAP Die Daten lassen sich in MIK-OLAP relational oder multidimensio-nal auf der Festplatte oder im Arbeitsspeicher halten. Mit den sogenanntenHybrid-Würfeln besteht zusätzlich die Möglichkeit, relationale und multidi-mensionale Speicherung sogar innerhalb eines Datenwürfels zu kombinieren.

QlikTech Mit dem Produkt QlikView war die Firma QlikTech einer der Vorrei-ter auf dem Gebiet der In-Memory-Technologie und hat im Jahre 2008 denSprung in die TOP 10 der BI-Anbieter in Deutschland geschafft (vgl. [BAR09]).QlikView abstrahiert dabei vom ETL-Prozess und ermöglicht die direkte Ver-knüpfung von Quellsystemen sowie den darauf aufbauenden Analysen, ohnedass zuvor Hierarchien und Dimensionen explizit definiert werden müssen.

Von den sechs genannten OLAP-Servern werden lediglich die drei erstgenanntenfür den Benchmark herangezogen, wobei Palo sowohl in der Standard- als auch inder GPU-Version getestet wird. Mondrian schied aus dem Testfeld aus, da es diePlanung nicht unterstützt, die beiden letzten Programme standen für den Bench-mark nicht zur Verfügung.


Jedes OLAP-System wird mit den Standard-Einstellungen getestet ohne Ände-rungen oder sonstige Optimierungen vorzunehmen. Es ist anzunehmen, dass mitbestimmten Einstellungen die Testergebnisse jeweils noch verbessert werden könn-ten, allerdings sind die Kenntnisse der einzelnen Produkte so unterschiedlich, dasseine Ungleichbehandlung nicht zu vermeiden gewesen wäre. Mit der Out-of-the-Box-Installation werden alle OLAP-Server gleichberechtigt und es wird auf dieseWeise honoriert, wenn ein System bereits ohne manuelles Eingreifen gute Ergeb-nisse liefert. Für den Datenimport im Rahmen des ETL-Prozesses wird – sofernvorhanden – das Datenintegrations-Tool des jeweiligen Herstellers verwendet.

5.2 Die Hardware

Wie bereits erwähnt ist ein vollständig von der Hardware abstrahierender Bench-mark kaum realisierbar. Sowohl der APB-1- als auch der der TCP-H-Benchmark re-duzierten ihre Benchmark-Ergebnisse zwar immer auf eine einzige Kennzahl, zurkorrekten Interpretation musste aber immer auch die Hardware zur Durchführungdes Leistungstest mit einbezogen werden. Dadurch sind die Benchmark-Ergebnisseschlecht bis gar nicht miteinander vergleichbar und vor allem Rückschlüsse auf diein der eigenen Systemlandschaft zu erwartende Performance nahezu unmöglich.

Anspruch dieser Arbeit ist die direkte Vergleichbarkeit der OLAP-Server, die alleauf der identischen Hardware getestet werden. Beim Test-Server handelt es sich umeinen Server mit den folgenden Ausstattungsmerkmalen:

• Mainboard Foxconn Destroyer mit OnBoard-Grafik

• Prozessor: AMD Phenom II X4 920 (4 x 2,80 GHz)

• 16 GB Arbeitsspeicher DDR-2

• 250 GB Festplatte (SATA, 7 200 rpm) von Western Digital, auf der das Betriebs-system sowie der OLAP-Server installiert werden

• 500 GB Festplatte von Samsung (SATA, 7 200 rpm) für die Quelldaten

• 4 GPUs Nvidia Tesla C1060 mit jeweils 4 GB Grafik-RAM; jede GPU besitzt240 (8 x 30) Grafikkerne


Bei den vier Nvidia-GPUs von Typ Tesla handelt es sich um spezielle Grafikkar-ten, die eigens als alternative Recheneinheit entwickelt und optimiert wurden. DieTesla-Grafikkarten werden nur von der GPU-Version des OLAP-Servers Palo ver-wendet. Für die Anzeige auf dem Monitor wird in allen Fällen die OnBoard-Grafikdes Foxconn-Mainboards verwendet.

5.3 Testszenarien und Datenmodelle

Im Kapitel 4.2 wurden mit der Umsatzanalyse und der Personalplanung die Szena-rien bestimmt, in denen sich die In-Memory OLAP-Systeme beweisen müssen. DerBenchmark soll einerseits die Performance unterschiedlicher Systeme direkt mit-einander vergleichbar machen und andererseits auch die Performance-Entwicklungder einzelnen OLAP-Server bei steigenden Datenmengen betrachten. An diesemPunkt wird es insbesondere dann interessant, wenn sich die Datenmenge zuneh-mend der Gesamtgröße des zur Verfügung stehenden Hauptspeichers annähert.

Die nebenstehende Grafik zeigtvereinfacht dargestellt den Daten-fluss von den Datenquellen über dieDatenintegration und Informations-aufbereitung bis hin zur Analyse.Im Zentrum steht als Symbol fürdie OLAP-Datenbank das „Daten-modell“. Wichtig ist an dieser Stelledie Performance beim Laden derDaten in den OLAP-Server (Daten-integration) sowie die Performancebei der Informationsbereitstellung.Der Benchmark wird demnach mes-sen, wie gut die Leistung an denSchnittstellen zur Daten-Sicht ist.

Abb. 5.1: Datenfluss von der Datenintegrati-on über die -aufbereitung bis hinzur -analyse (Quelle: [Rec10])


5.3.1 Datenmodell für die Umsatzanalyse

In den Anhängen A.1 bis A.7 sind die Eigenschaften der Anwendungen zu finde.Vier Anwendungen davon umfassen eine Umsatzanalyse, deren relevante Daten-würfel in Tabelle 5.1 noch einmal kurz zusammengefasst werden. Das Datenmodellwird sich hinsichtlich der Komplexität an den Durchschnittswerten orientieren.

Kunde Dimensionen Dimension und Aggregationsstufen

Kunde 1 8 7 684 Produkte in dreistufiger Hierarchie

38 Kennzahlen

8 Jahre

Kunde 2 8 160 Artikelgruppen in sechsstufiger Hierarchie

123 Länder in dreistufiger Hierarchie

87 Kennzahlen (der Großteil davon allerdingsnur für das Finanzcontrolling relevant)

29 Jahre (10 Jahre davon enthalten Planzahlen)

Kunde 4 9 433 Produkte in dreistufiger Hierarchie

306 Filialen in vierstufiger Hierarchie

27 Kennzahlen

7 Jahre

Kunde 7 10 582 Produkte in zweistufiger Hierarchie

227 Geschäftseinheiten in vierstufiger Hierarchie

11 Kennzahlen

9 Jahre

Mittelwert 8,75

Tabelle 5.1: Zusammenfassung der Kundenanwendungen mit Umsatzanalyse

Die Dimensionalität der betrachteten Umsatzanalysen liegt im Mittel bei 8,75. InAnlehnung daran wird das Datenmodell des Benchmarks aus acht Dimensionenbestehen, als Kennzahlen werden neben den Umsätzen die Gewinnspannen, dieAnzahl der verkauften Artikel sowie die gewährten Rabatte erfasst. Damit ergebensich die in Abbildung 5.2 zu sehenden Zusammenhänge, die einzelnen Dimensio-nen lassen sich wie folgt kurz beschreiben:


Abb. 5.2: Datenmodell der Umsatzanalyse

Jahr Um zwischen den einzelnen Jahren unterscheiden zu können, ist das Jahr ineiner eigenen Dimension untergebracht.

Monat Innerhalb eines Jahres erfolgt zunächst die Unterteilung in die einzelnenMonate sowie die Zusammenfassung von Monaten zu den Quartalen.

Tag In einer dritten Zeit-Dimension sind die Tage untergebracht. Die Trennungvon Tagen und Monaten in zwei Dimensionen ist nötig, da ansonsten Verglei-che der ersten 10 Tage zweier unterschiedlicher Monate nicht möglich wären.

Filiale Jeder Umsatz fällt in einer bestimmten Filiale an, die sich wiederum in ei-nem bestimmten Postleitzahlengebiet in einem bestimmten Land befindet.

Bezirk Zudem lässt sich jeder Umsatz einem Bezirk zuschreiben. Während sichallerdings die Zuordnung einer Filiale zu einem Postleitzahlengebiet nichtändert, können sich die Beschnitte von Bezirken und Regionen durchaus än-dern. Dies führt zur beschriebenen Trennung in zwei separate Dimensionen.

Artikel Innerhalb der Artikel-Dimension existiert eine dreistufige Hierarchie, diejeden Artikel einer Warengruppe sowie einer Untergruppe zuordnet.


Marke Artikel werden unter mehreren Markennamen verkauft, teilweise als No-belmarke, aber auch unter einem Label für Discounter. Ein und dasselbe Pro-dukte kann somit unter verschiedenen Marken vertrieben werden, weshalbdiese Unterscheidung nach Marken erforderlich wird.

Kunde Bei jedem Verkauf wird der Kunde erfasst, der wiederum einer Kunden-gruppe zugeordnet ist. Darüber hinaus erfolgt in der nächsten Aggregations-stufe die Unterteilung der Kunden in Privat- und Geschäftskunden.

5.3.2 Datenmodell der Personalplanung

Neben der klassischen Analyse ist mit einer Personalplanung auch eine Planungs-anwendung Teil des OLAP-Benchmarks. Dies ist, wie in Kapitel 1.4 bereits erwähnt,eine der aufkommenden Anforderungen an BI-Systeme, wird aber noch nicht vonallen OLAP-Servern unterstützt.

Für den Benchmark wird eine Personalplanung entworfen, da diese zu den obli-gatorischen Aufgaben jeder Unternehmensführung gehört. Das Datenmodell einerPersonalplanung präsentiert sich auch in unterschiedlichen Unternehmen häufigsehr ähnlich und ist zumeist einfach aufgebaut, wie die Tabelle 5.2 zeigt. Im Mittel-punkt steht der Mitarbeiter, der einen gewissen Monatslohn verdient und eventuellzusätzlich Urlaubs- und Weihnachtsgeld erhält. Diese Zahlen müssen ebenso mess-und planbar sein wie die Fehlzeiten eines jeden Mitarbeiters.

Kunde Dimension und Aggregationssstufen

Kunde 4 306 Filialen in vierstufiger Hierarchie

46 Monate und mit diversen Kombinationen und Aggrega-tionen in einer bis zu zwölfstufigen Hierarchie

12 unabhängige Kennzahlen für die Personalkosten (keineAggregationen)

6 Jahre zzgl. Aufsummierung (7 Dimensionselemente)

4 Szenarien, u.a. Ist, Budget und Hochrechnung

Tabelle 5.2: Personalplanung aus der analysierten Kundenanwendung


In Anlehnung an die beschriebene Kundenanwendung entstand das in Abbil-dung 5.3 zu sehende Datenmodell. Die Dimensionen Filiale sowie Jahr und Monatsind dabei analog dem Datenmodell der Umsatzanalyse. Neu hinzu kommen dieDimensionen „Mitarbeiter“ sowie der „Datentyp“, welcher zwischen Ist- und Plan-zahlen unterscheidet. Als Kennzahlen werden der Nettolohn, die Fehltage sowiedas Urlaubs- und Weihnachtsgeld erfasst.

Abb. 5.3: Datenmodell des Szenarios „Personalplanung“

Die Dimensionen lassen sich wie folgt kurz charakterisieren:

Filiale Die Filiale ist der Ort, an dem Personalkosten anfallen und ist auch im Pla-nungsszenario in Postleitzahlengebiete und Länder gegliedert.

Mitarbeiter Der Mitarbeiter ist das zentrale Element der Personalplanung. Einefeste Zuordnung zwischen einem Mitarbeiter und einer Filiale besteht nicht,da jeder Mitarbeiter Kosten in unterschiedlichen Filialen erzeugen kann. Mitdieser Trennung von Mitarbeitern und Filialen ist das Datenmodell auch si-cher gegenüber Stellenwechseln.

Datentyp Bei der Planung wird zwischen Ist- und Planzahlen unterschieden.

Jahr Die obligatorische Jahres-Dimension ermöglicht die Trennung der Personal-kostenplanung nach einzelnen Jahren.

Monat Da die tagesweise Betrachtung wenig Sinn ergibt ist der Monat die kleinsteEinheit. Die Monate werden zudem quartalsweise zusammengefasst.


5.3.3 Datengenerierung

Nachdem die Datenmodelle definiert sind, werden adäquate Daten in ausreichen-der Menge benötigt. Da es nicht sinnvoll ist, mehrere Gigabyte an Daten vorzuhal-ten und von A nach B zu kopieren, wurde für jedes Datenmodell ein Datengenera-tor18 in der Programmiersprache Perl programmiert. Perl ist plattformunabhängigund lässt sich leicht auf allen gängigen Betriebssystemen ausführen.

Die Datengeneratoren liefern CSV-Dateien, aus denen die Datenwürfel erstelltwerden müssen. Pro Dimension gibt es eine Datei, die die Elemente samt Hier-archien enthält. Darüber hinaus gibt es Fakten-Dateien, welche die eigentlichenDatensätze enthalten. Die Größen der Dimensionen sind fix und den Tabellen 5.3und 5.4 zu entnehmen. Jede Fakten-Datei für die Umsatzanalyse enthält 250 000Datensätze mit jeweils vier Kennzahlen, in Summer also 1 000 000 Zeilen. Bei derPlanung gibt es je Fakten-Datei 100 000 unterschiedliche Datensätze mit ebenfallsjeweils vier Kennzahlen sowie den Datentypen „Ist“ und „Plan“ – insgesamt kom-men so jeweils 800 000 Zeilen zustande. Für die Umsatzanalyse werden bis zu 64Fakten-Dateien generiert, bei der Personalplanung sind es 32 Dateien. Die geringe-re Datenmenge bei der Planung erklärt sich mit den in der Regel deutlich kleinerenDatenmodellen im Vergleich zu Analyseanwendungen.

Für jeden Datensatz wird mit Ausnahme der Kennzahl ein Element jeder Dimen-sion gewählt. Diese Auswahl geschieht in der Dimension „Filiale“ sowie innerhalbder Analyse zusätzlich bei den Artikeln und Kunden nicht rein zufällig, sonderngemäß dem Zipfschen Gesetz, das der 80:20-Verteilung – auch bekannt als Pareto-Prinzip – sehr nahe kommt . Eine Gleichverteilung – wie sie sich bei der komplettzufälligen Auswahl der Elemente ergeben würde – kommt in der Praxis selten vor.Abschließend wird für jede Kennzahl ein Zufallswert generiert, wobei offensichtli-che Zusammenhänge berücksichtigt werden. Bei der Datengenerierung für die Um-satzanalyse werden teilweise Duplikate erzeugt, also Datensätze, die exakt dieselbeKoordinate im Datenwürfel adressieren. Der Anteil der Dubletten ist allerdings so

18 Beide Datengeneratoren sind auf der CD zu dieser Master-Thesis enthalten.


Dimension Anz. Elemente Anmerkungen

Artikel 5 000

Bezirk 50

Filiale 500

Kennzahl 4

Kunde 50 000

Jahr 10 Jahre 2000 bis einschl. 2009

Marke 5

Monat 17 zusätzlich quartalsweise gegliedert

Tag 61 jeder Tag eines Monats sowie die Summe seitMonatsbeginn

Tabelle 5.3: Größe der Dimensionen innerhalb der Umsatzanalyse

Dimension Anz. Elemente Anmerkungen

Datentyp 4 Ist- und Planzahlen sowie deren absolute undrelative Abweichung

Filiale 50

Kennzahl 5 Nettolohn, Weihnachtsgeld, Sollarbeitszeit so-wie Fehl- und Urlaubstage

Jahr 10 Jahre 2005 bis einschl. 2014

Mitarbeiter Anzahl aufgrund eines anderen Algorithmusbei der Generierung abhängig von der Anzahlder generierten Datensätze.

Monat 17 zusätzlich quartalsweise gegliedert

Tabelle 5.4: Größe der Dimensionen innerhalb der Personalplanung

gering, dass er vernachlässigt werden kann19. Bei der Personalplanung konntenDubletten aufgrund eines anderen Algorithmus komplett vermieden werden.

19 Innerhalb der 64 Millionen Datensätze, die für die Umsatzanalyse verwendet wurden, fandensich lediglich ungefähr 1 000 oder 0,0016 % Duplikate, die ignoriert werden mussten.


5.3.4 Abfragen innerhalb der Umsatzanalyse

Bei der Umsatzanalyse gibt es fünf OLAP-Abfragen unterschiedlicher Komplexität.Während die erste Abfrage 25 % der Daten mit einbezieht, wird bei jeder weiterenAbfrage jeweils eine weitere Dimension eingeschränkt.

1. Gesamtumsatz über alle Datensätze hinweg ohne jegliche Einschränkung.

2. Gesamtanzahl der innerhalb eines Jahres verkauften Artikel.

3. Reingewinn innerhalb einer Marke in einem bestimmten Land.

4. Gesamtumsatz einer Marke in einem Land im Laufe eines Jahres.

5. Summe der innerhalb eines Quartals an alle Geschäftskunden eines Landesgewährten Rabatte.

5.3.5 Aktionen innerhalb der Personalplanung

Bei der Planung spielt die Abfrageperformance eine untergeordnete Rolle, der Fo-kus liegt auf der Zeit, die für das Zurückschreiben der geänderten Daten benötigtwird. Insgesamt gibt es sechs unterschiedliche Planungs-Anweisungen, um eineKennzahl der Performance für die Planungsfunktion zu erhalten.

1. Übernahme der Nettogehälter (Ist) aller deutschen Filialen aus 2009 als Plan-zahlen für das Jahr 2010

2. Minderung der Nettogehälter 2010 (Plan) um jeweils 10 %

3. Das im Juli 2010 auszuzahlende Urlaubsgeld (Plan) beträgt pro Mitarbeiterund Filiale 200 e

4. Das Weihnachtsgeld 2009 (Ist) lag aufgrund eines Bonus mit Auszahlung imNovember für jeden Mitarbeiter um 100 e höher

5. Die Fehltage 2010 (Plan) sollen 20 % unter dem Niveau von 2007 liegen, woeine Gleichverteilung auf alle Mitarbeiter vorgenommen wird.

6. Die Personalkosten für 2011 werden auf 75 % des Ist-Wertes aus dem Jahre2009 geplant, wobei sich die Kosten in gleicher Weise verteilen wie 2009.

Kapitel 6

Durchführung des OLAP-Benchmarks

Nachdem auch die technischen Rahmenbedingungen geklärt waren, wurde derBenchmark für die insgesamt drei OLAP-Server durchgeführt.

6.1 Palo

Zum Zeitpunkt des Benchmarks befand sich die Entwicklung der Version 3.2 mitdem geplanten Erscheinungsdatum 31. Oktober 2010 in den Endzügen. Gestestetwurde mit einer Entwicklungsversion vom 24. August. Gegenüber der finalen Ver-sion können aus diesem Grund noch Performance-Unterschiede auftreten.

6.1.1 Benchmark des ETL-Prozesses

Der ETL-Prozess wurde mit Hilfe des in der Palo Suite enthaltenen ETL-Serversdurchgeführt. Der ETL-Server läuft als Java-Applikation innerhalb eines Tomcat-Servers. Die Bedienung erfolgt wahlweise über die Kommandozeile oder die grafi-sche Oberfläche im Webbrowser. Die Erzeugung des Datenwürfels im OLAP-ServerPalo gestaltet sich dreistufig. Zunächst werden alle Dimensionen erzeugt, indemdie flachen Datensätze aus den CSV-Dateien in Hierarchien umgewandelt und umdas Top-Element, wie beispielsweise „Alle Kunden“, ergänzt werden. Im zweitenSchritt wird aus den Dimensionen der Datenwürfel erstellt, der abschließend mitden bis zu 64 Millionen Datensätzen befüllt wird. Der Ladeprozess wurde in Sum-me drei Mal ausgeführt, um einen Durchschnittswert zu erhalten.

Der Tabelle 6.1 sowie der Grafik 6.1 ist zu entnehmen, dass sich die Performancemit steigender Datenmenge deutlich verschlechtert – optimal wäre eine lineare Stei-

67

Kapitel 6 Durchführung des OLAP-Benchmarks 68

gerung gewesen. Die Verschlechterung lässt sich damit erklären, dass der OLAP-Server nach jedem Hinzufügen die Strukturen der gespeicherten Daten optimiert,um die bestmögliche Abfrageperformance zu gewährleisten. In der Standardein-stellung schickt der ETL-Client pro Aufruf 10 000 Datensätze an den Server. AußerKonkurrenz – alle Produkte sollen in der Standard-Einstellung miteinander vergli-chen werden – zeigen die Durchläufe 4 und 5 welche Auswirkungen eine Ände-rung dieser sogenannten Bulksize auf 100 000 respektive 1 000 000 Datensätze hat.

1 Mio. 2 Mio. 4 Mio. 8 Mio. 16 Mio. 32 Mio. 64 Mio.

Durchlauf 1 1:37 3:43 9:24 25:56 1:26:40 5:48:21 23:47:38

Durchlauf 2 1:38 3:47 9:32 26:37 1:29:59 5:53:31 23:29:03

Durchlauf 3 1:47 4:05 11:07 31:57 1:44:51 6:19:02 23:47:27

Mittelwert 1:40 3:52 10:01 28:10 1:33:50 6:00:18 23:41:23

Faktor 2,32 2,59 2,81 3,33 3,84 3,94

Durchlauf 4 1:32 3:27 8:16 21:58 1:06:35 4:00:05 15:36:11

Durchlauf 5 1:37 3:29 7:41 18:30 53:30 2:51:53 15:42:15

Tabelle 6.1: Benötigte Zeit zum Laden der Daten in den OLAP-Server Palo

Der 4. Durchlauf mit der Bulksize von 100 000 zeigt eine signifikante Verbesse-rung, die benötigte Zeit verringerte sich dabei um knapp 34 %. Den Zeitgewinnerkauft man sich mit einem höheren Hauptspeicherbedarf, da nun auf Seite desETL-Severs die zehnfache Datenmenge zwischengespeichert werden muss.

Abb. 6.1: Entwicklung der Ladeperformance des OLAP-Servers Palo


Der fünfte und letzte Durchlauf mit einer Bulksize von 1 000 000 Datensätzenzeigte gegen Ende des ETL-Prozesses ein sehr volatiles Verhalten, es wurde immerwieder einzelne Datenpakete à 1 000 000 Datensätze sehr langsam verarbeitet. Da-mit wurden die Verbesserungen in der ersten Hälfte des Prozesses wieder zunichtegemacht, der 5. Durchlauf brauchte schließlich für 64 Millionen Datensätze sogarlänger als sein Vorgänger mit der um den Faktor 10 geringeren Bulksize.

Die Ladezeit von knapp 24 Stunden für 64 Millionen Datensätze wirkt auf denersten Blick sehr lang und wird erst im direkten Vergleich mit den beiden anderenOLAP-Servern korrekt zu interpretieren sein. Es lässt sich aber schon jetzt feststel-len, dass beim OLAP-Server Palo die benötigten zeitlichen Ressourcen weniger vonder hinzuzufügenden Datenmenge, sondern vor allem von der bisherigen Größedes Datenwürfels und die Anzahl der befüllten Basiszellen abhängen.

6.1.2 Benchmark der Umsatzanalyse

Da der OLAP-Server Palo per HTTP mit der Außenwelt kommuniziert, wurden dieAufrufe des Palo Excel-Clients von einem Proxy protokolliert und anschließend mitHilfe der Software JMeter20 für die unterschiedlichen Datenmengen und Abfragenje zehn Mal reproduziert. Das Caching des OLAP-Servers war dabei deaktiviert.


Abfrage 1 [ms] 266 469 743 1 474 2 814 6 065 12 344

Abfrage 2 [ms] 40 62 87 164 294 618 1 246

Abfrage 3 [ms] 85 135 202 394 777 1 570 3 805

Abfrage 4 [ms] 23 28 34 53 92 169 409

Abfrage 5 [ms] 20 28 34 54 96 183 326

Summe [ms] 433 720 1 101 2 138 4 072 8 605 18 130

Faktor 1,66 1,53 1,94 1,90 2,11 2,11

Tabelle 6.2: Performance des OLAP-Servers Palo bei der Umsatzanalyse

Die ausführlichen Messprotokolle sind im Anhang B.1.1 zu finden, die Tabelle 6.2und die Grafik 6.2 zeigen deren Zusammenfassung. Die letzte Zeile der Tabelle gibt

20 Download unter jakarta.apache.org/jmeter/.


an, um welchen Faktor sich die Summe der durchschnittlichen Abfragezeiten ge-genüber der vorherigen Datenmenge verändert. Da sich die Datenmenge immerverdoppelt, würde der Faktor 2 für eine lineare Entwicklung stehen. Während dieSteigerung bei kleinen Datenmengen noch unter diesem Richtwert liegt, zeigt sichfür große Datenvolumina auch hier eine Verschlechterung, die allerdings weit we-niger gravierend ausfällt als dies noch beim ETL-Prozess der Fall war.

Abb. 6.2: Performance des OLAP-Servers Palo bei der Umsatzanalyse

Zusätzlicher Performance-Test der GPU-Version

In einem zweiten Durchlauf wurde der Benchmark nochmals mit der GPU-Variantedes OLAP-Servers Palo durchgeführt. Die Berechnungen werden nun von den vierinstallierten GPUs des Typs Nvidia Tesla C1060 mit jeweils 4 GB Grafik-Arbeits-speicher und je 240 Grafikprozessoren durchgeführt, die CPU fungiert in diesemFall nur noch als Verwaltungs- und Steuereinheit. Wie sich der Tabelle 6.3 entneh-men lässt, sorgen die GPUs für eine massive Performance-Steigerung gegenüberder CPU-Variante. Bei nur einer anstatt vier GPUs würde sich die Abfragezeit inetwa vervierfachen (vgl. [LDKA10, Seite 7]), was aber immer noch eine deutlicheVerbesserung gegenüber der Palo-Version ohne GPU-Unterstützung darstellt.



Abfrage 1 [ms] 24 28 31 33 43 61 97

Abfrage 2 [ms] 21 23 26 28 34 43 66

Abfrage 3 [ms] 21 22 26 29 36 45 68

Abfrage 4 [ms] 17 22 25 28 29 37 62

Abfrage 5 [ms] 16 22 26 27 29 37 62

Summe [ms] 98 117 133 143 171 223 356

Faktor 1,19 1,14 1,07 1,20 1,30 1,60

ohne GPU [ms] 433 720 1 101 2 138 4 072 8 605 18 130

Steigerung 4,41 6,18 8,26 14,95 23,79 38,66 50,97

Tabelle 6.3: Performance des OLAP-Servers Palo bei der Umsatzanalyse mit 4 GPUs

Auch mit GPU-Unterstützung ist ein Anstieg der Abfragezeiten zu beobach-ten, allerdings liegt dieser selbst bei einer Datenmenge von 64 Millionen Daten-sätzen immer noch deutlich unter dem zu erwartenden Faktor von 2. Der direkteVergleich der Abfragezeiten mit GPU-Unterstüzung gegenüber jenen ohne GPU-Unterstützung weist schon bei 1 Millionen Datensätzen eine enorme Verbesserungvon 341 % auf, bei 64 Millionen Datensätzen sind die Berechnungen fast 51 Mal soschnell. Es lässt sich also feststellen, dass die GPUs insbesondere bei großen Daten-mengen ihre Vorteile gegenüber der Berechnung durch die CPU ausspielen.

Abb. 6.3: Performance des OLAP-Servers Palo bei der Umsatzanalyse mit 4 GPUs im Ver-gleich zur Umsatzanalyse ohne GPU-Unterstützung


6.1.3 Benchmark der Personalplanung

Analog zur Umsatzanalyse wird der Datenwürfel zunächst mit bis zu 25,6 Millio-nen Datensätzen befüllt. Die Planungs-Operationen wurden erneut mit Hilfe derSoftware JMeter insgesamt zehn Mal reproduziert und die Antwortzeiten des Ser-vers protokolliert. Bei Analyse der Messwerte – für die detaillierten Messwerte sie-he Anhang B.1.2 – fiel sofort auf, dass der jeweils erste Aufruf (Tabelle 6.4) deutlichmehr Zeit beanspruchte als die folgenden neun Requests (Tabelle 6.5).

0,8 Mio. 1,6 Mio. 3,2 Mio. 6,4 Mio. 12,8 Mio. 25,6 Mio.

Operation 1 [ms] 1631 8 318 26 464 116 952 459 951 3 097 579

Operation 2 [ms] 6 13 22 44 87 251

Operation 3 [ms] 389 815 1 708 1 194 8 016 14 192

Operation 4 [ms] 130 298 558 584 2 841 4 709

Operation 5 [ms] 2 551 1 318 2 829 5 615 49 941 52 972

Operation 6 [ms] 12 095 41 029 168 262 702 213 3 328 758 19 704 997

Summe [ms] 16 802 51 791 199 843 826 602 3 849 594 22 874 700

Faktor 3,08 3,86 4,14 4,66 5,94

Tabelle 6.4: Performance des OLAP-Servers Palo im Planungsszenario (1. Aufruf)


Operation 1 [ms] 595 1 255 2 395 4 698 7 401 24 333

Operation 2 [ms] 5 12 21 42 84 198

Operation 3 [ms] 33 70 140 313 670 1 222

Operation 4 [ms] 32 63 135 255 580 1 198

Operation 5 [ms] 248 489 1 085 2 243 5 035 16 656

Operation 6 [ms] 4 474 9 055 17 786 35 816 71 208 150 272

Summe [ms] 5 387 10 944 21 562 43 366 84 979 193 879

Faktor 2,02 1,97 2,01 1,96 2,28

vgl. Aufruf 1 [ms] 16 802 51 791 199 843 826 602 3 849 594 22 874 700

Tabelle 6.5: Performance des OLAP-Servers Palo im Planungsszenario (2. - 10. Aufruf)


Diese Auffälligkeit lässt sich technisch damit erklären, dass beim ersten Aufruf inBereiche des Datenwürfels geschrieben werden muss, für die noch kein Speicher-platz allokiert wurde. Was den nötigen Speicherbedarf im Arbeitsspeicher zunächstgering hält, sorgt nun für einen doch erheblichen Unterschied. Der mit Abstandgrößte Anteil an der Gesamtzeit wird unabhängig von der Datenmenge für die 5.Planungsoperation benötigt.

Neben der absoluten Zeit entwickelt sich aber auch die relative Zunahme auf un-befriedigende Weise. Bei der Verdopplung der Datensätze von 12,9 auf 25,8 Millio-nen benötigte der OLAP-Server nicht wie zu erwarten gewesen wäre die doppelteZeit, sondern fast sechs Mal so lange (beim 1. Aufruf).

Abb. 6.4: Performance des OLAP-Servers Palo im Planungsszenario

Zu beantworten wäre nun die Frage, welche Zeiten für den Vergleich mit denanderen OLAP-Servern verwendet werden sollen. Mit Blick auf die Praxis ergebensich für den Planungsprozess zwei Möglichkeiten. Es können entweder Referenz-daten eines Vergleichszeitraums kopiert oder es kann nach dem Top-Down-Ansatzdirekt mit zur Verfügung stehenden Budgets begonnen werden. Beiden Alternati-ven gemein ist, dass im ersten Schritt bis dato leere Datenbereiche beschrieben wer-den müssen. Realistisch betrachtet wird es aber wohl nie bei nur dieser einen Ope-ration bis zum Abschluss der Planung bleiben. Stattdessen würden unterschiedli-che Szenarien durchgespielt und es würde mit unterschiedlichen Werten gesplasht.Aus diesem Grunde soll für den Vergleich der Durchschnittswert aller zehn Aufru-fe verwendet werden, der sich wie in Abbildung 6.4 zu sehen darstellt.


6.2 Infor PM 10

Beim zweiten OLAP-Server Infor PM 10 sieht man sich schon zu Beginn mit einemMehraufwand gegenüber Palo konfrontiert. Infor läuft ausschließlich unter Win-dows und stellt auch noch weitere Anforderungen, wie etwa das Vorhandenseineines Microsoft Internet Integration Servers (IIS). Der Installationsprozess gestaltetsich demnach deutlich langwieriger.


Da kein dedizierter ETL-Client mitgeliefert wird, wurde für die Durchführung desETL-Prozesses der Cubeware Importer 7.0 verwendet. Die Ursprungsdaten in denCSV-Dateien ließen sich mit relativ einfachen Mappings in die OLAP-Datenbanküberführen. Die Unzulänglichkeit des Cubeware Importers bei der Verarbeitungvon mehreren Dateien mit identischer Struktur führte allerdings dazu, dass insge-samt knapp 70 separate Verbindungen zu den Quelldateien erstellt werden muss-ten. Die für den ETL-Prozess benötigten Zeiten konnten dem internen Protokoll desCubeware Importers entnommen werden und präsentieren sich wie folgt:


Durchlauf 1 2:29 4:39 9:00 17:46 35:42 1:13:16 2:37:07

Durchlauf 2 2:49 4:55 9:15 17:46 35:03 1:10:59 2:27:51

Durchlauf 3 2:30 4:37 8:50 17:21 34:38 1:11:29 2:29:17

Mittelwert 2:36 4:44 9:02 17:38 35:08 1:11:55 2:31:25

Faktor 1,82 1,91 1,95 1,99 2,05 2,11

Tabelle 6.6: Benötigte Zeit zum Laden der Daten in den OLAP-Server Infor

Es zeigt sich für den Datenimport eine deutlich bessere Performance im Vergleichzu Palo. Mit Blick auf die Abbildung 6.5 lässt sich dem OLAP-Server eine nahezulineare Entwicklung der Zeiten bescheinigen. Nur bei Datenmengen unter 4 000 000Datensätzen muss sich Infor gegenüber Palo noch geschlagen geben. Anschließendsorgt die gleichmäßige Steigerung dafür, dass Infor PM 10 bei 64 Millionen Daten-sätzen nahezu zehn Mal so schnell ist wie sein direkter Konkurrent.


Abb. 6.5: Entwicklung der Ladeperformance von Infor PM 10


Der Zugriff auf Infor PM 10 erfolgt wahlweise über das Infor PM Application Stu-dio oder Infor PM Office Plus. Letzteres startet nach dem gleichen Prinzip wie Pa-lo Excel zusammen mit einem Plugin, welches den Zugriff auf den OLAP-Würfelermöglicht. Die Oberfläche beider Alternativen ist sehr ähnlich, die Handhabungidentisch. Da das Infor PM Application Studio standardmäßig mitgeliefert und kei-ne Drittsoftware benötigt wird, wurden die Abfragen auch damit durchgeführt.

Die Verbindung zur OLAP-Datenbank ließ sich problemlos herstellen, da derServer auf dem Standardport automatisch erkannt wurde. Erste AdHoc-Analysensind somit innerhalb kürzester Zeit möglich. Schwieriger gestaltete sich allerdingsdie Messung der benötigen Zeiten, da sich der Client nicht zur Verwendung einesProxys überreden ließ und deshalb auch seine Anfragen an den Server nicht gefil-tert werden konnten. Damit war die Reproduktion der Anfragen mit einem exter-nen Programm nicht möglich, ebenso wenig waren innerhalb des Clients Debug-Ausgaben vorhanden. Nach der serverseitigen Konfiguration eines Log-Serviceswurden schließlich Protokolle erstellt, denen sich die Zeiten entnehmen ließen. DieAnfragen wurden schließlich im Infor Application Studio je zehn Mal hintereinan-der manuell ausgeführt.



Abfrage 1 [ms] 242 495 1 027 2 060 4 324 9 117 19 578

Abfrage 2 [ms] 90 185 380 763 1 540 3 234 6 593

Abfrage 3 [ms] 73 146 298 632 1 302 2 676 5 457

Abfrage 4 [ms] 42 83 168 347 698 1 418 2 745

Abfrage 5 [ms] 61 123 259 528 1,90 2 065 4 163

Summe [ms] 509 1 032 2 131 4 331 8 913 18 511 38 536

Faktor 2,03 2,07 2,03 2,06 2,08 2,08

Tabelle 6.7: Performance des OLAP-Servers Infor PM 10 im Analyseszenario

Die Tabelle 6.7 sowie die Abbildung 6.6 zeigen die gemessenen Zeiten für dieUmsatzanalyse mit Infor PM 10. Die detaillierten Messergebnisse lassen sich demAnhang B.2 entnehmen.

Abb. 6.6: Performance des OLAP-Servers Infor PM 10 bei der Umsatzanalyse

Zwischen den einzelnen Datenmengen lässt sich eine relativ konstante Steige-rung feststellen, die nur knapp über dem Faktor 2 liegt. Für sich betrachtet ist diesein durchaus annehmbares Verhalten, da die Verdoppelung der Datenmenge in et-wa auch eine Verdoppelung der benötigten Zeit zur Folge hat. Im direkten Ver-gleich zu Palo (ohne GPU-Unterstützung) bedeutet dies aber bereits eine schlech-tere Performance. So benötigte Infor PM 10 bei 64 Millionen Datensätzen etwa diedoppelte Zeit für die Bearbeitung der fünf unterschiedlichen Analysen.



Nach dem gleichen Prinzip wie schon innerhalb der Analyse wurde auch die Pla-nung über das Infor Application Studio durchgeführt. Infor PM 10 bietet im Ver-gleich mit Palo deutlich mehr Planungsfunktionen, die sich neben der manuellenEingabe des Kommandos auch über einen grafischen Dialog nutzen lassen.

Trotz diesem Mehr an Funktionen ließ sich die 4. Planungsoperation nur mit Hil-fe eines Zwischenschritts durchführen, denn es fehlte die Möglichkeit, jede Basis-zelle unterhalb einer aggregierten Zelle um einen absoluten Wert zu erhöhen. Es istaber möglich die aggregierte Kennzahl - in diesem Fall die Summe der gezahltenWeihnachtsgelder - um einen absoluten Betrag zu erhöhen, der dann gleichmäßigauf alle darunterliegenden Basiszellen verteilt wird. Als nötige Zwischenrechnungmuss demnach zunächst die Anzahl der betroffenen Zellen mit 100 emultipliziertwerden bevor die Planungs-Operation durchgeführt werden konnte.

Es konnten somit doch alle Planungs-Operationen auf den unterschiedlichen Da-tenmengen mit dem OLAP-Server Infor PM 10 ausgeführt werden, was folgendeResultate einbrachte:


Operation 1 [ms] 116 224 434 991 2 591 6 314

Operation 2 [ms] 30 51 122 126 272 463

Operation 3 [ms] 348 639 1 328 2 323 4 789 9 408

Operation 4 [ms] 35 78 259 431 914 1 794

Operation 5 [ms] 3 670 6 985 14 386 — — —

Operation 6 [ms] 394 1 045 3 356 10 487 38 142 142 937

Summe [ms] 4 495 9 023 19 884 14 358 * 46 707 * 160 915 *

Faktor 2,01 2,20 (0,72) 3,25 3,40

Tabelle 6.8: Performance des OLAP-Servers Infor PM 10 im Planungsszenario

* ohne Operation 5 (siehe folgende Seite)


Abb. 6.7: Performance des OLAP-Servers Infor PM 10 im Planungsszenario

Wie der Tabelle 6.8 sowie der Grafik 6.7 zu entnehmen ist, konnte ab einer Da-tenmenge von 6,4 Millionen Datensätzen die 5. Planungs-Operation – Fehltage 2010(Plan) auf 80 % des Niveaus von 2007 setzen bei Gleichverteilung auf alle Mitarbei-ter – nicht mehr durchgeführt werden. Jeder Versuch wurde vom OLAP-Server miteiner Fehlermeldung quittiert, die auf die Überschreitung der für eine Splashing-Operation maximal zugelassenen Basiszellen hinweist. Tatsächlich sind bei dieserDatenmenge 135 516 Basiszellen von der Splashing-Operation betroffen, was dieStandard-Grenze von 100 000 Zellen überschreitet. Allerdings wurde dieser Wertdirekt zu Beginn des Benchmarks auf 5 000 000 erhöht, was wiederum clientsei-tig den größtmöglichen Wert dieser Einstellung darstellt. Auch der Versuch, einennoch höheren Wert direkt in der Konfigurationsdatei einzustellen, schlug fehl.

Kurioserweise funktionierte das Splashing bei der 6. Operation, die ebenfalls Än-derungen an 134 516 Basiszellen zur Folge hat. Demnach verhinderte offensicht-lich ein Programmfehler an dieser Stelle die vollständige Durchführung des Bench-marks, wahrscheinlich wird das Limit für die vom Splashing betroffenen Basiszel-len bei dieser speziellen Funktion „Absolute Verteilung 2“ nicht korrekt verarbeitet.

Leider führt dieser Fehler auch dazu, dass der direkte Vergleich mit den beidenanderen OLAP-Servern nicht mehr uneingeschränkt möglich ist, was bei der spä-teren Zusammenfassung zu beachten sein wird.


6.3 Cognos TM1

Das dritte und letzte Programm ist zugleich auch die umfangreichste und am kom-pliziertesten einzurichtende BI-Lösung: IBM Cognos Express 9 mit der OLAP-Da-tenbank TM1. Einige Komponenten dieser Suite ließen sich ausschließlich unterWindows Server 2003 installieren und auch das erst nachdem zahlreiche Abhän-gigkeiten wie ein installiertes Microsoft Office, die Internet Information Services(IIS) sowie das .NET Framework erfüllt wurden. Eine Installation unter Windows7 wie bei den anderen beiden OLAP-Servern scheiterte.


Auch IBM Cognos Express 9 besteht aus mehreren Teilkomponenten, von denender Xcelerator für den ETL-Prozess verantwortlich zeichnet. Zunächst werden dieDimensionen mit Platzhalter-Elementen angelegt, um daraus den Datenwürfel zuerstellen. Anschließend finden innerhalb der sogenannten „Processes“ die Map-pings der CSV-Dateien in die Dimensionen statt wobei auch die nötigen Hierarchi-en angelegt werden. Zuletzt erfolgt die Verarbeitung der Fakten-Dateien.

Leider ist es auch im Xcelerator beschwerlich, die bis zu 64 Fakten-Dateien zuverarbeiten. Es ist weder möglich über die einzelnen Dateien mit identischer Struk-tur zu iterieren, noch lassen sich die Prozesse kopieren. Für jede Datei muss darumin langwieriger Arbeit ein eigener Prozess von Grund auf angelegt werden.


Durchlauf 1 0:29 0:46 1:20 2:30 4:49 9:29 44:04

Durchlauf 2 0:30 0:47 1:28 2:40 5:02 9:47 49:19

Durchlauf 3 0:28 0:48 1:22 2:31 4:50 9:30 46:10

Mittelwert 0:27 0:47 1:23 2:34 4:54 9:35 46:31

Faktor 1,62 1,77 1,84 1,91 1,96 4,85

Tabelle 6.9: Benötigte Zeit zum Laden der Daten in den OLAP-Server IBM Cognos TM1

Nach dem langwierigen Anlegen des ETL-Prozesses wird man (zumindest an-fänglich) mit einer sehr guten Performance beim Laden der Daten belohnt. Lange


Zeit dauert das Laden pro einer Millionen Datensätze konstant nur etwas mehr als17 Sekunden. Was aus der Tabelle 6.9 nicht hervorgeht, sich aber in der Abbildung6.8 deutlich zeigt, ist ein massiver Performance-Einbruch ab ca. 47 Millionen Da-tensätzen. Dieser ist auf den extrem hohen Speicherbedarf zurückführen. Die 16 GBArbeitsspeicher sind ab dieser Datenmenge gänzlich belegt weshalb der Windows2003 Server Teile der Daten auf die Festplatte auslagern muss – mit deutlich sicht-baren Auswirkungen.

Abb. 6.8: Entwicklung der Ladeperformance von IBM Cognos TM1

Für den ETL-Prozess muss deshalb eine entsprechend große Auslagerungsdateizur Verfügung stehen. Der erste Versuch mit einer 4 034 MB großen Auslagerungs-datei schlug fehl und ließ den Server knapp über 58 Millionen Datensätzen abstür-zen. Erst die Vergrößerung auf die vom Betriebssystem vorgeschlagene Größe von24 382 MB sorgte schließlich für das erfolgreiche Durchlaufen des ETL-Prozesses.

Was aus den Zeiten in Tabelle 6.9 ebenfalls nicht hervorgeht, ist eine doch relativlange aber zugleich nicht quantifizierbare Zeitspanne im Anschluss an das eigentli-che Laden, in der der OLAP-Server mit Optimierungen beschäftigt zu sein scheint.In dieser Zeitspanne von ca. anderthalb Stunden (bei 64 Millionen Datensätzen, an-sonsten deutlich geringer) reagierte der Xcelerator nicht und es ließen sich deshalbauch keine Analysen durchführen.



Nach dem Laden lässt sich der Datenwürfel auch direkt im Xcelerator betrachten.Es können dabei beliebige AdHoc-Analysen durchgeführt werden, die sich auchals sogenannte „Views“ für spätere Aufrufe abspeichern lassen. Jede gespeicherteAbfrage lässt sich über den Cognos Viewer im Web-Frontend einbinden. Allerdingstraten auch zwei Probleme auf, für die sich lediglich Workarounds finden ließen.

Während die Teilschritte des ETL-Prozesses noch in der Log-Datei des Serversprotokolliert wurden, ist dies bei der Analyse nicht mehr der Fall. In Produktiv-umgebungen ist diese Einstellung sicherlich ratsam, da bei vielen Benutzern undvielen Abfragen die entsprechende Datei schnell sehr groß werden würde. Wäh-rend der Entwicklung können diese Informationen aber sinnvoll und wichtig sein,für den OLAP-Benchmark sind sie essentiell. Trotz aller Versuche ließ sich eineadäquate Protokollierung nicht einrichten weshalb es einer alternativen Zeitmes-sung bedurfte. Diese sieht so aus, dass jede gespeicherte View über den Browser-basierten Cognos (Cube) Viewer aufgerufen wird und dabei mittels der Erwei-terung Firebug21 für den Internetbrowser Firefox die Zeit des relevanten HTTP-Requests gemessen wird. Das Programm JMeter konnte an dieser Stelle nicht zurAutomatisierung verwendet werden, da der HTTP-Request während seiner Bear-beitung zu viele HTTP-Weiterleitungen produziert, damit die Verbindung nichtwegen eines Timeouts abbricht. Innerhalb von JMeter gibt es allerdings eine hartcodierte Grenze von maximal fünf Weiterleitungen, die nicht ausreichend ist.

Das zweite Problem betraf das Caching, das sich nicht ausschalten ließ. Da bei ak-tiviertem Caching jede wiederholte Anfrage sehr schnell beantwortet werden konn-te, musste der OLAP-Server nach jedem Durchlauf der fünf Abfragen neu gestartetwerden. Glücklicherweise war der Server-Neustart auch bei 64 Millionen Datensät-zen noch in einer annehmbaren Zeit von ca. fünf Minuten möglich.

Mit den beschriebenen Lösungen konnten schließlich die Analysen durchgeführtwerden, was die innerhalb der Tabelle 6.10 angegebenen Durchschnittswerte liefer-te (siehe Anhang B.3.1 für die exakten Messergebnisse).

21 Download unter addons.mozilla.org/de/firefox/addon/1843.



Abfrage 1 [ms] 647 1 023 2 151 4 679 7 821 12 390 21 653

Abfrage 2 [ms] 1 055 1 059 2 168 4 176 7 143 11 114 18 999

Abfrage 3 [ms] 760 1 151 1 675 3 629 6 642 19 246 17 181

Abfrage 4 [ms] 663 1 164 1 669 3 521 6 480 9 907 16 179

Abfrage 5 [ms] 694 1 156 1 170 2 167 4 187 7 146 16 330

Summe [ms] 3 817 5 553 8 833 18 172 32 273 50 803 90 342

Faktor 1,45 1,59 2,06 1,78 1,57 1,78

Tabelle 6.10: Performance des OLAP-Servers IBM Cognos TM1 im Analyseszenario

Auffallend ist, dass sich die einzelnen Abfragen untereinander zeitlich weit we-niger stark unterscheiden als das bei den anderen beiden OLAP-Servern der Fallwar. Während bisher immer die Abfrage 1 (Gesamtumsatz an jegliche Einschrän-kung) deutlich mehr Zeit benötigte als die folgenden Abfragen, verteilt sich dieZeit bei IBM Cognos TM1 nahezu gleichmäßig über alle Abfragen (siehe Abbil-dung 6.9). Zudem weisen die Steigerungsfaktoren zwischen den unterschiedlichenDatenmengen eine hohe Volatilität auf. Dieses Verhalten lässt sich nur schwer nach-vollziehen, an einem zu vollen Hauptspeicher lag es in diesem Fall definitiv nicht.

Abb. 6.9: Performance des OLAP-Servers IBM Cognos TM1 bei der Umsatzanalyse



Das Problem der mangelhaften Protokollierung verschärfte sich bei IBM Cognosim Planungsszenario nochmals. Jede Planungs-Operation wir in einem separatenBrowser-Fenster ausgelöst das sich direkt nach der erfolgreichen Bearbeitung sel-ber schließt. Aus diesem Grunde konnte auch mit dem Browser-Addon Firebugdie Zeit nicht gemessen werden. Als letzte und auch ungenaueste Variante (weilnur auf eine Sekunde genau) blieb nur noch die Messung der vom Server-Prozessbenötigten CPU-Zeit. Es konnte bereits während der Analyse sichergestellt werden,dass die mit Firebug gemessenen Zeiten im Rahmen der Messungenauigkeit iden-tisch mit der CPU-Zeit sind und der entsprechende Prozess die CPU auch nur dannbeschäftigt wenn eine Analyse oder Planung durchgeführt wird. Wenn auch unge-nauer als bisher gewohnt, finden sich in der Tabelle 6.11 die Durchschnittswerteder Planung auf den unterschiedlichen Datenmengen.


Operation 1 [ms] 5 000 5 000 6 900 20 000 35 900 75 800

Operation 2 [ms] 2 100 4 900 4 700 15 000 28 700 56 100

Operation 3 [ms] 4 400 8 800 16 800 37 200 73 50 146 100

Operation 4 [ms] 500 500 1 800 2 600 3 900 6 500

Operation 5 [ms] 50 600 102 500 186 900 429 000 857 800 1 724 300

Operation 6 [ms] 2 700 5 700 6 800 19 900 38 700 75 700

Summe [ms] 65 300 127 400 223 700 523 700 1 038 500 2 084 500

Faktor 1,95 1,76 2,34 1,98 2,01

Tabelle 6.11: Performance des OLAP-Servers IBM Cognos TM1 im Planungsszenario

Beim Blick auf die genauen Messergebnisse (siehe Anhang B.3.2) zeigt sich, dassbei der dritten Planungsoperation ähnlich wie auch schon beim OLAP-Server Palofür den 1. Aufruf deutlich mehr Zeit benötigt wurde als für die folgenden 9 Auf-rufe. Dieses Verhalten wurde bei Palo plausibel damit erklärt, dass in bisher lee-re Basiszellen geschrieben wird, für die zunächst neuer Speicher allokiert werdenmuss. Umso überraschender ist es deshalb, dass bei den Operationen 1 und 6 genaudas Gegenteil der Fall und der erste Aufruf im Vergleich mit den Wiederholungenschneller ist.


Abb. 6.10: Performance des OLAP-Servers IBM Cognos TM1 im Planungsszenario

Anders als noch bei der Analyse, bei der sich die Zeiten relativ einheitlich auf dieeinzelnen Abfragen verteilten, verhalten sich die Planung-Operation sehr unein-heitlich. Das ist nochmals ein deutliches Zeichen dafür, dass Analyse und Planungzwei komplett unabhängige Teildisziplinen einer Business-Intelligence-Lösung sind,die auch von Grund auch andere Algorithmen benötigen. Ein Programm, das inder Analyse schnelle Antwortzeiten bieten kann, ist nicht zwangsläufig auch ersteWahl bei der Planung oder für die Integration umfangreicher Datenvolumina. In-wieweit die einzelnen OLAP-Sever im direkten Vergleich in den einzelnen Teilbe-reichen überzeugen konnten, soll nun die Zusammenfassung zeigen soll nun zumAbschluss dieses Kapitels gezeigt werden.

6.4 Zusammenfassung und Bewertung

Nachdem schon produktspezifische Auffälligkeiten angesprochen wurden, kannnun zum Abschluss dieses Kapitels für jede der Teildisziplin – Datenintegration,Analyse und Planung – die direkte Gegenüberstellung der Alternativen erfolgen.

6.4.1 ETL-Prozess

Die Abbildung 6.11 mit den für den ETL-Prozess benötigten Zeiten zeigt die deut-liche Trennung in eine Zwei-Klassen-Gesellschaft, wobei der OLAP-Server Palo in


keiner Weise mit der Konkurrenz mithalten kann. Während Infor selbst 64 Millio-nen Datensätze in knapp über zweieinhalb Stunden lädt, braucht Palo dafür annä-hernd die zehnfache Zeit und bleibt nur knapp unter 24 Stunden. Bei den für Co-gnos gemessenen Zeiten ist zu berücksichtigen, dass im Anschluss an den eigent-lichen Ladevorgang noch serverseitige Optimierung von etwa anderthalb Stunden(bei 64 Millionen Datensätzen) durchgeführt werden, in denen der Xcelerator fürAnalysen nicht zur Verfügung stand (siehe auch Kapitel 6.3.2). Diese nicht genauquantifizierbare Zeit lässt IBM Cognos TM1 deutlich näher an Infor PM 10 rücken,trotzdem kann Cognos die Teildisziplin „Datenintegration“ für sich entscheiden.

Abb. 6.11: Die Performance der OLAP-Server beim ETL-Prozess im direkten Vergleich

Das Abschneiden von Palo beim ETL-Prozess ist nicht nur im direkten Vergleichschlecht, sondern kann bereits ein KO-Kriterium darstellen. Denn „nicht in der La-ge zu sein, die Datenvolumina zu bewältigen ist oft auch eine andere Form vonPerformance-Problem“ [FMB+10, Seite 160]. Unter den gegebenen Rahmenbedin-gungen war es nicht möglich, einen Datenwürfel mit 64 Millionen Datensätzen in-nerhalb einer Nacht komplett neu zu befüllen. Ob das Zeitfenster für inkrementelleLadevorgänge ausreicht hängt von der zu ladenden Datenmenge sowie der Anzahlvorhandener Datensätze ab. Der Hauptgrund für das schlechte Lade-Verhalten istsicherlich, dass nach jedem Datenpaket (10 000 Datensätze) eine serverseitige Op-timierung durchgeführt wird. Diese ist allerdings wenig sinnvoll wenn bereits be-kannt ist, dass noch weitere Daten folgen werden. Seltenere Optimierungen oderauch nur ein einziger Optimierungslauf nach Abschluss des ETL-Prozesses – wiebei IBM Cognos TM1 – sollten spürbare Performance-Verbesserungen ermöglichen.


Während die Ladezeit pro 1 Millionen Datensätze in Abhängigkeit von den be-reits vorhandenen Datensätzen bei Palo exponential zunimmt, bietet Infor PM 10mit einer konstant linearen Entwicklung das beste Verhalten. Auch IBM Cognosentwickelte sich lange linear und sogar deutlich schneller als Infor bis der enor-me Speicherhunger den Arbeitsspeicher soweit befüllt hatte, dass Daten auf dieFestplatte ausgelagert werden mussten. Die Auslagerung der Daten hatte einenPerformance-Einbruch zur Folge. Schlussendlich ist Infor PM 10 zwar nur der zweit-schnellste Server in der Datenintegration, bietet aber die berechenbarste Entwick-lung und schafft es auch problemlos, einen Datenwürfel der im Test gegebenenKomplexität mit 64 Millionen Datensätzen innerhalb einer Nacht zu befüllen.

6.4.2 Umsatzanalyse

Ebenso wie schon der direkte Vergleich der drei OLAP-Server beim ETL-Prozess,zeigen sich in Abbildung 6.12 auch bei der Umsatzanalyse erhebliche Unterschiedezwischen den OLAP-Servern.

Abb. 6.12: Die Performance der OLAP-Server in der Analyse im direkten Vergleich

Die Schaubilder 6.11 und 6.12 gleichen sich auf den ersten Blick, allerdings habenPalo und IBM Cognos die Positionen getauscht. Es scheint damit eine Wechselwir-kung zwischen der Dauer der Datenintegration und der Dauer der Analysen zu


bestehen. Je mehr Aufwand in der Optimierung während des ETL-Prozesses oderim Anschluss an diesen steckt, desto schneller sind später die Analysen. Palo schafftes dabei auch ohne GPU-Unterstützung, die beiden anderen OLAP-Server deutlichzu unterbieten. Bei kleinen Datenmengen sind die Unterschiede zwischen Palo undInfor PM 10 noch gering, bei 64 Millionen Datensätzen ist Palo schließlich knappdoppelt so schnell. Im direkten Vergleich mit IBM Cognos TM1 ist Palo bei der ma-ximalen Datenmenge fast fünf Mal so schnell, nachdem die Geschwindigkeit beieiner Millionen Datensätzen sogar um den Faktor 9 besser war.

Die schlechte Performance von IBM Cognos TM1 überrascht ein wenig zumalIBM Cognos im BI Survey 9 mit einer durchschnittlichen Abfragezeit von 4,1 msvor Infor mit 4,6 ms (vgl. [FMB+10, Seite 166]) liegt. Palo bietet in dieser Kate-gorie mit 3,4 ms im Übrigen das beste Resultat aller Produkte. Allerdings lassensich die Messergebnisse dieser Arbeit nicht mit den Erkenntnissen aus der BARC-Studie vergleichen, da darin „naturgemäß subjektive Urteile der Anwender überdie von ihnen eingesetzten Software-Werkzeuge“ [FM10] zusammengefasst wer-den. Eine „durchschnittliche“ Abfrage ist für Cognos-Anwender garantiert von an-derer Komplexität als für einen Benutzer von Infor PM 10 oder Palo.

Ein Grund für die schlechte Performance ist sicherlich in der Komplexität vonsuchen. IBM Cognos benötigt bereits für die Bereitstellung eines gecachten Ergeb-nisses – unabhängig von Abfrage und Datenmenge – konstant ca. 675 ms. In dieserZeit lassen sich mit Infor PM 10 und Palo bereits alle fünf Abfragen auf 1 MillionenDatensätzen ausführen. Für IBM Cognos bleibt bei der Analyse nur der letzte Platzwährend Palo auch ohne GPU-Unterstützung diesen Teilbereich für sich entschei-den und damit das Ergebnis aus dem BI Survey 9 bestätigen kann.

Bei der Analyse der Messergebnisse fällt auf, dass das Verhältnis der einzelnenAbfragen zueinander sehr unterschiedlich ist (siehe Tabelle 6.12). Während bei Pa-lo und Infor PM 10 die Abfrage 1 mit den meisten involvierten Basiszellen erwar-tungsgemäß deutlich länger dauert als die Abfragen 2 bis 5, ist dieser Unterschiedbei IBM Cognos TM1 sichtbar geringer. Überhaupt liegen bei Cognos die für dieeinzelnen Abfrage benötigten Zeiten trotz immer weniger betroffener Basiszellenviel dichter beieinander. Diese Unterschiede legen die Schlussfolgerung nahe, dass


Palo Palo 4 GPUs Infor PM 10 Cognos TM1

abs. [ms] rel. [%] abs. [ms] rel. [%] abs. [ms] rel. [%] abs. [ms] rel. [%]

Abfrage 1 12 344 68,09 97 27,21 19 578 50,80 21 653 23,97

Abfrage 2 1 250 6,87 66 18,58 6 593 17,11 18 999 21,03

Abfrage 3 3 806 20,98 68 19,20 5 457 14,16 17 181 10,02

Abfrage 4 409 2,26 62 17,46 2 745 7,12 16 179 19,02

Abfrage 5 326 1,80 62 17,54 4 163 10,80 16 330 18,08

Summe 18 130 100,00 356 100,00 38 536 100,00 90 342 100,00

Tabelle 6.12: Relativer Anteil der einzelnen Abfragen bei 64 Mio. Datensätzen

die Anbieter unterschiedliche Ansätze zur Datenorganisation und -speicherung imArbeitsspeicher verfolgen. Eine Art Best-Practise-Implementierung scheint nicht zuexistieren.

GPU-Technik als nächster Evolutionssprung in der Business Intelligence?

Die beeindruckenden Messergebnisse von Palos GPU-Version sind ein wenig au-ßer Konkurrenz zu sehen. Es zeigt sich aber, wie mit der radikalen Verlagerungder Berechnungen von der CPU auf die GPUs für den Moment konkurrenzlosePerformance-Ergebnisse erzielt werden. Daraus lässt sich schlussfolgern, dass sichdie vielen Teilschritte bei der Berechnung des Ergebnisses einer OLAP-Abfrage sehrgut parallelisieren lassen. Der gemessene Performance-Unterschied zwischen Palomit und ohne GPUs hängt sehr stark mit dem Verhältnis der GPUs zum Prozessorzusammen. Eine stärkere CPU als der verbaute Quad-Core-Prozessor AMD Phe-nom II X4 920 hätte hier merklichen Einfluss gehabt.

Nachdem die Daten durch die In-Memory-Technologie von der Festplatte in denArbeitsspeicher verlagert wurden könnte die GPU-Technik nun den nächsten Evo-lutionssprung in der Business Intelligence darstellen. Außerhalb des BI-Bereichswerden GPUs hauptsächlich für Simulationen bereits in Forschung und Medizinsowie im Risikomanagement eingesetzt (vgl. [Cor10]). Mit der Veröffentlichung derGPU-Unterstützung in der Version 3.2 ist Palo nun Vorreiter im BI-Bereich. Aber si-cherlich ist es nur eine Frage der Zeit bis auch andere Anbieter nachziehen.


6.4.3 Personalplanung

Die Planung zeigte erstmalig im Rahmen dieses Benchmarks, dass sich die Rangfol-ge der OLAP-Server in Abhängigkeit von der Datenmenge auch ändern kann. Wiein der Abbildung 6.13 ersichtlich wird, ist Palo bei der Planung fast immer schnel-ler als IBM Cognos TM1. Erst bei der Datenmenge von 25,6 Millionen Datensätzenändert sich dies und Cognos kann eine bessere Performance erzielen.

Abb. 6.13: Die Performance der OLAP-Server bei der Planung im direkten Vergleich

Die Einordnung von Infor PM 10 ist ein wenig schwierig, da es ab der Daten-menge von 6,4 Millionen Datensätzen aufgrund eines Programmfehlers nicht mehrmöglich war, die 5. Planungsoperation auszuführen (siehe auch Kapitel 6.2.3). Bisdahin bot Infor die beste Performance und unterbot Palo um 31 % (bei 0,8 Mio.Datensätzen), 35 % (1,6 Mio. Datensätze) respektive 42 % (3,2 Mio. Datensätze).Die Frage, ob auch Infor ohne den Programmfehler bei der maximal getesteten Da-tenmenge einen ähnlichen Performance-Einbruch wie Palo erlitten hätte, muss un-beantwortet bleiben. Unter leichtem Vorbehalt kann davon ausgegangen werden,dass Infor ohne dieses Problem den Teilbereich der Planung für sich entschiedenhätte. Dies nützt allerdings einem Anwender wenig, der auf die fehlerhafte Funk-tion „Absolute Verteilung 2“ zwingend angewiesen ist.

Auch bei der Planung zeigte sich, dass die einzelnen Operationen je nach OLAP-Server sehr unterschiedlichen Anteil an der Gesamtzeit haben. Die Hersteller schei-nen hier gleichermaßen unterschiedliche Wege hinsichtlich der Implementierung


zu gehen. Da nur bis zu einer Datenmenge von 3,2 Millionen Datensätzen für jedenOLAP-Server alle Planungsoperationen ohne Probleme ausgeführt werden konn-ten, zeigt die Tabelle 6.13 die relativen Anteile bei dieser Datenmenge.

Palo Infor PM 10 IBM Cognos TM1

abs. [ms] rel. [%] abs. [ms] rel. [%] abs. [ms] rel. [%]

Operation 1 4 802 12,19 434 1,89 6 900 3,08

Operation 2 21 0,05 122 0,53 4 700 2,10

Operation 3 297 0,75 1 398 6,11 16 800 7,50

Operation 4 177 0,45 260 1,14 1 800 0,80

Operation 5 1 259 3,20 17 411 76,03 186 900 83,47

Operation 6 32 834 83,36 3 275 14,30 19 900 3,04

Summe 39 390 100,00 22 901 100,00 523 700 100,00

Tabelle 6.13: Relativer Anteil der einzelnen Operationen bei 3,2 Mio. Datensätzen

Zu beachten ist dabei aber, dass lediglich Palo alle sechs Planungsoperationenohne Nebenrechnung ausführen konnte. Infor PM 10 und IBM Cognos TM1 bie-ten zwar einen grafischen Planungsdialog, der die Planung für den Benutzer einwenig intuitiver macht, allerdings mussten hier immer wieder Zwischenergebnis-se manuell berechnet werden. Der Aufwand hierfür spiegelt sich in den absolutenZahlen nicht wider. Auch das mag einer der Gründe für die in Tabelle 6.13 sichtba-ren teilweise gravierenden Unterschiede sein. Lediglich die Planungsoperationen 2– Verringerung aller involvierten Basiselemente um 10 Prozentpunkte – und 4 – Er-höhung jeder Basiszelle um einen absoluten Wert – waren bei allen OLAP-Servernsehr schnell durchführbar und vor allem auch deutlich schneller als Kopieropera-tionen.

Bei Kopieroperationen stellt sich immer die Frage, ob die zu beschreibende Ba-siszelle bereits existiert und überschrieben werden muss oder ob sie noch nichtexistiert und vor dem Schreibvorgang zunächst Speicher allokiert werden muss.Während Palo bei den Planungsoperationen 1 und 6 für den jeweils ersten Schreib-vorgang aufgrund der Speicherallokation immer extrem viel länger brauchte als beiden folgenden Aufrufen (siehe Anhang B.1.2), zeigten Infor PM 10 (Anhang B.2.2)


und IBM Cognos TM1 (Anhang B.3.2) hier genau das umgekehrte Verhalten: Dererste Aufruf wird jeweils schneller durchgeführt als die folgenden neun. Anschei-nend erkennen beide OLAP-Server in diesem Fall, dass noch keiner der zu schrei-benden Zellen vorhanden ist und somit der gesamte Speicherbereich auf einmalallokiert und schließlich auch komplett kopiert werden kann. Eine bessere Perfor-mance in diesen beiden Operationen hätte Palo vielleicht auch den letzten Platz(bei 64 Millionen Datensätzen) in der Teildisziplin „Planung“ erspart.

6.4.4 Drei Teilbereiche, drei OLAP-Server, drei

unterschiedliche Gewinner

Jeder der drei OLAP-Server konnte einen der drei Teilbereiche für sich entscheiden.Während IBM Cognos TM1 die schnellste Datenintegration ermöglichte, wusstePalo in der Analyse zu überzeugen während Infor PM 10 in der Planung die Nasevorne hatte.

Es gibt demnach nicht den einen besten OLAP-Server, je nach Schwerpunkt undAnforderungen kann aber eine Empfehlung ausgesprochen werden. Die Grund-satzentscheidung aus Kapitel 3.3, die Teilbereiche Datenintegration, Analyse undPlanung im Rahmen des Benchmarks zu trennen und separat zu betrachten, hatsich damit als richtig und wichtig erwiesen. Eine Vermischung der Resultate hät-te die jeweiligen Stärken und Schwächen ausgeglichen und letztlich ein deutlichweniger brauchbares Ergebnis zur Folge gehabt. So aber sind die Ergebnisse ein-deutig.

Kapitel 7

Fazit

Performance und Skalierbarkeit sind nicht nur nachweislich die größten Problemein Business-Intelligence-Projekten, sondern sie sind auch schon in ihrer Messungproblematisch, wie die vorangegangenen Seiten gezeigt haben. Mangelnde Perfor-mance kann alleiniger Grund für das Scheitern von BI-Projekten sein, auch wenn esmit der Wartbarkeit, der Sicherheit sowie der Verfügbarkeit und nicht zuletzt denKosten für Hardware, Lizenzen und Support noch viele weitere Kriterien bei derAuswahl eines OLAP-Servers gibt. Unternehmen sollten im Vorfeld einer Investi-tionsentscheidung keine Kosten und Mühen scheuen um sich bestmöglich mit derbenötigten sowie der zu erwartenden Performance zu beschäftigen. Auch wennsich die Performance nur annäherungsweise bestimmen lässt, so lässt sich das Ri-siko böser Überraschungen im späteren Betrieb zumindest ein wenig reduzieren.

Diese Master-Thesis versuchte die Performance von In-Memory OLAP-Systemenzu vergleichen. Aber trotz der Reduktion auf eine Hardware-Konfiguration unddie Betrachtung von nur drei OLAP-Servern in zwei unterschiedlichen Datenmo-dellen gibt es bei der Betrachtung der Ergebnisse bereits leichte Einschränkungenzu beachten. Zu unterschiedlich waren die einzelnen Programme in ihrer Architek-tur sowie den Anforderungen und es bedurfte an einigen Stellen Workarounds,um überhaupt vergleichbare Zeiten für Datenintegration, Analyse und Planungzu erhalten. Die Ergebnisse geben erste Hinweise auf die jeweiligen Stärken undSchwächen, trotzdem sollte auf einen Proof of Concept, also den Test in der eige-nen IT-Umgebung mit Daten und Datenmengen aus dem Live-Betrieb, nicht ver-zichtet werden. Hundertprozentige Sicherheit, sich für das „richtige“ System zuentscheiden, wird es aber auch dann nicht geben. Dazu ist der Datenbankmarkt zuschnelllebig und seine Entwicklung zu dynamisch.

92

Kapitel 7 Fazit 93

Für den Moment stellt die In-Memory-Technologie in Kombination mit multidi-mensionaler Speicherung sicherlich eine sehr gute Wahl dar und kann in PunktoPerformance Datenbanksysteme, welche die Daten noch auf Festplatten speichern,hinter sich lassen. Nichts desto trotz haben auch In-Memory-Systeme ihre Schwä-chen wie etwa der Umgang mit sehr großen Datenmengen oder auch dünn besie-delte Adressräume. Der kontinuierliche Optimierungsprozess wird weiter gehenund so experimentieren erste Hersteller bereits mit der Nutzung des „Prozessor-Cache für die Speicherung von Zwischenergebnissen in komplexen analytischenBerechnungen“ [Gro10, Seite 19] und könnten damit in absehbarer Zeit die Performance-Messlatte wieder ein Stück höher legen. Wie gesehen ist der Einsatz von Grafik-Prozessoren an Stelle der traditionellen CPUs gleichermaßen ein überaus inter-essantes Thema für die Zukunft. Zugleich ist auch die multidimensionale Spei-cherung nicht in Stein gemeißelt und muss sich mit spaltenorientierten, objektre-lationalen oder assoziativen Speicherformen messen (vgl. [Gro10]). Und nicht zu-letzt könnte der Cloud-Computing-Hype fundamentale Auswirkungen auf die BI-Branche haben und die benötigte Rechenleistung und Performance in Zukunft ausder symbolischen „Cloud“ kommen.

Stetiger Wandel sowie technologische Neuerungen und Innovationen werdenden BI-Bereich auch weiterhin beschäftigen. Business Intelligence ist und bleibt einkontinuierlicher Prozess und die sprichwörtliche eierlegende Wollmilchsau wirdes nie geben. Keine BI-Lösung und kein OLAP-System wird jemals so perfekt undfrei von Schwächen sein, dass auf konzeptionelle Arbeit verzichtet werden kann.Nur wenn die Ziele klar definiert sind und sich daraus die Anforderungen ein-deutig erschließen, kann die Suche nach dem für den Moment geeignesten Systemerfolgreich sein. Auch im Hinblick auf die Performance, welche weiterhin eines dergrößten Probleme in BI-Projekten bleiben wird.

Anhang A

Statistiken der Kundenanwendungen

A.1 Kunde 1 aus Kapitel 4.1.1

Dimension AnzahlElemente

Aggrega-tionsstufen

1 Artikel 7 684 3

2 Debitor 4 061 4

3 402 4

4 109 2

5 Artikelgruppe 74 2

6 Verkäufer 53 2

7 Kennzahlen 38 10

8 30 3

9 12 2

10 Jahr 8 2

11 5 2

12 3 2

13 3 3

14 3 1

Mittelwert 891,79 3,00

Median 34,00 2,00

Tabelle A.1: Dimensionen

Würfel Dimen-sionen

befüllteZellen

1 a 8 403 744

2 b 12 119 375

Mittelwert 10,00 261 560

Median 10,00 261 560

Tabelle A.2: Datenwürfel

a Vereinfachter Analysewürfel mit achtstatt zwölf Dimensionen.

b Dieser Würfel ist die Datenbasis für diein Kapitel 4.1.1 beschriebenen Analysennach Debitoren und Artikeln.

94

Anhang A Statistiken der Kundenanwendungen 95



Aggrega-tionsstufen

1 272 13

2 Sortiment 160 6

3 Land 123 4

4 Kennzahlen 87 6

5 Jahr 29 1

6 25 2

7 14 1

8 14 1

9 4 2

10 3 1

11 Währung 2 1


Median 25,00 2,00



befüllteZellen

1 a 8 701 195

2 b 8 1 341 579


Median 8,00 0,00


a Datenwürfel für das konzernweite Fi-nanzcontrolling.

b Umsatzanalyse und operative Ergebnis-rechnung.




Aggrega-tionsstufen

1 Wochentage 425 2

2 321 2

3 Banken 254 2

4 94 2

5 90 4

6 71 1

7 61 4

8 54 1

9 Wochen 54 1

10 48 0

11 42 1

12 31 5

13 26 0

14 Geschäftsjahre 25 1

15 24 2

16 Kennzahlen 22 2

17 Währung 21 1

18 14 3

19 8 1

20 5 1

21 3 0

22 3 0

23 3 0


Median 31,00 1,00



befüllteZellen

1 a 8 10


Median 8,00 10,00


a Datenwürfel für das Kreditcontrolling.Genauere Angaben zur Anzahl der be-füllten Zellen waren leider nicht zu er-halten.




Aggrega-tionsstufen

1 Artikel 433 3

2 326 1

3 Filiale 306 4

4 166 1

5 157 1

6 138 2

7 63 31

8 54 2

9 46 12

10 Warengruppe 46 2

11 Kennzahlen 1 a 27 1

12 Kennzahlen 2 b 12 0

13 11 0

14 Kennzahlen 3 c 7 0

15 Jahr 7 1

16 5 1

17 4 0

18 3 1

19 3 0

20 3 0


Median 36,50 1,00


a für Warenstatistik und Tagesauswertungenb für das Personalwesenc für die Kassenstatistik


befüllteZellen

1 a 9 7 266 945

2 b 7 1 020 471

3 6 169 200

4 7 33 939

5 7 29 896

6 c 6 21 701

7 6 7 053

8 7 2 648

9 2 540

10 3 67

11 7 10

Mittelwert 6,09 777 497,00

Median 7,00 21 7017,00


a Primäre Warenstatistik.b Tagesauswertung das Umsatzzahlen.c Datenwürfel für die Personalkos-

ten(planung).




Aggrega-tionsstufen

1 Kunden 90 3

2 18 1

3 Kennzahlen 17 3

3 Projektmanager 16 1

5 8 1

6 5 0

7 Jahre 3 0

8 Währung 2 0


Median 12,00 1,00



befüllteZellen

1 a 6 34


Median 6,00 34,00


a Datenwürfel für das Debitoren-Controlling. Genauere Angaben zurAnzahl der befüllten Zellen warenleider nicht zu erhalten.




Aggrega-tionsstufen

1 2 124 2

2 Datum 1 156 3

3 113 3

4 62 2

5 53 2

6 51 1

7 Ansprechpartner 26 2

8 Kategorie 25 3

9 24 1

10 17 0

11 Kennzahlen 16 0

12 10 1

13 10 0

14 9 0

15 7 0

16 7 1

17 Tätigkeit 5 1

18 5 0

19 4 1


Median 17,00 1,00



befüllteZellen

1 a 5 1 716

2 5 828

3 2 96

4 b 2 54

5 3 47

6 c 2 47

7 d 2 33

8 3 27

9 2 33


Median 2,44 50,50


a Leistungsnachweis über alle Projektehinweg.

b Verwaltung des Kundenstatus.c Übersicht über die Projekte.d Zuordnung von Mitarbeitern zu Kun-

den und Projekten.




Aggrega-tionsstufen

1 Arbeitnehmer 671 3

2 Produkt 582 2

3 548 1

4 540 1

5 505 8

6 429 8

7 Geschäftseinheit 227 4

8 97 1

9 37 3

10 Kennzahlen 1 34 3

11 33 2

12 29 1


14 18 3

15 18 1

16 16 1


18 10 0

19 9 1

20 Jahr 9 1

21 9 1

22 6 1

24 Tagesart a 4 1


Median 29,00 1,00


a Unterschieden wird zwischen Werktag, Samstagund Sonntag.


befüllteZellen

1 a 9 2 274 453

2 b 7 34 386

3 c 10 26 016

4 d 7 2 980

Mittelwert 7,50 584 459,00

Median 7,00 30 201,00


a Erfolgsrechnungb Projektabrechnung und -planungc Umsatzanalysed Personalanalyse

Anhang B

Ergebnisse der Performancemessung

B.1 Palo OLAP-Server

B.1.1 Umsatzanalyse

1 000 000 befüllte Basiszellen ohne GPU-Unterstützung (in ms)

1 2 3 4 5 6 7 8 9 10 Ø SD

1 267 265 265 267 268 266 265 267 265 265 266 1,15

2 42 41 40 40 40 39 40 40 39 39 40 0,94

3 87 85 84 84 84 84 85 84 84 84 85 0,97

4 24 22 23 22 22 22 22 22 23 23 23 0,71

5 22 20 21 20 20 20 20 20 20 20 20 0,67

Summe über alle fünf Abfragen: 433,3 ms

1 000 000 befüllte Basiszellen mit 4 GPUs (in ms)

1 2 3 4 5 6 7 8 9 10 Ø SD

1 24 25 27 24 24 23 22 22 23 23 24 1,49

2 25 20 21 20 21 20 21 20 21 20 21 1,52

3 22 21 20 20 22 20 24 20 20 20 21 1,37

4 21 17 16 17 15 15 16 17 16 16 17 1,71

5 18 17 15 18 16 15 16 16 15 15 16 1,20


101

Anhang B Ergebnisse der Performancemessung 102


1 2 3 4 5 6 7 8 9 10 Ø SD

1 457 472 468 479 468 469 469 469 468 468 469 5,33

2 63 62 61 62 61 61 62 61 61 61 62 0,71

3 138 133 134 133 133 134 133 138 137 136 135 2,13

4 28 27 27 28 28 27 27 28 28 27 28 0,53

5 28 27 28 28 27 27 28 28 27 27 28 0,67



1 2 3 4 5 6 7 8 9 10 Ø SD

1 30 30 27 31 27 27 26 27 28 28 28 1,66

2 25 24 23 21 23 22 21 23 22 23 23 1,25

3 22 21 23 22 22 23 22 22 23 22 22 0,63

4 21 21 21 22 23 22 21 21 23 22 22 0,82

5 23 23 22 21 22 21 23 22 21 21 22 0,88



1 2 3 4 5 6 7 8 9 10 Ø SD

1 754 751 752 747 751 748 750 698 739 744 743 16,53

2 87 91 85 88 85 89 85 88 85 89 87 2,15

3 203 204 198 203 199 209 199 204 198 203 202 3,50

4 35 35 34 35 34 34 34 34 34 35 34 0,52

5 38 34 34 34 33 33 34 33 33 34 34 1,49

Summe über alle fünf Abfragen: 1 101,0 ms


4 000 000 befüllte Basiszellen mit 4 GPUs

1 2 3 4 5 6 7 8 9 10 Ø SD

1 29 36 31 27 30 29 31 32 32 31 31 2,39

2 26 31 23 26 22 29 28 23 25 26 26 2,85

3 25 29 27 26 26 27 27 23 26 25 26 1,60

4 24 24 25 26 25 25 24 25 23 25 25 0,84

5 23 42 29 26 23 23 25 22 22 24 26 6,05



1 2 3 4 5 6 7 8 9 10 Ø SD

1 1 453 1 416 1 488 1 480 1 486 1 484 1 482 1 481 1 484 1 483 1 473 22,54

2 165 165 163 162 162 165 162 163 162 166 164 1,58

3 398 392 391 396 391 394 392 391 402 391 394 3,77

4 55 54 53 53 53 53 53 53 53 53 53 0,67

5 58 56 54 54 53 53 53 53 53 53 54 1,70



1 2 3 4 5 6 7 8 9 10 Ø SD

1 33 32 33 33 35 33 32 32 32 32 33 0,95

2 26 29 31 28 27 26 28 26 27 29 28 1,64

3 28 29 30 26 29 29 28 28 29 32 29 1,55

4 26 24 25 24 26 25 46 27 25 26 27 6,60

5 26 27 24 27 27 25 33 25 26 24 26 2,59




1 2 3 4 5 6 7 8 9 10 Ø SD

1 2 791 2 815 2 815 2 837 2 820 2 824 2 813 2 819 2 809 2 796 2 814 13,21

2 296 294 293 294 294 293 294 294 293 293 294 0,92

3 778 773 773 773 772 770 772 783 797 781 777 8,16

4 93 91 92 91 92 91 92 91 92 91 92 0,70

5 97 95 96 96 96 96 96 96 96 95 96 0,57



1 2 3 4 5 6 7 8 9 10 Ø SD

1 44 41 44 44 41 44 41 40 43 45 43 1,77

2 32 36 33 32 34 31 32 34 34 41 34 2,88

3 37 36 36 35 42 35 36 35 35 36 36 2,11

4 29 28 29 29 27 29 33 31 29 28 29 1,69

5 32 29 29 29 29 29 29 28 29 28 29 1,10



1 2 3 4 5 6 7 8 9 10 Ø SD

1 6 067 6 093 6 087 6 088 6 049 6 058 6 053 6 047 6 053 6 053 6 065 17,83

2 617 617 619 615 624 614 618 620 616 618 618 2,82

3 1 574 1 555 1 574 1 562 1 597 1 566 1 583 1 564 1 564 1 560 1 570 12,50

4 170 167 183 166 167 166 168 167 172 166 169 5,22

5 186 183 181 182 182 181 191 182 182 182 183 3,08




1 2 3 4 5 6 7 8 9 10 Ø SD

1 53 60 61 59 61 59 59 60 62 83 62 7,87

2 38 43 44 45 42 44 44 42 42 43 43 1,95

3 47 44 44 45 44 43 45 45 45 43 45 1,18

4 37 36 36 37 38 35 43 36 36 36 37 2,26

5 37 37 36 38 36 37 36 37 37 36 37 0,67



1 2 3 4 5 6 7 8 9 10 Ø SD

1 12 314 12 287 12 400 12 289 12 306 12 295 12 327 12 460 12 383 12 292 12 344 58,64

2 1 249 1 244 1 236 1 248 1 248 1 246 1 235 1 251 1 247 1 255 1 134 6,23

3 3 805 3 801 3 788 3 788 3 788 3 3850 3 850 3 786 3 776 3 813 3 805 26,24

4 408 414 402 402 411 412 412 401 420 412 409 6,13

5 321 330 326 326 329 331 321 331 330 317 326 4,96



1 2 3 4 5 6 7 8 9 10 Ø SD

1 98 96 114 95 95 93 94 95 94 94 97 6,20

2 68 62 61 62 63 64 64 88 67 62 66 8,02

3 67 69 67 65 66 86 67 66 65 65 68 6,34

4 66 59 58 67 74 61 60 59 58 59 62 5,26

5 62 60 59 59 59 80 60 60 59 66 62 6,55



B.1.2 Personalplanung

800 000 befüllte Basiszellen (in ms)

1 2 3 4 5 6 7 8 9 10 Ø

1 1 631 595 599 591 599 593 597 596 595 589 699

2 6 6 6 5 5 5 5 5 5 5 5

3 389 32 33 33 33 33 34 33 33 33 69

4 130 31 32 37 32 32 33 31 32 30 42

5 2 551 1 836 51 49 49 50 50 50 50 50 479

6 12 095 4 484 4 460 4 449 4 463 4 470 4 456 4 473 4 512 4 495 5 236

Summe über alle sechs Aktionen: 6 529 ms

1 600 000 befüllte Basiszellen (in ms)

1 2 3 4 5 6 7 8 9 10 Ø

1 8 318 1 259 1 247 1 256 1 251 1 259 1 256 1 252 1 265 1 252 1 155

2 13 12 12 13 13 12 12 12 12 13 12

3 815 67 68 67 73 73 72 70 68 68 70

4 298 68 63 65 62 62 62 62 63 63 144

5 1 318 3 568 199 122 105 97 97 97 115 98 571

6 41 029 9 024 9 015 9 182 9 186 9 056 9 004 9 019 9 008 8 997 12 252



1 2 3 4 5 6 7 8 9 10 Ø

1 26 464 2 484 2 431 2 378 2 378 2 372 2 388 2 383 2 375 2 366 4 802

2 22 22 21 21 21 21 21 21 21 21 21

3 1 708 150 138 138 137 137 137 138 141 142 297

4 558 154 140 131 131 131 131 131 132 133 177

5 2 829 8 062 224 206 205 207 208 228 217 208 1 259

6 168 262 17 767 17 763 18 055 17 761 17 761 17 688 17 901 17 762 17 681 32 834



6 400 000 befüllte Basiszellen (in s)

1 2 3 4 5 6 7 8 9 10 Ø

1 116,9 4 7 4,7 4,7 4,9 4,7 4,7 4,7 4,67 4,4 15,923

2 0,044 0,042 0,041 0,041 0,042 0,041 0,042 0,043 0,042 0,042 0,042

3 3,2 0,3 0,3 0,3 0,3 0,03 0,3 0,3 0,3 0,3 0,601

4 0,6 0,3 0,3 0,3 0,2 0,2 0,2 0,2 0,3 0,3 0,288

5 5,6 16,8 0,4 0,4 0,4 0,4 0,4 0,4 0,4 0,4 2,580

6 702,2 35,9 35,6 35,9 35,7 36,0 35,7 35,9 35,7 35,9 102,456



1 2 3 4 5 6 7 8 9 10 Ø

1 450,0 7,4 7,4 7,3 7,3 7,5 7,5 7,4 7,4 7,3 52,656

2 0,087 0,086 0,083 0,084 0,083 0,083 0,087 0,086 0,083 0,084 0,085

3 8,0 0,7 0,6 0,7 0,7 0,7 0,7 0,7 0,7 0,7 1,405

4 2,9 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,6 0,807

5 49,9 38,2 0,9 0,9 0,9 0,9 0,9 0,9 0,9 0,9 9,526

6 3 328,8 71,2 71,4 71,2 71,4 71,4 71,3 71,0 71,1 70,9 396,963



1 2 3 4 5 6 7 8 9 10 Ø

1 3 097,6 24,5 24,8 24,5 24,5 24,5 24,2 24,2 24,8 24,0 331,657

2 0,251 0,197 0,197 0,200 0,196 0,197 0,198 0,198 0,198 0,201 0,203

3 14,2 1,2 1,2 1,2 1,2 1,2 1,2 1,2 1,3 1,2 2,519

4 4,7 1,2 1,2 1,2 1,2 1,2 1,2 1,2 1,2 1,2 1,549

5 53,0 135,5 1,8 1,8 1,8 1,8 1,8 1,8 1,8 1,8 20,288

6 19 705,0 151,3 149,6 151,2 149,7 150,3 149,6 150,4 150,0 150,4 2 105,745

Summe über die Aktionen 1 bis 4 und 6: 2 461 961 ms


B.2 Infor PM 10

B.2.1 Umsatzanalyse


1 2 3 4 5 6 7 8 9 10 Ø SD

1 267 265 265 267 268 266 265 267 265 265 266 1,15

2 42 41 40 40 40 39 40 40 39 39 40 0,94

3 87 85 84 84 84 84 85 84 84 84 85 0,97

4 24 22 23 22 22 22 22 22 23 23 23 0,71

5 22 20 21 20 20 20 20 20 20 20 20 0,67

Summe über alle fünf Abfragen: 433 ms


1 2 3 4 5 6 7 8 9 10 Ø SD

1 496 517 513 518 479 457 502 464 508 498 495 21,67

2 206 169 187 189 188 163 187 188 187 185 185 11,68

3 158 148 148 148 146 136 148 148 134 149 146 6,80

4 83 83 83 83 83 83 83 82 82 83 83 0,42

5 123 123 125 108 124 125 125 124 125 125 123 5,23

Summe über alle fünf Abfragen: 1 032 ms


1 2 3 4 5 6 7 8 9 10 Ø SD

1 1 012 1 113 971 1 022 1 076 999 1 059 973 1 008 1 032 1 027 45,08

2 360 391 390 394 394 391 391 340 400 341 379 23,02

3 291 296 285 311 311 306 279 276 311 315 298 14,63

4 175 170 169 148 169 170 170 168 169 171 168 7,25

5 248 261 260 260 258 260 260 262 259 264 259 4,26




1 2 3 4 5 6 7 8 9 10 Ø SD

1 2 097 2 059 2 041 2 044 2 022 2 078 2 078 2 110 2 061 2 009 2 060 31,94

2 794 721 786 753 770 726 786 772 718 807 763 32,22

3 580 565 664 664 585 634 643 658 660 665 632 39,61

4 329 366 340 319 350 350 355 351 362 351 347 14,36

5 488 543 539 479 540 541 535 539 539 539 528 23,74



1 2 3 4 5 6 7 8 9 10 Ø SD

1 4 255 4 472 4 449 4 400 4 318 4 213 4 303 4 212 4 398 4 218 4 324 100,07

2 1 604 1 478 1 516 1 584 1 625 1 486 1 618 1 464 1 488 1 534 1 540 62,53

3 1 350 1 241 1 490 1 367 1 371 1 223 1 202 1 376 1 202 1 202 1 302 101,14

4 675 740 724 617 732 734 610 792 629 723 698 61,42

5 1 022 964 1 091 1 092 1 041 944 1 121 1 127 1 005 1 090 1 050 64,58



1 2 3 4 5 6 7 8 9 10 Ø SD

1 9 226 9 012 9 052 9 219 9 082 9 153 9 291 8 926 9 196 9 016 9 117 117,03

2 3 263 3 128 3 492 3 309 3 281 3 157 3 236 3 195 3 176 3 105 3 234 112,51

3 2 608 2 801 2 643 2 630 2 792 2 516 2 818 2 640 2 734 2 581 2 676 103,47

4 1 515 1 380 1 380 1 432 1 413 1 485 1 343 1 417 1 529 1 287 1 418 76,10

5 2 055 2 400 2 005 2 032 2 027 2 128 1 996 2 020 1 956 2 034 2 065 125,63




1 2 3 4 5 6 7 8 9 10 Ø SD

1 19 996 19 637 19 978 19 449 19 425 19 552 19 378 19 380 19 196 19 785 19 578 268,10

2 6 758 6 522 6 741 6 785 6 565 6 425 6 603 6 511 6 476 6 544 6 593 126,03

3 5 532 5 460 5 411 5 504 5 361 5 469 5 403 5 464 5 669 5 300 5 457 103,47

4 2 859 2 938 2 627 2 772 2 830 2 639 2 667 2 717 2 759 2 641 2 745 106,06

5 4 125 4 007 4 167 4 006 4 029 4 290 4 257 4 227 3 995 4 522 4 163 167,98




800 000 befüllte Basiszellen (in ms)

1 2 3 4 5 6 7 8 9 10 Ø

1 102 121 119 116 117 117 116 116 119 121 116

2 35 30 30 30 30 29 30 30 30 30 30

3 354 343 357 341 352 349 345 340 351 348 348

4 41 36 36 35 34 35 37 34 34 34 36

5 6 612 3 976 3 965 3 979 2 885 2 842 2 851 2 845 2 847 2 987 3 570

6 316 401 401 407 401 402 406 402 403 405 394

Summe über die alle sechs Aktionen: 4 495 ms


1 2 3 4 5 6 7 8 9 10 Ø

1 181 227 226 232 231 228 227 230 231 231 224

2 225 55 50 50 51 51 50 49 50 49 68

3 744 638 640 636 638 638 641 638 646 638 650

4 95 76 83 78 79 76 79 77 77 76 80

5 14 959 7 021 6 976 6 960 6 953 7 008 6 925 6 999 7 016 7 007 7 782

6 808 1 044 1 046 1 041 1 049 1 045 1 039 1 050 1 048 1 047 1 022



1 2 3 4 5 6 7 8 9 10 Ø

1 334 443 448 446 443 448 445 445 448 439 434

2 125 127 121 124 121 118 120 121 124 121 122

3 2 031 1 320 1 345 1 324 1 338 1 336 1 329 1 321 1 317 1 322 1 398

4 267 262 258 254 258 262 259 258 260 262 260

5 44 644 14 474 14 474 14 327 14 402 14 383 14 377 14 290 14 347 14 396 17 411

6 2 545 3 338 3 347 3 385 3 337 3 351 3 378 3 362 3 367 3 338 3 275




1 2 3 4 5 6 7 8 9 10 Ø

1 745 1 017 1 025 1 016 1 017 1 017 1 024 1 018 1 017 1 024 991

2 138 126 126 125 129 125 124 128 127 125 127

3 6 002 2 321 2 330 2 325 2 325 2 307 2 324 2 327 2 329 2 322 2 691

4 435 435 430 432 427 431 434 434 426 429 431

5 — — — — — — — — — — —

6 8 179 10 428 10 524 10 537 10 482 10 479 10 502 10 486 10 476 10 466 10 256

Summe über die Aktionen 1 bis 4 und 6: 14 497 ms


1 2 3 4 5 6 7 8 9 10 Ø

1 1 906 2 631 2 662 2 642 2 693 2 629 2 719 2 664 2 672 2 689 2 591

2 287 260 265 279 273 265 273 273 273 271 287

3 18 501 4 823 4 759 4 782 4 785 4 862 4 779 4 787 4 746 4 775 6 160

4 919 893 936 882 933 926 919 911 935 895 915

5 — — — — — — — — — — —

6 30 368 38 150 38 158 38 150 38 177 38 079 38 174 38 131 38 132 38 124 37 364



1 2 3 4 5 6 7 8 9 10 Ø

1 4 574 6 629 6 442 6 466 6 432 6 480 6 535 6 506 6 522 6 551 6 314

2 468 465 463 455 461 463 471 457 470 459 463

3 47 293 9 476 9 450 9 333 9 385 9 417 9 464 9 389 9 345 9 415 13 197

4 1 795 1 776 1 788 1 781 1 790 1 781 1 818 1 797 1 803 1 810 1 794

5 — — — — — — — — — — —

6 112 947 142 698 142 774 143 151 142 437 142 786 142 704 142 739 143 451 142 691 139 938



B.3 Cognos TM 1

B.3.1 Umsatzanalyse


1 2 3 4 5 6 7 8 9 10 Ø SD

1 641 640 734 641 609 625 672 640 625 641 649 34,66

2 1 160 1 160 656 1 160 640 1 140 1 170 1 140 1 160 1 160 1 055 214,53

3 672 656 657 1 170 641 641 1 190 657 671 641 641 221,91

4 867 657 640 672 640 656 672 672 672 657 657 15,19

5 719 656 641 781 812 640 672 656 688 671 671 59,42



1 2 3 4 5 6 7 8 9 10 Ø SD

1 1 050 1 000 1 020 1 020 1 020 1 020 1 020 984 1 050 1 050 1 023 21,81

2 1 160 1 170 1 140 1 140 1 160 1 160 1 160 1 170 1 160 1 170 1 059 11,01

3 1 160 1 140 1 140 1 140 1 160 1 140 1 140 1 160 1 160 1 170 1 151 11,97

4 1 160 1 140 1 140 1 160 1 160 1 160 1 140 1 170 1 160 1 250 1 164 32,04

5 1 170 1 140 1 160 1 160 1 160 1 140 1 140 1 160 1 160 1 170 1 156 11,74



1 2 3 4 5 6 7 8 9 10 Ø SD

1 2 110 2 090 2 200 2 080 2 130 2 110 2 170 2 250 2 170 2 200 2 151 55,67

2 2 170 2 170 2 170 2 140 2 170 2 140 2 200 2 170 2 160 2 190 2 168 18,74

3 1 690 1 690 1 670 1 660 1 690 1 660 1 670 1 690 1 660 1 670 1 675 13,54

4 1 670 1 670 1 670 1 640 1 690 1 640 1 690 1 670 1 660 1 690 1 669 18,53

5 1 200 1 170 1 170 1 140 1 190 1 160 1 170 1 170 1 160 1 170 1 170 16,33




1 2 3 4 5 6 7 8 9 10 Ø SD

1 4 420 4 340 4 670 4 590 4 660 4 780 5 770 4 420 4 300 4 840 4 679 425,24

2 4 170 4 160 4 190 4 160 4 190 4 190 4 200 4 140 4 170 4 190 4 176 18,97

3 3 670 3 660 3 740 3 670 3 670 3 690 3 690 3 140 3 670 3 690 3 629 173,30

4 3 170 3 160 3 670 3 660 3 670 3 690 3 690 3 140 3 670 3 690 3 521 251,73

5 2 160 2 160 2 170 2 170 2 170 2 190 2 170 2 140 2 170 2 170 2 167 12,52



1 2 3 4 5 6 7 8 9 10 Ø SD

1 8 580 7 720 7 560 7 700 7 800 7 770 7 860 8 000 7 720 7 500 7 821 301,64

2 7 190 7 200 7 200 7 200 7 200 7 200 7 190 7 200 7 190 6 660 7 143 169,77

3 6 690 6 690 6 690 6 700 6 720 6 670 6 690 6 690 6 690 6 190 6 642 159,29

4 6 670 6 690 6 170 6 700 6 690 6 170 6 190 6 690 6 670 6 610 6 480 264,91

5 4 200 4 190 4 200 4 190 4 190 4 170 4 190 4 200 4 170 4 170 4 187 12,52



1 2 3 4 5 6 7 8 9 10 Ø SD

1 12 660 12 250 12 250 12 470 12 300 12 130 12 220 12 440 12 770 12 410 12 390 202,87

2 11 300 11 200 11 250 11 230 11 160 10 700 10 660 11 250 11 220 11 170 11 114 232,48

3 10 220 10 170 10 690 10 720 10 220 9 660 9 660 10 670 10 230 10 220 10 246 379,54

4 10 170 9 690 10 190 10 240 9 690 9 200 9 690 10 240 10 220 9 740 9 907 355,59

5 7 280 7 160 7 230 7 230 7 170 6 690 7 160 7 190 7 190 7 160 7 146 165,01




1 2 3 4 5 6 7 8 9 10 Ø SD

1 21 520 21 700 21 490 21 160 22 000 21 660 22 110 21 480 21 770 21 640 21 653 271,34

2 18 690 19 200 18 700 18 170 19 200 19 190 19 220 19 700 19 220 18 700 18 999 430,49

3 17 190 17 190 17 170 16 660 17 190 17 190 17 190 17 170 17 690 17 170 17 181 242,97

4 16 190 16 170 16 190 15 660 16 170 16 690 16 190 16 170 16 190 16 170 16 179 242,97

5 16 090 16 610 16 060 16 030 16 610 16 580 16 610 16 080 16 580 16 050 16 330 283,16




800 000 befüllte Basiszellen (in s)

1 2 3 4 5 6 7 8 9 10 Ø

1 1 3 3 3 3 2 3 3 3 3 2,7

2 5 4 5 5 5 5 5 5 5 5 4,9

3 7 5 4 4 4 4 4 4 4 4 4,4

4 1 0 1 0 1 0 1 0 1 0 0,5

5 90 46 46 47 46 46 47 46 46 46 50,6

6 6 4 4 4 4 4 4 4 4 4 4,2



1 2 3 4 5 6 7 8 9 10 Ø

1 3 5 5 5 6 5 5 5 6 5 5,0

2 1 2 1 2 1 2 2 1 2 2 1,6

3 16 8 8 8 8 8 8 8 8 8 8,8

4 1 0 1 0 1 0 1 0 1 0 0,5

5 183 94 94 93 93 94 94 93 94 93 102,5

6 3 3 3 2 3 2 3 3 2 3 2,7



1 2 3 4 5 6 7 8 9 10 Ø

1 5 7 7 7 8 7 7 7 7 7 6,9

2 5 4 5 5 4 5 4 4 5 4 4,5

3 18 17 16 17 17 16 17 17 16 71 16,8

4 2 2 2 1 2 2 1 2 2 2 1,8

5 197 186 185 186 186 186 186 185 186 186 186,9

6 5 7 7 7 7 7 7 7 7 7 6,8




1 2 3 4 5 6 7 8 9 10 Ø

1 11 21 21 21 21 21 21 21 21 21 20

2 15 15 15 15 15 15 15 15 15 15 15

3 66 34 34 34 34 34 34 34 34 34 37,2

4 3 2 3 3 3 2 2 3 3 2 2,6

5 780 390 389 389 389 390 391 390 391 391 429

6 10 21 21 21 21 21 21 21 21 21 19,9



1 2 3 4 5 6 7 8 9 10 Ø

1 19 38 37 37 38 38 38 38 38 38 359

2 29 28 29 29 28 29 29 28 29 29 287

3 130 67 68 67 67 67 67 68 67 67 73,5

4 3 4 4 4 4 4 4 4 4 4 3,9

5 1 505 768 786 787 785 787 786 786 785 785 857,8

6 20 41 40 41 41 41 41 40 41 41 38,7

Summe über alle sechs Aktionen: 1 038 500 ms


1 2 3 4 5 6 7 8 9 10 Ø

1 38 80 80 80 80 80 80 80 80 80 75,8

2 56 56 57 56 56 56 56 56 56 56 56,1

3 263 133 136 132 133 133 133 133 132 133 146,1

4 7 6 7 6 6 7 6 7 6 7 6,6

5 3 137 1 568 1 562 1 566 1 567 1 567 1 567 1 570 1 568 1 569 1 724,3

6 37 80 80 80 80 80 80 80 80 80 75,7


Literaturverzeichnis

BAR09 BARC. BI-Markt trotzt der Krise, wächst 2008 um 6,2 Prozent.http://www.barc.de/de/news/barc-news/article/2009/07/01/

bi-markt-trotzt-der-krise-waechst-2008-um-62-prozent.html,2009. Letzte Abfrage: 13. Juli 2010.

Bec09 Ulrich Beckmann. Öfter mal „out of the cube“ denken. BI-Spektrum,4:42, 2009.

BG09 Andreas Bauer / Holger Günzel. Data-Warehouse-Systeme – Architektur,Entwicklung, Anwendung. dpunkt.verlag, Heidelberg, 3. überarbeiteteund aktualisierte Auflage, 2009.

BHvdD09 Tobias Blickle / Helge Heß / Markus vo den Driesch. Analysieren, über-wachen und steuern. BI-Spektrum, 1:16–19, 2009.

Blo10 Rik Blok. Computing Trends. http://www.zoology.ubc.ca/~rikblok/ComputingTrends/, 2010. Letzte Abfrage: 11. Mai 2010.

com96 computerwoche.de. Fragwürdiger Benchmark-Test für Olap-Server.http://www.computerwoche.de/heftarchiv/1996/19/1106318/, 1996.Letzte Abfrage: 21. April 2010.

Com06 Computerwoche. Datenanalyse: Arbeitsspeicher statt Olap. http:

//www.computerwoche.de/heftarchiv/2006/42/1216466/, 2006. Letz-te Abfrage: 10. Mai 2010.

Cor10 NVIDIA Corporation. CUDA in Aktion. http://www.nvidia.de/

object/cuda_in_action_de.html, 2010. Letzte Abfrage: 27. Oktober2010.

118

http://www.barc.de/de/news/barc-news/article/2009/07/01/bi-markt-trotzt-der-krise-waechst-2008-um-62-prozent.html

http://www.barc.de/de/news/barc-news/article/2009/07/01/bi-markt-trotzt-der-krise-waechst-2008-um-62-prozent.html

http://www.zoology.ubc.ca/~rikblok/ComputingTrends/

http://www.zoology.ubc.ca/~rikblok/ComputingTrends/

http://www.computerwoche.de/heftarchiv/1996/19/1106318/



http://www.nvidia.de/object/cuda_in_action_de.html

http://www.nvidia.de/object/cuda_in_action_de.html


Cou97 OLAP Council. OLAP Council Member Companies. http://www.

olapcouncil.org/member/meminfoly.htm, 1997. Letzte Abfrage: 27.Oktober 2010.

Cou98a OLAP Council. Analytical Processing Benchmark-1 (APB-1) Release II.http://www.olapcouncil.org/research/APB1R2_ovw.zip, 1998. LetzteAbfrage: 22. April 2010.

Cou98b OLAP Council. OLAP Council APB-1 OLAP Benchmark Release II.http://www.olapcouncil.org/research/APB1R2_spec.pdf, 1998. Letz-te Abfrage: 21. April 2010.

Cou10 Transaction Processing Performance Council. TPC BENCHMARK™H(Decision Support) Standard Specification Revision 2.11.0. http://www.tpc.org/tpch/spec/tpch2.11.0.pdf, 2010. Letzte Abfrage: 5. Mai 2010.

Fel09 Rudolf Felser. ROI von BI: Worauf Unternehmen achten müs-sen. http://www.computerwelt.at/detailArticle.asp?a=120939&n=

2, 2009. Letzte Abfrage: 11. Mai 2010.

FM10 Barney Finucane / Melanie Mack. Welche Vorteile ergeben sich aus demEinsatz von BI-Software? BARC Guide Business Intelligence 2010/2011, S.8–11, 2010.

FMB+10 Barney Finucane / Melanie Mack / Carsten Bange / Patrick Keller /Steffen Bierkorn. The BI Survey 9. Business Application Research Center,Würzburg, 2010.

GKS09 Peter Gluchovski / Hans-Georg Kemper / Andreas Seufert. Was ist neuan Operatiomal BI? http://www.beyenetwork.de/view/10821, 2009.Letzte Abfrage: 10. Juni 2010.

Gro10 Timm Grosser. Erfolgreiches BI setzt gutes Datenmanagement voraus.BARC Guide Business Intelligence 2010/2011, S. 17–20, 2010.

GTS10 Tom Gansor / Andreas Totok / Steffen Stock. Von der Strategie zum Busi-ness Intelligence Competency Center (BICC). Carl Hanser Verlag, Mün-chen, Wien, 1. Auflage, 2010.

http://www.olapcouncil.org/member/meminfoly.htm

http://www.olapcouncil.org/member/meminfoly.htm

http://www.olapcouncil.org/research/APB1R2_ovw.zip

http://www.olapcouncil.org/research/APB1R2_spec.pdf

http://www.tpc.org/tpch/spec/tpch2.11.0.pdf

http://www.tpc.org/tpch/spec/tpch2.11.0.pdf

http://www.computerwelt.at/detailArticle.asp?a=120939&n=2

http://www.computerwelt.at/detailArticle.asp?a=120939&n=2

http://www.beyenetwork.de/view/10821


HW05 Bernhard Humm / Frank Wietek. Architektur von data warehouses undbusiness intelligencesystemen. Informatik Spektrum, 28(1):3–14, 2005.

iMfpI09 iX Magazin für professionelle Informationstechnik. Öfter mal „out ofthe cube“ denken. iX – Magazin für professionelle Informationstechnik, 8:14,2009.

Jai10 Umesh Jain. In-Memory BI: The Next Frontier? http://www.

softwaremag.com/L.cfm?Doc=1260-4/2010, 2010. Letzte Abfrage: 11.Mai 2010.

Lau08 Georg Lausen. OLAP und Data Minig. http://download.

informatik.uni-freiburg.de/lectures/DB2/2008SS/Slides/01_

00_OLAPundDataMining_4auf1.pdf, 2008. Letzte Abfrage: 27. Mai 2010.

LDKA10 Tobias Lauer / Amitava Datta / Zurab Khadikov / Christoffer Anselm.Exploring Graphics Processing Units as Parallel Coprocessors for Onli-ne Aggregation. Proceedings of the 13th ACM International Workshop onData Warehousing and OLAP (DOLAP 2010), Toronto, Canada, 2010.

LPS10 Kenneth C. Laudon / Jane P.Laudon / Detlef Schoder. Wirtschaftsinfor-matik: Eine Einführung. Pearson Studium, München, 2. Auflage, 2010.

Man08a Klaus Manhart. Grundlagenserie Business Intelligence – BI-Datenmanagement (Teil 1): Datenaufbereitung durch den ETL-Prozess.http://www.tecchannel.de/server/sql/1746250/, 2008. Letzte Abfra-ge: 17. Mai 2010.

Man08b Klaus Manhart. Grundlagenserie Business Intelligence – BI-Methoden(Teil 1): Ad-hoc Analysen mit OLAP. http://www.tecchannel.de/

server/sql/1751285/, 2008. Letzte Abfrage: 17. Mai 2010.

Man08c Klaus Manhart. Grundlagenserie Business Intelligence – Business Intel-ligence (Teil 3): Datenmodellierung ? Relationale und Multidimensiona-le Modelle. http://www.tecchannel.de/server/sql/1744994/, 2008.Letzte Abfrage: 15. Oktober 2008.

http://www.softwaremag.com/L.cfm?Doc=1260-4/2010

http://www.softwaremag.com/L.cfm?Doc=1260-4/2010

http://download.informatik.uni-freiburg.de/lectures/DB2/2008SS/Slides/01_00_OLAPundDataMining_4auf1.pdf



http://www.tecchannel.de/server/sql/1746250/





Mer02 Peter Mertens. Business Intelligence - ein Überblick. http://www.

wi1-mertens.wiso.uni-erlangen.de/whoiswho/me.php, 2002.

Pel10 Thomas Pelkmann. BI trotzt der Krise. http://www.cio.de/subnet/

oracle-data-expert/887743/, 2010. Letzte Abfrage: 8. Juni 2010.

Pen08 Nigel Pendse. What is OLAP? http://www.bi-verdict.com/

fileadmin/FreeAnalyses/fasmi.htm, 2008. Letzte Abfrage: 19. Mai2010.

Püt10 Christiane Pütter. Nur SAP verliert Umsatz. http://www.cio.de/

knowledgecenter/bi/2232458/, 2010. Letzte Abfrage: 9. Juni 2010.

Rec10 Thomas Recke. Datenhaltung in BI-Systemen – Würfeln Sie nochoder wissen Sie schon? http://www.computerwoche.de/mittelstand/

1935269/, 2010. Letzte Abfrage: 13. Juli 2010.

Rit10 Mark Rittman. News on The BI Verdict, and an Interviewwith Nigel Pendse. http://www.rittmanmead.com/2010/01/19/

news-on-the-bi-verdict-and-an-interview-with-nigel-pendse/,2010. Letzte Abfrage: 21. April 2010.

Rog08 Thomas Rogler. Operational Business Intelligence. http:

//www.erpmanager.de/magazin/artikel_1685_operational_

business_intelligence.html, 2008. Letzte Abfrage: 10. Juni 2010.

Sar10 Riem Sarsam. Sechs Thesen zum deutschen BI-Markt. http://

www.computerwoche.de/subnet/oracle-data-expert/2215710/, 2010.Letzte Abfrage: 9. Juni 2010.

Sch06 Holger Schrödl. Business Intelligence mit Microsoft SQL Server 2005 – BI-Projekte erfolgreich umsetzen. Hanser Fachbuchverlag, München, 1. Auf-lage, 2006.

She10 Brett Sheppard. In-Database Analytics Moves from Early Ado-pters to Mainstream Use . http://www.bigdatanews.com/content/

database-analytics-moves-early-adopters-mainstream-use, 2010.Letzte Abfrage: 14. Mai 2010.

http://www.wi1-mertens.wiso.uni-erlangen.de/whoiswho/me.php

http://www.wi1-mertens.wiso.uni-erlangen.de/whoiswho/me.php

http://www.cio.de/subnet/oracle-data-expert/887743/

http://www.cio.de/subnet/oracle-data-expert/887743/

http://www.bi-verdict.com/fileadmin/FreeAnalyses/fasmi.htm

http://www.bi-verdict.com/fileadmin/FreeAnalyses/fasmi.htm

http://www.cio.de/knowledgecenter/bi/2232458/

http://www.cio.de/knowledgecenter/bi/2232458/

http://www.computerwoche.de/mittelstand/1935269/

http://www.computerwoche.de/mittelstand/1935269/

http://www.rittmanmead.com/2010/01/19/news-on-the-bi-verdict-and-an-interview-with-nigel-pendse/

http://www.rittmanmead.com/2010/01/19/news-on-the-bi-verdict-and-an-interview-with-nigel-pendse/

http://www.erpmanager.de/magazin/artikel_1685_operational_business_intelligence.html



http://www.computerwoche.de/subnet/oracle-data-expert/2215710/

http://www.computerwoche.de/subnet/oracle-data-expert/2215710/

http://www.bigdatanews.com/content/database-analytics-moves-early-adopters-mainstream-use

http://www.bigdatanews.com/content/database-analytics-moves-early-adopters-mainstream-use


SM04 Jörg Schumacher / Matthias Meyer. Customer Relationship Managementstrukturiert dargestellt - Prozesse, Systeme, Technologien. Springer-Verlag,Berlin, Heidelberg, New York, 1. Auflage, 2004.

Sto09 Michael Stonebraker. Performance Evaluation and Benchmarking:Transaction Processing Performance Council Technology Conference,TPCTC 2009, Lyon, France. In: Meikel Poess Raghunath Nambiar(Hrsg.): Erfolgsfaktor Innovation, S. 11–17. Springer-Verlag, Berlin, Hei-delberg, 1. Auflage, 2009.

Wik10 Wikipedia. Arbeitsspeicher. http://de.wikipedia.org/wiki/

Arbeitsspeicher, 2010. Letzte Abfrage: 11. Mai 2010.

Zim08 Mark Zimmermann. Business Intelligence (Teil 1): Erster Ein-stieg. http://www.tecchannel.de/server/sql/1738998/business_

intelligence_teil_1_erster_einstieg/index.html, 2008. Letzte Ab-frage: 17. Juni 2010.

Zim09 Mark Zimmermann. Quo vadis Business Intellingence? - Jetzt kommtdie Einbindung von Prozessen. BI-Spektrum, 14:39–40, 2009.

http://de.wikipedia.org/wiki/Arbeitsspeicher

http://de.wikipedia.org/wiki/Arbeitsspeicher

http://www.tecchannel.de/server/sql/1738998/business_intelligence_teil_1_erster_einstieg/index.html

http://www.tecchannel.de/server/sql/1738998/business_intelligence_teil_1_erster_einstieg/index.html

Documents

Entwicklung eines Benchmarks für die Performance von In-Memory