Partager via

Techniques de réduction des données pour la modélisation des importations

  • Article

Cet article cible les modélisateurs de données Power BI Desktop qui développent et publient des modèles sémantiques Power BI. Plus précisément, elle décrit diverses techniques permettant de réduire les données chargées dans les Modèles d’importation.

Les modèles d’importation sont chargés avec des données compressées et optimisées, puis stockées sur disque par le moteur de stockage VertiPaq. Lorsque les données sources sont chargées en mémoire, il est possible d’obtenir une compression de 10 x, et il est donc raisonnable de s’attendre à ce que 10 Go de données sources puissent être compressées à environ 1 Go de taille. De plus, en cas de persistance sur le disque, une réduction supplémentaire de 20 % peut être obtenue.

Malgré l’efficacité obtenue par le moteur de stockage VertiPaq, vous devez vous efforcer de réduire au minimum les données chargées dans vos modèles. C’est particulièrement vrai pour les grands modèles, ou les modèles que vous prévoyez de devenir de plus en plus volumineux au fil du temps. Voici quatre raisons intéressantes :

  • Les tailles de modèle supérieures peuvent ne pas être prises en charge par votre capacité. La capacité partagée peut héberger des modèles avec une taille maximale de 1 Go, tandis que les capacités Premium peuvent héberger de plus grands modèles en fonction du niveau tarifaire. Pour plus d’informations, consultez modèles sémantiques volumineux dans Power BI Premium.
  • Les tailles de modèle plus petites réduisent la contention des ressources de capacité, en particulier la mémoire. De nombreux modèles plus petits d’une capacité peuvent être chargés simultanément pendant des périodes plus longues, ce qui entraîne des taux d’éviction inférieurs.
  • Les tailles de modèle plus petites obtiennent une actualisation plus rapide des données, ce qui entraîne une latence inférieure, un débit d’actualisation de modèle sémantique plus élevé et moins de pression sur le système source et les ressources de capacité.
  • Les nombres de lignes de table plus petits peuvent entraîner des évaluations de calcul plus rapides, ce qui entraîne une meilleure performance globale des requêtes.

Important

Cet article fait parfois référence à Power BI Premium ou à ses abonnements de capacité (SKU P). Sachez que Microsoft regroupe actuellement des options d’achat et met hors service les SKU Power BI Premium par capacité. Les clients nouveaux et existants doivent plutôt envisager l’achat d’abonnements de capacité Fabric (SKU F).

Pour plus d’informations, consultez Importante mise à jour à venir des licences Power BI Premium et FAQ sur Power BI Premium.

Supprimer les colonnes inutiles

Les colonnes de table de modèle ont deux objectifs principaux :

  • Reporting, pour obtenir des conceptions de rapports qui filtrent, regroupent et résument correctement les données du modèle.
  • structure de modèle, en prenant en charge les relations de modèle, les calculs de modèle, les rôles de sécurité et même la mise en forme des couleurs des données.

Vous pouvez probablement supprimer n’importe quelle colonne qui ne sert pas l’un de ces objectifs. La suppression d’une colonne d’une table est parfois appelée filtrage vertical.

Nous vous recommandons de concevoir des modèles avec exactement le bon nombre de colonnes en fonction de vos exigences de création de rapports connues. Vos besoins peuvent changer au fil du temps, mais n’oubliez pas qu’il est plus facile d’ajouter des colonnes plus tard que de les supprimer ultérieurement. La suppression de colonnes peut rompre les rapports ou la structure du modèle.

Supprimer les lignes inutiles

Vous devez charger les tables de modèle avec le plus peu de lignes possible. Pour ce faire, chargez des ensembles de lignes filtrés dans des tables de modèles pour deux raisons différentes : filtrer par heure ou par entité. La suppression de lignes est parfois appelée filtrage horizontal.

  • Le filtrage basé sur le temps implique de limiter la quantité d’historique des données chargée dans les tables de faits (et de limiter les lignes de date chargées dans les tables de dates de modèle). Nous vous recommandons de ne pas charger l’historique disponible par défaut, sauf s’il s’agit d’une exigence de création de rapports connue. Vous pouvez implémenter des filtres Power Query basés sur le temps avec des paramètres, et même les définir pour utiliser des périodes relatives (par rapport à la date d’actualisation, par exemple, les cinq dernières années). En outre, n'oubliez pas qu'une modification rétrospective des filtres de temps n'interrompt pas les rapports ; cela se traduit simplement par moins (ou plus) d'historique de données disponible dans les rapports.
  • Le filtrage par entité implique le chargement d’un sous-ensemble de données sources dans le modèle. Par exemple, au lieu de charger des faits de ventes pour toutes les régions de ventes, chargez uniquement les faits relatifs à une seule région. Cette approche de conception permet d’obtenir de nombreux modèles plus petits et peut également éliminer la nécessité de définir la sécurité au niveau des lignes (SNL), mais elle nécessite d'octroyer des autorisations spécifiques pour les modèles sémantiques dans le service Power BI et de créer des rapports en double qui se connectent à chaque modèle sémantique. Vous pouvez utiliser des paramètres Power Query et des fichiers de modèle Power BI pour simplifier la gestion et la publication. Pour plus d’informations, consultez Créer et utiliser des modèles de rapport dans Power BI Desktop.

Regrouper par et totaliser

La technique la plus efficace pour réduire la taille d’un modèle consiste peut-être à charger des données prétotalisées. Vous pouvez utiliser cette technique pour augmenter le niveau de détail des tables de faits. Il existe cependant un compromis distinct, entraînant une perte de détails.

Prenons l’exemple d’une table de faits de vente source qui stocke une ligne par ligne de commande. Une réduction significative des données peut être obtenue en récapitulant toutes les mesures de vente, en regroupant par date, client et produit. Une réduction des données encore plus importante peut être obtenue en regroupant par date au niveau du mois. Bien qu'il puisse permettre une réduction de 99% de la taille du modèle, il n'est plus possible de créer des rapports au niveau quotidien ou au niveau de chaque ligne de commande individuelle. Décider de résumer les données de faits implique toujours des compromis. Ce compromis pourrait être atténué par une conception de modèle qui inclut certaines tables en mode de stockage DirectQuery, qui est décrit plus loin dans cet article.

Optimiser les types de données des colonnes

Le moteur de stockage VertiPaq utilise des structures de données internes distinctes pour chaque colonne. De par leur conception, ces structures de données permettent d’optimiser au maximum les données des colonnes numériques, qui utilisent l’encodage de valeur. Le texte et d'autres données non numériques utilisent toutefois l'encodage par hachage . L’encodage de hachage nécessite que le moteur de stockage attribue un identificateur numérique à chaque valeur unique contenue dans la colonne. Il s’agit de l’identificateur numérique qui est ensuite stocké dans la structure de données, ce qui nécessite une recherche de hachage lors du stockage et de l'interrogation.

Dans certains cas spécifiques, vous pouvez convertir des données de texte source en valeurs numériques. Par exemple, un numéro de commande client peut être préfixé de manière cohérente par une valeur de texte (par exemple, SO123456). Dans ce cas, le préfixe SO peut être supprimé et la valeur du numéro de commande convertie en nombre entier. Pour les tables volumineuses, cette modification peut entraîner une réduction significative des données, en particulier lorsque la colonne contient des valeurs uniques ou de cardinalité élevée.

Dans cet exemple, nous vous recommandons de définir la propriété de synthèse par défaut de colonne sur Do Not Summarize. Il permet d’éviter une synthèse inappropriée des valeurs de numéro de commande.

Privilégier les colonnes personnalisées

Le moteur de stockage VertiPaq stocke les colonnes calculées du modèle (définies dans DAX) comme les colonnes provenant de Power Query ordinaires. Toutefois, les structures de données internes sont stockées légèrement différemment et obtiennent généralement une compression moins efficace. En outre, les structures de données sont générées une fois que toutes les tables Power Query sont chargées, ce qui peut entraîner des temps d’actualisation des données étendus. Il est donc moins efficace d’ajouter des colonnes de tableau en tant que colonnes calculées que les colonnes calculées Power Query (définies dans M).

Dans la mesure du possible, privilégiez la création de colonnes personnalisées dans Power Query. Lorsque la source est une base de données, vous pouvez obtenir une plus grande efficacité de charge de deux façons : le calcul peut être défini dans l’instruction SQL (à l’aide du langage de requête natif du fournisseur), ou il peut être matérialisé en tant que colonne dans la source de données.

Toutefois, dans certains cas, les colonnes calculées de modèle peuvent être le meilleur choix. C’est vrai lorsque la formule implique l’évaluation des mesures, ou qu’elle nécessite une fonctionnalité de modélisation spécifique uniquement prise en charge dans les fonctions DAX. Pour plus d'informations sur un exemple de ce type, voir Fonctions de compréhension pour les hiérarchies parent-enfant dans DAX.

Désactiver le chargement des requêtes Power Query

Les requêtes Power Query destinées à prendre en charge l’intégration des données à d’autres requêtes ne doivent pas être chargées sur le modèle. Pour éviter de charger ces requêtes sur le modèle, veillez à désactiver la charge de requête dans ces instances.

capture d’écran de Power Query montrant l’option Activer le chargement.

Désactiver la date/heure automatique

Power BI Desktop comprend une option appelée Date/heure automatique. Lorsqu’elle est activée, elle crée des tables de date/heure automatiques masquées pour chaque colonne de date du modèle. Cette option prend en charge les auteurs de rapports lors de la configuration de filtres, de regroupements et d’actions d’exploration pour les périodes de calendrier. Les tables masquées sont en fait des tables calculées qui augmentent la taille du modèle.

Pour plus d’informations, consultez Aide sur l’option date/heure automatique dans Power BI Desktop.

Utiliser le mode de stockage DirectQuery

Le mode de stockage DirectQuery est une alternative au mode Importation de stockage. Les tables de modèle DirectQuery n’importent pas de données. Au lieu de cela, ils se composent uniquement de métadonnées définissant la structure de table. Lorsque la table est interrogée, les requêtes natives sont utilisées pour récupérer des données à partir de la source de données sous-jacente. Lorsque vous combinez des tables de mode de stockage Import et DirectQuery dans un modèle unique, elle est appelée modèle composite.

Une technique efficace pour réduire la taille du modèle consiste à définir le mode de stockage pour les tables de faits plus volumineuses sur DirectQuery. Cette approche fonctionne souvent bien avec la technique Grouper par et résumer présentée plus haut. Par exemple, les données récapitulatives des ventes peuvent être utilisées pour obtenir des rapports récapitulatives hautes performances. Une page d’extraction pourrait afficher des ventes granulaires pour un contexte de filtrage spécifique (et étroit), en affichant toutes les commandes client rattachées au contexte. Dans cet exemple, la page d’extraction peut inclure des visuels basés sur une table de modèle DirectQuery pour récupérer les données des commandes de vente.

Toutefois, de nombreuses implications en matière de sécurité et de performances sont liées au mode de stockage DirectQuery et aux modèles composites. Pour plus d’informations, consultez Utiliser des modèles composites dans Power BI Desktop.

Contenu connexe

Pour plus d’informations sur cet article, consultez les articles suivants :