Seite 3: Modellierung & Build-Prozess

Inhaltsverzeichnis

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.