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

L’actualisation n’échoue pas par manque de mémoire. Elle échoue parce qu’elle fait un travail qui n’aurait jamais dû avoir lieu au moment de l’actualisation.

Ce qui casse : le Query Folding

• Lorsque le Query Folding opère sur votre code M, Power Query écrit une seule instruction SQL et la base de données effectue le travail. Power BI reçoit simplement le résultat.
• Dès que le Query Folding est rompu, Power Query devient le moteur de calcul. Il rapatrie des tables brutes par le réseau jusqu’en mémoire et traite les données lui-même.
• L’interruption est silencieuse : une fusion, une colonne personnalisée, une correspondance approximative, une colonne d’index. Aucun avertissement n’apparaît.
• Le code M passe les tests parce que votre ordinateur l’exécute sur une petite table. Puis la table grossit.

Pourquoi cela retombe sur vous

• Ces étapes existent parce que vous deviez livrer un rapport. La dimension dont vous aviez besoin n’existait pas, ou obtenir une colonne supplémentaire signifiait une attente de plusieurs mois.
• La logique se trouve dans le fichier .pbix, invisible pour toute personne travaillant en amont.
• Vous pouvez modifier le rapport. Vous ne pouvez pas modifier le data warehouse.

Le travail se fait au mauvais endroit

• Les fusions, les colonnes personnalisées et les correspondances approximatives relèvent de l’intégration de données. Dans Power Query, ces opérations s’exécutent à nouveau à chaque actualisation.
• 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 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.

• Votre code M devient SELECT * FROM dim_customer, bénéficiant ainsi d’un Query Folding par définition.
• Pas de fusion, pas de parsing, pas de correspondance approximative. Ce travail a disparu du rapport.
• Les actualisations se terminent en quelques secondes, et de manière prévisible.
• Les dimensions à évolution lente sont gérées en amont sous forme de satellites du vault, et non reconstituées approximativement.
• La logique gagne en traçabilité, donc « d’où vient ce chiffre » a une réponse visible.

Ce qu’il faut demander

Pas « l’actualisation échoue sans arrêt », mais :

« Dans nos étapes Power Query, le Query Folding ne s’applique plus, donc l’actualisation charge chaque nuit des tables brutes en mémoire. Peut-on obtenir ces données sous forme de dimensions conformes et d’une table de faits dans le data warehouse, pour que le rapport se contente de les lire ? »

Si la réponse est que modéliser cela correctement prendrait un trimestre de travail d’ingénierie, c’est exactement l’objection que Datavault Builder lève.