Performance-Optimierungen in Qlik (Qlik Sense und QlikView) zählen zu den Aufgaben, in die man leicht viele Stunden investiert. Wie in vielen anderen Bereichen gilt aber auch hier die 80 / 20 Regel: Mit 20% des Aufwandes werden oft 80% des gewünschten Resultats erzielt.
In der Praxis gibt es bei Qlik genau 3 Massnahmen, die Sie zuerst angehen sollten, um die grössten Performance-Gewinne zu erzielen:
- Reduzieren: Nur die benötigten, nicht alle möglichen Daten in einer App vorhalten.
- Strukturieren: Ein strukturiertes Stern-Datenmodell etablieren statt einzelne (Fakten-) Tabellen wild zu verknüpfen.
- Vereinfachen: Nur einfache Aggregationsformeln im GUI implementieren, keine komplexe (Daten-) Probleme lösen.
In seltenen Fällen klagen die Endanwender auch nach Umsetzung dieser drei Massnahmen weiterhin über mangelhafte Performance. Hier lohnt es, das Benutzerverhalten im Detail zu erheben, um die Schwachstellen einer App gezielt zu eliminieren. Das kann der/die Qlik-Applikationsverantwortliche entweder selbständig vornehmen oder wir begleiten ihn mit einem Healthcheck - dem Qlik PLUS:
Schauen wir uns nun die drei erwähnten Massnahmen zur Performance-Optimierung in QlikView und QlikSense genauer an...
1 Datenreduktion: Nur benötigte Daten laden - und trotzdem den Informationsgehalt bewahren
In den meisten Fällen genügt bereits dieser Schritt, um die Performance-Probleme zu beheben. Allerdings birgt dies Konfliktpotenzial: Viele Endanwender betrachten eine Reduktion der Datenmenge als Verlust an Informationen.
Hier ist eine enge Abstimmung mit dem Fachbereich gefragt, um sicherzustellen, dass nach der Optimierung der grösstmögliche Informationsgehalt erhalten bleibt. Wie kann nun also die Datenmenge konkret reduziert werden?
- maximal 3-5 Jahre einbeziehen: Oft sieht man in Problemapplikationen Daten der letzten zehn oder noch mehr Jahre. Doch wie oft werden die mehr als 5 Jahre alten Daten tatsächlich konsumiert?
Meist kommt das eher selten vor, also können die Daten gelöscht werden. Alternativ können sie in eine Archiv-App ausgelagert werden, so dass der Informationsgehalt mit zwei oder drei Klicks mehr erhalten bleibt. - maximal 5-10 Mio. Datensätze vorhalten: In vielen Fällen reichen 5 bis max. 10 Millionen Datensätze pro App aus, um die relevanten Business-Fragen zu beantworten. Wobei die Grössenordnung natürlich abhängig ist vom Anwendungsfall - es gibt auch perfomante Apps mit ~50 Mio und mehr Datensätzen.
Bei überschaubarem Datenvolumen reichen übrigens meistens auch RAM/CPU-Standardkonfigurationen beim Qlik-Applikations-Server, weitere Massnahmen werden damit zweitrangig. Die «überzähligen» Daten verlagern Sie am besten in Detail-Applikationen (mit intelligentem Absprung) oder in Backup-Apps, die nur bei Bedarf geöffnet werden. - Daten aggregieren: Aggregierte Daten sind bei vielen Endanwendern unbeliebt, weil sie einen Verlust an Informationsgehalt befürchten. Das ist im Grunde auch richtig: Werden Daten im Datenmodell (oder auf Stufen davor) aggregiert, fallen Detailangaben oft automatisch weg.
Hier gilt es also, in enger Abstimmung mit dem Auftraggeber zu prüfen, ob bspw. tatsächlich alle Ausprägungen einer Buchung benötigt werden oder ob es reicht, den Wert pro Kostenstelle und Monat zu aggregieren? Ein sinnvoller Kompromiss findet sich oft mit einer Detail-Applikation mit intelligentem Absprung. - Anzahl der Felder reduzieren: Immer wieder entstehen Faktentabellen mit Dutzenden von Feldern - man weiss ja schliesslich nie, ob morgen das eine oder andere Feld nicht doch benötigt wird…
Hier sollten alle im GUI nicht verwendeten Felder spätestens beim Aktualisieren der Frontend-App entfernt werden. Wird ein Feld auch im Datenmodell nicht verwendet, dann ist es auch dort zu entfernen.
Gerade Timestamps sind bei vielen Feldern unnötig! Angenehmer Zusatzeffekt dieser Reduktion: deutlich bessere Ladezeiten.
2 Ein strukturiertes Stern-Datenmodell als roter Faden in der Datenmodellierung
Das Sternmodell ist nicht nur für Qlik optimal, sondern gilt auch für andere BI-Technologien als Best-Practice-Verfahren. Dabei steht eine Faktentabelle in der Mitte, die mit verschiedenen Dimensionstabellen ringsherum direkt verknüpft ist. Das Datenmodell ist aufgeräumt und auf einen Blick zu erkennen.
Den Gegensatz dazu bildet das Snowflake-Modell: Angelehnt an der Form einer Schneeflocke hängen oft mehrere Fakten- mit vielen Dimensionstabellen zusammen, wobei eine Dimensionstabelle auch auf weitere Dimensionstabellen zeigen kann. Man erkennt weder ein Zentrum noch eine Struktur des Datenmodells.
Je grösser das Datenvolumen (Anzahl Datensätze / Anzahl Felder) und je mehr Faktentabellen involviert sind, desto grösser ist der Performance-Gewinn eines Sternmodells. Je geringer das Datenvolumen (< 5 Mio. Datensätze), desto weniger schadet ein Snowflake-Modell.
3 Nur einfache Aggregationsformeln im GUI - Datenprobleme werden im Modell gelöst
Komplexe Berechnungen schleichen sich oft schneller ein als man denkt: Eigentlich wollte man im Balkendiagramm «nur» schnell eine einfache Summe bilden... doch dann kommt eine Bedingung hinzu... dann eine weitere... und ehe man es sich versieht, belegt die Formel mehrere Zeilen.
Oft steckt eine gute Absicht dahinter, man will ja verschiedene Anwendungsfälle berücksichtigen und korrekte Werte darstellen, oder ein paar Stunden vor dem Go-Live noch den Input des Controllers berücksichtigen. Häufig plant der App-Verantwortliche, die Formel später zu bereinigen, vergisst es dann aber...
Je mehr solcher Fälle in einer App auftreten, je komplexer die Aggregationsformeln werden, desto eher leiden die Antwortzeiten. Der oben erwähnte Controller wird übrigens einer der ersten sein, der das Performance-Problem anspricht … Auch der Aufwand im Unterhalt wächst erheblich, deshalb gilt:
Datenprobleme werden im Datenmodell gelöst, nicht in der Aggregationsformel im Frontend!
Typisches Beispiel:
Abhängig von einer bestimmten Kostenstelle sollen unterschiedliche Wertfelder summiert werden.
Dieses Problem gehört im Datenmodell gelöst, nicht im Formelfeld an der Oberfläche, mit dem Ziel: Sum(Wert5). Wobei Wert5 die oben erwähnte Logik beinhaltet. Gleichzeitig wird sichergestellt, dass die Messgrösse / Kennzahl in der Oberfläche so dokumentiert wird, dass der Endanwender jederzeit die Herleitung nachvollziehen kann.
Reduzieren, Strukturieren und Vereinfachen – mit diesen drei Massnahmen lässt sich die Performance von Qlik-Anwendungen oft mit wenig Aufwand signifikant verbessern.
Wenn Sie diese Optimierungen implementiert haben, die Endanwender aber noch immer über mangelhafte Reaktionszeiten der Qlik-App (QlikView oder Qlik Sense) klagen, ist es Zeit für eine Detailanalyse:
Kontaktieren Sie uns für einen unverbindlichen "App-Healthcheck" und wir zeigen auf, welche Potenziale in Ihren Apps stecken.
Das Qlik® Performance PLUS - ON-DEMAND-EVENT (Deep Dive)
Profitieren Sie von den umfangreichen Projekterfahrungen unserer Qlik Experten und erfahren Sie, welche Stolpersteine mit der Zeit entstehen können und wie Sie sie aus dem Weg räumen können.
>>Jetzt anmelden und mehr erfahren!
