Votre rapport Power BI DirectQuery est-il lent à chaque clic ?

DirectQuery et Direct Lake promettent des données en direct. Ce que vous obtenez, c'est un visuel de trente secondes et une facture de calcul que personne ne veut expliquer. Le mode n'est pas le problème. Le schéma en dessous l'est.

Votre rapport Power BI DirectQuery est-il lent à chaque clic ?

La plateforme d'automatisation de data warehouse à laquelle font confiance les équipes data de tous les secteurs

Petr Beles Petr Beles Co-Founder · Publié dans Solutions aux défis des outils BI LinkedIn

Cela vous semble familier ?

  • Chaque clic sur un filtre déclenche une nouvelle vague de requêtes et les visuels se traînent.
  • Les coûts de calcul Synapse ou Fabric ont bondi le mois où le dashboard a été mis en ligne.
  • Direct Lake bascule en DirectQuery et personne ne peut vous dire exactement pourquoi.
  • Le même rapport est rapide en mode import, alors vous utilisez l'import et perdez les données en direct.

DirectQuery fait exactement ce que son nom indique : il transforme chaque interaction en SQL envoyé à votre base de données. Que ce soit rapide dépend entièrement de ce sur quoi il tombe.

Ce que génère DirectQuery

  • Sur un schéma en étoile : une table de faits, quelques jointures de dimensions sur de vraies clés. La base répond en millisecondes.
  • Sur de la 3NF ou des tables brutes du lake : des jointures imbriquées sur une douzaine de tables, reconstruites pour chaque visuel et chaque clic.
  • Aucun push down sur lequel s’appuyer. Des tables non partitionnées et non indexées signifient un scan complet à chaque fois.
  • Le fallback est silencieux. Direct Lake repasse discrètement en DirectQuery quand la source n’a pas la forme dont il a besoin, et c’est là que le coût apparaît.

Multipliez par le nombre de visuels sur la page, puis par le nombre d’utilisateurs simultanés. Voilà la facture.

Pourquoi cela retombe sur vous

  • Le warehouse a exposé ce qu’il avait, c’est-à-dire des tables opérationnelles, pas des tables analytiques.
  • Le mode import est le contournement, et il vous coûte les données en direct pour lesquelles vous aviez choisi DirectQuery.
  • Vous pouvez optimiser les visuels. Vous ne pouvez pas repartitionner la source.

Le travail se fait au mauvais endroit

  • Mettre les tables en forme pour l’analyse est un travail de warehouse. DirectQuery ne peut pas le faire, donc chaque clic paie pour la forme manquante.
  • Ce travail a sa place dans un endroit central : un data warehouse ou un data hub, construit une fois et lu par chaque rapport.
  • 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 des modèles dimensionnels nativement dans la plateforme cible, matérialisés ou virtualisés, conçus pour le push down analytique plutôt que pour l’accès transactionnel.

  • Une table de faits, de vraies dimensions. Le SQL généré est court par construction.
  • Partitionné et clusterisé sur les colonnes que les utilisateurs filtrent réellement.
  • Direct Lake reste en Direct Lake, parce que les tables ont déjà la forme qu’il attend.
  • Le coût de calcul baisse parce que chaque clic parcourt un modèle léger au lieu de la couche brute.
  • Les données en direct ne se paient plus au prix de la vitesse.

Ce qu’il faut demander

« DirectQuery fait des jointures sur des tables normalisées à chaque clic, donc le coût de calcul augmente avec le nombre d’utilisateurs. Peut-on exposer un schéma en étoile partitionné que ce rapport interrogerait à la place ? »

Assez précis pour être chiffré, et cela désigne la couche où la correction doit se faire.

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.

Réserver une démo gratuite

Trois étapes vers des chiffres qui concordent

  1. Extraire la logique existante

    Rassemblez les calculs, jointures et filtres qui vivent aujourd’hui dans vos rapports.

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

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

Témoignage client: Porta

BI nouvelle génération — un point de vérité unique sur Snowflake. Jusqu’à 200 KPIs par département livrés dans Power BI.
Lire l'étude de cas
Porta customer success story

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

Matt Collett

Sales Director

Que recherchez-vous ?

En soumettant, vous acceptez notre Politique de confidentialité.

Autres problèmes traités dans cette série

  • Vos rapports Power BI affichent-ils des chiffres différents pour la même chose ?

    Finance, Ventes et Opérations ont chacun construit leur propre modèle sémantique, et chacun est cohérent en lui-même. Les définitions n’étaient fausses nulle part. Elles n’ont simplement jamais été harmonisées.

  • Votre DAX Power BI devient-il trop long pour être maintenu ?

    Deux cents lignes de CALCULATE et de FILTER ne sont pas le signe d’un DAX avancé. C’est généralement le signe que le warehouse ne vous a jamais fourni les clés, l’historique ou la granularité dont vous aviez besoin.

  • Votre actualisation Power BI échoue-t-elle chaque nuit ?

    L’actualisation planifiée expire, Power Query manque de mémoire, et vous l’apprenez quand quelqu’un ouvre le dashboard. La cause n’est presque jamais Power BI. C’est ce qu’on demande à Power BI de faire.