Langsame Essbase-Datenimporte? So beschleunigst du ASO-Loads mit Parallelisierung

Wie Daten in Essbase-Cubes geladen werden

Essbase Würfel werden mit zwei unterschiedlichen Arten von Daten beladen: 

1. Zuerst mit den Strukturdaten der Dimensionen, um die Outline zu definieren. 
2. Anschließend mit den zu den Dimensionen passenden Faktendaten, um die Datengrundlage für Auswertungen bereit zu stellen.

Ein spannender Ansatz zur Optimierung findet sich beim Laden größerer Mengen Faktendaten in Würfel vom Typ ASO, welche typischerweise für Reportingapplikationen einsetzt werden.

Technisch können über verschiedene Wege Daten in einen Würfel gelangen. Am weitesten verbreitet ist sicherlich das Laden mittels Load Rules aus relationalen Datenbanken oder Dateien (csv, txt, o.ä.).

Auch ein Datenupload über ein Userfrontend (Smart View, Hyperion Planning oder Drittanbietertools) ist möglich.

Ebenso können technisch über API Schnittstellen (z.B. Java API) Daten in den Cube geladen werden. Für das regelmäßige Laden größerer Mengen Daten wird normalerweise eine relationale Datenbank als Quelle verwendet, weswegen die folgende Optimierung auf dieses Szenario fokussiert.

Einfaches Datenladen

Als Ausgangsbeispiel soll folgender MaxL Befehl dienen, welcher Daten aus einer relationalen Datenquelle mittels der Load Rule „l_Daten“ in den ASO Würfel „ASOSampl.Basic“ lädt:

import database ASOSampl.Basic data connect as SQL_U identified by SQL_P using rules_file l_Daten;

SQL_U und SQL_P sind dabei der Username und das Passwort für die relationale Datenbank.

Technisch wird dabei der im folgenden Bild illustrierte Prozess durchlaufen:

Die Load Rule erzeugt eine SQL Abfrage, welche an die relationale Datenbank zur Ausführung gesendet wird. Als Resultat werden Daten von der relationalen Datenbank in einen Essbase Load Buffer importiert.
Nach dem kompletten Laden aller Daten in den Load Buffer werden die Daten von dort in den Würfel importiert und stehen damit zur Verfügung. Bei großen Datenmengen ist im Normalfall der erste Importschritt von der relationalen Datenbank in den Essbase Load Buffer der Teil, welcher den Prozess verzögert.

Der zweite Schritt vom Load Buffer in den Würfel findet rein intern im Essbase Server statt und ist daher zu vernachlässigen. Bei der Untersuchung einer Verzögerung muss beachtet werden, welcher Teil des ersten Schrittes langsam ist. Unter Umständen kann auch die SQL Abfrage eine lange Ausführungszeit auf der Datenbank aufweisen. In diesem Fall sollte dort mit der Suche begonnen werden. Falls die Verzögerung beim Import in den Load Buffer auftritt, kann das Folgende Abhilfe schaffen.

Paralleles Datenladen (Standard)

Um hier zu optimieren, gibt es die Möglichkeit den ersten Schritt zu parallelisieren. Im Standard bietet Essbase die Möglichkeit einer maximal achtfachen Parallelisierung. In dem folgenden Beispiel wird eine vierfache Parallelisierung durchgeführt.

Dazu müssen die zu ladenden Daten in vier disjunkte Teile zerlegt werden. Dies kann zum Beispiel nach Szenario (Actual, Budget, Forecast, Actual Vorjahr, …), nach Jahr oder auch nach Inhalt (Sales, Inventory, Purchase, …) erfolgen.

Für jeden Teil dieser Daten muss eine eigene Load Rule erstellt werden. Die Load Rules können dann parallelisiert mit dem folgenden MaxL Befehl ausgeführt werden:

import database ASOSampl.Basic data connect as SQL_U identified by SQL_P using multiple rules_file l_Daten1, l_Daten2, l_Daten3, l_Daten4 to load_buffer_block starting with buffer_id 50;


Damit wird der Prozess wie folgt aussehen:

Dabei werden alle Load Rules parallel gestartet und die jeweilige SQL Abfrage an die relationale Datenbank geschickt. Von dort kommen die Daten zurück und werden in mehrere Load Buffer (je einer pro Load Rule) importiert. Nach Abschluss des letzten Imports aus der relationalen Datenbank in den Load Buffer werden im Folgenden die Daten aus allen Load Buffern gleichzeitig in den Würfel importiert und stehen damit zur Verfügung.

Damit kann im Regelfall eine signifikante Beschleunigung erreicht werden.

Paralleles Datenladen (Erweitert)

Falls man mehr als acht parallele Ladeprozesse verwenden möchte, muss man ein wenig mehr Handarbeit betreiben. Es muss jeweils manuell pro Prozess ein Load Buffer initialisiert werden, die Daten müssen aus der relationalen Datenbank in diesen Load Buffer importiert werden und abschließend müssen die Daten aus allen Load Buffern in den Würfel importiert werden. 

Diese Schritte wurden im obigen Beispiel alle automatisch im Hintergrund während der Ausführung des einen MaxL Befehls durchgeführt.

Der Prozess sieht dann logisch wie folgt aus:

• Schritt 1 initialisiert die Load Buffer
• Schritt 2 importiert die Daten in den Load Buffer
• Schritt 3 importiert die Daten aus allen Load Buffern in den Würfel

In der Ausführung würde man Schritt 1 und 2 jeweils in einem MaxL Skript wie folgt kombinieren:

alter database ASOSampl.Basic initialize load_buffer with buffer_id 101 resource_usage 0.25;

import database ASOSampl.Basic data connect as SQL_U identified by SQL_P using rules_file l_Daten1 to load_buffer with buffer_id 101;


Die Skripte für die weiteren Load Rules werden analog aufgebaut, mit jeweils eigenen Buffer IDs.

Diese Skripte müssen auf Betriebssystemebene parallel jeweils in einer MaxL-Shell ausgeführt werden.

Weiterhin muss ein Synchronisationsmechanismus verfügbar sein, der den nächsten Schritt erst ausführt, wenn die letzte parallele Ausführung beendet ist.

Schritt 3 wird dann wie folgt ausgeführt:

import database ASOSampl.Basic data from load_buffer with buffer_id 101, 102, 103, 104 override values;

Dabei werden die Daten in den Würfel importiert und die Load Buffer direkt gelöscht.
Auf diesem Wege sind mehr als acht parallele Ladeprozesse möglich. Wichtig dabei ist, dass man die Auslastung sowohl des Essbase-Servers als auch des Systems mit der relationalen Datenbank im Auge behält.

Dort wird die Abarbeitung der parallel eintreffenden SQL Abfragen u.U. intern noch weiter parallelisiert, was – je nach Systemgröße – zu einer nicht zu unterschätzenden Last führt. In einem Kundenszenario haben wir dieses Setup mit bis zu 19 parallelen Prozessen getestet, sind im Endeffekt aber mit 12 parallelen Prozessen in den Regelbetrieb gegangen, um die Systeme nicht zu überlasten.