Microsoft Fabric et power BI Desktop

1/Tableau des différences entre Power BI Desktop et Fabric

Phase	Power BI Desktop	Power BI Fabric
ETL	Power Query	Dataflow (Power Query)
Stockage données après ETL	Local : fichier .Pbix	– Lakehouse – Datawarehouse
Méthode d’actualisation incrémentielle	Aucun	Dépends du moyen de stockage des données transformées : – lakehouse : oui, ajout des nouvelles données uniquement   – Datawarehouse : oui, ajout des nouvelles données et possibilité de mettre à jour les anciennes données   (dans les 2 cas, à programmer dans le Dataflow)
Bloc-notes		Permet la Création de  : Colonne calculée langage Spark sql ( lakehouse) et/ou langage T-sql ( warehouse)) requis
Modèle sémantique		Création à partir d’un lakehouse ou d’un warehouse.
Langage DAX	Création à partir des tables chargé et stocké en local : – Colonne calculée, – Table calculée – Mesure	Création dans le modèle sémantique : – Table calculée (ne peut utiliser de données stockées dans le modèle sémantique) – Colonne calculée dans une table calculé mais pas possible dans une table chargé -Mesure
Visuels	Liste volet visualisations	Liste volet visualisations
Actualisation planifié	Non, sauf si un flux power automate a été crée pour cliquer automatiquement sur le bouton « actualiser » à différents intervalles	Oui, possibilité d’actualiser les rapports toutes les 15 minutes avec l’utilisation des pipelines

La création d’un rapport power BI sous Fabric se fait différemment sous power BI desktop et demande de maîtriser au minimum un autre langage pour créer un bloc-notes qui va apporter des mises à jour sur les tables si nécessaire.

2/ Aspect financier

Un autre point important est l’aspect financier :

	Power BI Desktop	Fabric
Finance	gratuit	Dépend du temps d’utilisation des différentes capacités

  Power BI Desktop est gratuit et peut être utilisé par n’importe quel utilisateur mais ses capacités dépendent des caractéristiques de l’ordinateur sur lequel il est installé (Processeur, RAM,…), donc l’utilisateur doit fournir le matériel.

Fabric fonctionne sur le même principe, mais ce n’est pas l’utilisateur qui achète le matériel. C’est Microsoft qui le fournit.

En effet, l’utilisateur a la possibilité d’utiliser sur Microsoft azure une des capacités suivantes :

L’utilisateur est libre de passer à tout moment une capacité à une autre.

Le coût indiqué pour chaque capacité est une estimation si la capacité est utilisée pendant 1 mois.

En réalité, le prix à payer est le temps d’utilisation de la capacité pendant le mois.

Exemple :

Si l’utilisateur utilise les capacités suivantes pendant un mois :

• Capacité F16 pendant 1 heure pour charger 2GO de données (1^er chargement massive de données)
• Capacité F8 pendant 1 jours pour charger 200 MO de données (plusieurs chargements non prévus d’une quantité moyenne de données)
• Capacité F2 pendant 28 jours et 23heures (pas de chargement d’un volume de données élevées (<10 MO))

Le prix à payer est :

Prix d’utilisation d’une heure pour la capacité F16 :

Prix d’utilisation d’une journée pour la capacité F8 :

Prix d’utilisation de 28 jours et 23heures pour la capacité F2 :

Montant total à payer pour l’utilisation des différentes capacités pendant le mois pour l’utilisateur

Note importante :

Microsoft donne tous les mois 150$ de crédit pour tester ses différents outils sur la plateforme Azure.

Donc le vraie montant à payer est :

Pour aller plus loin, il est possible grâce à une logic apps de programmer automatiquement la mise en pause et la reprise en marche de la capacité.

Quand la capacité est en pause, la facturation s’arrête.

En reprenant l’exemple précédent :

Si l’utilisateur utilise les capacités suivantes pendant un mois :

• Capacité F16 pendant 1 heure pour charger 2GO de données (1^er chargement massive de données)
• Capacité F8 pendant 1 jours pour charger 200 MO de données (plusieurs chargements non prévus d’une quantité moyenne de données)
• Capacité F2 pendant 28 jours et 23heures (pas de chargement d’un volume de données élevées (<10 MO))
• Sa capacité fabric se met en pause tous les jours à 18heures et reprend à 8h le jour suivant sauf samedi et dimanche où la capacité reste en pause de vendredi 18h jusqu’au lundi suivant à 8h

En appliquant le logic apps le montant payé par l’utilisateur impacte surtout le temps d’utilisation de la capacité F2

 Prix d’utilisation de 21 jours (10 heures par jour, inactive samedi et dimanche(8 jours par mois)) pour la capacité F2 :

Le nouveau prix total d’utilisation de la capacité est :

Prix d’utilisation d’une heure pour la capacité F16 :

+

Prix d’utilisation d’une journée pour la capacité F8 :

+

Prix d’utilisation de 21 jours (10 heures par jour) pour la capacité F2 :

=

127,3366 $

-Crédit microsoft de 150$

=-22.6633$ (soit 0 $ de dépensé pour l’utilisateur)

3/ Projet Big Data : méthode efficace

Un Projet impliquant le Big Data (volume important de données) nécessite de bien définir les données nécessaires afin de limiter le coût.

En effet, chaque capacité fabric peut contenir un volume définit de données comme le montre le tableau suivant :

SKU	Max Direct Lake model size on OneLake (GB)1, 4
F2	10
F4	10
F8	10
F16	20
F32	40
F64	Unlimited
F128	Unlimited
F256	Unlimited
F512	Unlimited
F1024	Unlimited
F2048	Unlimited

Tableau issue de What is Power BI Premium? – Power BI | Microsoft Learn

Les colonnes SKU et Max Direct Lake model size on OneLake (GB)^{1, 4} montrent la quantité maximale de données que peut contenir chaque capacité.

Pour réduire le coût au maximum qu’une capacité fabric puisse générer, l’utilisateur devra :

1/ créer son rapport power BI sous power BI Desktop. La taille fichier .pbix contenant le rapport et le modèle de données permettra d’obtenir une 1^ère idée de la capacité à utiliser.

Exemple : si la taille totale du fichier .pbix est inférieur à 10 GO alors, l’utilisateur pourra utiliser une capacité F2 pour réduire les coûts au maximum.
Si la taille est supérieure à 10 GO, l’utilisateur sera forcé d’utiliser une capacité F16 minimum. Si l’utilisateur veut tout de même utiliser une capacité F2, alors il doit revoir le modèle qu’il a mis en place et filtrer plus de données.

2/ Bien définir les outils qui vont appliquer tel opération. Si trop d’opérations sont effectuées avec un seul outil, la capacité fabric peut s’arrêter avant même la fin des opérations. Il est préférable d’attribuer à chaque outils ses différents rôles.

Exemple : le rôle de power Query (et Dataflow) est surtout de supprimer les colonnes non nécessaires pour charger plus rapidement les tables. Ajouter des colonnes au contraire donne un chargement plus lent des données et peut ne pas aboutir.

Ajouter des nouvelles colonnes est plus le rôle du langage DAX et/ou des blocs-notes qui contiennent des codes visant à ajouter des colonnes après le chargement des données.

En séparant les rôles, la capacité est moins sollicitée et risque moins de s’arrêter.

3/mise en place d’une méthode d’actualisation incrémentielle

L’actualisation des données dans power BI desktop remplace toutes les lignes de chaque table par les lignes des tables mise à jour côté base de données, plus il y a de lignes plus cette méthode de chargement des données prend du temps.

La méthode d’actualisation incrémentielle permet principalement d’ajouter les nouvelles lignes sans retirer les lignes précédemment chargé.

Ce qui limite le temps de chargement et le nombre d’opérations à effectuer dans un dataflow.

Remarque : Si lors d’une actualisation, Le volume de donnée est trop élevé malgré la mise en place de cette   méthode d’actualisation incrémentielle, l’utilisateur peut passer temporairement à une capacité supérieure pour charger ce volume de données puis repasser à une capacité inférieure une fois l’actualisation finit.

4/ créer un logic apps sur azure qui automatise la mise en pause et la reprise de sa capacité fabric pour réduire le temps d’utilisation de la capacité.

4/ Conclusion

Créer un rapport power BI sur Desktop n’est pas complétement analogue à la création de rapport power BI sur Fabric et dépend de beaucoup de facteur, mais les deux outils sont complémentaires et oblige l’utilisateur à mieux optimiser son modèle de données.