Vos rechargements Qlik échouent-ils à mesure que les données grossissent ?

Le moteur associatif est rapide parce que tout le modèle de données vit en mémoire. C’est aussi pourquoi une application pleine de détail brut finit par manquer de place.

Pourquoi l’application ne cesse de grossir

• Le détail ligne à ligne est chargé, des dizaines de millions de lignes, parce qu’aucun agrégat n’existe en amont.
• Les transformations s’exécutent au rechargement. Jointures, recherches et nettoyage consomment de la mémoire avant qu’une seule ligne soit stockée.
• Les rechargements complets ralentissent chaque mois. Une logique incrémentale avec des QVD est possible, mais elle est écrite à la main et fragile.
• Rechargements et utilisateurs partagent la même RAM. Un rechargement lourd entre en concurrence avec les personnes qui utilisent les applications.

Plus de mémoire fait gagner du temps. Cela ne change pas la courbe.

Pourquoi cela retombe sur vous

• Le détail a été chargé parce que c’était la seule table disponible, pas parce que quelqu’un en avait besoin.
• La capacité du serveur, ou les limites de taille d’application de votre tenant Qlik Cloud, ne dépendent pas de vous.
• Vous pouvez supprimer des champs et optimiser le script. Vous ne pouvez pas créer les agrégats en amont.

Le travail se fait au mauvais endroit

• Joindre, agréger et charger de manière incrémentale est un travail de warehouse. Dans Qlik, il est refait à chaque rechargement de chaque application.
• Ce travail a sa place dans un endroit central : un data warehouse ou un data hub, construit une fois et lu par chaque application.
• Si cela semble coûteux, l’estimation suppose probablement des pipelines construits à la main. Une plateforme d’automatisation spécialisée les génère à partir d’un modèle, ce qui change à la fois le coût et le délai.

Ce qui change quand le modèle arrive prêt à l’emploi

Datavault Builder génère le vault et les information marts nativement dans la base de données dont l’entreprise dispose déjà, comme Snowflake, Databricks, Synapse, Fabric ou Exasol.

• Des marts agrégés à la granularité dont l’application a besoin, donc beaucoup moins de lignes arrivent en mémoire.
• Le chargement incrémental se fait en amont, généré plutôt que scripté à la main.
• Le rechargement copie, il ne calcule pas. Il devient un simple LOAD depuis des tables finies.
• La taille de l’application suit la question, pas la taille du système source.
• Le détail reste dans le warehouse, accessible quand quelqu’un a réellement besoin d’y descendre.

Ce qu’il faut demander

Pas « le rechargement échoue sans arrêt », mais :

« Notre application charge chaque ligne de transaction et fait les jointures pendant le rechargement, c’est pourquoi elle manque de mémoire. Peut-on obtenir un mart agrégé dans le warehouse, chargé de manière incrémentale, que l’application n’aurait plus qu’à lire ? »

Si la réponse est que construire correctement les marts prendrait un trimestre, c’est l’objection que Datavault Builder a été conçu pour lever.