Unification des données dans Microsoft Fabric

Phare Data

0:03[musique] [musique] Oh ouais, bonjour et bienvenue sur Fardata, la chaîne qui éclaire vos données. Alors, dans l'océan des données, voir clair change tout. Sur farata, on décrypte les services de données d'analytique CDIA, le tout avec un ton accessible, des choix techniques assumés et une touche dermar. Que vous soyez architecte, analyste, data, engénéieur, product honur ou simplement curieux, Fardata vous accompagne pour comprendre les enjeux réels, éclairer les compromis et prendre de meilleures décisions et parfois avec le cri des mouettes en bruit de fond. Si ce genre de contenu vous parle, n'hésitez pas à vous abonner. Cap sur l'épisode du jour. Alors aujourd'hui, on aborde un sujet central pour toutes les organisations à savoir unifier son patrimoine de données sans transformer sa plateforme en archipel de silo. Parce qu'au final, le

Unification des données dans Microsoft Fabric

0:57problème c'est pas le stockage, c'est la fragmentation des données dispersées, des copies multiples et des équipes qui ne travaillent pas sur la même réalité. C'est exactement là que Microsoft fabrique change la donne puisqu'on va stocker la donnée une seule fois dans le one leg. On va la rendre accessible, sécurisée, exploitable finalement un peu comme un port où toutes vos données viennent samarer. Et pour ça, Fabrique pour plusieurs stratégies qu'on va voir aujourd'hui, à savoir les shortcut, le mirroring et les copys. Trois façons de naviguer. Et pour parler de ce sujet, je suis pas seul à bord. Aujourd'hui, j'ai le plaisir d'être accompagné par deux experts reconnues du sujet, à savoir Nadine qui accompagne au quotidien des clients sur les architecture data moderne et Roxana spécialiste sur les workload fabriqu et pas seulement. Je vous laisse mesdames vous présenter. Bonjour tout le monde. Aline Rchitecte Cloud. J'accompagne les clients sur le segment Francophone notamment sur les sujets data sur le cloud Azur. Et moi Roxana, bonjour à tous. Je suis cloud Solution Advisor chez Microsoft passé à Dublanc et au quotidien j'accompagne les équipes data sur Microsoft fabrique plus particulièrement sur tout ce qui touche à leur gestion comment faire la donnée au bon endroit et au bon format et ravi d'être avec vous pour parler de tout ça aujourd'hui. Et alors pour rentrer dans le vif du sujet, comment rendre la donnée accessible et cohérente ? Et ben avant de cliquer ou quoi que ce soit, posons-nous le vrai problème. Le réflexe naturel c'est de tout copier dans fabrique. Sauf que copier ça coûte cher en capacité, ça duplique du stockage et surtout ça casse la fraîcheur de la donnée. Donc vous travaillez par exemple sur une photo, pas sur le direct. Alors avant de choisir, vous posez vous devez vous poser quatre questions. La latence donc il vous faut du temps réel ou est-ce que un bâche suffit le coût ? Combien coûte vraiment la copie et son rafraîchissement ? la gouvernance, où vit la source de vérité et enfin la complexité. Donc combien de tuyaux vous allez devoir maintenir dans le temps ? Il faut retenir une chose, c'est que aucune des trois approches ne gagne partout et tout dépend de la source que vous avez et de votre besoin. On va parler des trois outils ici que vous

Shortcut, Mirroring et Copy Job

3:05voyez. Donc le premier c'est le shortcut. Donc c'est le raccourci zéro copie. Donc c'est un simple pointeur vers la donnée là où elle est. Vous la lisez immédiatement sans la déplacer. Donc vous avez des exemples, donc par exemple du S3, du datalake, du dataverse. Vous avez ensuite le mirroring. Donc lui réplique une base entière via du CDC, donc du change data capture, une copie initiale puis un flux d'incrément en quasi temps réel. Et tout ça sans écrire le moindre pipeline. Par exemple, vous pouvez avoir de SQL, du Cosmos DB, du Snowflake, du Postgress Sequel. Et enfin, on a le copy job. Donc Copy Job, c'est un peu le couteau suisse. C'est une copie batch planifiée ou bien incrémentale avec plus de 200 connecteurs data factory. C'est votre filet de sécurité quand les deux premiers ne ne se fissent pas. [grognement] regard un par un en dém suivant la source de données en plus des cas qu'on va sélectionner par rapport à notre besoin. Mais le fait qu'on choisisse une source de par exemple un fichier Excel va nous orienter plutôt vers du shortcut parce que supporté par le shortcut. Alors que si on veut faire répliquer une liste SharePoint là on va plutôt faire du mirroring parce que supporté par le mirroring. Donc en fait notre source de données va aussi nous orienter je crois. Exactement. Donc première approche le shortcut. L'idée est simple comme on a dit tout à l'heure, la donnée reste à sa place et One Lake ne stock qu'un lien, donc pas les OCT. Vous l'interrogez

Shortcut

4:32instantanément par exemple en SQL et en Spark. Donc quand est-ce qu'on doit l'utiliser ? Quand votre donnée est déjà dans un one lake ou un datalake bien gouverné et que vous ne voulez surtout pas dupliquer des terraoctés, c'est donc c'est légitime de choisir un shortcut. C'est aussi l'arme idéale en multicloud. Donc on peut exposer du S3 comme je l'ai dit tout à l'heure ou euh du euh du Google aussi euh dans fabrique sans rien déplacer. Mais attention, il y a des limites. Si la source est est de dans une autre région, en fait chaque lecture traverse le réseau, donc la de la latence et de l'égrisse. Donc et comme c'est un miroir en lecture, il y a pas de transformation possible. Et donc là, on passe au vif du sujet. On va voir la démo ensemble. Alors oui, les shortcuts par design n'ont pas de transformation possible. Maintenant, on a des shortcuts qui permettent d'enrichir la donnée, à savoir j'ai des fichiers Excel, je fais semblant que c'est des fichiers delta parquet et aussi plus récemment les transformations de type AI on top de mes shortcuts pour détecter le sentiment, pour faire de la traduction et cetera. Donc, il y a des shortcuts et des shortcuts qu'on peut aussi enrichir d'information. Yes ! Donc là, je suis dans mon lake house. Donc au lieu d'importer mes données, je vais référencer depuis un emplacement externe. Donc là, je suis sur Fabrique. Donc Fabrique me propose des sources internes. Donc là, je vais créer un shortcut. Je vais choisir Azure Dataalic Gen 2. Ici, je vais choisir une nouvelle connexion. Donc je renseigne bien sûr tous les identifiants. Donc ici j'ai l'URL du de mon datalec de mon stockage et je sélectionne le dossier qui va m'intéresser. Donc faut savoir ici que moi sur les connexions, j'ai choisi Workspace Identity, ce qui est plutôt pas mal parce que derrière ben on n pas besoin de gérer donc l'identité donc ou les credentials. Et du coup j'ai je peux juste me connecter avec mon entité fabrique qui a accès à mon storage accountant. Donc là j'ai choisi mes fichiers, je vais créer mon shortcut et c'est fait. Donc le shortcut apparaît dans mon explorateur au côté de mes données natifs. Donc les fichiers euh donc ils restent dans le datalc d'origine. D'accord ? Là, je vais essayer de d'aller plus loin. Donc, je vais créer une delta table pour définer bénéficier pardon des des performance analytique. Donc là, c'est créé et je vais requetter tout ça. Je vais faire une requête SQL exactement comme sur ma donnée locale donc mes utilisateurs, ils voient aucune différence. Donc là, je vais je vais requitter et voilà. Du coup, j'aurai mes résultats qui s'affichent ici. Un très pertinent pour l'unification des données. On sait que les clients ont des données un peu dispersées dans différents cloud providers, dans différents endroits. Ici, tu crées des shortcuts vers ces différentes euh sources et tu les centralises et les permets à tes utilisateurs de les requêter au même endroit. Exactement. Donc là maintenant, on va parler de la deuxième approche donc le mirroring. Donc on réplique une base de données transactionnelle en continu via du CDC, donc un snapshot initial puis un

Mirroring

7:56flux d'increment qui arrive en quasi temps réel directement en delta dans votre on sans coder un seul pipeline. Quand est-ce qu'on va l'utiliser ? Donc dès que vous avez une source qui change vite, il y a un vrai besoin de fraîcheur. [soupir][souffle coupé] Par exemple, un ERP, un site e-commerce de l'UTI, euh il faut savoir que il y a des pièges à connaître. Donc tous les types de colonnes ne sont pas répliqués. Donc il y a des changements de schémas qui ne sont pas suivis automatiquement et sur une table très volatile, le coût donc du change data capture peut grimper. Donc faut faire faut faire attention. Allez, on va voir ça en direct durant une démo. Ouais. Alors, juste avant la démo, faut rappeler que les données répliquées en mirroring sont en quelque sorte offertes. On peut rappeler qu'à une F64, tu as 64 Tas de données mirrorées offertes. He l'idée hein, c'est on unit toutes les données dans le onele et pour ça, c'est en quelque sorte gratuit au travers du mirroring. Plutôt intéressant. Alors maintenant, on va parler de la démo. Donc je pars de mon workspace fabrique. Je vais créer un nouvel élément. D'accord ? Je vais choisir mirror de Azure SQL database. D'accord ? Donc fabrique va s'occuper de tout. Donc on n pas des de tuyaux de données à coder. Donc j'ai j'indique ici mon Azure SQL database et bien sûr donc tout ce qui est mes connection settings. Donc simplement le serveur, la base, mes identifiants euh et la connexion, elle est sécurisée et réutilisable. Donc là vous voyez, j'ai changé, j'ai mis organizational account pour vous montrer la différence parce que moi j'ai accès à cette base de données. Donc on peut aussi le faire de cette manière-là. Donc ici, je vais choisir les tables. Donc moi, j'ai orders. D'accord ? Donc soit toute la base, soit une sélection. Donc je peux ajuster ce périmètre. OK. Et donc après quand j'aurai choisi ma base, je me connecte et il y aura la partie provision. Donc Fabrique va provisionner la base de données mirrored, OK ? Qui est créé automatiquement. Donc on a un SQL Analytic Points qui qui va être créé. La réplication va être configurée et tout est automatisé en arrière-p comme vous pouvez le voir ici. [grognement] Euh et il y a pas d'infrastructure de à gérer de mon côté. Donc voilà. Après donc la réplication, vous voyez j'ai le statut running. Donc les données sont synchronisées en continu. Chaque modification dans la base de la source donc insertion, mise à jour ou suppression est répercuté en temps réel. sans que j'ai à à réordonancer. Donc là, j'ai une query SQL juste pour vous montrer que je vais faire une requête pour rajouter un élément. Et si je reviens, donc là je l'ai exécuté, donc j'ai rajouté un élément sur ma base source. Ouais, exactement. Et donc là, si je reviens, je fais faire un petit refrage, vous voyez, j'ai 101 éléments. Donc je vais ajouter un élément ici et c'est quasi nul. Donc euh c'est très rapide euh pour la réplication. Tu peux m t'abonner à tous les changements via le Delta Change Datafeed et donc capturer tous les inserts, les updates et les changements sur ta base de données sources qui est plutôt aussi intéressant.

Copy Job

11:20Et donc il nous reste la troisème approche et sans doute la plus polyvalente, le copy job. Euh c'est l'idée d'une copie orchestrée par Data Factory. On peut la planifier typiquement la nuit ou en fin de journée, mais surtout on peut la rendre incréementale grâce à un watermark. Concrètement, à chaque exécution, on ne recopie qu'est-ce qui est nouveau depuis le dernier rang et puis donc seulement le le delta à chaque fois. Et son grand atout, c'est sa couverture avec plus de 200 connecteurs. C'est vraiment le couteau suisse de l'ingestion. Et la question euh quand est-ce qu'on le sort ce couteau suisse ? Dans deux cas. [raclement de gorge] Euh premièrement, quand la source n'est ni raccourçable par shortcut, ni méorable ou réplicable par le miring, bref, quand les deux premières approches ne s'appliquent pas. Et deuxièmement, quand on a besoin de transformer ou nettoyer la donnée euh dès l'ingestion, donc le moment où elle entre. Et le revers de la médaille, parce qu'il il y en a un ici, euh c'est que en fait on copie pour de vrai. Donc à chaque exécution c'est de la capacité consommée et donc faire attention au pics euh qui peuvent crer des spike au niveau de la capacité. Et comme la donnée est dupliquée, il y a aussi un coup de stockage euh et un refresh agéré dans le temps. Donc le mieux c'est encore de voir la démo. OK, on part de notre workspace fabric. Je fais new item, je choisis Copy Job et je l'appelle Copy Job 2 et je le laisse dans le dans le workspace. Rien de plus, on va laisser le l'assistant nous guider étape par étape. Premièrement, on choisit la source. C'est là qu'on retrouve les fameux 200 connecteurs et moi je prends l'Azure Sequel database. Je renseigne le serveur la base et je me connecte avec mon compte organisationnel. Et à noter que je n'ai aucune infra à monter. Donc c'est l'assistant qui gère la connexion. Ensuite je choisis quoi copier. Je coche mes tables du schéma CCT euh l'adresse, le client, le produit et cetera. Donc une dizaine de tables et regardez le bandeau qui s'affiche tout haut. Vos tables sont le ont le CDC logased activé. Ça veut dire que Fab va pouvoir capter automatiquement les inserts, les updates, les deletes sans que j'ai écrire la moindre logique de détection et ou de changement. Ensuite la on va choisir la destination euh et c'est là que vous vous voyez tout le catalogue, le Lhouse, warehouse, une base de données sequel, un dossier one lake, du sharepoint, datverse et cetera. Et dans mon cas, j'ai choisi pour la destination également une base Azure sequel. Et voici le point le plus important dans le read method. Je peux faire une copie complète ou une copie encrémentale. Donc je choisis encrémental. Donc le premier run qui copie tout et puis le run suivant qui copie que les changements. [grognement] Et pour savoir ce qui est nouveau, donc l'assistant me demande une colonne enrémentale par table. Et c'est exactement le watermark dont je parlais. Ici dans append. Ça veut dire que que qu'à chaque exécution les nouvelles lignes sont ajoutées à la fin du table. Et là, je coche aussi la case override parce que c'est un détail qui évite un piège parce qu'encré mental, le premier one c'est une charge complète et si ma destination n'est pas vide à pente euh me me créer des doublons. Donc en en cochant je dis euh je dis à fabrique sur une charge complète repart sur une table propre. Donc le résultat c'est une table de départ saine. Ensuite seul les deltas qui s'ajoutent. Petite parenthèse ici le bandon qui précise que le CDC n'est pas supporté qu'avec le la le méthode merch. Donc à côté de append, si vous cliquez sur edit, vous pouvez sélectionner merch et c'est ce qui est que ça fait donc pour chaque ligne 30, il regarde si elle existe déjà euh côté destination. Si oui, il la met à jour. Sinon, il l'insère. et il peut aussi euh répercuter euh les suppressions. C'est exactement ce qu'il faut pour du vrai CDC euh pour refléter les inserts, les updates et les deletes. Et ensuite, il y a l'étape de mapping. Donc l'assistant aligne chaque table source avec sa destination et puis il n'y a que le review and save avec un récapitulatif, la source, la destination, l'évitable et puis je décide du read une fois ou sur planification ici toutes les quelques minutes. Et puis on passe on bascule directement sur le suivi d'exécution. Euh c'est ce que je voulais vous montrer. Euh table par table, j'ai le statut, les lignes, euh les lignes écrites, la durée, euh les bornes basses et hautes, donc le watermark concrètement en action. Euh ici, on a 9 tables sur 10 terminées, euh à peu près 3800 lignes déjà transférées. Et c'est là aussi qu'on retrouve le revers de la médaille dont je parlais car les lignes sont copiées vraiment. Donc chaque exécution consomme de la capacité, d'où l'intérêt de l'incremental justement pour n'écrire que le strict nécessaire. Super, merci. Je crois que vous avez prévu un comparatif entre ces différentes solutions.

Comparatif

16:07Effectivement, donc on a prévu une matrice de décision pour vous aider en fait à choisir donc quel type donc vous pouvez donc appliquer sur votre cas d'usage. Donc on va reprendre nos critères ligne par ligne comme on l'a dit au début. Donc on a la latence, donc la lecture directe pour le shortcut, quasi temps réel pour le monitoring et le batch batch pour le copy job. Donc la copie des données, donc aucune pour le shortcut, gérée pour le mirroring et complète pour le copy job. Le coût suit la même logique. Donc le shortcut est le moins cher puisque il y a pas de stockage. Le copy job par contre est le plus lourd. D'accord. la transformation. Donc euh bon, avant là, on sait que le copy job le fait mais donc Romain nous a aussi partagé que pour les shortcut maintenant c'est possible, c'est en preview donc on peut aussi le faire. Donc on va mettre à jour notre petite matrice de décision. Côté gouvernance, donc on a le shortcut qui garde la source de vérité à l'extérieur. Alors que le copy job, on crée une copie indépendante. D'accord ? Faut aussi savoir sur le côté gouvernance, on peut utiliser Purview avec Fabrique et on a déjà une bonne baseline qui est déjà intégré sur la couche fabrique. D'accord ? Et bah ce que je peux vous dire c'est garder cette grille sur le coude car elle répond à 90 % des cas d'usage qu'on voit de nos jours. Ouais. Et en effet pour la copie des données par rapport au shortcut. En effet, ces shortcut transformation auquels on peut rajouter les transformations. En fait, ils vont synchroniser les données transformées dans le oneelake. Donc là pour ces shortcuts, il y aura une copie des données. Donc un coût par rapport au stockage. Ce qu'il faut toujours mettre au regard, c'est euh le coût de processing par rapport au coût de stockage. Et qu'est-ce que je vais en faire de ma donnée demain ? parce que si je vais exposer ma donnée au travers d'un sémantique model en direct le ben ça sera peut-être moins performant que d'accéder la donnée depuis ce sémantique model si c'est par à partir de shortcut sur des données qui seraient externes auelake alors que si c'est des données internes qu'on a copié une seule fois et ben là on est un peu plus performant donc c'est toujours à mettre au regard de ce qu'on veut en faire après coup quoi. Alors ici vous nous avez comparé trois modes d'accès à la donnée. Est-ce qu'il y en a d'autres dans Fabrique ? Oui, il y en a d'autres. Donc nous, on s'est axé sur ces ces trois donc manières de copier les données ou de les utiliser, on va dire sur fabrique parce que elles étaient les plus demandées auprès de nos clients donc et on pensait que c'était pertinent de les présenter. Mais par exemple, si vous voulez faire si vous avez de l'ITI, on a en fait des ingestions en mode streaming qu'on peut utiliser. On a aussi donc une copie pipeline qui est assez similaire à copy job mais où là on peut faire plus de transformation et donc de customisation donc très détaillé avec des paramètres. Voilà donc il y a plusieurs manières de copier. Oui. Et euh on peut citer aussi peut-être les datafow gène 2 qui pourraient être utilisé pour aller chercher la donnée si on reste de plutôt dans l'usage low code. Et si on parle du code first, on peut citer là les notebooks qu'on pourrait aussi utiliser pour aller chercher et transformer la donnée. Exactement. Et maintenant qu'on a vu les trois approches en action, passons à la vraie question, celle qui intéresse les DAF et les architectes. Euh qu'est-ce que ça coûte concrètement ? Donc ce graphe, c'est l'emprunte relative sur la capacité pour amener environ un terctèque par jour. Donc c'est un schéma illustratif. Vos chiffres à vous dépendront du volume, de la fréquence et surtout de la volatilité de la source. Mais l'ordre de grandeur lui, il est juste car il a raconte une histoire très claire. à gauche le shortcut euh avec une emprente quasi nulle et c'est logique parce qu'on ne copie rien. On paye surtout euh la lecture au moment où on interroge donc pas de stockage et c'est l'option la plus la plus légère de loin. Ensuite au milieu c'est le mirror, on monte d'un cran là où on a un coût en continu celui du CDC qui réplique les changements en permanence et tant que la tant que la source bouge raisonnablement ça reste maîtrisé. Mais euh faire attention si la source est très volatile car ce coup peut exploser bien sûr parce qu' on réplique chaque changement en continu et à droite euh le copy job le plus lourd euh des trois et ce n'est pas une surprise car c'est le qui copie vraiment la donnée. Donc vous cumulez euh le stockage dupliqué le comp le compute d'in gestion à chaque run et puis le refresh récurrent dans le temps. Et donc le message à retenir, c'est pas que le copy job est cher, c'est plus on copie, plus on paye. Donc le bon réflexe, c'est de toujours se demander est-ce que j'ai vraiment besoin de déplacer cette donnée ? Si la réponse est non, Shortcrat peut peut nous éviter toute cette tout ça. Oui. Encore une fois, on peut rappeler que après ça va dépendre de ce qu'on va faire de cette donnée. Si c'est pour y accéder toutes les secondes, peut-être que les performances on les souhaite aussi rapides et en ce sens on va peut-être les dupliquer les données mais pour accélérer le processus de de rendering d'accès à la donnée en quelque sorte. Super, merci. Et d'ailleurs, n'hésitez pas à consulter la documentation de Microsoft qui tient un jour une arbre de décision en quelque sorte par rapport à l'usage des différentes technologies pour transformer, enrichir ou encore accéder à la donnée. Ici, on voit différents cas d'usage, donc n'hésitez pas à le consulter. Ouais. Et alors Roxana, Nadine, qu'est-ce que vous voyez

Conclusion

21:45le plus utiliser chez nos clients ou qu'est-ce que vous vous utiliserez en premier lieu pour accéder à votre donné ? Ça c'est une très bonne question Romain. Ben je pense je vais commencer. Moi de mon côté j'avais bien aimé les les Datafow G 2 que j'ai utilisé avec les clients et qu'ils étaient assez sortis parce que vraiment on commence avec du low code euh et donc on n pas besoin de de recruter donc des personnes avec des profils assez avancés. on peut commencer à faire des usc et des poques euh pour voir euh voilà qu'on peut comment on peut transformer des des données assez facilement avec des jointures complexes, des agrégats euh voilà. Et toi Roxana ? Et moi euh en fait moi euh ce que j'ai trouvé le plus souvent chez chez mes clients, c'est les shortcuts parce qu'en fait la plupart d'entre eux ils ont une stratégie euh multicloud et donc euh les shortcut les permettaient d'accéder à la donnée donc sans sans copier, sans duplication et donc c'est une souplesse de leur travail euh chaque jour. En effet, ben merci beaucoup, merci Nadine, merci Rosana pour cette présentation et démonstration. On mettra les liens qu'on a présenté euh en dans la vidéo. Si on doit retenir une chose, c'est que Fabrique ne cherche pas à multiplier les copie mais plutôt orchestrer intelligemment l'accès à toutes les données dans votre organisation. les shortcut pour exposer, le mirroring pour rester à jour, le copy job pour rapatrier la donnée, mais surtout la vraie règle c'est pas de la copier ou ne pas la copier, c'est plutôt de l'unifier et en fonction de vos besoins. Donc encore une fois, merci d'avoir suivi cet épisode. Si vous avez des questions, des retours d'expérience ou si vous souhaitez creuser un point en particulier, les commentaires sont ouverts. On vous dit à très vite pour un nouvel épisode et d'ici là, abonnez-vous à la chaîne. À bientôt. À bientôt. Bientô.