Salut à tous,
Après une longue période de repos (je vous promets que j'ai travaillé sur plein d'autres choses entre-temps !), j'ai décidé de repartir sur la rédaction d'un petit article pas piqué des hannetons. Comme vous pouvez le voir, le sens de l'humour douteux et l'utilisation d'expressions désuètes sont toujours bien présents.
Aujourd'hui, je souhaiterais voir avec vous en détail comment fonctionne notre chère Capacité Fabric. Comme vous le savez, lorsque vous choisissez une capacité, vous avez un large choix allant de la F2 jusqu'à la F2048, soit pour les plus affûtés (ou juste légèrement dérangés) de 2¹ jusqu'à $2¹¹
Lorsque vous sélectionnez une capacité, vous disposez de X CU par seconde. Donc, une capacité F64 utilisée pendant 1 heure vous donnera théoriquement
64 X 60 X 60 = 230 400 secondes de CU (CU-seconds).
Mais que se cache-t-il derrière ces CU ?
Afin d'éviter les coûts cachés, les coûts à la requête et autres joyeusetés, Microsoft a décidé d'utiliser une approche légèrement plus pragmatique en assignant un certain "poids" à chaque action effectuée au sein de Fabric. La première difficulté intervient ici : il n'y a pas de règles claires permettant de connaître à l'avance le coût exact de chaque chose. On est clairement sur une détermination empirique (essai/erreur). C'est d'ailleurs un peu pour ça que la F64 en version d'essai (Trial) est plus qu'utile pour benchmarker.
Afin de clarifier tout cela, prenons un exemple plus simple. Représentons notre capacité comme un magasin avec des caisses. Comme vous le savez, les magasins peuvent aller du petit "Night & Day" de quartier jusqu'à l'hypermarché constitué de 42 caisses (dont seulement 12 sont ouvertes, classique...). Cela représente bien notre capacité pouvant varier de 2¹ à 2¹¹ CUs.
Donc, dans notre exemple, nous sommes dans un supermarché de petite ville, disposant de 4 CU... pardon, de 4 caisses !
Afin de continuer notre analogie, Microsoft Fabric distingue 2 types d'opérations : les Opérations Interactives (Interactive operations) et les Opérations d'Arrière-plan (Background operations). Derrière chaque type se cachent deux réalités totalement différentes.
Les Opérations Interactives représentent l'ensemble des interactions que vos utilisateurs peuvent avoir avec Fabric (principalement Power BI) à travers des interfaces graphiques ou des programmes tiers. Ces interactions regroupent donc tout ce qui concerne l'utilisation directe de Power BI, comme consulter un rapport ou utiliser l'interface web pour concevoir un modèle sémantique. Comme ces interactions sont plus légères et demandent une réactivité immédiate, elles peuvent être représentées par un panier.
Les Opérations d'Arrière-plan, quant à elles, représentent toutes les tâches de fond. Il s'agit généralement de processus n'étant pas issus d'une interaction directe et instantanée avec l'utilisateur, et pouvant prendre plus de temps. Ici, nous parlons de tout ce qui concerne le rafraîchissement d'un modèle sémantique, l'exécution d'un Notebook Spark ou encore l'utilisation complexe de Copilot et des pipelines de données. Ces types d'interactions, plus lourdes, peuvent être représentés par des caddies pleins à craquer.
Donc si je comprends bien, si j'utilise des opérations d'arrieres-Plan, c'est ça qui va faire sauter ma capacité, correct ?
Et c'est là le moment de vous parler d'un premier concept important, le smoothing
Ce concept peut etre représenté comme un magasin disposant de 4 caisses, mais n'ouvrant qu'une seule caisse, afin de conserver un flux constant de clients
Le Smoothing (ou lissage) est la capacité de Fabric à étaler la consommation de CU sur une certaine période. En fonction du type d'opérations, la fenêtre de lissage ne sera pas la même (un peu comme pour les types de cheveux...).
Lorsque vous êtes sur une opération interactive, le temps de lissage est de 5 minutes. C'est-à-dire que si l'application d'un filtre consomme 400 secondes de CU (CU-seconds), cela reviendra à une consommation moyenne de $1,33$ CU chaque seconde pendant 5 minutes ($400 / 300s$).
Là où ce mécanisme devient vital, c'est pour les opérations d'arrière-plan. Ce genre d'opération est généralement beaucoup plus gourmand. Sans le smoothing, elles pourraient faire tomber une capacité très facilement.
Prenons l'exemple d'un job de rafraîchissement qui dure 15 minutes et qui nécessite 120 000 secondes de CU pour être exécuté.
Si nous faisons abstraction du smoothing, un tel job demanderait une puissance instantanée de :
120 000 / (15 x 60) = 133,33 Cu
Cela reviendrait donc à devoir acheter une capacité théorique F133 juste pour ce pic !
Mais grâce au smoothing sur 24 heures, nous arrivons à une consommation de :
120 000 / (24 x 60 x 60) = 1.39 CU
Et c'est ici que résident à la fois la puissance et le piège du smoothing. La capacité ne tombera pas sur l'instant, mais si nous lançons plusieurs opérations de ce type sur une petite capacité, nous allons accumuler une "dette" de calcul lissée sur 24h. Nous risquons alors de dépasser notre quota et de subir des ralentissements (Throttling) plus tard, même si aucune opération n'est en cours à ce moment-là.
Le Bursting (l'éclatement) est la possibilité de dépasser la consommation théorique d'une capacité durant un court laps de temps. Si je reprends l'analogie du magasin, c'est comme si ce dernier ouvrait des caisses supplémentaires en urgence pour absorber la marée de clients lors du Black Friday.
Ce mécanisme permet de dépasser sa capacité d'un facteur allant jusqu'à 32 pour les plus petites capacités (et d'environ 12 pour les plus grosses). Il est donc possible, avec une simple F2, d'avoir l'impression d'être en possession de la puissance d'une F64 pendant un court instant !
C'est ici qu'intervient le dernier concept à comprendre : le Throttling (ou limitation). Lorsque vous dépassez trop souvent la puissance à laquelle vous avez accès, et comme avec Microsoft Fabric vous êtes sur un modèle à coût fixe, il faut se méfier des pénalités. Ce ne sont pas des pénalités pécuniaires, mais des blocages mis en place pour vous forcer à rembourser votre dette de calcul.
Mais comment éviter cela et surtout, comment sortir de cet état critique ? Nous aborderons le sujet passionnant du throttling ainsi que sa gestion lors de notre prochain article ;-)
0 Commentaires