Eine schnellere Welt erfordert schnellere Daten. Qlik bietet für Datenloads eine mächtige In-Memory Engine und effiziente Speicherformate. Doch die nächtliche Datenaktualisierung reicht oft nicht mehr aus, es müssen mehr Daten häufiger nachgeladen werden. Das führt zu Auslastungsproblemen und einem Daten-Overload auf der Qlik-Plattform und Frust bei Nutzern und Entwicklern.

Qlik Daten-OverloadÜberlastung mit Reload-Tasks

Je mehr Qlik-Applikationen produktiv laufen, desto mehr Ladeprozesse werden in der Qlik Management Konsole (QMC) eingerichtet. Oft teilen sich mehrere Bereiche eine Qlik-Plattform und alle wollen ihre Daten zur gleichen Zeit, möglichst nachts, laden, damit zum morgendlichen Arbeitsbeginn alle Applikationen aktualisiert bereitstehen. Die Nacht ist lang und die Beteiligten werden sich einig, wer in welchem Zeitfenster seine Tasks einplant. Doch spätestens bei einem zweiten Datenlauf mittags, um für den Nachmittag noch aktuellere Daten zu bekommen, wird es jetzt eng auf der QMC. Der sogenannte Scheduler, der die Tasks in der QMC verwaltet und die Reloads durchführt, hat nur begrenzte Ressourcen und kann nur eine bestimmte Anzahl Tasks gleichzeitig ausführen. Alle weiteren Tasks, die getriggered werden, starten nicht, sondern landen in der Warteschlange.
Die Sanduhr der Warteschlange ist zum verhassten Symbol aller Nutzer von vollen Qlik-Plattformen geworden. Hier hilft Up-Scaling des Qlik Schedulers.

Qlik Daten-Overload

Statt nur einem Scheduler auf der QMC können sich auch mehrere Scheduler die Arbeit teilen. Damit wird auch linear die Anzahl der Tasks, die parallel ausgeführt werden können, erhöht.

Hier können je nach Konfiguration die Scheduler einfach parallel laufen und sich die Tasks aus der Warteschlange greifen. Das kann allerdings dazu führen, dass die CPU beider Scheduler zwar ausgeglichen ist, sie sich in der RAM-Auslastung aber deutlich unterscheiden. Beispielsweise, weil ein Scheduler immer einfache kleinere Load und Store Tasks ausführt, der andere aber große Datenmengen verknüpft oder aggregiert.

Die bessere Wahl bei unterschiedlichen Tasks ist die Konfiguration, dass ein bestimmter Scheduler als Master dient, das Load Balancing durchführt und die Tasks auf die anderen Scheduler als Slaves verteilt.
Auch kann es nötig sein, den oder die Scheduler selbst mit mehr Power auszustatten. Ein paar GB mehr RAM für den Scheduler wirken wahre Wunder, was Taskabbrüche anbelangt, die der Auslastung der Plattform zuzuschreiben sind.

Überlastung des Hubs oder des Laufwerks

Je mehr Entwickler auf der Plattform sind, desto öfter gibt es auch Probleme beim Daten laden im DEV-Hub, dem Qlik-Entwicklungsserver. Jeder möchte sein Skript einmal schnell testen oder seine gerade entwickelte Applikation einmal reloaden und so wird der Weg gespart, eigens einen Task dafür anzulegen, indem im DEV-Hub geladen wird. Läuft das Skript auf einen Fehler, so muss kein Logfile durchsucht werden, sondern es kann direkt während des Datenladens jeder Schritt mitverfolgt werden und das Skript direkt debugged werden. Kein Wunder also, dass nicht nur ein einziger Entwickler auf diese Idee kommt und da geht der DEV-Knoten schon mal in die Knie. Abhilfe schafft hier ein Upscaling des DEV-Hubs.

Wenn die Qlik-Plattform dann stabil läuft und fleißig Daten läd, müssen diese schlussendlich auch irgendwo abgespeichert werden. Auch wenn Qlik mit den QlikView-Daten (QVD) ein eigenes sehr kompaktes Dateiformat entwickelt hat, kann das Qlik-Laufwerk voll werden. Zumindest wenn sich der Entwickler an das Best Practice Vorgehen hält und die Daten mehrfach als QVDs vorhält, einmal als direkter Quellabzug und einmal bereits transformiert und fertig fürs Einladen in die Apps. Hier gibt es die Möglichkeit weitere NAS-Laufwerke einzuhängen, um den Speicherplatz zu erhöhen.

Je mehr Daten ein Kunde hat und je unterschiedlicher die Ladestrategien sind, desto komplizierter wird es. Hier sind passgenaue Lösungen gefragt.

Ü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.