Modèles composites dans Power BI : Mélanger Import et DirectQuery

Pendant des années, les praticiens de Power BI ont dû choisir : le mode d'importation (rapide, mais les données sont aussi récentes que la dernière actualisation) ou DirectQuery (toujours à jour, mais potentiellement lent et limité en termes de requêtes). Les modèles composites ont modifié ce calcul en permettant aux deux modes de stockage de coexister dans un seul modèle, avec des relations qui traversent la frontière des modes.

Cette fonctionnalité ouvre des scénarios qui étaient auparavant impossibles : un tableau de bord qui affiche l'historique complet des transactions d'hier à partir d'une partition d'importation ainsi que les données en temps réel d'aujourd'hui provenant d'une source DirectQuery, le tout joint à une table d'opportunités Salesforce en direct interrogée à la demande. Comprendre comment fonctionnent les modèles composites (et quand ils créent plus de problèmes qu’ils n’en résolvent) est une connaissance essentielle pour tout praticien Power BI avancé.

Points clés à retenir

• Les modèles composites mélangent les modes d'importation, DirectQuery et Dual au sein d'un seul modèle sémantique
• Le mode d'importation fournit une compression VertiPaq et des performances de requête en mémoire pour les données historiques
• Le mode DirectQuery interroge la source en temps réel — la fraîcheur est excellente, mais les performances dépendent de la source
• Les tables double mode peuvent servir soit d'importation, soit de DirectQuery en fonction du contexte de la requête.
• Les relations dépassant les limites du mode de stockage ajoutent de la complexité aux requêtes et peuvent entraîner des problèmes de performances.
• Les tables d'agrégation dans les modèles composites améliorent considérablement les performances des requêtes DirectQuery
• Les ensembles de données DirectQuery pour Power BI (chaînage) permettent de créer des modèles composites construits sur des modèles sémantiques partagés
• Les relations limitées entre les tables d'importation et DirectQuery restreignent certaines fonctions DAX

---

Modes de stockage : importation, DirectQuery et double

Avant de comprendre les modèles composites, chaque mode de stockage doit être compris individuellement.

Le mode Importation charge les données du système source dans le moteur de stockage VertiPaq en mémoire de Power BI. Les données sont compressées (souvent 10:1 ou mieux) et stockées sous forme de données en colonnes qui exécutent des requêtes analytiques extrêmement rapidement – ​​généralement en quelques millisecondes pour la plupart des requêtes sur des ensembles de données pouvant atteindre des centaines de millions de lignes. La limitation : les données sont aussi récentes que la dernière actualisation planifiée ou manuelle.

Le mode DirectQuery interroge le système source en temps réel chaque fois qu'un utilisateur interagit avec un rapport. Le moteur Power BI traduit les requêtes DAX en requêtes source natives (SQL pour les bases de données relationnelles, etc.) et les exécute sur la source. Les données sont toujours à jour, mais les performances dépendent entièrement des performances des requêtes du système source. Une base de données analytique dédiée et bien indexée gérera bien les requêtes DirectQuery ; une base de données de production OLTP soumise à une charge transactionnelle importante peut produire des résultats lents et incohérents.

Le mode double est un hybride spécial disponible dans les modèles composites. Une table bimode est physiquement stockée en importation (données chargées dans VertiPaq) mais peut également être interrogée via DirectQuery lorsque le contexte de requête l'exige. Ceci est principalement utilisé pour les tables de dimensions partagées qui doivent participer à des relations avec les tables de faits d'importation et DirectQuery.

---

Quand utiliser des modèles composites

Les modèles composites conviennent à des scénarios spécifiques. Ils ajoutent une complexité qui n'est pas justifiée lorsque des architectures plus simples répondent aux exigences.

Utilisez des modèles composites lorsque :

N'utilisez pas de modèles composites lorsque :

• Un modèle d'importation complet s'actualise assez rapidement et la latence des données est acceptable (dans la plupart des cas)
• La source DirectQuery ne peut pas gérer la charge des requêtes (bases de données OLTP de production)
• Des calculs DAX complexes sont nécessaires — les modèles composites limitent certaines fonctions DAX
• La sécurité au niveau des lignes doit couvrir les limites du mode de stockage (implémentation complexe)

---

Configuration des modes de stockage

Dans Power BI Desktop, le mode de stockage est défini par table. Cliquez avec le bouton droit sur une table dans la vue Modèle → Propriétés → Avancé → Mode de stockage.

Pour un modèle composite typique avec une grande table de faits dans DirectQuery et des dimensions dans Import :

1. Définissez FactSales → Mode de stockage : DirectQuery
2. Définissez DimDate → Mode de stockage : Dual (sert à la fois les requêtes d'importation et DirectQuery)
3. Définissez DimProduct → Mode de stockage : Importer (petite table, entièrement mise en cache)
4. Définissez DimCustomer → Mode de stockage : Dual (utilisé dans les relations inter-sources)
5. Définissez RealtimeSales (données du jour) → Mode de stockage : DirectQuery

Lorsque vous configurez une table en tant que DirectQuery ou modifiez les modes de stockage, Power BI affiche des avertissements sur les relations et les limitations potentielles. Examinez-les attentivement : ils indiquent les domaines dans lesquels le comportement du modèle peut différer de celui d'un modèle d'importation pur.

---

Relations dans les modèles composites

Les relations entre les tables de différents modes de stockage se comportent différemment des relations de même mode, et il est essentiel de comprendre ces différences pour créer des modèles produisant des résultats corrects.

Relations régulières relient deux tables où le côté "plusieurs" peut utiliser le côté "un" pour filtrer. Dans les modèles d’importation, les deux tables sont en mémoire et la relation s’exécute en mémoire – rapidement. Dans les modèles composites avec une table d'importation et une table DirectQuery, la relation provoque une analyse de table d'une table qui est ensuite utilisée pour filtrer l'autre, générant potentiellement de grandes requêtes multimodes.

Des relations limitées sont créées automatiquement lorsqu'une table DirectQuery a une relation plusieurs-à-plusieurs avec une table d'importation, ou dans certains autres scénarios multimodes. Les relations limitées ne prennent pas en charge les filtres bidirectionnels et restreignent certaines fonctions DAX (par exemple, les fonctions qui reposent sur le chemin du filtre de relation). Power BI signale des relations limitées dans la vue modèle avec une ligne pointillée au lieu d’une ligne continue.

Les relations entre sources connectent des tables provenant de sources de données complètement différentes (par exemple, une table de SQL Server connectée via DirectQuery et une table de Salesforce connectée via une autre connexion DirectQuery). Ces relations nécessitent qu'un côté soit une table double mode : Power BI doit être capable de matérialiser un côté de la relation en mémoire pour le joindre à l'autre.

L'impact pratique de ces types de relations : les mesures DAX qui fonctionnent correctement dans un modèle d'importation pur peuvent produire des résultats inattendus ou des erreurs dans un modèle composite. Testez soigneusement toutes les mesures après avoir modifié les modes de stockage, en particulier celles impliquant USERELATIONHIP, CROSSFILTER, CALCULATE avec des fonctions de filtre liées aux relations et les agrégations sur des tables associées.

---

Tableaux d'agrégation : le modèle de modèle composite de base

Le modèle de modèle composite le plus précieux combine une grande table de faits DirectQuery avec une table d'agrégation en mode importation qui pré-résume les données avec un grain plus élevé.

Le problème : une table de faits sur les ventes de 500 millions de lignes dans DirectQuery est trop volumineuse pour que la plupart des systèmes sources puissent l'interroger de manière interactive : chaque graphique prend plus de 10 secondes pendant que la source exécute des requêtes globales coûteuses.

La solution : pré-créez un tableau récapitulatif qui regroupe les faits en un grain quotidien/mensuel/catégorie de produit et importez ce tableau récapitulatif dans Power BI. La plupart des requêtes (au niveau mensuel, trimestriel ou par catégorie) atteignent l'agrégation d'importation rapide. Seules les requêtes qui descendent jusqu’au niveau de transaction individuelle retournent à DirectQuery.

Configuration des agrégations :

Tout d'abord, créez la table d'agrégation dans votre entrepôt de données :

CREATE TABLE SalesByDayProduct AS
SELECT
    SaleDateKey,
    ProductKey,
    CustomerSegmentKey,
    RegionKey,
    SUM(SalesAmount) as SalesAmount,
    SUM(Quantity) as Quantity,
    SUM(Cost) as Cost,
    COUNT(*) as TransactionCount
FROM FactSales
GROUP BY SaleDateKey, ProductKey, CustomerSegmentKey, RegionKey;

Importez cette table dans Power BI et définissez le mode de stockage sur Importer.

Ensuite, configurez l'agrégation dans Power BI :

• Clic droit sur SalesByDayProduct → Gérer les agrégations
• Mappez chaque colonne à sa relation avec le tableau de détail et la fonction de synthèse (Somme, Moyenne, Nombre, etc.)
• Définissez la colonne "Résumé" (SalesAmount → Sum correspond à FactSales[SalesAmount] → Sum)

Le moteur de requête de Power BI achemine désormais automatiquement les requêtes vers la table d'agrégation lorsque cela est possible et revient à la table de détails DirectQuery uniquement lorsque la requête nécessite des détails au niveau de la ligne que l'agrégation ne fournit pas.

Le résultat en termes de performances est spectaculaire : les agrégations au niveau de la catégorie et au niveau du temps qui prenaient auparavant 15 secondes reviennent désormais en moins d'une seconde, tandis que l'option d'exploration des transactions individuelles reste disponible.

---

DirectQuery pour les ensembles de données Power BI

Power BI a introduit DirectQuery pour les ensembles de données Power BI (également appelé « connexion en direct avec des modèles composites » ou simplement « modèles composites sur des ensembles de données partagés »). Cela permet à un développeur de créer un nouveau rapport ou un nouveau jeu de données qui utilise un jeu de données Power BI publié existant comme source DirectQuery, tout en ajoutant de nouvelles tables, des mesures calculées et des données d'importation locales.

Cas d'utilisation clé : une organisation dispose d'un modèle sémantique d'entreprise certifié couvrant les données financières et commerciales de base. Une équipe travaillant sur une analyse spécifique doit ajouter des données locales (un fichier CSV avec les codes projet, un fichier Excel avec les cibles) sans modifier le modèle d'entreprise certifié. À l'aide de DirectQuery pour les ensembles de données Power BI, ils créent un modèle composite qui référence le modèle d'entreprise via DirectQuery et ajoute leurs tables locales en tant que données d'importation.

Cela permet une architecture d'analyse gouvernée dans laquelle :

• L'équipe centrale de données maintient des ensembles de données d'entreprise certifiés
• Les équipes commerciales étendent ces ensembles de données avec le contexte local sans créer de modèles distincts et incohérents
• Le modèle d'entreprise reste la source unique de vérité pour les métriques partagées

Limitations : DirectQuery pour les ensembles de données Power BI hérite de toutes les limitations de DirectQuery standard : certaines fonctions DAX sont restreintes, la sécurité au niveau des lignes doit être correctement configurée pour se propager à travers le modèle composite et la connexion à l'ensemble de données source ajoute une couche de traitement des requêtes.

---

Optimisation des performances pour les modèles composites

Les modèles composites nécessitent un réglage des performances plus minutieux que les modèles d’importation pure. Les optimisations suivantes ont le plus d'impact :

Réduire les requêtes multimodes : chaque parcours de relation qui traverse une limite de mode de stockage ajoute de la latence. Réduisez-les en conservant les tables de dimension en mode double (elles peuvent servir à la fois des requêtes d'importation et DirectQuery sans traversée multimode) et en structurant le modèle de manière à ce que la plupart des requêtes restent dans un seul mode.

Pré-agrégation à la source : ne demandez pas à la source DirectQuery d'effectuer des agrégations que Power BI pourrait effectuer plus efficacement. Créez des vues ou des vues matérialisées dans la base de données source qui sont pré-agrégées selon les besoins réels de vos rapports.

Surveiller le plan de requête avec Performance Analyzer : dans Power BI Desktop, Affichage → Performance Analyzer enregistre le temps nécessaire pour la requête DAX de chaque visuel et la requête source suivante (si DirectQuery). Cela révèle quels visuels sont lents et si la requête lente se trouve dans la couche DAX ou dans la couche de requête source.

Utiliser les paramètres de réduction des requêtes : dans Power BI Desktop → Options → Réduction des requêtes, activez les options pour ajouter des boutons Appliquer aux trancheurs et aux filtres. Cela empêche chaque interaction de slicer de déclencher immédiatement une requête source, ce qui est particulièrement important pour les rapports DirectQuery où chaque requête présente une latence d'exécution réseau et source.

Limiter le nombre de connexions DirectQuery : chaque source DirectQuery différente dans un modèle composite crée un pool de connexions distinct. Limitez-vous à 1 à 2 sources DirectQuery lorsque cela est possible ; plus de 3 augmente considérablement la complexité du modèle et les problèmes de performances potentiels.

---

Sécurité au niveau des lignes dans les modèles composites

La sécurité au niveau des lignes (RLS) dans les modèles composites nécessite une planification minutieuse, en particulier lorsque RLS est défini sur une table d'importation ayant une relation avec une table DirectQuery.

Lorsqu’un utilisateur doté d’un filtre RLS interroge un rapport, Power BI applique le filtre à la table appropriée. Si la table filtrée est en mode importation et qu'elle a une relation avec une table DirectQuery, Power BI doit traduire le filtre d'importation en un filtre pouvant être envoyé à la source DirectQuery. Cela fonctionne dans la plupart des cas mais peut produire des résultats inattendus avec des hiérarchies de filtres complexes.

Bonne pratique : définissez RLS sur les tables de dimensions en mode importation (et non sur les tables de faits DirectQuery). Le filtre se propage d'une dimension à l'autre à travers la relation, qui fonctionne de manière fiable. Définir RLS directement sur les tables DirectQuery est possible mais plus difficile à tester et à déboguer.

Pour les modèles composites utilisant DirectQuery pour les jeux de données Power BI, le RLS défini dans le jeu de données source est automatiquement appliqué lorsque ce jeu de données est interrogé. Des RLS supplémentaires peuvent être définis dans la couche de modèle composite. Cette approche RLS en couches nécessite des tests minutieux pour garantir que les filtres se composent correctement.

---

Questions fréquemment posées

Puis-je mélanger des données provenant de plates-formes de bases de données complètement différentes dans un modèle composite ?

Oui. Un modèle composite peut contenir simultanément des tables de SQL Server (DirectQuery), Salesforce (DirectQuery), un fichier Azure Blob Storage (Import) et Snowflake (DirectQuery). Chaque source maintient sa propre connexion. Les relations entre les tables de différentes sources doivent avoir au moins une table double mode pour faciliter les jointures entre sources. Les performances et la complexité augmentent avec chaque source supplémentaire : se limiter à 2 ou 3 sources est pratique pour la plupart des implémentations.

Quelles fonctions DAX ne fonctionnent pas dans les modèles composites ?

Certaines fonctions DAX sont restreintes ou se comportent différemment dans les modèles composites avec des tables DirectQuery. Les fonctions qui ne fonctionnent pas avec des relations limitées incluent SUMMARIZE (dans certains contextes), TOPN (sur les tables DirectQuery) et certaines fonctions d'intelligence temporelle. USERELATIONSHIP fonctionne mais peut provoquer des requêtes multimodes. La liste complète des limitations est documentée dans la documentation Power BI de Microsoft sous « Limitations de DirectQuery ». Il est fortement recommandé de tester toutes les mesures critiques après l'ajout de tables DirectQuery.

Comment fonctionne l'actualisation incrémentielle avec les modèles composites ?

L'actualisation incrémentielle s'applique aux partitions en mode importation au sein d'un modèle composite. Les tables configurées en DirectQuery n'utilisent pas d'actualisation incrémentielle : elles interrogent la source en temps réel à chaque interaction. La combinaison la plus courante consiste à utiliser l'actualisation incrémentielle sur les partitions historiques en mode importation tout en disposant de DirectQuery pour les données de la période en cours. Il s'agit de la fonctionnalité de tables hybrides, qui est une forme spécifique de modélisation composite au sein d'une seule table.

Quel est l'impact sur les performances des modèles composites par rapport à l'importation pure ?

Les modèles composites avec des composants DirectQuery seront toujours plus lents que les modèles d'importation purs équivalents pour des requêtes équivalentes. L'écart de performances dépend des performances du système source et de la proportion de requêtes qui atteignent DirectQuery par rapport aux partitions d'importation. Avec des tables d'agrégation bien conçues, la plupart des requêtes des utilisateurs atteignent l'agrégation d'importation et reviennent en moins d'une seconde, ce qui rend les performances acceptables. Les requêtes qui explorent les détails de DirectQuery peuvent prendre de 3 à 15 secondes en fonction des performances de la source.

Dois-je utiliser des modèles composites ou simplement planifier des actualisations plus fréquentes ?

Des actualisations plus fréquentes (toutes les 15 minutes pour le mode importation) sont suffisantes pour la plupart des cas d'utilisation où le « temps quasi réel » est acceptable. Les modèles composites avec DirectQuery ajoutent une complexité significative : utilisez-les uniquement lorsque : (a) vous avez besoin de données véritablement actuelles à la minute ou à la seconde près, (b) l'ensemble de données est trop volumineux pour être actualisé dans la fenêtre disponible, même avec une actualisation incrémentielle, ou (c) vous devez combiner des données provenant de sources qui ne peuvent pas être consolidées dans une seule actualisation d'entrepôt.

---

Prochaines étapes

Les modèles composites sont un outil puissant pour les architectures Power BI sophistiquées, mais ils nécessitent une conception minutieuse pour éviter les pièges en termes de performances et d'exactitude. Les implémentations les plus réussies utilisent des modèles composites pour des scénarios spécifiques et justifiés plutôt que comme architecture par défaut.

Les services de modélisation de données Power BI d'ECOSIRE incluent la conception de modèles composites, la mise en œuvre de tables d'agrégation et l'optimisation des performances. Contactez-nous pour évaluer si les modèles composites constituent la bonne solution pour vos exigences spécifiques en matière de fraîcheur des données et de performances.