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

• Quand votre code M se replie, Power Query écrit une seule instruction SQL et la base de données fait le travail. Power BI reçoit simplement le résultat.
• Quand le folding casse, Power Query devient le moteur. Il rapatrie des tables brutes à travers le réseau jusqu’en mémoire et fait le travail lui-même.
• Il casse sans bruit : une fusion, une colonne personnalisée, une correspondance approximative, une colonne d’index. Aucun avertissement.
• Il 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 .pbix, invisible pour tous ceux qui sont en amont.
• Vous pouvez modifier le rapport. Vous ne pouvez pas modifier le warehouse.

Le travail se fait au mauvais endroit

• Fusions, colonnes personnalisées et correspondances approximatives sont un travail d’intégration. Dans Power Query, elles 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, qui se replie 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 se terminent de manière prévisible.
• Les dimensions à évolution lente sont gérées en amont sous forme de satellites du vault, pas approximées.
• La logique gagne un lineage, donc « d’où vient ce chiffre » a une réponse visible.

Ce qu’il faut demander

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

« Nos étapes Power Query ne se replient pas, 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 warehouse, pour que le rapport se contente de les lire ? »

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