Apache Kylin: OLAP im Big-Data-Maßstab

Inhaltsverzeichnis

Die von eBay entwickelte OLAP-Engine (Online Analytical Processing) Kylin will die in der klassischen Business Intelligence seit vielen Jahren etablierten OLAP-Cubes mit Unterstützung der Hadoop-Plattform in die Big-Data-Welt übertragen. Ein Überblick zur Architektur und zu Prozessen sowie ein paar nützliche Hinweise bei der Generierung von Cubes.

In der klassischen Business Intelligence kommen seit vielen Jahren in der Regel relationale Datenbanken als Datenspeicher zum Einsatz. Das ermöglicht Analysten, ihre Hypothesen entweder direkt mit SQL oder dafür vorgesehenen Analysewerkzeugen auf Basis von SQL zu verifizieren. Jedoch skalieren sowohl klassische relationale Datenbanken als auch OLAP-Engines nicht horizontal und besitzen daher eine natürliche Grenze bezüglich ihrer Datenspeicher- und Datenverarbeitungskapazität. Die Beschränkungen lassen sich mit Big-Data-Techniken überwinden. In den letzten Jahren hat hierbei das verteilte Datenbetriebssystem Apache Hadoop und sein Ökosystem zunehmend an Bedeutung gewonnen.

Wie viele große Firmen stand eBay vor der Herausforderung, die stetig wachsende Datenmenge bei steigender Vielfalt der Nutzer im Sekundenbereich analysieren zu wollen. Die Systemanforderungen waren schnell aufgeschrieben: Das Tool sollte ANSI-Standard-SQL für interne SQL-kompatible Tools verstehen, eine gleichzeitige Nutzung von mehreren 1000 Benutzern ermöglichen und auf einer horizontal skalierenden Architektur auf Hadoop basieren. Die Ausführungsdauer der Analysen sollte dabei im Sekundenbereich liegen, auch bei mehreren Milliarden Datensätzen.

Die Suche nach dem passenden Werkzeug führte in der Open-Source-Community ins Leere. Deshalb beauftragte eBay im September 2013 Luke Han und sein Team damit, ein neues Projekt ins Leben zu rufen – die Geburtsstunde von Kylin.

OLAP – Online Analytical Processing

Bevor der Artikel näher auf Architektur und Komponenten von Kylin eingeht, soll zunächst das Prinzip hinter dem von Edgar F. Codd geprägten Begriff Online Analytical Processing (OLAP) genauer betrachtet werden. Im Gegensatz zum Online Transaction Processing (OLTP) steht bei OLAP das Durchführen komplexer und flexibler Analysen im Vordergrund. Zur logischen Darstellung werden die Daten als Elemente eines mehrdimensionalen Würfels (OLAP-Cube) dargestellt.

Ein Beispiel: Ein Getränkehändler mit mehreren Standorten in Deutschland will analysieren, wie viele Hektoliter Bier 2014 verkauft wurden. Da die Frage bei der Entwicklung des Analysesystems vermutet wurde, speicherte man die Daten in einen OLAP-Cube:

Im Beispiel besteht der OLAP-Cube aus folgenden drei Dimensionen: Zeit, Getränke und Standorte des Unternehmens. Die Werte des Cubes werden als Measures bezeichnet. Um die Frage beantworten zu können, sind lediglich die Measures in der Zeile "Bier im Jahr 2014" zu addieren.

Eine wichtige Eigenschaft von OLAP-Systemen ist die hierarchische Anordnung der Daten, die sich in vielen Daten wiederfindet. Beispielsweise besteht ein Jahr aus zwölf Monaten und ein einzelner Monat aus mehreren Tagen. OLAP-Systeme ermöglichen die Navigation entlang einer Hierarchie. Wenn analysiert werden soll, wie viele Hektoliter 2014 pro Monat verkauft wurden, lassen sich durch eine detaillierte Navigation die Zahlen für einzelne Monate auslesen. Diese Verfeinerung des Detaillierungsgrades der Daten wird als Drill-down-, die entgegengesetzte Richtung als Roll-up-Operation bezeichnet. Durch die Anordnung der Daten ermöglicht das OLAP-System eine einfache, flexible und schnelle Bereitstellung entscheidungsrelevanter Informationen aus verschiedenen Perspektiven.

Je nach Speichertechnik wird zwischen unterschiedlichen OLAP-Verfahren unterschieden. Die gebräuchlichsten sind ROLAP (Relational OLAP) und MOLAP (Multidimensional OLAP). Greift ein OLAP-System bei der Analyse auf eine relationale Datenbank zu, nennt man das ROLAP. Aufgrund der weiten Verbreitung relationaler Datenbanken wird dieses Verfahren häufiger eingesetzt. In den meisten Fällen besteht das Datenmodell aus einer zentralen Relation, der Faktentabelle, die mehrere, sternförmig angeordnete Relationen, die Dimensionstabellen, umgeben. Die Faktentabelle enthält pro Datensatz sowohl alle Measures als auch die Fremdschlüssel zu den Dimensionstabellen. Die beschreibenden Informationen werden in den jeweiligen Dimensionstabellen gespeichert.

Im Vergleich zur Datenspeicherung in einer relationalen Datenbank legt man die Daten bei MOLAP direkt in einer multidimensionalen Datenbank ab. Dabei sind Vorberechnungen der Aggregationen im OLAP-Cube erforderlich. Dieser Aufwand ermöglicht während der Analyse eine kürzere Ausführungsdauer, führt jedoch gleichzeitig zu einem größeren Speicherplatzverbrauch, da die Aggregationen für jede Kombination der Dimensionen vorzuberechnen sind. Solch eine einzelne Teilmenge der Dimensionen heißt Cuboid. Die mögliche Anzahl an Cuboids steigt exponenziell zur Anzahl der Dimensionen an. Im Beispiel werden bereits 2^3 Cuboids benötigt: ein Cuboid mit drei Dimensionen (Getränk, Zeit, Standort), drei Cuboids mit zwei Dimensionen (Zeit, Standort), (Getränk, Standort), (Getränk, Zeit), drei Cuboids mit einer Dimension (Standort), (Zeit), (Getränk) und zuletzt ein Cuboid ohne Dimension ().

Um die Vorteile beider Verfahren zu nutzen, ist eine Kombination der Speichertechniken möglich. Auch Kylin setzt auf eine Verbindung von ROLAP und MOLAP.

Architektur & Installation

Architektur und Komponenten

Der Einsatz von Kylin wird dadurch begünstigt, dass die Technik auf etablierten Systemen aus dem Hadoop-Ökosystem aufbaut. Das Zusammenspiel der Hadoop-Komponenten in Kylins Architektur stellt die folgende Abbildung dar. Dabei ist zwischen Offline- und Online-Datenfluss zu unterscheiden.

Im Hadoop Distributed File System (HDFS) abgelegte Daten werden über Apache Hive als Sternschema modelliert. Im Offline-Datenfluss (blauer Pfad) greift die Cube Build Engine über Hive auf die Daten zu, um mit mehreren, hintereinander ausgeführten MapReduce-Jobs den OLAP-Cube zu generieren. Zusätzlich werden Metainformationen erstellt, die den Cube und die später möglichen Cube-Abfragen beschreiben. Für die Speicherung der Cuboids ist die NoSQL-Datenbank HBase verantwortlich. In der nichtrelationalen, spaltenorientierten und verteilten Datenbank werden die verschiedenen Aggregationen der Cuboids gespeichert und über das Cluster hinweg horizontal verteilt.

Nach der erfolgreichen Generierung des OLAP-Cubes und der Metainformationen stehen die Daten für Analysen zur Verfügung. Der Online-Datenfluss (grüner Pfad) beschreibt die Interaktion mit Kylin. Dabei werden SQL-Anfragen entweder direkt über die REST-Schnittstelle oder mithilfe der mitgelieferten JDBC-/ODBC-Treiber und einem SQL-basierten BI-Tool an den REST-Server gesendet. In der SQL-Query-Engine schreibt Apache Calcite die SQL-Abfrage um. Sind die angefragten Daten im HBase-Cube verfügbar, lassen sich die Queries mit Ausführungszeiten im (Sub-)Sekundenbereich beantworten. Das entspricht dem Low-Latency-Pfad in Abbildung 2 (grüner, durchgezogener Pfad).

Lässt sich die Anfrage nicht über den Cube beantworten, wird das SQL-Statement an Apache Hive weitergeleitet. Hierbei wandelt Hive die Query in MapReduce-Jobs um, deren Abarbeitung mit entsprechendem Overhead und Latenzen verbunden ist. Das entspricht dem Absolvieren der SQL-Anfrage im Mid-Latency-Pfad (grüner, gestrichelter Pfad). Je nach Datenmenge eignet sich der Vorgang nur eingeschränkt für interaktive Analysen. Das wesentliche Ziel besteht daher darin, für möglichst viele Abfragen der Nutzer den Low-Latency-Pfad bereitzustellen. Während des Cube-Designs sind aus diesem Grund die Anforderungen der Analysten bestmöglich zu berücksichtigen.

Installation: Aller Anfang ist wichtig

Voraussetzung für eine erfolgreiche Installation von Kylin ist eine fehlerfreie Konfiguration des Hadoop-Ökosystems. Auf jedem Knoten innerhalb des Clusters muss eine korrekte Funktionsweise von Apache Hadoop (ab Version 2.5), MapReduce mit aktiviertem JobHistory-Server, Apache Hive (ab 0.13.1), Apache HCatalog (ab 0.13.1) und Apache HBase (ab 0.98.6 bis < 1.0) mit Zookeeper (ab 3.4.5) sichergestellt sein. Um schnell erste Ergebnisse mit Kylin zu erreichen, wird eine Hadoop-Distribution wie Hortonworks (ab 2.2.0) oder Cloudera (ab 5.3.0) empfohlen.

Derzeit befindet sich Kylin in der Incubator-Version 1.0. Auf der Kylin-Webseite lässt sich das aktuelle Binärpaket herunterladen. Beim Download werden alle kompilierten Komponenten und ein aktueller Tomcat-Webserver bereitgestellt. Vor dem Starten von Kylin ist im Terminal eine neue Umgebungsvariable zu definieren:

export KYLIN_HOME=/absoluter/pfad/kylin-0.7.2-incubating

Zusätzlich ist nach diesem Schritt eine Überprüfung der Rechte notwendig. Der Benutzer braucht für die Generierung des Cubes Schreib- und Ausführrechte in Hadoop, HDFS, Hive und HBase. Kylin stellt für diese Überprüfung ein Shell-Skript zur Verfügung:

sh /bin/check_env.sh

Falls dem ausgewählten Benutzer Rechte fehlen, erhält er Informationen dazu. Sind die Rechte korrekt vergeben, lässt sich Kylin mit folgendem Aufruf starten:

bash bin/kylin start

Der Aufruf benötigt beim ersten Mal einige Zeit. Kylin überprüft nämlich, ob die HBase-Tabellen kylin_metadata, kylin_metadata_user und kylin_metadata_acl existieren. Diese werden benötigt, um Informationen zum Cube, User und seinen Rechten in Kylin zu definieren. Danach lässt sich Kylins Weboberfläche unter http://localhost:7070/kylin aufrufen. Der Standard-Benutzer lautet admin, das zugehörige Standard-Passwort KYLIN.

Kylins Weboberfläche

Die mit AngularJS erstellte Weboberfläche bietet dem Benutzer einem Einblick über die vorliegenden Funktionen in Kylin:

Unter dem Tab "Query" kann der Benutzer SQL-Abfragen an den Cube senden. Eine Historie der der Abfragen bietet die Möglichkeit, zu einem späteren Zeitpunkt die Queries erneut auszuführen. Zudem lässt sich das Ergebnis in Form von Diagrammen darstellen. Das Feature ermöglicht bei der erstmaligen Benutzung von Kylin, das Überprüfen des Apache-Projekts auf Performanz und Tauglichkeit.

Wie der Name erahnen lässt, zeigt der Bereich "Cubes" alle Cubes eines Projekts an. Hier lassen sich neue Cube-Datenmodelle erstellen, Metainformationen darstellen und der Cube-Build-Prozess anstoßen.

Unter "Jobs" wird eine Auflistung aller aktiven oder durchgeführten Cube Builds angezeigt. Dabei werden grundlegende Informationen wie der letzte Modifizierungszeitpunkt, der Besitzer des Cubes und die Ausführungsdauer des Builds dargestellt. Zusätzlich lassen sich alle Schritte des Builds in einer detaillierten Ansicht anzeigen. Wie erwähnt, werden die in Hive befindlichen Daten in mehreren MapReduce-Jobs vorberechnet und in HBase als OLAP-Cube gespeichert. Zudem bietet Kylin die Möglichkeit, alle verwendeten MapReduce-Parameter, die dazugehörigen Logs, Informationen und Details des ausführenden MapReduce-Jobs aufzurufen. Bei einem Problem im Cube-Build-Prozess lässt sich daher genau überprüfen, an welcher Stelle der Prozess aus welchem Grund beendet wurde.

Unter dem Tab "Tables" befindet sich die Sync-Funktion. Sie teilt Kylin vor dem Erstellen eines Cubes mit, welche Tabellen und Spalten bei der Modellierung des Cubes zur Auswahl stehen. Im Tab "Admin" kann der Administrator Kylins Serverkonfiguration und Umgebungsvariablen überprüfen und bei Bedarf neu laden. Zusätzliche Optionen wie das Deaktivieren des Caches, das Aktualisieren der Metainformationen und Links zur Hadoop-Umgebung sind weitere Features der Weboberfläche.

Modellierung & Build-Prozess

Die Cube-Modellierung

Grundvoraussetzung für die Modellierung eines Cubes ist die Abbildung der Daten in HDFS in ein Sternschema in Apache Hive. Bevor sich mit der eigentlichen Modellierung des Cubes beginnen lässt, sind die Tabellen aus dem Hive Metastore mit Kylin zu synchronisieren. Dabei werden im Hintergrund Metainformationen zu den Hive-Metastore-Tabellen erstellt. Dadurch stehen für die Modellierung des OLAP-Cubes alle notwendigen Informationen bereit. Erst nach der Synchronisierung kann man die Modellierung des Cubes Schritt für Schritt interaktiv mit der Weboberfläche aufbauen.

Im ersten Schritt wird der Name des Cubes angegeben. Ein wichtiger Hinweis: Der Cube-Name ist bislang in Kylin über alle Projekte hinweg eindeutig zu wählen. Zusätzlich lassen sich E-Mail-Adressen hinterlegen, an die bei erfolgreichem Ablauf des Build-Prozesses eine Benachrichtigung gesendet wird.

Der nächste Schritt besteht darin, das Datenmodell für den OLAP-Cube in Kylin zu definieren. Nach Auswahl der Faktentabelle lassen sich die Lookup-Tabellen hinzufügen. Dabei ist der Join-Typ (Inner-, Left- oder Right-Join) auszuwählen und um Angaben der Primary- und Foreign Keys zu ergänzen. Dieser Schritt ist für jede gewünschte Dimension des Cubes zu wiederholen.

Sind alle Lookup-Tabellen hinterlegt, werden im dritten Schritt die Dimensionen des Cubes definiert. Hierfür stellt Kylin drei Typen zur Verfügung: "Normal", "Hierarchy" und "Derived". Bei der Auswahl "Normal" wird die Dimension ohne jede Besonderheit zum Cube hinzugefügt. Beim Typ "Hierarchy" bietet Kylin eine hierarchische Anordnung der Attribute einer Dimension an. Wie beschrieben, spielt diese Art der Anordnung eine wichtige Rolle für die Drill-down- und Roll-up-Navigation durch den Cube.

Die letzte Möglichkeit, eine Dimension hinzuzufügen, besteht im Typ "Derived". Hierbei handelt es sich um Attribute einer Dimension, die keinem hierarchischen Aufbau entsprechen und sich eindeutig durch einen Primary Key ableiten lassen. Die Berechnung der Measures basiert damit lediglich auf diesen einzelnen Keys. Das führt zu einer Reduktion der Kombinationsmöglichkeiten der Dimensionen.

Im vierten Schritt werden die Measures des Cubes definiert. Die Auswahl der Aggregationsfunktionen ist bisher auf SUM, MIN, MAX, COUNT und COUNT_DISTINCT beschränkt, die sich je Measure der Faktentabelle auswählen lassen.

Im nächsten Schritt lässt sich optional ein Filter durch eine WHERE-Anweisung einstellen, beispielsweise wenn nur die Einträge aus dem Jahr 2014 oder nur die in Deutschland verkauften Artikel für die Analyse benötigt werden. Das führt zu einer Reduzierung der Cube-Größe und ist besonders sinnvoll, wenn lediglich eine Teilmenge der Daten für die Analyse zur Verfügung gestellt werden soll.

Falls gewünscht, lassen sich im sechsten Schritt die Refresh-Settings definieren. Dadurch ist es möglich, OLAP-Cubes mit neu hinzukommenden Daten zu generieren und mit bestehenden Cubes zu vereinen. Hierbei ist eine Date-Spalte im Format "YYYY-MM-DD" auszuwählen und ein Startdatum anzugeben. In diesem Fall lässt sich der Cube-Build-Prozess nur starten, wenn ein Start-Datum angegeben wird.

Der vorletzte und siebte Schritt besteht aus den fortgeschrittenen Einstellungen, die eine Optimierung des Cubes ermöglichen. Die Profile unter Cube-Size definieren die Größe der HBase-Region-Splits. "Small" generiert HTables mit 10 Gigabyte, "Medium" mit 20 Gigabyte und "Large" mit 100 Gigabyte. Je nach Cluster- und HBase-Konfiguration lässt sich hier ein Performanzgewinn erzielen.

Mithilfe von Aggregation Groups kann man eine weitere Optimierung durchführen. Bei einer großen Anzahl an Dimensionen ist es nicht sinnvoll, jedes Cuboid zu generieren. Beispielsweise wären bei 30 Dimensionen 2^30 (ca. eine Milliarde) Cuboids zu erstellen. Aggregation Groups unterteilen diese 30 Dimensionen in Gruppen. Statt 2^30 Cuboids zu generieren, lässt sich der Cube in drei Gruppen à 10 Dimensionen aufteilen. Die Anzahl der Cuboids reduziert sich dadurch auf 2^10 + 2^10 + 2^10 (= 3072 Cuboids). Sowohl die Berechnungszeit des Cubes als auch der Speicherverbrauch werden hierdurch minimiert. Bei "ungünstigen" Gruppierungen kann jedoch ein fehlendes Cuboid die Ausführungszeit der Analyse stark beeinträchtigen (s. Mid-Latency-Pfad in Abb. 2). Der Einsatz von Aggregation Groups ist von Projekt zu Projekt unterschiedlich und sollte daher wohlüberlegt sein.

In der letzten Einstellungsmöglichkeit lässt sich pro Spalte angeben, ob ein Dictionary angelegt werden soll. Hierbei wird bei der Generierung des Cubes nicht der eigentliche Wert, sondern eine Referenz zum Dictionary gespeichert. Standardmäßig erstellt Kylin für jede Spalte ein Dictionary. Ist die Kardinalität der Spalte hoch (> 1.000.000), sollte aus Performanzgründen keines angelegt werden. Dadurch werden die Werte direkt
im Cube gespeichert und bei der Analyse ausgelesen.

Der letzte Schritt bietet dem Benutzer eine kurze Übersicht über die ausgewählte Faktentabelle, Anzahl der Dimensionen und Measures. Nach Speicherung lässt sich der Cube-Build-Prozess in Kylins Weboberfläche einleiten.

Der Cube Build-Prozess

Nach erfolgreicher Modellierung des OLAP-Cubes lässt sich der Cube-Build-Prozess starten. Anhand der Metainformationen und der Modellierung werden die verschiedenen Dimensionen und ihre Aggregationen berechnet. Abbildung 4 stellt den Workflow dar:

Alle verwendeten Hive-Tabellen des Cubes werden zunächst in einer Intermediate Hive Table zusammengefasst. Das entspricht dem größtmöglichen Cuboid. Anhand dieser Hive-Tabelle werden durch verschiedene Gruppierungen die immer kleiner werdenden Cuboids berechnet. Das geschieht mithilfe mehrerer MapReduce-Jobs. Es ist darauf zu achten, dass der Speicherplatz im HDFS ausreichend groß ist, da die Zwischenschritte dort abgelegt werden.

Zum jetzigen Zeitpunkt ist es notwendig, nach dem erfolgreichen Build die temporären Dateien manuell zu entfernen. Sind alle Zwischenschritte berechnet, werden HFiles erstellt. Das sind Dateien im HDFS, die HBase für die Datenspeicherung verwendet. Der letzte Schritt besteht aus dem Importieren der HFiles in die HBase-Datenbank. Je nach Größe der Datenmenge und des Clusters kann der Build-Prozess einige Zeit beanspruchen. Anschließend ist Kylin für die Verarbeitung analytischer Queries vorbereitet.

Fazit und Ausblick

Trotz seiner noch jungen Historie stellt sich Kylin als ein interessanter und vielversprechender Ansatz dar, um die aus der Business Intelligence bekannten OLAP-Cubes mit Hadoop-Komponenten in das Big-Data-Umfeld zu transportieren.

Bei einer stetig wachsenden Community befindet sich Kylin in einer fortlaufenden Weiterentwicklung. Die erste stabile Version 1.0 wurde am 6. September veröffentlicht. Die Vorteile des Projekts, durch die eine interaktive Analyse eines großen Datenbestands mit etablierten Frameworks aus dem Hadoop-Umfeld möglich ist, sind enorm. Der Einsatz in der Produktivumgebung innerhalb von eBay zeigt, dass Kylin bereits erfolgreich eingesetzt werden kann. Bei Tests läuft es bisher stabil und performant.

An Ideen für zukünftige Verbesserungen und Erweiterungen mangelt es bei Kylin nicht. Zum derzeitigen Zeitpunkt steht die Optimierung der Cube Build Engine weit oben auf der Liste. Die Committer arbeiten zurzeit an der Integration von Apache Spark, um die Ausführungsdauer des Cube-Build-Prozesses zu reduzieren. Ein weiterer interessanter Punkt ist das Upgrade von Apache Calcite auf die Version 1.3, was eine größere Vielfalt an SQL-Abfragen ermöglichen soll. Ferner arbeitet der Autor im Rahmen einer Forschungsarbeit an der Erweiterung der Abfragemöglichkeit unter Verwendung der OLAP-Engine Mondrian. Dadurch soll Kylin zukünftig neben SQL- auch multidimensionale Abfragen in Form von MDX verarbeiten können.

Sébastien Jelsch
ist bei der inovex GmbH in Karlsruhe in der Abteilung Data Management & Analytics beschäftigt. Im Rahmen einer Forschungsarbeit untersucht er die Einsatzmöglichkeiten und Erweiterungen von Kylin. (ane)