Untersuchung der Migration einer MySQL basierten Monitoring & Data-Warehouse Lösung nach Hadoop

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Kurzbeschreibung
1.3 Abstract

2 Problemstellung
2.1 Ist-Zustand
2.1.1 Kurzbeschreibung
2.1.2 Funktionsübersicht
2.1.3 Komponenten
2.1.4 Infrastruktur, Kommunikation und Datenfluss . .
2.2 Problembeschreibung und Anforderungen
2.2.1 Reliability, Availability und Serviceability (RAS) .
2.2.2 Ressourcenverbrauch
2.2.3 Performance und Skalierung
2.2.4 Funktionsumfang und Komplexität der Auswertung
2.3 Zielsetzung

3 Grundlagen
3.1 ETL-Prozess
3.2 PHP Data Objects (PDO)
3.3 Thrift
3.4 Apache Hadoop
3.4.1 Hadoop Distributed File System (HDFS)
3.4.2 HBase
3.4.3 MapReduce
3.4.4 Hive

4 Systementwurf
4.1 Infrastruktur
4.2 Komponenten
4.2.1 Hadoop Daten-Import
4.2.2 Hadoop Daten-Export
4.2.3 Monitoring
4.3 Datenstruktur
4.3.1 HBase
4.3.2 Hive

5 Implementierung
5.1 PHP-Hadoop Framework
5.1.1 Thrift-Clients
5.1.2 PHP Data Object (PDO)
5.1.3 Plug-in-Interfaces
5.1.4 Tests
5.1.5 Commandline-Tool
5.1.6 Programmfluss
5.2 Monitoring-Dienst

6 Evaluation
6.1 Testumgebung
6.2 Test-Szenario
6.2.1 Daten-Import
6.2.2 Statistik-Abfragen
6.2.3 Ressourcenverbrauch
6.2.4 Hive und HBase Vergleich
6.3 Ergebnis
6.3.1 Statistik-Abfrage
6.3.2 Ressourcenverbrauch
6.3.3 Hive und HBase Vergleich

7 Fazit
7.1 Ergebnis
7.2 Ausblick
7.3 Epilog

A Anhang
A.1 Parameter des Commandline-Tools

Literaturverzeichnis

1 Einleitung

1.1 Motivation

Im Internet etwas suchen oder mal schnell eine Nachricht an Freunde senden, diese Dinge sind für uns alltäglich geworden. Das Internet ist allgegenwärtig für jedermann. Jeder ist online, in sozialen Netzwerken aktiv, gibt permanent Informationen zum Befinden, über Aufenthaltsorte und Aktivitäten preis. Riesige Freundeskreise konsumieren, verbreiten und kommentieren diese Informationen. Ständig wird dadurch eine unglaubliche Datenmenge produziert.

Im Internet omnipräsente Unternehmen und Betreiber von sozialen Netzwerken sind Google und Facebook. Google versucht das komplette Internet auszuwerten und besitzt hierzu einen fast 100 Millionen Gigabyte großen Index, in den jeden Tag hundert tausende Gigabytes hinzugefügt werden [Inc10]. Bei Facebook werden in jeder Sekunde mehr als 50 000 Sofortnachrichten verschickt [Gra11] und das Speichern der Profile und Aktivitäten der Weltbevölkerung erstrebt.

Doch wie viele Daten sind überhaupt in der Welt vorhanden und wie viele Informationen lassen sich daraus gewinnen?

Die höchste bekannte Datendichte findet man in der DNA mit 0[Abbildung in dieser Leseprobe nicht enthalten]Buchstaben pro mm [Git06]. Damit könnte man den Inhalt der Bibel auf der große eines Stecknadel- Kopfes ungefähr 788 Milliarden Mal speichern. Das menschliche Genom besteht aus ungefähr [Abbildung in dieser Leseprobe nicht enthalten]Buchstaben, dies entspricht ca. drei Gigabyte an Daten. Diese Zahl wirkt erstaunlich klein, wenn man bedenkt, dass sich dahinter der komplette Bauplan eines Menschen verbirgt.

In der Praxis zeigt sich jedoch, dass die in den Daten gespeicherte Information ein unvorstellbar hohes Ausmaß annimmt. Dies wurde im Zuge des Human Genome Projects [oEtNIoH] offensichtlich, bei dem durch die Decodierung der Basenpaare die Daten der DNA entschlüsselt wurden, die dahinter liegende Bedeutung der einzelnen Gene allerdings größtenteils verborgen blieb.

Mit wie vielen Daten lässt sich ein Menschenleben beschreiben? Der Mensch nimmt seine Umwelt vorwiegend über die visuellen Reize war und besitzt hierzu ungefähr 126 Millionen Sinneszellen pro Auge. Jeder Rezeptor liefert pro Sekunde Informationen im Bereich von 0 bis 1000 Impulsen, dies entspricht 10 Bits pro Sekunde.

Daraus ergibt sich eine Datenmenge von ca. 1,2 Gigabyte pro Sekunde [Git06]. Bei acht Stunden Schlaf pro Tag und einer Lebensdauer von 75 Jahren ergibt sich so eine Menge von 1.503 Petabyte an visuellen Daten pro Auge.

Die anfallenden Daten der Sinneszellen werden im Gehirn von über hundert Milliarden Nervenzellen verarbeitet, die jede Sekunde elektrische Signale an Zehntausende weitere Neuronen senden. Diese enorme Menge an Datenfluss entspricht hundertmal der Menge an Bits, die in dieser Zeit im Internet transferiert werden. [KB09] Dies führt schließlich zu der Frage: Was begrenzt die Ansammlung von Daten, wie viel Informationen können daraus gewonnen werden und welchen Wert haben diese?

Der Mensch strebt seit jeher danach, die von der Natur gesetzten Maßstäbe mit moder- nen Technologien zu erreichen oder sogar zu übertreffen. In die Zukunft prognostiziert bedeutet das eine sich permanent potenzierende Datenmenge. Exponentielles Wachstum der Speicher-Dichte, rapide fallende Preise für persistente Terabytes eines wird klar - der Preis für Speicherplatz, die gesetzlich verordnete Datensparsamkeit und der von der Politik geforderte “digitale Radiergummi” wird die bestehende Datensammelwut nicht aufhalten können.

Der enorme Wert von Information kann an der Börsen-Dotierung von Unternehmen wie Facebook und Google abgelesen werden, die ihren Umsatz fast ausschließlich durch die Verarbeitung von Daten generieren. Der Marktwert von Google Inc. liegt bei ca. 150 Milliarden Euro (02/2012) [Res]. Facebook Inc. konnte jüngst die Summe an Investorengeldern um 1,5 Milliarden Dollar [Inc11] erhöhen. Doch der reelle Wert von Daten lässt sich weniger aus der gespeicherten Menge derselben ableiten. Von viel größerer Bedeutung sind die relevanten Informationen, die sich aus ihnen gewinnen lassen. Folglich bemisst sich der wahre Wert der Daten vielmehr an der Qualität der zur Verfügung stehenden Methoden der Extraktion von relevanten Informationen.

So wird deutlich, dass der heutzutage begrenzende Faktor nicht mehr durch die fehlende Möglichkeit der Speicherung, sondern vielmehr durch die Leistung von Systemen zur Informationsgewinnung und Verarbeitung definiert wird. Es gilt also, durch die Entwick- lung neuer Paradigmen in der EDV den Anforderungen des Informationszeitalter Herr zu werden.

Die im großen Kontext aufgezeigte langfristige Weiterentwicklung der informationsverar- beitenden Systeme wird in dieser Arbeit innerhalb eines Subsystems umgesetzt.

1.2 Kurzbeschreibung

Die escape GmbH betreibt ein MySQL basiertes Dataware-House in das Daten aus verschiedenen Webpräsenzen fließen, um dort ausgewertet zu werden. Nach Jahren des erfolgreichen Betriebs nimmt mit der ständig steigenden Menge an gespeicherten Daten die Leistung des Systems allerdings ab. Die Laufzeiten für Auswertungen steigen und die Agilität sinkt. Kleine Optimierungen und Veränderungen des Systems können das Unbrauchbarwerden hinauszögern, als aber aus Gründen der Leistung auf einen Teil der Abfragen verzichtet werden muss, wird schließlich klar, dass nur eine grundlegende Veränderung des Systems den langfristigen Betrieb sicherstellen kann. Aus diesem Grund wurde nach Technologien gesucht, deren Fähigkeiten die Leistung des bestehenden Dataware-Houses verbessern können. Dies führte zu Hadoop [Fouc][Whi10a], einem Open Source Framework, welches die Verarbeitung von riesigen Datenmengen in einem Cluster erlaubt.

Diese Arbeit untersucht, wie Komponenten des bisherigen Systems durch Dienste von Hadoop ersetzt werden können. Sie wertet die Möglichkeiten zur Strukturierung von Daten in einer spaltenbasierten Datenbank aus, evaluiert in einem Benchmark, wie sich die Zeit von Abfragen im Verhältnis zu einer stetig steigenden Datenmenge verhält und analysiert detailliert den Ressourcenverbrauch des Clusters und dessen Knoten.

Die Implementierung zeigt, dass sich die spaltenbasierten Datenbank HBase sehr gut zum Speichern von einer sehr großen Menge an semistrukturierten Daten eignet und die Dataware-House Komponente Hive durch die Unterstützung eines SQL ähnlichen Syntax das Erstellen von Abfragen komfortabel ermöglicht. Die Literatur beschreibt, dass HBase automatisch linear mit dem Hinzufügen von neuen Knoten skaliert. Der durchgeführte Benchmark zeigt, dass die Ausführungs-Zeit der getesteten Abfragen fast genau linear zur Datenmenge steigt, der Ressourcenverbrauch nur gering wächst und die Last im Cluster gleichmäßig verteilt wird. Dies lässt die Schlussfolgerung zu, dass sich Hadoop gut zum Betrieb einer Dataware-House Lösung eignet.

1.3 Abstract

The escape GmbH runs a MySQL based on data warehouse in which data from various websites flows to be analysed. The constant growing size of the data stored over the years led to a decreasing performance of the system. The execution time for queries increases while the agility declines. Small improvements and changes of the system were able to delay the inoperativeness. Because of the lack of performance though, part of the queries had to be abandoned. It was clear thus that only a fundamental change could ensure the operation of the system in the long term. For this reason an analysis was made in order to find a new technology that could improve the existing system. This led to Hadoop [Fouc][Whi10a] an Open Source framework for processing vast datasets in a cluster.

This paper studies how components of the current system can be replaced by services of Hadoop. It shows an analysis of possibilities of structuring data in a column oriented database, an evaluation on how the execution time of queries behaves with a constant growing dataset size and detailed monitoring data of the resource consumption of the cluster and its nodes.

The implementation points out that the column oriented database Hbase works very well for saving vast amounts of semi-structured data and the data warehouse component Hive allows a creation of queries conveniently due to its SQL like syntax support. The literature describes that HBase automatically scales linearly with new nodes. The performed benchmark shows that the execution time of the tested queries increases almost exactly linear with a growing data set size. The resource consumption also grows slightly and is distributed evenly to all nodes within the cluster. This leads to the conclusion that Hadoop is well suitable to operate a data warehouse system.

2 Problemstellung

Das folgende Kapitel widmet sich dem strukturierten Aufzeigen der Problemstellung.

Hierzu wird zuerst der Ist-Zustand skizziert, indem eine illustrative Funktions-Übersicht geboten wird, deren Komponenten im weiteren Verlauf detailliert beschrieben werden. Anschließend wird die Kommunikation und der Datenfluss im System aufgezeigt.

Darauf aufbauend wird die Problemstellung formuliert, deren wesentliche Punkte in einer Zielsetzung münden.

2.1 Ist-Zustand

Dieser Abschnitt beschreibt das vorhandene System mit allen wichtigen Komponenten und dem Fluss der Daten. Dies verdeutlicht den Funktionsumfang und die wesentliche Charakteristik der implementierten Software.

Es zeigt die relevanten und spezifischen Merkmale auf und erlaubt dem Leser darauf aufbauender Beschreibungen und Annahmen nachzuvollziehen.

2.1.1 Kurzbeschreibung

Das vorhandene System besteht im Wesentlichen aus einer öffentlichen Webseite und einem Backend-Bereich, in welchem Statistiken über den Betrieb und die Benutzer betrachtet werden können. Außerdem erlaubt dort ein Monitoring-Dienst aufgezeichnete Vorgänge auszuwerten.

Beim Eintreffen eines Besuchers auf der Webseite wird eine Sitzung für diesen erstellt.

Diese verfügt über einen eindeutigen Namen und kann mehreren Aktionen eines Benut- zers im System zugeordnet werden, da sie diesen Request übergreifend mit Hilfe von Sitzungscookies identifiziert.

Die Applikation der Website besteht aus einer Vielzahl von Modulen, die relevante Daten, versehen mit Zeitstempel und Sitzungs-Namen, abspeichern.

2.1.2 Funktionsübersicht

Die betriebene Monitoring und Data-Warehouse Lösung erlaubt es, relevante Modul- Daten der Applikation aufzuzeichnen, gespeicherte Werte zu überwachen und Kennzahlen in einer Statistik zusammenzufassen. Die festgehaltenen Werte der Module können zum Zweck der Überwachung mit der Hilfe eines Monitoring-Dienstes betrachtet werden, welcher die Möglichkeit zum Filtern nach Kriterien wie Sitzungs-Namen, Modulen und Zeiträumen erlaubt. In der Statistik wird eine globale Sicht auf die Quelldaten aus den verschiedenen Modu- len geboten und so eine übergreifende Auswertung der aufgezeichneten Vorgänge und Eingaben ermöglicht. Die gewonnen Informationen werden als Berichte und Diagramme dargestellt.

Eine Funktionsübersicht, bei der die Applikation, welche aus einer Vielzahl von Modulen besteht, Daten liefert, die im Monitoring überwacht und in einer Statistik betrachtet werden können, kann in Abbildung 2.1 betrachtet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Funktionsübersicht der Applikation mit Modulen, Monitoring und Statistik

2.1.3 Komponenten

Die Applikation und deren Module stellen die Informations-Quelle dar, deren Daten durch die Logging-Komponente im linken Teil der Datenhaltung abgelegt werden, hier finden ausschließlich schreibende Zugriffe auf die MySQL-Datenbank statt. Die aufgezeichneten Daten werden periodisch auf die rechte Seite des Ring-Puffer über- tragen, auf die der Monitoring-Dienst und die Statistik ausschließlich lesend zugreifen. Eine Übersicht der vorhanden Komponenten des Systems und dem zugehörigen Infor- mationsfluss. Bestehend aus der Applikation, deren Modul-Daten mit Hilfe der Logging- Komponente in die Datenhaltung fließen, um dort dem Monitoring und der Statistik zur Verfügung zu stehen. Kann unter Abbildung 2.2 betrachtet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2: Übersicht der Komponenten und dem Informationsfluss

2.1.3.1 Applikation und Module

Die Applikation besteht aus einer Vielzahl von Modulen, welche Daten wie System- Variablen, Benutzer-Interaktion bzw. -Eingaben und Intersystem-Kommunikation verar- beiten. Von den anfallenden Daten werden jene an die Logging-Komponente übergeben, die relevant für das Nachvollziehen von Vorgängen und Zuständen sind.

Der überwiegende Teil der hierbei transferierten Informationen hat die Struktur eines assoziativen Datenfelds (<Key,Value> z.B. < ‘ transactionId ’ , ‘ ID_a1s54dsd ’ >).

2.1.3.2 Logging

Die Logging-Komponente bietet den Modulen ein einheitliches Interface zum Hinterlegen von Daten und steuert die Persistenz. Interface Das homogene Interface für die Module hat folgende Form: log(ModuleName, ModuleEvent, Array<<K1,V1>,<K2,V1>,...,<Kn,Vn>>)

- ModuleName

Name des aufrufenden Moduls als alphanumerischer String.

- ModuleEvent

Ereignis innerhalb eines Moduls als alphanumerischer String.

- DataArray

Aufzuzeichnende Modul-Daten als assoziatives Array. Beispiel für einen Bezahlungseingang im Modul Payment:

log( ‘ Payment ’ , ‘ New ’ , << ’ transactionId ’ , ‘ ID_a1s54dsd ’ >, < ’ amount ’ , ‘ 199 ’ >>)

Persistenz

Die übergebenen Daten werden in einer MySQL-Datenbank mit folgenden Tabellen gespeichert:

- logging

Haupteintrag des Modul-Ereignisses mit Zeitstempel und Verweisen auf weitere Tabellen.

- logging_module

Name des aufrufenden Moduls.

- logging_event

Name des Ereignisses im Modul.

- logging_data

Modul-Daten zeilenweise als <Key, Value> mit Referenz zur Tabelle mit den Schlüsselwerten.

- logging_data_key

Schlüsselwerte für alle Modul-Daten.

- logging_session

Benutzer Sitzung mit eindeutigem Token.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.3: Schema der MySQL-Datenbank der Persistenz.

Bei jedem Aufruf wird ermittelt, ob das übergebene Modul und dessen Event bereits hinterlegt sind. Falls dies nicht der Fall ist, wird das entsprechende Modul in der Tabelle ‘logging_module’ eingetragen und eine Modul-Daten-Tabelle nach dem Schema ‘logging_- data_[module_id]’ erzeugt bzw. ein Eintrag in der Tabelle ‘logging_event’ eingefügt.

Die gegebenenfalls erzeugten Modul-Daten-Tabellen (z.B. ‘logging_data_1’) dienen zur Partitionierung der Daten auf Anwendungsebene, um eine Erhöhung der Performance zu erreichen und eine physische Abgrenzung der jeweiligen Modul-Daten zu gewährleisten.

Die Modul-Daten in der Form <Key, Value> werden mit den Tabellen ‘logging_data’ und ‘logging_data_key’ abgebildet. Hierbei werden die Values in der Tabelle ‘logging_- data’ gespeichert und von dort aus auf den Key, der in der Tabelle ‘logging_data_key’ hinterlegt ist, referenziert. Falls beim Aufruf ein Schlüsselwert in der ‘logging_data_key’ noch nicht existiert, wird dieser angelegt. Abschließend wird die aktuelle Benutzer-Sitzung (Session) ermittelt, um mehrere Modul- Ereignisse einem Benutzer eindeutig zuordnen zu können. Hierfür wird pro Session ein eindeutiger Token erstellt, der in der Tabelle ‘logging_session abgelegt’ wird. Nach dem Ablegen der Daten in der MySQL-Datenbank greift der Ring-Puffer periodisch auf die Tabellen zu, um sie weiter zu verarbeiten.

2.1.3.3 Datenhaltung

In der Datenhaltung ist ein Ring-Puffer implementiert, der dazu dient eine Datenbasis zu schaffen, in der die Schreibzugriffe der Logging-Komponente nicht in Interferenz zu den Lesezugriffen des Monitor Dienstes und der Statistik treten. Außerdem wird dadurch eine Server übergreifende periodische Übertragung der Informationen ermöglicht.

Die Funktionalität wird durch die Benutzung von mehreren MySQL-Datenbanken, Views und Synchronisations-Skripten umgesetzt.

Eine Übersicht des Datenflusses innerhalb der Datenhaltungs-Komponente. Ausgehend vom View, in den die Daten geschrieben werden und der auf die rotierenden Puffer- Datenbanken verweist, bis zur Zieldatenbank, auf die lesend zugegriffen wird. Kann unter Abbildung 2.4 betrachtet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.4: Datenfluss innerhalb der Datenhaltungs-Komponente

Datenbanken, Views und Indizes

Die Datenhaltung besteht im Wesentlichen aus fünf Puffer-Datenbanken, in die jeweils für einen bestimmten Zyklus-Abschnitt der Rotation geschrieben wird, und einer Ziel- Datenbank, in die die Daten schließlich fließen, nachdem sie die Rotation durchlaufen haben.

In den Puffer-Datenbanken befinden sich die Tabellen, in die das Logging die Daten ablegt. Dabei wird der Zugriff auf die eigentlichen Tabellen mit Views gesteuert, damit während einer Rotation immer in genau eine Datenbank geschrieben wird, die sich für diesen Zyklus-Abschnitt im Schreib-Modus befindet. Die Indizes und Schlüssel der Puffer-Datenbanken sind für das Schreiben, die Ziel- Datenbank für das Lesen optimiert. Die konkreten Index-Einträge werden jeweils beim Einfügen der Daten in die Tabellen kreiert.

Rotation und Daten-Übertragung In Phase I der Rotation befinden sich noch keine Informationen in den Datenbanken und die Views, auf die die Logging-Komponente schreibend zugreift, referenzieren auf die Puffer-Datenbank mit dem Index 0.

Nach einer bestimmten Zeit-Periode in Phase I, in der das Logging seine Daten in die Puffer-Datenbank mit dem Index 0 geschrieben hat, beginnt die erste Rotation in der folgenden Aktionen ausgeführt werden:

- Referenzen der Views werden geändert

Die Referenzen der Views werden auf die Puffer-Datenbank mit dem nächstgrößeren Index gesetzt. Die Daten des Loggings fließen jetzt in die Puffer-Datenbank mit dem Index 1.

- Export der bisher angefallenen Daten

Die Datensätze aus der bisher aktiven Puffer-Datenbank mit dem Index 0 werden in eine komprimierte Datei exportiert.

- Übertragung der Export-Daten

Die Export-Datei wird zum Zielserver übertragen und dort extrahiert.

- Einspielen der Export-Daten

Auf dem Zielserver werden die exportierten Datensätze in die Ziel-Datenbank eingefügt und die zugehörigen Indizes erstellt.

- Leeren der verarbeitenden Puffer-Datenbank

Die Daten aus der bisher aktiven Puffer-Datenbank mit dem Index 0 werden gelöscht.

Der Ring-Puffer befindet sich nun in Phase II. Die Prozessschritte des Übergangs von

Phase II zu Phase III gestalten sich analog zum Übergang der Phase I in Phase II. Falls

die Puffer-Datenbank mit dem größten Index erreicht wurde, wird mit dem Index 0 fortgefahren.

2.1.3.4 Monitoring

Das Monitoring erlaubt es, gespeicherte Modul-Daten in der Ziel-Datenbank der Daten- haltung zu betrachten und auszuwerten. Im Allgemeinen dient es dazu aufgezeichnete Benutzersitzungen zu analysieren, um vergangene Vorgänge nachvollziehbar zu machen und Detail-Informationen abzufragen. Ein Screenshot des Monitoring-Dienstes, der die Modul-Daten in der Übersicht zeigt und die Filterung bzw. Sortierung der Spalten erlaubt, kann unter Abbildung 2.5 betrachtet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.5: Screenshot des Monitoring-Dienstes

Die Darstellung erfolgt in tabellarischer Form, bei der jede Zeile ein Modul-Ereignis darstellt. Durch einen Mausklick werden alle Modul-Daten zu dem jeweiligen Ereignis- Element angezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.6: Screenshot des Monitoring-Dienstes mit Anzeige der Modul-Daten.

Die Möglichkeit der Filterung nach Sitzungen, Modulen, Modul-Aktionen und Zeitraum macht das komfortable Auswerten des Datenbestandes möglich. Außerdem wird eine Suche nach speziellen Modul-Daten unterstützt, um Transaktionen und Benutzersitzungen ausfindig zu machen.

2.1.3.5 Statistik

In der Statistik-Komponente werden aus den aufgezeichneten Modul-Informationen Statistik-Daten extrahiert, diese mit Stammdaten angereichert und daraus Berichte und Diagramme erstellt. Die hierbei verwendeten Abfragen folgen einem ähnlichen Extraktions- Schema und speichern ihre Ergebnisse in spezifisch definierten Ergebnis-Tabellen, deren Aufbau für das effektive Abrufen optimiert sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7 zeigt, wie aus den Informationen der Datenhaltungs-Komponente die Statistik-Datenbank befüllt, anschließend mit den Stammdaten angereichert und in Berichten sowie Diagrammen angezeigt wird.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.7: Datenfluss zur Aufbereitung der Statistik

Daten-Extraktion

Bei der Daten-Extraktion wird nach folgendem Schema vorgegangen, um relevanten Modul-Daten zu extrahieren und sie in den Statistiken auswertbar zu machen:

- Extraktion von Modul-Ereignissen

Aus den Modul-Daten werden bestimmte Ereignisse anhand von Prädikaten extra- hiert. So werden beispielsweise aus dem Modul ‘Payment’ Ereignisse mit dem Wert ‘New’ extrahiert, die einen ‘amount’ größer als ‘100’ haben.

- Anwendung von Mengenoperationen

Auf die Mengen von Modul-Ereignissen werden Operationen wie Schnittmenge, Vereinigungsmenge, Differenz und Komplement angewendet. Damit wird die Menge der Informationen erhalten, die es erlaubt die gewünschten Aspekte zu analysieren.

- Speicherung spezifischer Tabelle

Auswahl der relevanten Key-Value-Daten. Gegebenenfalls Transformation bezie- hungsweise Zusammenführung von Werten und Speicherung in einer spezifischen Tabelle mit einer Abbildung von Key = Spalte und Value = Zeile.

- Anreicherung mit Stammdaten

Einfügen von Stammdaten, die die Lesbarkeit für den Menschen erhöhen z.B. Ersetzen von Identifikationsnummern durch Beschreibungstexte.

Abbildung 2.8 zeigt wie Ergebnismengen mit der Hilfe von Prädikaten aus Modul-Daten gewonnen werden, die anschließend in einer Statistik-Datenbank münden und dort mit Stammdaten angereichert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.8: Datenextraktion für die Statistik

2.1.4 Infrastruktur, Kommunikation und Datenfluss

Die auf dem Live-Server anfallenden Modul-Daten der Applikation werden über das für alle Module homogene Interface der Logging-Komponente in den MySQL-View eingetragen, der auf die sich im ‘Write-Mode’ befindende Ring-Puffer-Tabelle referenziert. Periodisch werden die im Ring-Puffer angefallenen Daten exportiert, komprimiert und via Secure Copy (SCP/SSH) zum Report-Server übertragen, auf dem die Datensätze extrahiert, importiert, indiziert und für langfristig aufbewahrt werden. Auf dem Live- Server befindet sich somit immer nur ein kleiner Ausschnitt der aktuellsten Modul-Daten.

Der Datenbestand auf dem Report-Server kann im Monitoring-Dienst betrachtet werden und wird außerdem in die Statistik-Tabellen überführt. Hierbei findet eine Extraktion von relevanten Informationen und außerdem eine Transformation statt. Hinzu kommt eine Anreicherung mit Stammdaten, die regelmäßig vom Live-Server übertragen werden.

Aus den Kennzahlen der Statistik werden schließlich Berichte und Diagramme erstellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8 zeigt den Fluss der Daten vom Live- zum Report-Server, auf dem die Statistk erstellt wird und der Monitoring-Dienst die Überwachung der Daten ermöglicht.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.9: Detailierter Datenfluss im System

2.2 Problembeschreibung und Anforderungen

In diesem Abschnitt werden Probleme aufgezeigt, die die Leistung des bisherigen Systems einschränken. Hierbei wird auf die Komponenten aus dem Abschnitt Ist-Zustand Bezug genommen.

Es wird auf die Zuverlässigkeit, die Leistung und den Funktionsumfang eingegangen und Schwächen aufgezeigt, die sich vor allem mit der enorm wachsenden Menge der Daten ergaben.

2.2.1 Reliability, Availability und Serviceability (RAS)

Das vorhandene System verarbeitet Informationen, die ökonomische Relevanz haben.

Situationen, in denen ein Datenverlust stattfindet oder falsche Berechnungen auftreten, können deswegen hohe wirtschaftliche Verluste zur Folge haben. Bei diesem besonders sen- siblen Teil der Komponenten bzw. Prozesse spricht man von einem Critical Computational System [Var00], bei dem Ausfälle nicht tolerierbar sind.

Bei der Erstellung von Berichten und Statistiken sind gelegentlich auftretende kurzzeitige Unterbrechungen der Verfügbarkeit akzeptabel. Diese Teil-Systeme fallen in die Kategorie General Purpose Computing. [Var00] Die bisher eingesetzte Monitoring und Data-Warehouse Lösung bietet die Protokollierung von fehlgeschlagenen Datenbankabfragen, um ungewollte Datenverluste auszuschließen.

Allerdings besteht die Gefahr Datensätzen beim gewaltvollen Beenden des MySQL- Dienstes zu verlieren, da zur Performance-Erhöhung die Delayed-Methode bei Insert- Statements genutzt wird. Das führt dazu, dass Informationen im Arbeitsspeicher gepuffert werden und somit flüchtig sind. [Ora]

Hinzu kommt, dass durch die hohe Komplexität des Ring-Puffers die Wahrscheinlichkeit von Störungen hoch ist. Hierbei ist das Auftreten von Datenverlusten zwar unwahrschein- lich, aber das manuelle Eingreifen der Administration ist im Falle von Beeinträchtigungen unabdingbar. Außerdem besteht die Gefahr des kompletten Systemstillstands beim Ver- sagen der Datenhaltungs-Komponente, da diese nicht redundant ausgelegt ist. Hierbei handelt es sich um einen Single Point Of Failure. [AJ06]

Folglich bietet das System keine Zuverlässigkeit bei Planned (Wartung) [Var00], bzw. Unplanned System Outages (Betriebsstörungen) [Var00] und erfordert einen hohen Wartungsaufwand bei Fehlfunktionen.

2.2.2 Ressourcenverbrauch

Der Ressourcenverbrauch im vorhandenen System ist nicht optimal. Zum einen übersteigt die Indexlänge zum Teil die Größe der eigentlichen Nutzdaten und zum Anderen kann der Großteil der Festplattenzugriffe (I/O) nicht sequenziell ausgeführt werden.

2.2.2.1 Speicher

In der Abbildung 2.10 wird deutlich, dass die Indexlänge für die Tabelle ‘logging’ um mehr als 50 Prozent größer ist als die eigentliche Datenlänge. Das liegt daran, dass für den schnellen Zugriff auf die Daten B-Tree Indizes [BS08a] für bestimmte Spalten erstellt wurden. Diese werden zwar durch die Verwendung der MyISAM Datenbank-Enginge mit einer Prefix-Kompression [BS08a] versehen. Dies hilft allerdings nur bedingt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.10: MySQL-Tabellen der Datenhaltung mit jeweiliger Indexlänge und Nutzdaten.

2.2.2.2 Input/Output

Die Grafik für die Festplattenzugriffe zeigt, dass der Großteil der Schreibzugriffe nicht sequenziell stattfindet; dies führt zu geringeren Datendurchsatzraten, weil der Lesekopf der Festplatte Zeit für das Suchen der Daten verwenden muss. Insbesondere bei Group- By-Queries und Volltext-Suchen finden wahlfreie I/O-Operationen der Festplatte statt [BS08b] , die zu einen hohen Ressourcenverbrauch führen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.11: Storage I/O Zugriffs-Muster während der Aufbereitung der Statistik

2.2.3 Performance und Skalierung

Ein MySQL-System ist per se monolithisch strukturiert und skaliert deswegen vorerst nur horizontal. Eine vertikale Skalierung kann durch einen Replikations- und Sharding-Prozess [BS08c] erreicht werden, bei dem Daten auf mehreren Knoten verteilt und gegebenenfalls Partitionierungen in sogenannten Shards gruppiert werden.

Das Ziel hierbei ist, die benötigten Knoten bzw. Shards (Cross-Shard Query) pro Anfrage zu minimieren, da eine übergreifende Abfrage Inter-Knoten-Kommunikation verursacht, welche stark durch die Datendurchsatzrate des Netzwerkes eingeschränkt wird. Beim Sharding mit einer Partitionierung, die die Zeit als Basis verwendet, gelingt dies im vorhandenen System gut, da für die Abfragen der Statistik meist Daten eines begrenzten Zeitraumes betrachtet werden.

Bei der Verteilung der Moduldaten auf mehrere Knoten tritt allerdings das Problem auf, dass bei der Speicherung der Daten nicht klar ist, welche Modul-Daten bei der späteren Auswertung miteinander verglichen werden sollen.

Die vertikale Skalierung des Systems ist folglich begrenzt.

2.2.4 Funktionsumfang und Komplexität der Auswertung

Da der Ressourcenverbrauch hoch und die Skalierung ungenügend ist, kann das System nur einen begrenzten Funktionsumfang bieten und die Möglichkeiten von Auswertung und Abfragen sind limitiert. So ist die mögliche Anzahl der Prädikate pro Modul-Abfrage, das Vergleichen und die Aggregation von unterschiedlichen Modul-Ergebnismengen beschränkt.

Dies führt dazu, dass komplexe Abfragen nicht durchführbar sind und tief liegende Informationen nicht abgefragt werden können.

2.3 Zielsetzung

Diese Arbeit soll untersuchen, wie Teile des bisherigen Systems durch die Open Source Lösung Hadoop [Fouc][Whi10a] und dessen Subprojekte ersetzt werden können, um eine Verbesserung der Leistung zu erzielen. Im Speziellen soll evaluiert werden, welche Auswirkungen der Einsatz des MapReduce [DG04] Verfahrens, der spaltenbasierten, verteilten Datenbank [Foud] [Geo11a] und der Data-Warehouse Komponente Hive [Foue] [TSJ+10] [Whi10b] in Hadoop mit sich bringt.

Ziel ist das Erstellen eines Systems, welches eine hohe Skalierbarkeit bei der Anwendung in einem Cluster bietet, große Datenmengen halten und verarbeiten kann, Ausfallsicher- heit gewährleistet und die bisher vorhandene Funktionalität der Überwachung und das Erstellen von Statistiken bietet. Außerdem sollen Abfragen unterstützt werden, die sehr große Zeiträume berücksichtigen und datailiertes Datamining erlauben.

Eine anschließende Evaluation soll zeigen, wie die Performance des neuen Systems ist, ob eine gute Skalierung erreicht wurde und welche relevanten Schwellenwerte ausgemacht werden konnten.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.12: Entwurf der Zielsetzung

[...]