Votre dashboard Tableau est-il lent à chaque changement de filtre ?
Vingt secondes de « Exécution de la requête » à chaque clic sur un filtre. Tableau n'affiche pas lentement. Il attend une base de données à qui l'on a posé une question à laquelle elle ne peut pas répondre rapidement.
La plateforme d'automatisation de data warehouse à laquelle font confiance les équipes data de tous les secteurs
Cela vous semble familier ?
- Changer un filtre affiche « Exécution de la requête » à l'écran pendant vingt secondes ou plus.
- L'enregistrement des performances montre presque tout le temps passé dans l'exécution des requêtes, et presque rien dans l'affichage.
- Le dashboard fonctionne bien avec un trimestre de données et devient inutilisable avec trois ans.
- Vous avez commencé à masquer des filtres pour éviter que les utilisateurs ne déclenchent le chemin lent.
Tableau n’est pas la partie lente. VizQL transforme chaque interaction en SQL, et le temps que cela prend dépend entièrement de la forme de ce qu’il interroge.
Ce qu’on demande à VizQL
- Sur un schéma en étoile : une table de faits, quelques jointures de dimensions sur de vraies clés. La réponse arrive en millisecondes.
- Sur de la 3NF ou des tables brutes : des jointures sur une douzaine de tables, reconstruites pour chaque repère, chaque filtre, chaque utilisateur.
- Rien sur quoi indexer. Les tables opérationnelles sont indexées pour les transactions, pas pour les colonnes selon lesquelles les analystes regroupent.
- L’effet se cumule. Chaque feuille du dashboard envoie sa propre requête.
Pourquoi cela retombe sur vous
- La source de données qu’on vous a fournie est celle qui existait, pas une source conçue pour l’analyse.
- Le SQL personnalisé et les fusions de données étaient le seul moyen de faire fonctionner le tout, et ils alourdissent chaque requête.
- Vous pouvez optimiser le classeur. Vous ne pouvez pas remodéliser la source.
Le travail se fait au mauvais endroit
- Joindre des tables brutes pour en faire quelque chose d’analysable est un travail de warehouse. VizQL le refait à chaque changement de filtre.
- Ce travail a sa place dans un endroit central : un data warehouse ou un data hub, construit une fois et lu par chaque classeur.
- 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 faits et dimensions nativement dans Snowflake, Databricks, BigQuery, Synapse, SQL Server, Oracle, Exasol ou PostgreSQL, conçus pour l’accès analytique.
- Une table de faits, des dimensions conformes. VizQL émet du SQL court par construction.
- De vraies clés, donc des jointures sur une seule colonne plutôt que des correspondances de chaînes sur plusieurs champs.
- Une seule granularité par table, ce qui supprime les lignes dupliquées qui gonflent les scans.
- Les connexions en direct restent utilisables, donc un extrait devient un choix plutôt qu’une échappatoire.
- Les filtres répondent assez vite pour que vous puissiez les remettre sur le dashboard.
Ce qu’il faut demander
« VizQL fait des jointures sur des tables normalisées à chaque clic sur un filtre, donc le temps de requête augmente avec le volume de données. Peut-on obtenir un schéma en étoile auquel ce dashboard se connecterait, à la place des tables opérationnelles ? »
Cela nomme le mécanisme et désigne la couche où le problème peut être corrigé.
Voyez-le fonctionner sur vos propres données
Réservez une démo gratuite et apportez le rapport qui vous pose le plus de problèmes.
Trois étapes vers des chiffres qui concordent
-
Extraire la logique existante
Rassemblez les calculs, jointures et filtres qui vivent aujourd’hui dans vos rapports.
-
La centraliser en un seul endroit
La logique passe une seule fois dans le modèle du warehouse, et chaque rapport lit la même définition.
-
Des chiffres qui concordent
Chaque rapport affiche le même chiffre, et « d’où vient ce chiffre » a une réponse visible.
Comment Datavault Builder fournit à votre rapport un modèle prêt à l'emploi
-
Le modèle arrive prêt à l'emploi
Datavault Builder génère le vault et le schéma en étoile pour qu’ils s’exécutent nativement dans la base de données dont vous disposez déjà : SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks ou BigQuery.
-
Le travail quitte le rapport
Pas de fusion, pas de parsing, pas de correspondance approximative. Ce travail a disparu du rapport.
-
Les sources arrivent intégrées
Les clients de l’ERP, du CRM et de la boutique en ligne sont rapprochés en un seul ensemble de dimensions conformes. La jointure a lieu une fois dans le warehouse, et non à nouveau dans chaque rapport.
-
Un historique interrogeable
Chaque modification est conservée à son arrivée, vous pouvez donc produire des rapports sur l’état passé comme sur l’état actuel, même lorsque le système source écrase ses propres enregistrements.
-
Chaque chiffre a son lineage
La logique gagne un lineage, donc « d’où vient ce chiffre » a une réponse visible.
-
Évolutions gérées en amont
Les dimensions à évolution lente sont gérées en amont sous forme de satellites du vault, pas approximées.
Reconnu par BARC dans The Data Fabric Survey 26
Rencontrez notre expert
Vingt minutes avec notre Sales Director, et une réponse honnête sur l’adéquation avec votre situation.
Matt Collett
Sales Director
Parfait, choisissez un créneau qui vous convient :
Autres problèmes traités dans cette série
-
Votre Tableau Server contient-il trop de versions du même chiffre ?
Chaque .tdsx publié était raisonnable le jour de sa création. Ensemble, ils forment des centaines de définitions privées du même indicateur, sans aucun moyen de savoir laquelle est la bonne.
-
Vos expressions LOD Tableau sont-elles trop complexes pour y toucher ?
FIXED, INCLUDE et EXCLUDE sont des outils précis pour de véritables questions à plusieurs granularités. La plupart de celles de votre classeur sont là parce que le warehouse n’a jamais résolu la granularité ni conservé l’historique.
-
Vos actualisations d'extraits Tableau échouent-elles ou prennent-elles du retard ?
Le backgrounder expire, le fichier .hyper ne cesse de grossir, et le dashboard affiche les données de la veille. L’extrait est volumineux parce qu’il transporte des lignes brutes qui n’ont jamais été agrégées en amont.