Maîtriser le query folding dans Power BI : déléguer le travail à votre source de données

By Mirko Peters · 2026-08-28

Automatically translated with AI from the original post. Read the English original

Titelbild: Mastering Query Folding in Power BI: Push the Work to Your Data Source

Lorsque vous travaillez avec Power BI, rares sont les choses plus frustrantes que de voir l’actualisation de vos données durer une éternité, ou pire, échouer complètement faute de ressources. Si vous extrayez des millions de lignes d’une base SQL distante, d’un entrepôt de données d’entreprise ou d’un service cloud, la manière dont vous gérez vos transformations compte. Chaque étape que vous réalisez dans Power Query peut être traitée efficacement par le serveur puissant qui héberge vos données, ou laborieusement par votre poste local ou le moteur mémoire du service Power BI. C’est là qu’intervient la magie du query folding.

Dans cet article, nous allons explorer en profondeur le query folding : son fonctionnement pour optimiser les transformations de données, les techniques concrètes pour s’assurer que vos étapes sont correctement déléguées, les pièges courants qui rompent la chaîne de délégation, et la manière dont vous pouvez améliorer considérablement l’efficacité de l’actualisation de vos rapports. Faisons en sorte que le travail soit effectué là où il doit l’être : au niveau de la source de données.

Introduction au query folding

Le query folding est, dans son principe, le mécanisme par lequel Power Query traduit les étapes de transformation que vous construisez dans votre interface en un langage de requête natif, généralement SQL, puis envoie cette requête à votre base de données source pour exécution. Au lieu de télécharger chaque ligne, chaque table et chaque colonne dans la mémoire de Power BI pour ensuite les filtrer, les regrouper ou les joindre localement, Power BI demande à la base source de faire le gros du travail.

Imaginez des courses au supermarché. Si vous vous rendez dans un immense entrepôt, prenez chaque article du magasin, les ramenez sur votre table de cuisine, puis jetez 90 % d’entre eux parce qu’ils sont périmés ou ne correspondent pas à vos besoins, vous gaspillez un temps et une énergie considérables. C’est ce qui se produit sans query folding. Avec le query folding activé, vous remettez au magasinier une liste précise : « Donnez-moi uniquement les pommes de plus de 450 grammes, regroupées par couleur. » Le magasinier effectue le tri dans l’entrepôt et vous remet une petite caisse ne contenant que ce que vous avez demandé. Votre cuisine reste propre, et vous terminez votre préparation bien plus vite.

Comment le query folding optimise les transformations de données

Le query folding est la pierre angulaire d’une architecture Power BI évolutive. Correctement mis en œuvre, il limite les transferts de données sur le réseau, réduit considérablement l’utilisation de la mémoire pendant la phase d’actualisation et accélère votre flux de développement.

Lorsque vous appliquez tôt dans vos étapes Power Query des transformations telles que le filtrage de lignes, la suppression de colonnes, le tri ou des agrégations simples, le connecteur sous-jacent vérifie si la source de données peut exécuter cette opération nativement. Si c’est le cas, ces étapes sont regroupées dans une seule requête hautement optimisée, envoyée à la source. Le moteur de la base exécute celle-ci sur les index existants, ce qui lui permet de parcourir des millions de lignes en quelques millisecondes.

À l’inverse, si le query folding est interrompu, Power BI est contraint de faire transiter l’intégralité du jeu de données non compressé et non filtré à travers le réseau, jusque dans le moteur d’évaluation de Power Query (moteur mashup). Une fois les données stockées localement, Power BI applique vos filtres et transformations à l’aide du processeur et de la mémoire vive de la machine. Pour les grands jeux de données d’entreprise, c’est la recette assurée des délais d’expiration de la passerelle, des erreurs de mémoire insuffisante et des mises à jour de rapports lentes.

Techniques concrètes pour garantir la délégation des étapes

Toutes les étapes Power Query ne se valent pas, et toutes les sources de données ne prennent pas en charge le query folding. Les bases de données relationnelles comme SQL Server, Oracle ou PostgreSQL disposent de capacités de délégation robustes, tandis que les fichiers plats comme les CSV ou les classeurs Excel ne se délèguent pas de la même façon, car ils ne disposent d’aucun processeur de requêtes natif.

Pour que vos étapes soient correctement déléguées, vous devez structurer vos étapes appliquées selon une séquence précise et faire attention aux fonctions que vous utilisez. Voici les techniques concrètes pour préserver le query folding de vos requêtes :

Filtrer le plus tôt possible : appliquez toujours vos filtres de lignes (par exemple, ne conserver que les trois dernières années de données ou filtrer sur le statut actif) le plus près possible du début de vos étapes appliquées. Plus vous réduisez tôt le jeu de données, plus la traduction SQL qui suit sera efficace.
Supprimez immédiatement les colonnes inutiles : Supprimer les colonnes non utilisées dès le début du processus évite à la source de données de gaspiller des ressources à sérialiser et transférer des données dont vous n’avez pas besoin.
Connaître les transformations prises en charge : Des opérations comme la suppression de colonnes, le renommage de colonnes, la fusion de tables (sous certaines conditions), l’ajout de lignes et les colonnes conditionnelles simples se prêtent généralement bien au repli de requête. En revanche, les formules personnalisées complexes, les manipulations de texte reposant sur des recherches d’index et les colonnes personnalisées nécessitant une logique de programmation rompent souvent la chaîne de repli.
Vérifiez l’option Afficher la requête native : Faites un clic droit sur n’importe quelle étape appliquée dans l’Éditeur Power Query. Si l’option « Afficher la requête native » est activée et cliquable, félicitations : votre requête se replie correctement jusqu’à cette étape. Si elle est grisée, le repli a été interrompu à cette étape ou à une étape précédente.

Erreurs courantes qui rompent le repli de requête

L’un des aspects les plus délicats du repli de requête est sa fragilité. Une seule étape de transformation anodine placée au mauvais endroit peut interrompre complètement la chaîne de repli, obligeant toutes les étapes suivantes à s’exécuter localement, même si la base de données est tout à fait capable de les traiter.

Voici quelques-unes des erreurs les plus fréquentes qui rompent le repli de requête :

Insérer du SQL natif puis transformer : Si vous écrivez une requête SQL native au tout début de l’étape de source de données, Power Query traite ce jeu de résultats comme une boîte noire. Les transformations ajoutées ensuite via l’interface de Power Query ne se replient généralement pas, car Power Query ne peut pas insérer de manière fiable des étapes d’interface dans un bloc SQL personnalisé.
Conversions de types trop tôt ou dans le mauvais ordre : La modification des types de données est essentielle, mais la réaliser avant le filtrage ou avant des opérations en conflit avec les règles de typage de la base de données peut rompre le repli. Par exemple, convertir une colonne numérique en texte, puis tenter d’appliquer un filtre de plage numérique sur cette colonne, peut empêcher la base de données d’optimiser la requête.
Ajouter des colonnes d’index ou utiliser des numéros de ligne : Les fonctions qui reposent sur la position des lignes, comme « Ajouter une colonne d’index » ou les opérations qui font référence aux lignes voisines par un index absolu, exigent de charger l’intégralité du jeu de données en mémoire pour déterminer les positions. Cela interrompt immédiatement le repli de requête.
Mélanger des sources de données : Si vous fusionnez une table issue d’une base SQL avec une table provenant d’un fichier Excel, le repli de requête s’arrête à la frontière où les deux sources interagissent, car Excel ne peut pas traiter nativement les requêtes SQL.

Améliorer l’efficacité de l’actualisation Power BI

Lorsque vous maîtrisez le repli de requête, ses effets se font sentir dans toute votre architecture de données. Des durées d’actualisation de rapports qui prenaient autrefois des heures peuvent descendre à quelques minutes, voire à quelques secondes. Cette efficacité permet non seulement d’économiser les ressources de calcul de vos passerelles ou serveurs cloud, mais aussi de permettre aux développeurs d’itérer plus rapidement.

Pour tirer le meilleur parti de l’actualisation, associez le repli de requête à d’autres bonnes pratiques fondamentales de modélisation. Par exemple, veillez à ce que vos tables de base de données utilisent des index appropriés sur les colonnes que vous filtrez ou joignez fréquemment. Si vos tables SQL ne disposent pas d’index, même une requête repliée obligera le moteur de base de données à effectuer des analyses de table coûteuses. Par ailleurs, associez le repli de requête à un modèle de données en schéma en étoile bien conçu, supprimez les colonnes redondantes et mettez en place des stratégies d’actualisation incrémentielle pour les volumineux jeux de données historiques.

Surveiller et dépanner les requêtes Power BI

On ne peut pas corriger ce que l’on ne mesure pas. Face à des actualisations lentes ou à des échecs de requête inattendus, il faut une approche méthodique pour identifier la source du goulot d’étranglement. Commencez par utiliser l’outil de diagnostic de Power Query disponible dans Power BI Desktop. Cette fonctionnalité permet de suivre le temps d’exécution de chaque étape, en montrant précisément combien de temps prend chaque transformation et si les données sont extraites à distance ou traitées localement.

Par ailleurs, surveillez les journaux de votre passerelle et les outils de profilage de base de données (comme SQL Server Profiler ou les événements étendus) pour observer les requêtes exactes envoyées de Power BI à votre source de données. Si vous voyez de volumineuses instructions SELECT extraire des tables brutes et non filtrées, au lieu de requêtes ciblées avec des clauses WHERE et GROUP BY, vous savez immédiatement que le repli de requête a échoué à un endroit de vos étapes appliquées.

Pour une vue d’ensemble complète de l’ordre d’exécution, des pièges opérationnels et des flux d’optimisation avancés, n’hésitez pas à écouter l’épisode de podcast associé et à parcourir les notes consacrées à Power Query Folding and Execution Order in Power BI. Comprendre l’ordre sous-jacent des opérations vous donnera l’assurance de construire, à chaque fois, des modèles robustes et ultra-rapides.

Conclusion

Maîtriser le query folding est l’une des compétences les plus déterminantes pour un développeur Power BI. En déplaçant la charge de calcul de votre machine locale ou du service Power BI vers les moteurs puissants et hautement optimisés de vos sources de données, vous éliminez les goulots d’étranglement de performance, réduisez la congestion réseau et garantissez que l’actualisation de vos rapports s’effectue de manière fluide et fiable. En étant rigoureux dans l’enchaînement de vos étapes, en vérifiant régulièrement vos requêtes natives et en évitant des écueils courants, comme l’indexation prématurée ou le mélange de sources incompatibles, vous pourrez exploiter pleinement le potentiel de votre environnement de business intelligence.

Pour approfondir ces concepts et découvrir une analyse détaillée de l’impact de l’ordre d’exécution des requêtes sur les performances de votre espace de travail, écoutez la discussion complète dans l’épisode de podcast Power Query Folding and Execution Order in Power BI. Mettez ces stratégies en œuvre dès aujourd’hui, et constatez l’amélioration de vos rapports !