Heute möchten wir eine kleine aber schicke und insbesondere performante Lösung aus dem Essbase-Umfeld vorstellen, die unserer Erfahrung nach in vielen Projekten genutzt werden kann.

Den Ausgangspunkt stellen Dateneingaben durch User in Essbase-Würfel dar. Diese finden häufig im Rahmen von Planungsapplikationen statt. Nach der Eingabe durch den User liegen diese Daten nur im Würfel vor und müssen zu Zwecken der Weiterverarbeitung und auch Datensicherung erst wieder daraus exportiert werden. Da Dateneingaben meist mit anschließenden Kalkulationen verbunden sind, finden Dateneingaben weit überwiegend in Würfeln des Typs BSO statt. Der optimierte Export von Daten aus diesem Würfeltyp wird im Folgenden näher betrachtet.

Technisch können Daten auf unterschiedliche Arten mit unterschiedlichen Zielformaten aus einem Essbase-Würfel exportiert werden.

1. Export direkt in eine relationale Datenbank
   • durch ein Kalkulationsskript (DATAEXPORT)
2. Export in eine formatierte Datei (csv, txt, o.ä.)
   • durch ein Kalkulationsskript (DATAEXPORT)
   • durch ein MaxL-Skript (export database)
   • durch eine MDX-Abfrage
   • durch ein Report Skript
3. Export nach Excel
   • durch eine Smart View Abfrage
4. Export in eine Java-Datenstruktur
   • durch die Java API

Zu bevorzugen ist aus unserer Sicht die Variante „1. Export direkt in eine relationale Datenbank“. In der relationalen Datenbank können die Daten im Anschluss einfach gesichert und auch weiter verarbeitet werden. Zum Beispiel können die aktuellen Planzahlen dem Reportingsystem zur Verfügung gestellt werden. Daher fokussieren wir uns im Weiteren auf diese Variante.

Essbase stellt seit einigen Versionen dafür eine erweiterte Funktionalität des Kalkulationskommandos DATAEXPORT bereit. Dieses kann über den Parameter „DSN“ eine ODBC-Verbindung nutzen und somit als Datenziel direkt in eine relationale Datenbanktabelle schreiben. Dabei sollte man den Export so konfigurieren, dass der sogenannte „batch-insert“ Modus verwendet wird. Ein „batch-insert“ bedeutet, dass Essbase die Daten in Paketen mit bis zu 1000 Datenzeilen auf einmal an die Datenbank sendet. Dort werden die Daten dann in die Zieltabelle eingefügt, bevor das nächste Datenpaket geschickt werden kann. Dies ist eine recht effiziente Vorgehensweise, welche für einen schnellen Datentransfer sorgt.

Hier sehen Sie als Beispiel ein Kalkulationsskript für den direkten Export in die Datenbank:

SET DATAEXPORTOPTIONS
	{
	DataExportLevel Level0;
	DataExportDynamicCalc  OFF;
	DataExportNonExistingBlocks  OFF;
	DataExportRelationalFile ON;
	DataExportOverwriteFile ON;
	DataExportDecimal 10;
	};

FIX ("P01":"P12",&PlanYear,&PlanScenario)
	DATAEXPORT "DSN" "ODBC_Conn" "DATA_EXPORT_PLAN" „SQL_U" „SQL_P";
ENDFIX

Dabei haben die Parameter folgende Bedeutung:

• ODBC_Conn: Name der ODBC DSN, welche auf Betriebssystemebene angelegt wurde
• DATA_EXPORT_PLAN: Name der Zieltabelle
• SQL_U: User für die Verbindung zur relationalen Datenbank
• SQL_P: Passwort für die Verbindung zur relationalen Datenbank

Das Ausführen dieses Skriptes führt einen Datenexport direkt in die Zieltabelle der relationalen Datenbank durch. Die meisten Leser, die sich bereits mit diesem Thema beschäftigt haben, werden vermutlich früher oder später auf den folgenden Hinweis in der „Technical Reference“ von Essbase gestoßen sein:

„64-bit Essbase does not support using the DATAEXPORT batch-insert method to export data directly into a SQL data source.”
(Quelle: “Oracle Essbase Technical Reference” https://docs.oracle.com/cd/E57185_01/ESBTR/dataexport.html )

In der heutigen Zeit sind 64-bit Essbase Server jedoch Standard, so dass die oben zitierte Einschränkung fast universell gilt. Als Folge sendet ein 64-bit Essbase-Server bei dem identischen DATAEXPORT Kommando die Daten zeilenweise an die Datenbank. Diese fügt jeweils die neue Zeile in die Zieltabelle ein und gibt Essbase das Signal, die nächste Zeile zu senden. Eine solche Vorgehensweise ist unnötig langsam und kann bereits bei wenigen hundert Zeilen Datenexport zur merklichen Verzögerungen führen. Bei größeren Datenexporten mit einer vier- bis fünfstelligen Anzahl an exportierten Datenzeilen kann dieser Punkt zu massiven Performance-Problemen führen.
Um dieses Bottleneck zu umgehen, bietet sich der Umweg über Dateien an. Dabei erfolgt der Export in csv-Dateien. Diese werden im Anschluss in die relationale Datenbank geladen und stehen dann dort zur Verfügung. Dabei lassen sich beide Teilschritte zusätzlich noch parallelisieren.

Für den ersten Schritt muss man das obige Kalkulationsskript wie folgt anpassen:

FIXPARALLEL (8,@LEVMBRS ("Entity",0))
	FIX ("P01":"P12",&PlanYear,&PlanScenario)
		DATAEXPORT "File" ";" "D:\DataExport\PlanDataExport.txt";
	ENDFIX
ENDFIXPARALLEL

Die DATAEXPORTOPTIONS bleiben identisch, der Export erfolgt jedoch in eine Datei. Weiterhin wird eine Parallelisierung mittels des Kommandos FIXPARALLEL erreicht. Damit wird der Export achtfach parallel ausgeführt. Entsprechend werden acht Ausgabedateien erzeugt. Diese sind im Dateinamen um den Postfix „…_Ty.txt“ ergänzt, wobei y eine Zahl zwischen 1 und 8 ist. (also z.B. PlanDataExport_T4.txt) Weiterhin greift beim Export in eine Datei die Einschränkung bezüglich des „batch-insert“ nicht. Diese beiden Änderungen führen zu einer bemerkenswerten Beschleunigung des reinen Export-Vorganges.

Nun liegen die Daten in Dateien auf der Festplatte des Essbase-Servers und müssen noch in die Zieltabelle der relationalen Datenbank geladen werden. Dazu empfehlen wir die Nutzung der von der jeweiligen Datenbank mitgelieferten Tools zum schnellen Laden großer Datenmengen aus Dateien. Für eine Oracle Datenbank wäre dies der „SQL Loader“ oder „External Tables“, für den SQL Server „BCP“ oder „BULK INSERT“. Andere Datenbanksysteme bringen meist ähnliche Tools mit. Auch hierbei kann der Datenimport teilweise noch parallelisiert werden.

Auf einer virtuellen Testmaschine haben wir in Kombination von einem 64-bit Essbase-Server mit einer relationalen Oracle-Datenbank folgenden Zeiten messen können:

1. Direkter SQL-Export aus Essbase in die rel. Datenbank (zeilenweise)
   52 Sekunden
2. Export aus Essbase in Datei, Import aus Datei in die rel. Datenbank (nicht parallel, 1 Datei)
   12 Sekunden -> 77% Beschleunigung
3. Export in Datei aus Essbase, Import aus Datei in die rel. Datenbank (parallel mit 2 Prozessen)
   8 Sekunden -> 85% Beschleunigung

Selbst in diesem begrenzten Test-Setup kann man schon das Optimierungspotential erkennen.

Also probieren Sie es aus …

Bei Fragen oder Interesse an weitergehenden Informationen zu diesem Thema, schreiben Sie uns eine Email an info@partake-consulting.com oder rufen Sie uns an unter 02132/5100400.