Lade Inhalt...

In-Memory BI Architectures am Beispiel QlikView

Seminararbeit 2013 32 Seiten

Informatik - Software

Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1. Einleitung

2. In-Memory-Business-Intelligence-Systeme
2.1. Architektur von Business-Intelligence-Systemen
2.2. Grundlagen der In-Memory-Technik
2.3. Zeilen- und spaltenorientierte Datenbanken
2.4. Datenkompression mit Data Dictionaries

3. QlikView - Architektur, Technologie, Anwendung
3.1. Komponenten der Architektur
3.2. Verwendete Technologien
3.3. Betriebsmodelle im Vergleich -on-Premise vs. Cloud
3.4. Skalierbarkeit und Parallelität
3.5. Integration externer Quellen

4. Bewertungvon QlikView
4.1. Vorteile
4.2. Nachteile
4.3. Vergleich mit konkurrierenden BI-Tools

5. Schlussbetrachtung

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Referenzarchitektur für Data-Warehouse-Systeme

Abbildung 2: Datenzugriff bei zeilen- bzw. spaltenorientierte Speicherung

Abbildung 3: Vergleich ohne(links) und mit(rechts) Data Dictionary

Abbildung 4: Architektur-Uberblick mit Komponenten und Beziehungen

Abbildung 5: Analyse-Operationen von QlikView (Screenshot)

Abbildung 6: Speichernutzung von QlikView

Abbildung 7: Mögliche Aufteilung der Komponenten im Cloud-Modell

Abbildung 8: Beispiel einer parallelen Ausführung

Abbildung 9: Integrierbare Datenquellen

Abbildung 10: Kosten für Analysen pro Nutzer

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Mit zunehmendem Fortschritt in der Hardware-Technologie entwickeln sich neue Möglichkeiten für Anwendungssysteme, die bis vor einigen Jahren nicht vorstellbar waren. So ist durch die Weiterentwicklung der Speichertechnologie möglich, ganze Datenbanken vollständig im Hauptspeicher zu lagern, statt nur bestimmte Teile, für eine begrenzte Zeit, in einem Puffer zu halten. Es ergibt sich dadurch das Potential, für zunächst in bestimmten Anwendungsszenarien, die Daten nur noch im Hauptspeicher zu halten und nur für Backup und Recovery einen persistenten Speicher zu verwenden. Aufgrund des Geschwindigkeitsvorteil gegenüber den weitverbreiteten Magnetplatten, aber auch moderneren Solid State Disks (SSD), sind Echtzeit­Berechnungen auf viel aktuelleren Daten möglich, als es bisherige Data-Warehouse- Systeme ermöglichen.

Zwar wird es noch einige Jahre dauern, bis auch große Datenbanken mit mehreren Petabyte an Daten, mit vertretbaren Aufwand, in einer In-Memory-DB gespeichert werden können. Doch können spezielle Anwendungen wie Business Intelligence-Tools schon heute größere Datenmengen im Hauptspeicher analysieren. Für viel Aufsehen sorgte dabei in den letzten Jahren vor allem ganze Systeme der großen Software­Anbieter SAP und Oracle. Doch bereits seit Ende der 1990er Jahre wird eine Software entwickelt, die bereits auf Datenauswertungen im Hauptspeicher setzte, als diese nur wenig Kapazität und hohe Kosten hatten.

Diese Arbeit, die im Rahmen der Lehrveranstaltung „Large-Scale Data Analytics" erstellt wurde, betrachtet ein In-Memory-BI-Tool näher - das Produkt QlikView der Firma QlikTech. Das Ziel war dabei, einen Überblick über die In-Memory-Technik und die damit verbundenen Verfahren zu geben, sowie am Beispiel QlikView zu untersuchen, wie diese in die Praxis umgesetzt wurden.

Dazu wird zu Beginn ein Überblick über die Architektur von Business-Intelligence- Systemen gegeben. Weiterhin werden die In-Memory-Technologie selbst, sowie Methoden die mit ihr in Verbindung stehen erläutert. Anschließend wird die Architektur von QlikView, sowie die innerhalb des Anwendungssystem verwendete Verfahren und Methoden erläutert. Zum Abschluss erfolgt eine Bewertung der untersuchten Software und ein kurzer Vergleich mit ähnlichen Produkten, sowie eine Schlussbetrachtung dieser Arbeit.

2. In-Memory-Business-Intelligence-Systeme

Als Business-Intelligence-System wird ein Anwendungssystem verstanden, das zur Entscheidungsunterstützung in Unternehmen verwendet wird. Es besteht aus einer „physischen Datenbank, die eine integrierte Sicht auf beliebige Daten zu Analysezwecken ermöglich"[BG09].

Eine Datenbank wird als In-Memory-Datenbank bzw. als Hauptspeicherdatenbank bezeichnet, wenn sämtliche Datenobjekte im Primärspeicher gehalten werden. Wenn die Daten vollständig im Hauptspeicher liegen, bringt das besondere Vorteile in den Verarbeitungs- und Zugriffszeiten mit sich. Um diese Möglichkeiten ausnutzen zu können, reicht es nicht aus die Daten im RAM statt auf HDDs zu speichern. Vielmehr müssen diverse Änderungen an bisherigen Datenbank-Systemen durchgeführt werden, welche später erläutert werden. Dabei ist zu unterscheiden, in welchem Kontext das System später verwendet werden soll. Eine der Möglichkeiten ist, dass die In-Memory-Datenbank für Analysezwecke genutzt wird. Charakteristisch für diese Form der Anwendung sind viele - häufig sequentielle - Lesezugriffe, in denen die Daten auf Muster untersucht, oder Analysen von Geschäftsdaten erstellt werden. Daneben gibt es transaktionsorientierte Daten-banken, die im Gegensatz dazu, weniger Leseoperationen ausführen und stattdessen wesentlich häufiger Einfüge- und Änderungsoperationen auf Daten ausführen[BG09].

Durch die Kombination der In-Memory-Technik mit einem Business-Intelligence- System, ist es möglich Realtime- bzw. Near-Realtime-Systeme zu erstellen, die dem Anwender Berechnungen, Analysen und Information der aktuellsten Daten liefern. Dies stellt einen großen Vorteil gegenüber herkömmlichen Systemen dar, deren Informationen auf vor längerer Zeit berechneten Aggregaten beruhen.

2.1. Architektur von Business-Intelligence-Systemen

Neben der bereits erwähnten physischen Datenbank, oft auch als Data-Warehouse- System bezeichneten Komponente, besteht ein BI-System aus einer Integrations- und einer Analysekomponente.

Data-Warehouse-System

Im Data-Warehouse-System befinden sich alle Daten, die für den Data-Warehousing- Prozess nötig sind. Wie in Abbildung 1 zu sehen ist, wird zwischen dem Datenbeschaffungs-, dem Auswerte- und einem Managementbereich unterschieden.

Im Managementbereich erfolgt die Steuerung und Überwachung des Data- Warehousing-Prozess und aller beteiligten Komponenten im DWH-System. So wird vom DWH-Manager bspw. die Extraktion der Daten aus den Quellen initiiert. Der Auslöser ist dabei ein bestimmtes Ereignis, z.B. eine Datenänderung, ein abgelaufener Zeitintervall oder eine explizite Datenanforderung. Weiterhin werden in diesem Bereich Metadaten, über den Metadaten-Manger und das zugehörige Repository verwaltet. Das betrifft Informationen über die Datenschemata, Speicherinformationen und Zugriffsrechte, aber auch über Prozesse und Systeme des DWH oder mit diesem verbundener Systeme.

Die Datenbeschaffung ist der erste Schritt des Data-Warehousing-Prozess. Hier werden die Daten aus den Quellsystemen geladen und anschließend transformiert. Das bedeutet, die extrahierten Daten werden an die Bedürfnisse des DWH angepasst. Beispielsweise muss bei Daten aus heterogenen Datenquellen ein gemeinsames Datenschema, sowie u.a. einheitliche Datentypen, Kodierungen und Datumsangaben gefunden werden. Außerdem werden in dieser Phase die Daten konsolidiert. Das bedeutet, statt jeden Datensatz aus den Quellen zu übernehmen, können bestimmte Daten zu Aggregaten zusammengefasst werden. Nach Abschluss der Transformation werden die Daten in den Auswertebereich überführt, was auch Laden genannt wird. Dieser Ablauf wird häufig als ETL-Prozess (Extraktion-Transformation-Laden) zusammengefasst.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Referenzarchitektur für Data-Warehouse-Systeme[BG09]

Im Auswertebereich werden die Daten zunächst in die sogenannte Basisdatenbank überführt. Diese stellt - zumindest theoretisch - „eine integrierte Datenbasis für Analysen dar und hat somit eine zentrale Verteilungsfunktion"[BG09]. Jedoch findet man diese in der Praxis eher selten, da sie zusätzlichen Aufwand an Kosten darstellt. Die für das DWH-System namensgebende Komponente, ist die Data-Warehouse- Datenbank. In ihr sind die für die Analysen notwendigen Daten gespeichert, meist in einem multidimensionalen Datenmodell. Um schnellere Anfragen und höheren Datenschutz zu gewährleisten, werden die Daten in Data Marts gelagert. Diese stellen einen spezifischen Ausschnitt des DWH bereit. Meist wird dabei die Trennung anhand der funktionalen Organisationsstruktur eines Unternehmens vorgenommen. Dadurch erhöht sich allerdings auch die Komplexität der Transformationen, sowie entstehen weitere Redundanzen und Konsistenzprobleme[BG09].

Analyse

Diese Komponente soll die gesammelten Daten in einer geeigneten Weise präsentieren und interaktive Navigations- und Analysemöglichkeiten bieten. Dabei wird zwischen mehreren Komplexitätsstufen, die bei der Auswahl von Analysewerkzeugen beachtet werden müssen, unterschieden. Die einfachste Stufe stellen einfache Abfragen und Berichte dar, in denen nur einfache arithmetische Operationen erfolgen. Etwas komplexer sind OLAP-Analysen, in denen Daten in mehreren Dimensionen dargestellt werden. Damit ist es dem Anwender möglich, in kurzer Zeit zwischen verschiedenen Detail-Stufen und Perspektiven zu wechseln. Ein Beispiel ist die Darstellung des Jahresumsatzes anhand der Dimensionen Zeit, Ort und Produktgruppen in denen sich der Nutzer frei bewegen kann. Die schwierigste Form der Analyse ist das Data Mining. Die Daten werden hier - im Gegensatz zu den anderen Verfahren - auf bisher unbekannte Muster und Zusammenhänge untersucht. Dabei kommen Methoden aus der Statistik und des maschinellen Lernens zum Einsatz, wie Cluster- und Assoziationsanalysen[BG09]. Nicht zu vernachlässigen ist die ansprechende Visualisierung der Ergebnisse für den Endnutzer. Denn nur wenn die Informationen ausreichend schnell und benutzerfreundlich angezeigt werden, wird der Anwender das System nutzen und akzeptieren. Damit die Geschwindigkeit der Auswertungen erhöht wird, erfolgen immer häufiger der Einsatz von In-Memory-Datenbank und die Ausnutzung von paralleler Verarbeitung durch Mehrkernprozessoren[Pl09].

Integration

Unter diesem Punkt wird nicht nur die Integration der Daten aus den Quellsystemen in das DWH-System verstanden. Es kommt bei einem Business-Intelligence-System auch die Integration von Anwendungen, Prozessen und Technologien anderer Systeme hinzu. Technisch realisiert werden die Schnittstellen zu den Datenquellen mit standardisierten Treibern, falls strukturierte Daten in Form einer Datenbank zugrunde liegen. Sehr weit verbreitet ist der ODBC-Treiber (Open Database Connectivity), der von Microsoft entwickelt wurde.

2.2. Grundlagen der In-Memory-Technik

Wie bereits angedeutet, hat sich in den letzten Jahren die Hardware-Technologie beständig weiterentwickelt. Das Moore'sche Gesetz hat sich bis heute als richtig bewiesen, was bedeutet, das sich die Komplexität integrierter Schaltkreise alle 1-2 Jahre verdoppelt. Das Ergebnis dieser Entwicklung ist u.a. die beständige Erhöhung der Kerne in CPUs, aber auch das Wachstum der Kapazität von Halbleiterspeichern - unter gleichzeitig stagnierenden Kosten für diese Komponenten. Eine Ausnahme in dieser Entwicklung stellen Festplatten dar. Zwar wuchs die Speicherdichte - und somit die Kapazität der HDDs - noch schneller als bei integrierten Schaltkreisen. Aber die Zugriffszeiten haben sich innerhalb eines Jahrzehnts nur um ca. 10% verbessert. Dadurch entwickelte sich der Extern-Speicher immer mehr zum schwächsten Glied der Architektur und machte neue Technologien erforderlich. Die Alternative zum Extern­Speicher befindet sich in der Speicherhierarchie nur eine Stufe weiter oben und heißt Hauptspeicher[Ra99]. Mit dem Wachstum der Kapazität ist man mittlerweile in der Lage, durch Server-Cluster, mehrere Terabyte große Datenbanken mit dutzenden von CPU-Kernen zu verarbeiten. Extern-Speicher wird dadurch allerdings nicht überflüssig, sondern dient als persistenter Speicher, da diese Eigenschaft vom Hauptspeicher nicht erfüllt werden kann. Damit inbegriffen sind auch Funktionen für Backup und Recovery der Daten[PZ12].

Mit der In-Memory-Technik sind keine Zugriffe auf externe Speichermedien mehr nötig. Lange Positionierungs- und Ladezeiten, sowie niedrige Übertragungsgeschwindigkeiten - von der HDD über den RAM zur CPU - fallen dadurch weg. Diese machen einen Großteil des Datenbeschaffungs- und Analyseprozesses aus[Ra99]. Zum anderen reduziert sich die Komplexität der Datenbanksysteme. Das ist darin begründet - ausgehend von den etablierten Schichtenmodellen für Datenbanksystem - das eine bzw. mehrere Schichten, durch die nicht mehr nötigen Zugriffe auf Speichersysteme, entfallen können (diese Komponenten werden aber bei den Datenquellen weiterhin benötigt). Weiterhin sind keine Datenbankpuffer, sowie Schnittstellen für Dateien und externe Geräte mehr notwendig[Ra99].

2.3. Zeilen- und spaltenorientierte Datenbanken

In Transaktions- und Analyse-Systemen werden die Daten häufig unterschiedlich angeordnet. In zeilenorientierten DBs werden die Attribute eines Datensatzes nacheinander abgespeichert. Diese schreiboptimierte Form der Speicherung wird meist in transaktionalen Systemen (OLTP) verwendet. Einfüge-Operationen werden dabei fortlaufend gespeichert und alle Attribute können mit einem Zugriff gelesen werden. Als nachteilig stellt sich diese Organisation bei großen Lesezugriffen heraus. Wenn bspw. für eine Berechnung nur eine Spalte eines Tupel benötigt wird - diese aber aus mehreren Millionen Datensätzen - sind viele Zugriffe nötig[Pl09].

In spaltenorientierten DB-Systemen werden die Datensätze leseoptimiert angeordnet. Da viele Leseoperationen darauf abzielen, Datensätze anhand der Werte einer oder mehrerer Spalten auszuwählen, ist es effizienter das Tupel aufzubrechen und die Attribute einer Spalte nacheinander zu speichern. Die Zuordnung der Attribute zu einem Datensatz erfolgt über Indizes. Nachteil dieser Anordnung ist, dass bei Abfragen in der alle Attribute eines Datensatzes nötig sind, diese nicht mehr nacheinander im Speicher liegen. So muss über die Indizes - mit mehreren Zugriffen - ein zusammengehörender Datensatz erstellt werden (siehe Abbildung 2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Datenzugriff bei zeilen- bzw. spaltenorientierte Speicherung[P109]

2.4. Datenkompression mit Data Dictionaries

Mit dem Data Dictionary werden gleich zwei Zielstellungen verfolgt. Durch die Zuordnung von IDs zu konkreten Attributwerten lassen sich Redundanzen innerhalb der Daten dazu nutzen, um diese zu komprimieren. Statt mehrmals den gleichen Attributwert in den Tabellen zu speichern, wird nur eine Referenz auf den zugehörigen Eintrag des Data Dictionaries gespeichert. Dieses Verfahren wird bei Attributen verwendet, die Zeichenketten speichern, da diese damit stark komprimiert werden können. Da jedes Zeichen einer Zeichenkette ein Byte an Speicherplatz belegt benötigt beispielsweise ein Attribut mit einer Länge von 30 Zeichen auch 30 Byte. Ohne Data Dictionary verbraucht jeder Datensatz 30 Byte, für eine Tabelle mit einer Millionen Einträgen sind das 30 Megabyte. Angenommen das Attribut speichert die Bundesländer Deutschlands ab, reicht ein smallint-Attribut mit 2 Byte um diese in einem Wörterbuch zusammenzufassen. Für das Data Dictionary würden nur 512 Byte benötigt - 16mal die 30 Byte pro Bundesland, sowie 16mal die 2 Byte für den Identifier. Und für eine Million Datensätze würden zwei Millionen Byte, also zwei Megabyte benötigt. Das führt zu einer Reduzierung des Datenaufkommens ungefähr um den Faktor 15. Der zweite Vorteil der durch ein Data Dictionary entsteht ist die gleiche Länge der Attribute. Eine Tabelle die zu einem großen Teil aus Zeichenketten besteht hat die Eigenschaft dass jeder Datensatz eine unterschiedliche Länge besitzt. Wenn das Data Dictionary-Verfahren auf die gesamte Tabelle angewendet wurde, ist man anschließend in der Lage die Position eines Attributes des Datensatzes im Speicher zu berechnen da jedes Tupel die gleiche Länge besitzt. Das ist dann besonders hilfreich wenn eine Leseoperation auf einer Spalte ausgeführt wird, bspw. um eine Berechnung durchzuführen[PZ12]. In Abbildung 3 ist das Prinzip des Data Dictionary beispielhaft dargestellt. Auch für die Spalte „Nachname" könnte noch eine weitere Wörterbuch­Tabelle angelegt werden, um die Kompression weiter zu erhöhen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Vergleich ohne(links) und mit(rechts) Data Dictionary

[...]

Details

Seiten
32
Jahr
2013
ISBN (eBook)
9783656441205
ISBN (Buch)
9783656441618
Dateigröße
814 KB
Sprache
Deutsch
Katalognummer
v215338
Institution / Hochschule
Universität Leipzig
Note
1,0
Schlagworte
in-memory architectures beispiel qlikview

Autor

Zurück

Titel: In-Memory BI Architectures am Beispiel QlikView