Dans cette série de posts, nous allons examiner comment il est possible de limiter la taille d’un modèle en quelques actions simples.
Voici les posts précédents :
- Comment contrôler la taille d’un modèle ?
- Supprimer les tables de dates cachées
- Supprimer les colonnes superflues
L’impact des doublons dans une colonne
Dans les posts précédents, nous avons vu comment il est possible d’alléger un peu le modèle grâce à quelques actions simples. Une intervention à ne pas sous-estimer est la suppression des colonnes superflues. Il est nécessaire de s’y atteler étant donné que Power BI est essentiellement constitué de colonnes.
Mais parfois il faut faire exactement le contraire. Au lieu de diminuer le nombre de colonnes, il peut s’avérer plus efficace de subdiviser une colonne en plusieurs colonnes. Cela semble contradictoire par rapport au post précédent, mais ce n’est pas le cas.
Examinons à nouveau le résultat final que nous avions obtenu au post précédent :
Nous nous étions surtout concentrés sur la taille totale et avions accordé moins d’attention à la taille des colonnes individuelles. Dans la capture d’écran ci-dessus, on voit que le total des colonnes fait environ 16,8 MB, mais qu’une colonne prend quasiment 14 MB de la mémoire totale : SalesDate.
Pour comprendre cela, nous devons également observer la première valeur du tableau croisé dynamique : « cardinality » ou le nombre de valeurs uniques dans cette colonne. On aperçoit ainsi une corrélation entre le nombre de valeurs uniques et la taille d’une colonne. En arrière-plan, Power BI dispose d’une table pour la plupart des colonnes où figurent uniquement les valeurs uniques de cette colonne. Dès lors, plus il y a de doublons, plus la table sous-jacente devient petite, et moins la colonne occupera de mémoire.
Bien que le nom du champ soit SalesDate, le champ comporte une combinaison de dates et d’heures.
Supposons que les données concernent les 10 dernières années, vous avez alors en théorie : 10 * 365 (# jours par an) * 86400 (# années* # jours/an * # secondes/jour), donc différentes valeurs dans cette colonne. Si cette colonne est divisée en 2 colonnes : SalesDate et SalesTime – le fait d’avoir désormais 2 colonnes sera bien moins impactant que lorsqu’il y a énormément de doublons.
De plus, il faut d’abord se demander si le « salestime » est réellement utile. Si ce n’est pas le cas, on peut supprimer cette colonne. Si la colonne « salestime » est tout de même nécessaire, on peut évaluer si oui ou non il est nécessaire d’aller jusqu’au niveau de la seconde. Imaginons qu’il soit suffisant de savoir si la vente a eu lieu entre le 10 et le 11 ou entre le 11 et le 12, on obtient dans ce cas que 24 valeurs uniques dans la colonne.
En utilisant diverses fonctionnalités de Power Query, nous pouvons diviser ces données et ajuster l’heure à quelque chose comme 14:00-15:00. Le résultat
Si nous vérifions à présent la mémoire dans Excel, le résultat est incroyable. La taille de notre modèle de données passe de 16,8 MB à moins de 4 MB.
La colonne SalesID
Dans le post précédent, nous abordions les colonnes à supprimer si vous n’en avez pas besoin. J’avais dû supprimer la colonne SalesID, mais je l’ai gardée pour ce post-ci.
Vous pouvez voir sur la capture d’écran que la colonne SalesID fait 1,7 MB. Et ce, sur un total de 3,9 MB. C’est naturellement dû au fait que SalesID est la clé primaire de cette table, en d’autres termes, chaque valeur dans la colonne SalesID est unique. C’est la raison pour laquelle la cardinalité est aussi importante que le nombre de lignes dans la table complète.
Posez-vous la question suivante : « Quelle est l’utilité de SalesID dans mon modèle ? » Si vous ne parvenez pas à formuler une réponse sensée à cette question, il faut supprimer cette colonne du modèle.
Ne pensez donc pas : « Cette colonne pourrait être utile plus tard, je vais la laisser dans mon modèle ». Avec ce raisonnement, il est également préférable de supprimer la colonne. Moins il y a de colonnes, moins Power BI a à faire et plus les données se rafraîchissent rapidement. »