In dem fünften Beitrag unserer Qlik-Reihe geht es um das performante Verarbeiten von Daten in Qlik durch Aggregieren, Joinen und Parallelisieren.

Alle Daten sind angebunden, das Skript läuft ohne Fehler, das Qlik-Dashboard ist fertig. Um aktuelle Daten in das Dashboard zu laden, wird der Reload-Knopf gedrückt und jetzt läuft der Task und läuft und läuft und läuft… . Um diese Situation zu vermeiden, sollte bereits bei der Erstellung des Qlik-Skripts darauf geachtet werden, die Verarbeitung der Daten möglichst performant zu gestalten.

In der Datenverarbeitung sind die Qlik-Prozesse, welche viel Zeit in Anspruch nehmen, häufig Schleifen oder Aggregierungen oder Joins großer Datensätze. Doch „For/while-Schleifen“ sollten überall vermieden werden, wo es möglich ist.

Performantes Aggregieren

Bei Aggregierungen mit der Verwendung group by kann es von Vorteil sein, die Datensätze vorher nach der Dimension zu sortieren, auf die aggregiert wird.

Vor allem bei mehreren Dimensionen kann zu deutlichen Verbesserungen in der Performance führen.

Sobald eine große Tabelle nach mehreren Dimensionen aggregiert wird, ist es schneller, zunächst ein Schlüsselfeld aus diesen Dimensionen zu bilden, dann nur auf den Schlüssel zu aggregieren und später die Dimensionen wieder hinzuzunehmen. Die Funktion Autonumber() eignet sich hierfür besonders gut, weil sie einen zusammengesetzten Schlüssel mit numerischen Werten bildet und daher dieser Schlüssel schneller von Qlik verarbeitet werden kann.

Die Aggregierung selbst läuft hier jetzt lediglich noch über ein nummerisches Schlüsselfeld. Bei großen Datensätzen ist dieser Weg performanter, obwohl zusätzlich der Schlüssel erst gebildet werden muss und die Felder später per Left Join angehängt werden müssen.

Performantes Joinen

Auch ein Join kann die Ladegeschwindigkeit des Skripts deutlich ausbremsen. Muss nur ein Feld hinzugefügt werden, ist ein ApplyMap() wie hier links dargestellt schneller als ein Left Join wie unten dargestellt. Bei mehreren Feldern wiederum wäre ein Left Join schneller.

Parallelisierungen

Die Optimierung innerhalb des Skripts klappt nicht immer. Manchmal sind langsame Berechnungen einfach notwendig und es gibt keine Möglichkeit, diese durch eine schnellere Alternative zu ersetzen. Hier kommt eine weitere gute Option ins Spiel, um viel Zeit im Skript einzusparen: Parallelisierungen. Teile der Datenverarbeitung können manchmal ausgelagert werden und laufen dann parallel.

Beispielsweise könnte ein größerer Join oder eine Aggregierung in ein separates Skript geschrieben werden und diese könnte dann parallel zu anderen unabhängigen Datenverarbeitungen laufen. Das Skript speichert das Ergebnis in eine QVD und diese QVD kann im anderen Skript wieder optimiert eingelesen werden.

Nachfolgendes Beispiel zeigt ein Datenmodell, in dem lokale Umsatzdaten aus verschiedenen Verkaufsstandorten weltweit zu einer Tabelle mit vergleichbaren Werten in Währung EUR umgewandelt wird, die mit Informationen zum Standort angereichert wird.

Anstatt alle Datenverarbeitungsschritte in einem Datenmodell-Skript durchzuführen, wurden hier zwei Skripte verwendet, die dann parallel über zwei verschiedene Tasks laufen können und dadurch die finale Tabelle schneller zur Verfügung stellen können.
Datenmodell 1 nimmt das Datum und den Umsatz aus der lokalen Sales-Tabelle und führt mit einer Wechselkurs-Tabelle eine Währungsumrechnung durch. Die Euro-Umsätze werden dann abgespeichert. Währenddessen hat Datenmodell 2 zu den Verkaufsstandorten weitere Informationen gesammelt. Hier werden mehrere Joins durchgeführt und daher hat Datenmodell 2 eine längere Laufzeit als Datenmodell 1. In Datenmodell 2 kann daher dann direkt noch die fertige Euro-Sales Tabelle eingebunden werden.

Über die Autorin

Daniela Pohl berät und betreut als Senior Consultant Kunden im Bereich Reporting und Analytics. Ihr Schwerpunkt liegt dabei auf den Themen Frontendentwicklung und Konzeption.

Daniela Pohl gehört zum Team Reporting & Analytics.