Gérer le mode de stockage dans Power BI Desktop
Dans Microsoft Power BI Desktop, vous pouvez spécifier le mode de stockage d’une table. Le mode de stockage vous permet de contrôler si Power BI Desktop met en cache les données de table en mémoire pour les rapports. La mise en cache signifie le stockage temporaire des données en mémoire.
La définition du mode de stockage offre de nombreux avantages. Vous pouvez définir le mode de stockage pour chaque table individuellement dans votre modèle. Cette action permet un modèle sémantique unique, qui offre les avantages suivants :
performances des requêtes: lorsque les utilisateurs interagissent avec des visuels dans les rapports Power BI, les requêtes DAX (Data Analysis Expressions) sont soumises au modèle sémantique. La mise en cache des données en mémoire en définissant correctement le mode de stockage peut améliorer les performances et l’interactivité des requêtes de vos rapports.
modèles sémantiques volumineux: les tables qui ne sont pas mises en cache ne consomment pas de mémoire à des fins de mise en cache. Vous pouvez activer l’analyse interactive sur de grands modèles sémantiques trop volumineux ou coûteux pour mettre complètement en cache en mémoire. Vous pouvez choisir quelles tables valent la peine d'être mises en cache, et lesquelles ne le sont pas.
optimisation de l’actualisation des données: vous n’avez pas besoin d’actualiser les tables qui ne sont pas mises en cache. Vous pouvez réduire les temps d’actualisation en mettant en cache uniquement les données nécessaires pour répondre à vos contrats de niveau de service et à vos besoins métier.
exigences en temps quasi réel: les tables avec des exigences en temps quasi réel peuvent tirer parti du fait qu’elles ne sont pas mises en cache, afin de réduire la latence des données.
Écriture différée : l’écriture différée permet aux utilisateurs professionnels d’analyser des scénarios de simulation en modifiant les valeurs des cellules. Les applications personnalisées peuvent appliquer des modifications à la source de données. Les tables qui ne sont pas mises en cache peuvent afficher immédiatement les modifications, ce qui permet une analyse instantanée des effets.
Le paramètre de mode de stockage dans Power BI Desktop est l’une des trois fonctionnalités associées :
modèles composites: permet à un rapport d’avoir au moins deux connexions de données, y compris les connexions DirectQuery et les connexions d'importation, dans n’importe quelle combinaison. Pour plus d’informations, consultez Utiliser des modèles composites dans Power BI Desktop.
Relations plusieurs à plusieurs : avec les modèles composites, vous pouvez établir des relations plusieurs à plusieurs entre les tables. Dans une relation plusieurs à plusieurs, les exigences sont supprimées pour les valeurs uniques dans les tables. Les solutions de contournement préalables, comme la présentation de nouvelles tables uniquement pour établir des relations, sont également supprimées. Pour plus d’informations, consultez Relations plusieurs à plusieurs dans Power BI Desktop.
mode stockage: avec le mode de stockage, vous pouvez désormais spécifier les visuels qui nécessitent une requête pour les sources de données principales. Les visuels qui n’ont pas besoin d’une requête sont importés même s’ils sont basés sur DirectQuery. Cette fonctionnalité permet d’améliorer les performances et de réduire la charge back-end. Auparavant, même de simples visuels, comme les segments, initiaient des requêtes qui étaient envoyées à des sources back-end.
Utiliser la propriété Mode de stockage
Le mode de stockage propriété est une propriété que vous pouvez définir sur chaque table de votre modèle et contrôle la façon dont Power BI met en cache les données de la table.
Pour définir la propriété Mode de stockage ou afficher son paramètre actuel :
Dans vue Modèle, sélectionnez la table dont vous souhaitez afficher ou définir les propriétés.
Dans le volet des propriétés , développez la section avancée et ouvrez la liste déroulante du mode de stockage .
Vous définissez la propriété en mode stockage
Importer: les tables importées avec ce paramètre sont mises en cache. Les requêtes soumises au modèle sémantique Power BI qui retournent des données à partir de tables d’importation peuvent être remplies uniquement à partir de données mises en cache.
DirectQuery: les tables avec ce paramètre ne sont pas mises en cache. Les requêtes que vous envoyez au modèle sémantique Power BI ( par exemple, les requêtes DAX) et qui retournent des données à partir de tables DirectQuery peuvent être remplies uniquement en exécutant des requêtes à la demande vers la source de données. Les requêtes que vous envoyez à la source de données utilisent le langage de requête de cette source de données, par exemple, SQL.
double: les tables avec ce paramètre peuvent agir comme mises en cache ou non mises en cache, selon le contexte de la requête soumise au modèle sémantique Power BI. Dans certains cas, vous remplissez des requêtes à partir de données mises en cache. Dans d’autres cas, vous remplissez des requêtes en exécutant une requête à la demande sur la source de données.
Si vous modifiez la propriété Mode de stockage d’une table sur Importer, cette opération est irréversible. Une fois cette propriété définie, elle ne peut pas être modifiée ultérieurement en directQuery ou double.
Note
Vous pouvez utiliser le mode de stockage double dans Power BI Desktop et le service Power BI.
Contraintes sur les tables DirectQuery et Dual
Les tables doubles ont les mêmes contraintes fonctionnelles que les tables DirectQuery. Ces contraintes incluent des transformations M limitées et des fonctions DAX restreintes dans des colonnes calculées. Pour plus d’informations, consultez Limitations de DirectQuery.
Propagation du paramètre Double
Considérez le modèle suivant, où toutes les tables proviennent d’une source unique qui prend en charge Import et DirectQuery.
Supposons que toutes les tables de ce modèle sont initialement définies sur DirectQuery. Si vous modifiez ensuite le mode stockage
Vous pouvez définir les tables de dimension (Customer, Geographyet Date) sur Double pour réduire le nombre de relations limitées dans le modèle sémantique et améliorer les performances. Les relations limitées impliquent normalement au moins une table DirectQuery où la logique de jointure ne peut pas être envoyée aux systèmes sources. Étant donné que les tables doubles peuvent agir comme des tables DirectQuery ou Import, cette situation est évitée.
La logique de propagation est conçue pour aider les modèles qui contiennent de nombreuses tables. Supposons que vous disposez d’un modèle avec 50 tables et que seules certaines tables de faits (transactionnelles) doivent être mises en cache. La logique dans Power BI Desktop calcule l’ensemble minimal de tables de dimension qui doivent être définies sur double, de sorte que vous n’avez pas besoin de le faire.
La logique de propagation traverse uniquement un seul côté des relations un-à-plusieurs.
Exemple d’utilisation du mode de stockage
Imaginez d’appliquer les paramètres de propriété du mode de stockage suivants :
| Table | Mode de stockage |
|---|---|
| Ventes | DirectQuery |
| SurveyResponse | Importer |
| Date | Double |
| Client | Double |
| Géographie | Double |
La définition de ces propriétés de mode de stockage entraîne les comportements suivants, en supposant que la table Sales a un volume de données important :
Power BI Desktop met en cache des tables de dimension, Date, Customeret Geography, afin que les temps de chargement des rapports initiaux soient rapides lors de la récupération des valeurs de segment à afficher.
Power BI Desktop ne met pas en cache la table Sales. Power BI Desktop fournit les résultats suivants en ne mettant pas en cache ce tableau :
- Les temps d’actualisation des données sont améliorés et la consommation de mémoire est réduite.
- Les requêtes de rapport basées sur la table Sales s’exécutent en mode DirectQuery. Ces requêtes peuvent prendre plus de temps, mais sont plus proches du temps réel, car aucune latence de mise en cache n’est introduite.
Les requêtes de rapport basées sur la table SurveyResponse sont retournées à partir du cache en mémoire et sont donc relativement rapides.
Requêtes qui réussissent ou échouent dans le cache
Si vous connectez SQL Profiler au port de diagnostic pour Power BI Desktop, vous pouvez voir quelles requêtes atteignent ou manquent le cache en mémoire en effectuant une trace basée sur les événements suivants :
- Événements de requêtes\Début de la requête
- Traitement de requêtes\Début de la requête Vertipaq SE
- Traitement des requêtes\Début de DirectQuery
Pour chaque événement de Début de requête, vérifiez d’autres événements ayant le même ID ActivityID. Par exemple, s’il n’existe pas d’événement DirectQuery Begin, mais qu’il existe un événement Vertipaq SE Query Begin, la requête est répondue à partir du cache.
Les requêtes qui font référence à des tables double retournent des données à partir du cache, si possible ; sinon, ils reviennent à DirectQuery.
La requête suivante se poursuit à partir du tableau précédent. Il s’agit uniquement d’une colonne de la table Date, qui est en mode Double. Par conséquent, la requête doit atteindre le cache :
La requête suivante fait référence uniquement à une colonne de la table Sales, qui est en mode DirectQuery. Par conséquent, cela ne devrait pas affecter le cache :
La requête suivante est intéressante, car elle combine les deux colonnes. Cette requête n’atteint pas le cache. Vous pouvez initialement vous attendre à ce qu'elle récupère les valeurs de CalendarYear du cache et celles de SalesAmount de la source, puis combine les résultats. Cependant, cette approche est moins efficace qu'envoyer l'opération SUM/GROUP BY au système source. Si l’opération est envoyée (push down) à la source, le nombre de lignes retournées sera probablement bien moindre :
Note
Ce comportement est différent des relations plusieurs à plusieurs dans Power BI Desktop quand les tables mises en cache et non mises en cache sont combinées.
Les caches doivent être maintenus synchronisés.
Les requêtes affichées dans la section précédente montrent que les tables doubles atteignent parfois le cache et parfois ne le font pas. Par conséquent, si le cache est obsolète, différentes valeurs peuvent être retournées. L’exécution de requête ne tente pas de masquer les problèmes de données par exemple, en filtrant les résultats DirectQuery pour qu’ils correspondent aux valeurs mises en cache. Il vous incombe de connaître vos flux de données et de concevoir en conséquence. Il existe des techniques établies pour gérer ces cas à la source, si nécessaire.
Le mode de stockage double est une optimisation des performances. Elle ne doit être utilisée que de manière à ne pas compromettre la capacité de répondre aux exigences de l’entreprise. Pour implémenter un autre comportement, envisagez d’utiliser les techniques décrites dans Relations plusieurs à plusieurs dans Power BI Desktop.
Vue Table
Si au moins une table du modèle sémantique a son mode de stockage défini sur Import ou Dual, l’onglet Table est affiché.
Quand vous sélectionnez des tables Double ou Importer dans la vue Table, ces tables affichent les données mises en cache. Les tables DirectQuery n’affichent pas de données et un message s’affiche qui indique que les tables DirectQuery ne peuvent pas être affichées.
Considérations et limitations
Il existe quelques limitations pour la version actuelle du mode de stockage et sa corrélation avec les modèles composites.
Les sources de connexion dynamique (multidimensionnelle) suivantes ne peuvent pas être utilisées avec des modèles composites :
- SAP HANA
- SAP Business Warehouse
Lorsque vous vous connectez à ces sources multidimensionnelles à l’aide de DirectQuery, vous ne pouvez pas vous connecter à une autre source DirectQuery ou la combiner avec des données importées.
Les limitations existantes de l’utilisation de DirectQuery s’appliquent toujours lorsque vous utilisez des modèles composites. La plupart de ces limitations sont désormais par table, en fonction du mode de stockage de la table. Par exemple, une colonne calculée sur une table importée peut faire référence à d’autres tables, mais une colonne calculée sur une table DirectQuery est toujours limitée pour faire référence uniquement aux colonnes de la même table. D’autres limitations s’appliquent au modèle dans son ensemble, si l’une des tables du modèle est DirectQuery.
Contenu connexe
Pour plus d’informations sur les modèles composites et DirectQuery, consultez les articles suivants :