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 DAX Power BI devient-il trop long pour être maintenu ?

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 ?

  • Une seule mesure dépasse cent lignes et une seule personne la comprend.
  • Les visuels mettent quinze à quarante-cinq secondes, et ce sont toujours les trois mêmes mesures.
  • Modifier une mesure casse discrètement quatre visuels sur une autre page.
  • Vous écrivez du DAX pour retrouver ce que valait une donnée en mars dernier, pas ce qu'elle vaut aujourd'hui.

Un DAX long est rarement un problème de DAX. C’est une structure qui manquait en amont, reconstruite au moment de la requête, à chaque clic.

Ce que font réellement les mesures longues

  • Reconstruire l’historique. CALCULATE avec des filtres de date, en remplacement d’une dimension à évolution lente que le warehouse n’a jamais conservée.
  • Résoudre le many to many. Des itérateurs qui résolvent une relation sans table de pont.
  • Simuler des clés. LOOKUPVALUE et des colonnes texte concaténées, parce qu’il n’existe aucune clé de substitution sur laquelle faire la jointure.
  • Corriger la granularité. SUMX sur une table filtrée, parce que la table de faits contient deux granularités à la fois.

Ces quatre calculs s’exécutent par visuel, par filtre, par utilisateur. Ce sont les quinze à quarante-cinq secondes.

Pourquoi cela retombe sur vous

  • Personne ne l’a choisi. Chaque mesure était, cette semaine-là, le chemin le plus court vers un visuel qui fonctionne.
  • La logique est invisible en dehors du .pbix, elle ne peut donc être ni relue ni réutilisée.
  • Vous pouvez réécrire la mesure. Vous ne pouvez pas ajouter la dimension dont elle a besoin.

Le travail se fait au mauvais endroit

  • Historique, clés, tables de pont et granularité relèvent du warehouse. En DAX, ils sont reconstruits à chaque clic.
  • 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 les clés, l’historique et la granularité dans le warehouse lui-même, sur SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks ou BigQuery.

  • Les clés de substitution sont explicites, les relations sont donc réelles et LOOKUPVALUE disparaît.
  • Les tables point in time répondent à « à quoi cela ressemblait en mars » par une jointure, pas par une mesure.
  • Les tables de pont résolvent le many to many avant que Power BI ne le voie.
  • Une seule granularité par table de faits, donc SUM veut dire ce qu’il dit.
  • Les mesures se réduisent à SUM, AVERAGE, COUNT. Assez courtes pour qu’un collègue puisse les relire.

Ce qu’il faut demander

« Cette mesure reconstruit l’historique au moment de la requête, parce que la dimension n’est pas historisée. Peut-on obtenir une table point in time et de vraies clés de substitution dans le warehouse, pour que la mesure devienne un simple SUM ? »

Cela nomme ce qui manque, au lieu de demander que le rapport soit plus rapide.

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