Partager via

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

  • Article

Cet article s’adresse aux modélisateurs de données Power BI Desktop développant des modèles d’importation. Il décrit différentes 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 qui sont 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'observer une compression 10x. Il est donc raisonnable de s'attendre à ce que 10 Go de données sources puissent être compressées jusqu'à une taille d'environ 1 Go. 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, il est important que vous vous efforciez de minimiser les données à charger dans vos modèles. C’est particulièrement vrai pour les modèles volumineux ou qui sont amenés à croître 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, lisez l’article Prise en charge de Power BI Premium pour les grands modèles sémantiques.
  • Les tailles de modèle plus petites réduisent la contention des ressources de capacité, en particulier la mémoire. Cela permet de charger simultanément un plus grand nombre de modèles pendant des périodes plus longues, ce qui réduit les taux d’éviction.
  • Les modèles plus petits permettent une actualisation des données plus rapide, ce qui se traduit par des rapports de latence plus faibles, un débit d'actualisation du modèle sémantique plus élevé et une pression moindre sur le système source et les ressources de capacité.
  • La réduction du nombre de lignes de table peut entraîner une accélération des évaluations de calcul, ce qui peut améliorer les performances globales 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.

Cet article aborde huit techniques de réduction des données. Ces techniques sont les suivantes :

Supprimer les colonnes inutiles

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

  • Création de rapports, pour obtenir des conceptions de rapport qui filtrent, regroupent et totalisent correctement les données de modèle
  • Structure du 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 de données

Les colonnes qui ne sont pas utilisées à ces fins peuvent probablement être supprimées. La suppression de colonnes est appelée filtrage vertical.

Nous vous recommandons de concevoir des modèles avec exactement le nombre approprié de colonnes en fonction des exigences de création de rapports connues. Vos besoins peuvent changer au fil du temps, mais gardez à l'esprit qu'il est plus facile d'ajouter des colonnes plus tard que de les supprimer plus tard. La suppression de colonnes peut rompre les rapports ou la structure du modèle.

Supprimer les lignes inutiles

Les tables de modèle doivent être chargées avec le moins de lignes possible. Pour ce faire, vous pouvez charger des ensembles de lignes filtrés dans des tables de modèle pour deux raisons différentes : pour effectuer un filtrage par entité ou en fonction du temps. La suppression de lignes est appelée filtrage horizontal.

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 se traduira par de nombreux modèles plus petits et peut également éliminer le besoin de définir la sécurité au niveau des lignes (mais nécessitera l'octroi d'autorisations de modèle sémantique spécifiques dans le service Power BI et la création de rapports « en double » qui se connectent à chaque modèle sémantique). Vous pouvez tirer parti de l’utilisation de paramètres Power Query et de fichiers de modèle Power BI pour simplifier la gestion et la publication. Pour plus d’informations, lisez l’entrée de blog Deep Dive dans Query Parameters and Power BI Templates

Le filtrage basé sur le temps implique de limiter la quantité d’historique des données chargée dans les tables de type fait (et de limiter les lignes de date chargées dans les tables de dates de modèle). Nous vous suggérons de ne pas charger automatiquement tout l'historique disponible, sauf s'il s'agit d'une exigence de création de rapports connue. Il est utile de comprendre que les filtres Power Query basés sur le temps peuvent être paramétrés, et même configurés pour utiliser des périodes de temps relatives (par rapport à la date d’actualisation, par exemple les cinq dernières années). Gardez également à l’esprit que les modifications rétrospectives apportées aux filtres temporels n’interrompront pas les rapports ; cela entraînera simplement moins (ou plus) d'historique de données disponible dans les rapports.

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. Cette technique peut être utilisée pour élever la granularité des tables de type fait. Il existe cependant un compromis distinct, entraînant une perte de détails.

Par exemple, une table de faits de ventes source stocke une ligne par ligne de commande. Vous pouvez réduire significativement les données en totalisant toutes les métriques de ventes, en regroupant par date, client et produit. Considérez alors qu'une réduction encore plus significative des données pourrait être obtenue en regroupant par date au niveau du mois. Cela peut représenter une réduction de 99 % de la taille du modèle, mais la création de rapports au niveau du jour ou d’une commande spécifique n’est plus possible. La décision de totaliser des données de types de fait implique toujours un compromis. Ce compromis peut être atténué par une conception de modèle mixte, dont vous trouverez la description dans l’article Basculer vers le mode mixte.

Optimiser les types de données des colonnes

Le moteur de stockage VertiPaq utilise des structures de données distinctes pour chaque colonne. Par défaut, ces structures de données réalisent les optimisations les plus élevées pour les données de colonnes numériques, qui utilisent l’encodage de valeur. Toutefois, le texte et les autres données non numériques utilisent l’encodage de hachage. Cela nécessite que le moteur de stockage affecte un identificateur numérique à chaque valeur de texte unique contenue dans la colonne. C'est donc l'identifiant numérique qui est ensuite stocké dans la structure de données, nécessitant une recherche de hachage pendant le stockage et 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 systématiquement préfixé par une valeur textuelle (par exemple « SO123456 »). Le préfixe peut être supprimé et la valeur du numéro de commande convertie en nombre entier. Pour les grandes tables, cela peut entraîner une réduction significative des données, en particulier quand la colonne contient des valeurs de cardinalité uniques ou élevées.

Dans cet exemple, nous vous recommandons de définir la propriété Total par défaut de la colonne sur « Ne pas totaliser ». Cela permet de minimiser le résumé inapproprié des valeurs des numéros de commande.

Privilégier les colonnes personnalisées

Le moteur de stockage VertiPaq stocke les colonnes calculées de modèle (définies en DAX) comme des colonnes ordinaires fournies par Power Query. Toutefois, les structures de données sont stockées de façon légèrement différente et offrent généralement une compression moins efficace. En outre, ils sont créés une fois que toutes les tables Power Query sont chargées, ce qui peut entraîner des temps d'actualisation des données prolongés. 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. Quand la source est une base de données, vous pouvez améliorer l’efficacité du chargement de deux manières. 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. Cela peut être le cas quand la formule implique l’évaluation de mesures ou qu’elle nécessite des fonctionnalités de modélisation spécifiques prises en charge uniquement dans les fonctions DAX. Pour plus d’informations sur un exemple de ce type, consultez l’article Présentation des fonctions 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 de données avec d’autres requêtes ne doivent pas être chargées dans le modèle. Pour éviter de charger la requête dans le modèle, veillez à désactiver le chargement des requêtes dans ces cas.

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. Quand elle est activée, elle crée une table de date/heure automatique masquée pour les colonnes de date afin de prendre en charge les auteurs de rapport lors de la configuration des filtres, du regroupement et d’actions d’exploration des détails des périodes de temps du calendrier. Les tables masquées sont en fait des tables calculées qui augmentent la taille du modèle. Pour obtenir des instructions sur l’utilisation de cette option, reportez-vous à l’article Conseils sur la fonctionnalité de date/heure automatique dans Power BI Desktop.

Basculer vers le mode mixte

Dans Power BI Desktop, une conception en mode mixte produit un modèle composite. Fondamentalement, il vous permet de déterminer le mode de stockage pour chaque table. Ainsi, la propriété Mode de stockage de chaque table peut être définie sur Importer ou DirectQuery (Double est une autre option).

Une technique efficace pour réduire la taille du modèle consiste à définir la propriété Mode de stockage sur DirectQuery pour les tables de type fait plus grandes. Vous pouvez combiner cette approche de conception avec la technique présentée plus haut dans Regrouper par et totaliser. Par exemple, les données de ventes totalisées peuvent être utilisées pour obtenir des rapports « de synthèse » hautes performances. Une page d’extraction peut afficher des ventes granulaires pour un contexte de filtre spécifique (et étroit), affichant toutes les commandes client rattachées au contexte. Dans cet exemple, la page d’extraction inclut des visuels basés sur une table DirectQuery pour récupérer les données des commandes client.

Toutefois, il existe de nombreuses implications en matière de sécurité et de performances liées aux modèles composites. Pour plus d’informations, consultez l’article Utiliser des modèles composites dans Power BI Desktop.

Contenu connexe

Pour plus d’informations sur la conception de modèles d’importation Power BI, consultez les articles suivants :