Maîtriser et optimiser les coûts de la plateforme
Comprendre l’utilisation des ressources de la plateforme Fabric
Pour optimiser l’utilisation de Fabric, tout utilisateur devrait avoir une connaissance, même sommaire du comportement de la plateforme et des capacités de Fabric. Bien évidemment, en fonction de votre profil, l’impact que vous aurez sera différent.
1. Je suis un utilisateur
Vous êtes un utilisateur, vous évoluez donc dans un environnement purement SaaS (Software as a Service). La plateforme vous est mise à disposition et vous l’utilisez, vous n’avez donc que peu ou pas de connaissance du modèle économique de celle-ci.
Si vous publiez des rapports, une licence Power BI Pro doit vous être assignée. Au-delà de cette assignation de licence qui est personnelle, vous évoluez sur la plateforme en consommant les services qui vous ont été ouverts selon les droits de sécurité qui vous ont été assignés. La plateforme doit répondre à vos exigences d’utilisation, tant en termes de performance que de scalabilité.
2. Je suis un développeur ou data engineer
Vous êtes un développeur, vous évoluez donc dans un environnement SaaS mais avec une compréhension du comportement des clusters Spark sous-jacents mis à votre disposition. Bien sûr, plusieurs types de développeurs coexistent sur Fabric, les plus impactés par cette compréhension sont ceux développant massivement dans des environnements Spark (Notebooks, jobs spark…).
Comme détaillé dans les chapitres Transformation avancée des données et Architecture, le choix de la configuration de votre cluster Spark va impacter certes les performances mais surtout la contingence d’utilisation du cluster au sein de votre groupe de travail. En d’autres termes, une sur utilisation de celui-ci aura des impacts sur vos codéveloppeurs. Cette compréhension est d’autant plus importante en environnement de développement qu’en environnement de production.
En tant que développeur Spark vous maîtrisez le code qui s’exécutera sur les différents nœuds du cluster, vous contrôlez donc la parallélisation de votre...
Comprendre le business model de Fabric
La plateforme Fabric met à disposition une puissance de calcul dite « universelle », qui permet aux utilisateurs de bénéficier de plusieurs types de fonctionnalités suivant leurs persona. Cette puissance est achetée en mode SaaS. Nous allons détailler le fonctionnement de cette puissance et la facturation associée à ce fonctionnement. Les vecteurs de coûts à adresser sont les suivants :
-
la capacité Fabric correspondant à ce moteur de calcul universel ;
-
le stockage ;
-
le trafic réseau ;
-
la publication Power BI.
Toutes les notions abordées ci-après s’appliquent au niveau d’une capacité spécifique. Cela signifie qu’une capacité peut se retrouver dans un état particulier, comme celui d’une utilisation intensive, tandis qu’une autre capacité pourrait être dans un état différent. Les indicateurs de performance ne sont donc pas partagés ou croisés entre les différentes capacités, chaque capacité fonctionne et est évaluée de manière indépendante.
1. La notion de CU/s et la mesure de la consommation
Une capacité Microsoft Fabric correspond à une puissance allouée, qui dépend du nombre d’unités de capacité achetées. Plus ce nombre est élevé, plus la capacité est puissante. Les capacités actuelles de Fabric vont de F2 à F2048, ce nombre représentant les unités de capacité disponibles, appelées CU (Capacity Unit). Par exemple, une capacité F64 dispose de 64 CU.
La consommation des ressources d’une capacité est mesurée toutes les 30 secondes, dans ce qu’on appelle un « intervalle de consommation ». En une journée de 24 heures, cela représente 2880 intervalles (120 intervalles par heure). Chaque intervalle mesure la consommation en CU/s (Capacity Unit par seconde). Pour une capacité F64, cela signifie 64 CU multipliées par 30 secondes, soit un total de 1920 CUs disponibles par intervalle de 30 secondes.
Ainsi, si une capacité F64 est utilisée à pleine puissance (100 %), elle consommera 1920 CUs par intervalle....
L’application métriques de capacité
Microsoft met à disposition une application qui vous permettra de monitorer tous les concepts vus précédemment ce qui vous permettra de comprendre comment est utilisée votre capacité Fabric.
1. Installation de l’application Microsoft Fabric Capacity Metrics
Vous devez dans un premier temps installer cette application afin de pouvoir l’utiliser dans votre environnement.
Pour installer l’application Microsoft Fabric Capacity Metrics pour la première fois, vous devez accéder à AppSource via le lien https://appsource.microsoft.com/.
Accédez à AppSource - Microsoft Fabric Capacity Metrics et sélectionnez Get it now.
Dans le service Power BI, sélectionnez Applications.
Sélectionnez Obtenir des applications.
Recherchez Microsoft Fabric.
Sélectionnez l’application Microsoft Fabric Capacity Metrics.
Sélectionnez Obtenir maintenant.
Quand vous y êtes invité, connectez-vous à AppSource en utilisant votre compte Microsoft et complétez l’écran d’inscription. L’application vous amène à Microsoft Fabric pour terminer le processus. Sélectionnez Installer pour continuer.
Dans la fenêtre Installer cette application Power BI ?, sélectionnez Installer.
L’installation de l’application prend quelques secondes.
Dans Microsoft Fabric, sélectionnez Applications.
Sélectionnez l’application Microsoft Fabric Capacity Metrics.
Quand vous voyez le message Vous devez vous connecter à vos propres données pour visualiser ce...
L’optimisation d’utilisation de la plateforme
1. Profil développeur
Dans une approche commune d’utilisation des ressources Spark, les développeurs peuvent ouvrir une session, depuis un Notebook, de type standard ou à concurrence élevée.
Dans une approche standard, la session va réserver un ensemble de ressources sur le cluster Spark, et celles-ci ne sont pas partagées. Cette approche est limitée sur un certain nombre d’utilisateurs à hauteur des ressources présentes sur le cluster Spark.
Dans une approche de session à concurrence élevée, et dans un souci de mieux utiliser les ressources, les utilisateurs vont partager la même session mais dans des environnements isolés. En mode de concurrence élevée, la session Spark peut prendre en charge l’exécution indépendante de plusieurs éléments au sein de cœurs REPL (read-eval-print loop) individuels qui existent dans l’application Spark. Ces cœurs REPL fournissent une isolation pour chaque élément et empêchent les variables de Notebook locales d’être remplacées par des variables portant le même nom que d’autres Notebooks partageant la même session.
Ce mode d’interaction avec les Notebooks est à privilégier si vous avez déjà une session ouverte et que vous travaillez sur plusieurs Notebooks. Les points suivants sont à prendre en compte pour que cela soit possible :
-
Les Notebooks doivent être exécutés par le même utilisateur.
-
Ils partagent le même Lakehouse par défaut. Les Notebooks sans Lakehouse par défaut peuvent partager des sessions avec d’autres Notebooks qui n’ont pas de Lakehouse par défaut.
-
Ils héritent de la même configuration Spark.
-
Ils partagent les mêmes packages et bibliothèque.
2. Profil architecte
Les différents administrateurs des espaces de travail peuvent paramétrer des cluster Spark dédiés ou paramétrer différemment le cluster Spark à la demande par défaut. Dans un souci de gouvernance centralisée et pour une meilleure gestion des ressources, Microsoft permet la création de pool Spark directement par un administrateur global...