Translytical taks flows: Révolution ou usine à gaz
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 j'ai bien compris, ce sont nos opérations d'arriere plans qui vont faire exploser ma capacité ? Et là comme à chaque fois, je vais vous donner la meme réponse : ça dépend
Il s'agit donc de la transition idéale pour vous parler du premier mécanisme de Fabric lorsqu'on parle de capacité: le smoothing (et non pas le smoothie)
Une fois que tout est prêt dans notre code, on le publie puis on peut le tester
Donc dans mon interface de test, je passe deux parametres (l'ID d'une biere, et la description que je souhaite ajouter)
Et voila, ma fonction a bien modifié la description de notre biere Fox Tail avec le texte: Unicorns are great but expensive
Et voila, je sais sur que tu risques de me dire cher lecteure, ouais, t'as juste écris une query SQL dans du pyspark, je fais ça dans Jupyter depuis des années...
Mais non, je ne te prends pas pour un jambon, nous sommes actuellement à la premiere phase: Créer la fonction
Maintenant, nous allons créer un "rapport Power BI", pour vous montrer ce qu'on va pouvoir faire avec cette fonction
Avant de pouvoir créer le rapport, il faut IMPERATIVEMENT activer deux features en preview dans Power BI Desktop
Translytical Task Flow
Text Slicer Visual
Voici donc mon chef d'oeuvre
Donc, ce rapport se compose de 3 éléments distincts:
Un Text Slicer (Enter a description for the beer of your choice)
Un tableau
Un boutton (c'est ici que le plus gros de la logique se passe)
Voici les settings de mon bouton action ainsi que quelques customisations qui ont été faites, mais le plus important reste les settings suivant, si j'entre une description mais qu'aucune biere n'est selectionnée dans mon tableau, il prendra par defaut l'ID le dernier ID par ordre alphabétique
Passons donc à la démo, je pense que nous allons revoir cette horrible définition de la biere de ma région: l'orval
Je souhaiterais rempalcer la description par cette description: (non, je ne suis pas fou, c'est mon ami copilot qui me l'a rédigé ;-) )
Chère Orval, avec ta robe ambrée et ton col de dentelle, tu promets une complexité que seule ta nature sauvage et évolutive sait offrir. Chaque gorgée est un dialogue unique, une amertume franche qui s'adoucit en une fidélité fruitée, faisant de toi bien plus qu'une bière, un véritable amour de trappiste.
Malheureusement, ma description dépassant 200 caracteres, j'ai eu droit à une petite erreur ( limitation écrite dans ma fonction, donc la fonction prend en compte ce morceau de code)
J'ai donc revu ma copie pour quelque chose de moins pédant, dont voici la description
À toi, Orval, trésor ambré au goût si unique. Chaque bulle raconte ta légende, chaque gorgée est une promesse d'éternité. Mon Val d'Or, ma divine gorgée. (Pour clore tout débat futile, on dit UN orval et non UNE orval (vous apprendrez au fur et à mesure que j'ai TOUJOURS raison))
La nouvelle fonctionnalité permettant d'écrire dans les sources de données directement depuis Power BI le positionne comme un véritable hub opérationnel. Si le potentiel est immense, sa mise en œuvre pratique appelle à la prudence.
Avantages :
Centralisation : Power BI n'est plus seulement un outil de visualisation, mais aussi d'action.
Efficacité : Les utilisateurs peuvent corriger ou enrichir les données sans quitter leur rapport.
Points de vigilance :
Licence : L'accès à cette fonctionnalité est conditionné par une licence Microsoft Fabric.
Gouvernance : Une stratégie de gouvernance des données mature est indispensable pour contrôler qui peut écrire, où et comment.
Risque de divergence des données : C'est le défi principal. L'écriture ne modifie que la destination (base de données, warehouse), pas la source d'origine (ex: fichiers plats). À terme, cela peut créer un décalage dangereux entre les données de référence et celles des rapports.
Il s'agit donc d'une évolution puissante mais exigeante. Son adoption à grande échelle semble pour l'instant peu probable, la réservant aux organisations les plus matures sur le plan de la data.