Microsoft Fabric et Power BI : Peut-on migrer une capacité vers une autre région Azure ?

Phare Data

Maintenant, compliquons un peu la tâche avec un modèle qui est large. Je vais avoir un rapport qui me dit ben non, tu je peux pas loader ton modèle parce qu'il était en large et tu l'as bougé de région. [musique] Ouais. Oui, bonjour et bienvenue sur Fardata, la chaîne qui éclaire vos données. Aujourd'hui, nous allons répondre à une question que de nombreuses organisation se pose. Peut-on déplacer des capacités Power BI ou Microsoft fabrique d'une région vers une autre ? Qu'en est-il du tenant lui-même ? Est-ce qu'on peut déplacer cette fameuse Home région ? Derrière ces questions se cachent de nombreux enjeux. L'emplacement des données, les performances, les coûts, la conformité réglementaire ou encore la souveraineté. Est-ce aussi simple qu'un simple clic ? Quelles sont les limites à connaître et surtout quels sont les impacts et qu'est-ce qu'il faut anticiper. Bon, c'est précisément ce que nous allons voir dans cet épisode. Sur Far Data. Notre objectif est simple, vous aider à y voir plus clair dans l'univers de la data, de l'analytics, mais aussi de l'intelligence artificielle. Chaque épisode est préparé par des passionnés avec l'envie de partager, d'apprendre et de rendre un sujet utile au plus grand nombre. Fardata est une chaîne ouverte. Alors, n'hésitez pas à nous suggérer des sujets ou même à venir partager votre expertise lors de futurs épisodes. N'hésitez pas à nous contacter et le contenu s'il vous plaît, pensez à vous abonner pour ne manquer aucun des prochaines publications. Capsule épisode du jour.

Introduction

1:31Alors, ce qu'on va montrer dans cet épisode, on va voir pourquoi les projets de migration cross région deviennent de plus en plus fréquents chez nos clients, les différents scénarios possibles, cross tenant, tenant split ou encore tenant trimap, les risques et les limites qu'il faut absolument connaître avant de se lancer et les principales étapes d'un projet de migration puisqu'on a avec nous quelques experts du sujet et surtout plein de démos et des retours terrain. Pour nous accompagner aujourd'hui, j'ai le plaisir de recevoir deux spécialistes renommés à savoir Manel et Akram. Bonjour à tous les deux. Est-ce que vous pouvez vous présenter ? Avec plaisir. Donc euh je vais commencer priorité aux femmes, n'est-ce pas Acram ? [rires] Manelani, je suis class architecte chez Microsoft France depuis depuis presque 5 ans maintenant et et j'accompagne en fait les clients sur la mise en place d'architecture et de plateformes autour de la data. Voilà. et de mon côté Acramdre Cloud Solution Architect chez Microsoft de V presque 2 ans sur la thématique des I de fabrique data plateforme. Au plaisir de parler au sujet de ces migraçons cross region aujourd'hui. Lorsqu'une organisation doit déplacer ses données vers une autre région azur, la réalité est souvent plus complexe qu'il n'y paraît. Il n'existe pas de bouton move my tenant ou move my capacity. Les objets doivent être analysés afin d'identifier ce qui peut être migré, recréé ou reconfiguré. avant de parler de migration. Donc on va commencer par comprendre pourquoi ces projets sont mis en œuvre et dans quel cas ils sont fortement ils ont réellement un sens. Manel, donc il y a plusieurs raisons pour lesquelles on peut être amené à changer

Pourquoi changer de région ?

3:08de région et la première raison est souvent réglementaire. Certaines organisations doivent conserver leurs données dans un pays ou une région bien particulière, bien précise pour répondre à des exigences de conformité ou de souveraineté. Et puis on retrouve aussi la raison de la performance où on veut se rapprocher le plus possible de nos utilisateurs finaux. Et du coup dans certains cas, si on a mal fait notre architecture en amont, on peut être amené à rattraper le coût et à redéplacer ou à rapprocher nos données de nos utilisateurs pour améliorer l'expérience globale de nos rapports ou de notre plateforme data. Effectivement Manal, il y a aussi même d'autres projets qui sont motivés par des considérations organisationnelles comme donner plus d'autonomie à une filiale s'ils sont surtout multirégion accompagner une fusion. On a eu récemment avec un client également une acquisition ou au contraire une séparation d'activités. Donc même certaines entreprises, on les voit chercher à optimiser leur coût comme tu l'avais bien dit ou à limiter les flux de données entre plusieurs régions. D'où l'importance de cette migration cross region qui peut avoir plusieurs raisons également. Oui. Et donc on voit bien changer de région n'est pas une décision technique, c'est surtout un choix métier lié à la conformité, aux performances, l'organisation et souvent motivé par l'évolution des besoins géographiques, la transition vers fabrique ou des opérations de fusion et d'acquisition.

Pourquoi changer la région du Tenant ?

4:35Avant de rentrer dans le vif de notre sujet qui est la migration cross région au niveau des capacités fabriques, on voulait quand même faire le point sur euh une migration euh assez particulière qui est la migration cross tenant, c'est-à-dire quand une entreprise veut changer son la région de son euh tenant, donc de son tenant fabrique d'une région à une autre. Effectivement le point clé est qu'une migration n'est pas toujours nécessaire. des solutions comme multio et justement fabrique, il accepte, il adhère au multio, c'est ce qu'on va voir durant nos différentes présentations et démos ou certaines architectures de stockage peuvent souvent répondre aux besoins avec moins de risque et d'effort que faire cette migration de tenant entier ? En fait, lorsqu'une migration est réellement nécessaire, il faut garder à l'esprit qu'il n'existe pas de mécanisme automatique. Une grande partie de travail reste à la charge de clients. Certains composants doivent être recréés. Les espaces personnels ne sont généralement pas migrables et surtout les données elles-mêmes ne sont pas déplacées automatiquement. Les modèles, les lakous, les artefacts fabriquent, on va voir ça avec Manel sur sa démo tout à l'heure également. Donc tout ça à prendre en considération avant de prendre cette décision de changement tenant ou changement de capacité. D'où la nécessité et la recommandation de plutôt utiliser cette solution multigéo. Oui. Donc en résumé hein, la migration du home tenant doit rester une exception. On voit que c'est quand même compliqué réservé aux contraintes organisationnelles ou réglementaires qui ne peuvent pas faire autrement que de migrer le tenant. Mais sinon, on va voir d'autres process notamment en régionalisant nos capacités. Avant d'utiliser le multigéo, il faut garder

Considérations et limitations

6:16en tête que cette fonctionnalité permet de localiser les données, les traitements dans une autre région, mais qu'elle ne déplace pas l'intégralité des composants du tenant. En effet, le calcul et le stockage, notamment le one lake sont hébergés dans la région de la capacité. En revanche, certaines métadonnées comme par exemple la structure euh d'un modèle sémantique, les permissions sont hébergés au niveau de la région du home tenant, donc euh les autorisations, les informations d'identification, les modèles sémantiques et même certaines données de pourvieu et de gouvernance. Justement, les données mises en cash et les requêtes restent repos dans la région distante avec une réplication possible dans une autre région de la même zone géographique pour la reprise après sinistre. Cependant, lors d'un déplacement, quand on fait cette migration, les données sources peuvent rester jusqu'à 30 jours dans l'ancienne région avant leur suppression. Donc à vraiment garder en tête lors de ces projets. Ouais. Et il existe exalement plusieurs limitations importantes. On peut citer les dataflogè 1 dans un environnement multigéo. Le stockage doit être configuré sur un adal gen 2 et tu nous montreras ça en démo, je crois à Cram. Le point essentiel à retenir est donc que le multiéo répond aux besoins de résidence des données mais que la région d'origine du Ton conserve un rôle important. Il faut donc vérifier en amont les exigences de conformité, les types d'éléments concernés et leurs dépendances.

Étapes de migration et prérequis

7:42Et du coup, on revient à notre sujet principal qui est la migration cross cross région à l'intérieur d'une capacité. Et pour ça, en fait, on a plusieurs étapes. C'est des étapes type d'une migration projet. Euh il est très très important de commencer par cesser et de comprendre qu'est-ce qu'on veut migrer. Euh combien d'espace de travail, euh combien d'items euh ou de rapports PowerBI, euh est-ce qu'on a des dépendances d'un rapport vers un autre ? Est-ce qu'on a des dépendances entre les data flow et cetera ? C'est hyper important de faire un inventaire de de ce qu'on va migrer. Ensuite, euh, il est important aussi de prendre certaines décisions stratégiques, c'est-à-dire quelle est law de la nouvelle capacité vers laquelle on veut déplacer nos artefacts fabriqu euh dans quelle région ? Euh qui seront les administrateurs ? Qui va monitorer la nouvelle capacité et cetera ? et bien évidemment la planification, c'est-à-dire nous généralement on ne recommande pas de faire une migration directe. On recommence justement de toujours commencer par un petit scope, de faire des tests et ensuite faire la migration par vague. Et enfin la migration en tant que telle qui est infiné une action technique où on va justement vous détailler un certain nombre de scénarios et comment vous pouvez les mettre en place chez vous. Ouais. Donc on s'aperçoit que c'est un vrai projet qui doit donc avoir un planning avec comme tu l'as dit nous ce qu'on suggère c'est des waves. Donc si on a plusieurs capacités, on a vu des clients avec 60 capacités qu'il fallait migrer, on a commencé par migrer peut-être 10 capacités par 10 capacités. Ce qui a permis donc d'ordonnanoncer toutes ces activités aussi après de review de vérification et plusieurs manières pour faire ces différentes migrations. Là on en en cite quatre. La première, c'est de le faire individuellement. Ça, vous pouvez juste euh réassigner les workspace parce que en gros, quand on parle de migration euh de de projet ou de workspace, c'est juste réassigner la licence qui est affectée à ce workspace- là. Donc par exemple, il est c'est quand on dit une P2F, donc Power BI Premium, tout fabrique capacité. Donc vous avez juste à changer ça. Vous allez le voir dans nos différents démos réassigner, on va les réassigner individuellement, soit à partir du portail admin euh sélectionner plusieurs et les réassigner, plus facile, plus rapide. Mais après, si vous avez vraiment beaucoup de d'espace de travail, on peut bien sûr utiliser les R APPI en code ou sinon la fameuse bibliothèque Cantic Linklab. C'est ce qu'on utilise le plus. Vous allez aussi les voir en démo, plusieurs manières pour faire cette migration. Donc quelques prérequis à cette migration. La première, c'est de vérifier qu'on a bien les Azur quota disponibles dans la région où on souhaite créer notre capacité. Ensuite, on peut imaginer d'acheter les réservations. On peut imaginer si on a déjà du bringy sur nos capacités euh premium, pourquoi pas aussi encrypter nos capacités fabriques de destination et cetera. Bref, il y a quelques prérequis euh on va pouvoir les lister aussi dans nos démonstrations. Ensuite, l'assessement qui est un prérequis, ben c'est d'assesser qu'est-ce qu'il y a sur votre capacité que vous souhaitez migrer. Et en ça, on a différents scripts communautaires qu'on euh qui sont disponibles avec notamment ce rapport qui nous permet de savoir la difficulté qu'on aura à migrer en fonction des items qu'on a à l'intérieur de notre capacité. Donc la première étape, c'est l'assessment. Ici, c'est l'environnement de démo que je vais

Assessment

11:14utiliser pour les différentes démos à venir. Donc, j'ai deux capacités, une en France, une aux US. On va devoir migrer euh l'une des régions. Je regarde d'abord où est mon home tenant. Et vous voyez ici, je suis en Arizona. Maintenant, ce que je vais vouloir voir, c'est regarder ben qu'est-ce que j'ai comme workspace en l'occurrence sur cette capacité de démo. J'en ai pas beaucoup, j'en ai trois. Regardons. Donc c'est en France maintenant aux US combien j'en ai. C'est la nouvelle capacité que j'ai créé. Pour le moment, j'ai rien du tout. Première étape et une étape manuelle puisqu'on a pas de reste à PI pour le faire, ça va être de copier les paramètres de la capacité 1 vers la capacité 2. Maintenant, j'utilise une capacité tierce ici pour faire cet assessment. J'ai un notebook, on vous mettra le lien du Snopbook euh dans le lien de la vidéo dans lequel j'utilise comme l'a énoncé Akram le Sémantique Linklab qui va me permettre comme ceci de regarder tous les objets qui sont sur ma capacité que je souhaite migrer. Une fois que ce script exécuté, les informations sont enregistrées dans un donc qui sont persistés, ce qui vous permet de l'exécuter aussi plusieurs fois et de suivre peut-être l'historique. Ce même notebook va nous créer un rapport ce qui va nous permettre après de regarder d'analyser ces informations là. Ici, on voit qu'il a créé un sémantique modèle, un rapport associé. Et donc, si on regarde rapidement d'abord le on va pouvoir effectuer des requêtes aussi sur les données. Ici, je vois les deux capacités que je veux utiliser pour les démos. Et si je regarde le rapport, ça nous simplifie un peu l'analyse. Ça me donne aussi des Capi sur les difficultés que je vais avoir à migrer. Donc ici, si je choisis la capacité que je souhaite migrer et la cible, je vois ici les informations. Je vois notamment que j'ai des l'archémantique modèle. On en parlera tout à l'heure. Et ce qui est bien dans ce disco, c'est qu'on a un code couleur qui simplifié dans le monotage, c'est que avec le vert, ça passe directement, très facile. Euh au rouge, donc c'est un large modèle et donc on devra faire les différentes transformations. Et sinon, le jaune, ce qu'il y a un datafow et on verra les spécificités du datafow lors de mes démos.

Démo 1

13:32Justement, parlons des différentes démos. Voici les différentes démos qu'on va vous jouer en commençant par la première à savoir migrer un workspace ayant un small sémantique model. On va voir que c'est plutôt euh simple à effectuer. Puis on va complexifier les différentes démos par la suite. Donc ici je suis sur ma capacité France dans lequel j'ai actuellement un certain nombre euh de workspace. Je vais utiliser encore un notebook qu'on pourra vous partager parce que imaginons que j'ai plusieurs workspace, j'ai pas envie de le faire à la main workspace par workspace. Donc ici en l'occurrence j'en ai qu'un mais je vais quand même le faire à partir du script ce qui m'évitera de le faire manuellement. Donc c'est pour ça que j'ai précisé, comme vous le voyez ici, le workspace ID du workspace que je souhaite migrer. Sur ce workspace, j'avais qu'un sémantique modèle qui est configuré en small et on voit qu'il a été euh déplacé rapidement sur maintenant la capacité aux US. Donc je j'ai bougé de France à US. J'ouvre le rapport, vous voyez que ça va très rapidement et le rapport fonctionne plutôt bien. Il y a pas de souci. Des mots plutôt simples. Maintenant, compliquons un peu la tâche avec un modèle qui est large mais qui est inférieur à 10 Go. Donc, on va regarder une autre démonstration. Donc ici, je

Démo 2

15:02suis sur ma capacité. Il me reste deux workspace à migrer. Le premier étant celui où j'ai un sémantique modèle inférieur à 10 Go. Donc, je suis encore en France. La paramètre au niveau du workspace est small, mais c'est un paramètre pour les nouveaux workspace qui arriveront sur ce workspace. Les workspace après on peut au niveau du sémantique model le configurer. Donc c'est le cas pour ce sémantique modèle qui est en large alors que le paramètre par défaut est small. J'espère que vous m'avez suivi. Maintenant je migre ce workspace à la main pour vous montrer qu'on peut le migrer aussi à la main. Mais on voit que alors que je l'ai pas passé en small, j'ai cette erreur. Donc vous voyez ici quelque chose que les clients ont eu souvent à savoir je peux migrer le workspace, il y a pas de souci, j'ai pas d'erreur. Pour autant, c'est lorsque je vais l'ouvrir ce modèle que là je vais avoir un modèle, je vais avoir un rapport qui me dit "Ben non, tu je peux pas loader ton modèle parce qu'il était en large et tu l'as bougé de région." Donc l'étape qu'il faut faire dans ces cas-là, c'est rebasculer sur la région précédente, mer la région mer. Donc ici en l'occurrence France. Et là, je peux réouvrir le modèle. Tout va bien. Donc maintenant ce que je vais faire c'est que je vais le passer en small et on vous passera aussi ce notebook. Donc j'utilise encore la librairie sémantique linglab et donc je passe le modèle en small. Comme il est inférieur à 10 Go, ça se passe bien. On verra ce qui se passera lorsque j'aurai un modèle supérieur à 10 Go. Maintenant, je souhaite ici euh le basculer et là en l'occurrence, j'utilise euh le code. Maintenant, si je regarde les euh workspace, je vois que j'en ai un nouveau qui est en train d'arriver à savoir real cutting. C'està-dire qu'il est pas encore arrivé, maintenant il est arrivé aux US. Et euh je peux là le rebasculer en large une fois que je l'ai basculé dans sa région cible. Et donc maintenant si j'ouvre le rapport, il fonctionne bien. Suivant la taille de votre modèle, le réalocating peut prendre plus ou moins de temps. Rappelez-vous, on migre de région, donc les données migrent aussi d'un continent à l'autre. Ici en l'occurrence, on voit ici le paramètre large sémantique modèle au niveau du sémantique model.

Démo 3

17:233è et dernière euh démo pour ma part, à savoir ici un modèle supérieur à 10 Go. Alors, regardons ce que ça va amener comme complexité. J'ai plus qu'un workspace à migrer, donc je souhaite migrer de France aux US. Je vais aesser mon modèle. Je vois qu'il est en premium file, c'est-à-dire qu'il est en large schémantique model. Ce euh sémantique modè, il est plutôt volumineux. il a plus de 16 Go à un certain nombre de tables, pourquoi pas. Maintenant, je vais regarder au niveau aussi euh du système storage, je retrouve euh le la taille du modèle. Donc, qu'est-ce que je dois faire dans ces cas-là ? La première option, c'est d'essayer de le passer en small. On va voir ce qui se passe. Comme il est supérieur à 10 G, vous aurez l'erreur suivante. C'est pas possible. Qu'est-ce qu'on va pouvoir faire ? Alors, je pourrais le cleiner puis après le passer en small, basculer mon workspace, le remettre en large et faire un refresh full ou plus intéressant si je veux pas avoir à payer un autre full refresh ou un incremental refresh. Enfin, ce sera un full puisqu'il a il sera vidé. C'est ici comme je fais à savoir faire un backup de mon sémantique modèle. Et donc pour se faire, j'ai connecté un compte de stockage. J'utilise cette fonctionnalité backup sémantique model. Mon modèle va être compressé, stocké sur un compte de stockage. Je vois ici la taille de modèle créé. On voit que ça a pris 3 minutes, hein. Donc c'est plutôt rapide pour la volumétrie. Maintenant, ce que je vais faire, c'est que je vais faire un clear value. Donc je vais vider mon modèle, ce qui va me permettre de pouvoir le passer en small puisqu'il sera vidé. Hein là, là j'ai complètement vidé modèle, d'où le fait de l'avoir backup auparavant. Donc ici, mon modèle est vide. Maintenant, je vais pouvoir configurer le settings ici en small. Là, je vais pas avoir de problème puisquil est inférieur à 10 G. Une fois que c'est fait, je vais pouvoir basculer mon workspace. Différentes solutions. Ici, j'utilise la version manuelle. OK, là je vais pas avoir de problème. L'étape d'après, ça va être de repasser en large. Une fois que j'ai basculé, maintenant je suis aux US, je dois rebasculer mon modèle en large avant de le restaurer. Le restaurer toujours à partir du même compte de stockage. Donc j'ai réattaché mon euh ADLS GN2 et ici, je fais un restore. Donc il va écraser euh mon modèle. Faut savoir ici que je suis en Ouest US euh et que la restauration a pris 2 minutes, hein, vous voyez. Donc c'est plutôt rapide pour un modèle de 16 Go. Et puis j'ai plus qu'à réouvrir mon rapport maintenant qu'il est aux US et tout va bien. Pas mal d'activités qui sont scriptables. Donc on peut automatiser ça sur un ensemble de sémantique modèles. Et je retrouve bien mon modèle original. Rappelez-vous he ce backup restore, ça peut être aussi intéressant pour sauvegarder une version de votre modèle. Ça contient aussi bien la structure que les données. Ça peut être pertinent pour faire un restore en cas de problème. Remarque par rapport à ce que tu as fait comme process sur les larges modèles de 10 Go. La DLS que Romain a utilisé comme backup, il doit être public, c'est une limitation. Il peut pas être derrière un fireall ou privé. Et donc des entreprises peuvent refuser l'utilisation de ce ADLS public. Dans ce cas-là, ce qu'il faudra faire, c'est faire le clean parce qu'il ne fonctionnera pas. Vous pouvez pas le passer. Mais après, il faudra refaire un full de votre modèle post migration. Le full peut se passer rapidement donc tant mieux pour vous. Sinon, si ça prend beaucoup de temps, deux foions envisager pour éviter de faire un full complet. La première, c'est peut-être de faire un clean d'une partition si c'est en incrémental ou bien de quelques tables. Donc pour faire passer ce modal en dessous de 10 Go et on passe sur le cas précédent. Si vous voulez pas faire un clean complet et refaire un full complet, ça dépend de la taille de votre de vos modèles. Et la deuxième chose, c'est un peu de faire un double run. un double run, c'est-à-dire à partir de votre de votre PowerBI desktop, vous avez votre projet, vous allez le déployer directement dans un un nouveau workspace dans la capacité cible. Vous vous assurez que toutes les données sont prêtes et puis vous faites la bascule. Soit les anciens rapports vous les liez au niveau sémantique modè qui est sur le la capacité cible ou bien vous utilisez directement les nouveaux rapports et vous éliminez l'ancien. Cette solution c'est surtout pour éviter cette attente de euh d'un full refresh qui peut prendre des heures voire plus pour quelques sémantiques modèles et coûter cher en CU aussi. Exactement.

Démo 4

22:36Maintenant, on va s'intéresser à au cas où si on avait un espace de travail qui contient des fabriques items ou des éléments fabrique. Je tiens juste à préciser que les datafow gè 1 n'en font ne font pas partie des fabriques item. Donc ça c'est un scénario que Akram va prendre en charge tout à l'heure. Donc là j'ai un exemple d'un espace de travail qui est dans la région North Europe. Comme vous pouvez le voir, c'est un espace de travail qui contient énormément d'éléments fabriques comme par exemple ici un notebook qui est rattaché à un lake house. On va aussi avoir des data agents. On va aussi avoir des data flow, des modèles sémantiques en direct lake vers un lake house. On va avoir aussi des pipelines qui font référence à d'autres pipelines. Donc comme vous pouvez le voir, c'est un espace de travail où on a plusieurs éléments fabriques. Et là, en fait, le processus de migration de cet espace de travail vers un autre espace de travail d'une autre région n'est pas aussi simple. En fait, il n'y a pas aujourd'hui la possibilité de changer de région d'un espace de travail qui contient des fabriquem. Par contre, ce qu'on va vous proposer ici, c'est une alternative à comment vous pouvez recopier la structure euh de tous ces éléments vers un autre espace de travail. Mais je tiens tout à préciser qu'il va y avoir pas mal de d'étapes très manuelles. Donc ici, je vais créer un nouvel espace de travail qui sera cette fois-ci dans la région Ouest Europe, US pardon. Donc c'est un espace de travail complètement vide et mon but c'est de migrer les différents éléments qu'on a vu tout à l'heure directement ici. Pour ce faire, je vais créer un deployment pipeline. Donc ici je vais juste renommer les stage de mon deployment pipeline. Je commence d'un déploiement de North Europe et je veux déplacer ça vers un autre espace de travail qui est en West US. Donc rattaché à ma capacité West US. Jusqu'ici, tout va bien. Par la suite, bien évidemment, il faudrait que je déploie les éléments de mon espace de travail North Europe vers mon espace de travail West Europe. Donc ici, j'ai 25 éléments en tout. Donc je sélectionne tous ces éléments et je clique sur deploy. Ça va vous prendre un certain nombre de temps, donc un certain une certaine période, mais infini, je vais avoir la structure, donc le schéma, la définition de tous mes items fabriques dans le nouvel espace de travail West West. Donc on peut constater que les fich dossiers ont été recréés, les éléments ont été recréés. Mais mais si on regarde un peu plus dans le détail, ce n'est pas aussi simple. Donc déjà là, on va prendre un petit moment et on va essayer de prendre quelques exemples. Je vais essayer de m'intéresser à ce notebook. Donc ce notebook là avant de le migrer, il était rattaché à un lake house qui est résidé dans mon espace de travail nord-ope. Donc on peut voir qu'après migration vers c ce nouveau nouvel espace de travail on voit sur Europe mon ce nouveau notebook il est aujourd'hui rattaché au lake house qui est dans le nouveau espace de travail c'est parce que en fait il y a certains items fabriques qui permettent l'autobinding avec guit donc quand on parle de guit c'est soit quand on veut déployer et de faire du cidd avec des branches soit via le déployement pipeline. Donc chaque élément, on va avoir au niveau de cette documentation s'il adhère à l'autobiding ou pas. Donc s'il ad l'autobinding, très bien, ça se passe si on a rien à reconfigurer. Par contre si l'item avec certaines options ne fait pas de l'autobiting, il faudrait qu'on fasse des étapes manuelles obligatoires pour être sûr que tout fonctionne. Donc ici, si je reviens à mon espace de travail North Europe, je peux voir queau niveau du setting de mon notebook, j'avais bien précisé que je veux l'autobinding. Je veux que une fois que je migre ça avec mon guide, le nouvel notebook est rattaché au LCR qui est dans le nouvel espace de travail. Donc ici, il y a pas de problème. Par contre, dans certains éléments, on peut voir que ça peut être un peu plus préquy. Si je prends le cas d'un datafow jeune 2, donc au niveau de la source, ça change pas. Donc euh ma source euh elle est auto bindée donc on a rien à configurer. Par contre au niveau de la destination si on regarde la documentation écrit noir sur blanc que quand on utilise un datafow gun 2 et si au niveau des destinations on a un layout, il n'y a pas d'autre binding. Donc on peut voir d'ailleurs que ici je suis en train de référencer le Lake House qui existe dans mon espace de travail North Europe. Donc c'est important d'aller faire le rebind soit manuellement comme je le fais ici, soit via les API. Mais ça c'est une action obligatoire à mettre en place dans le cadre où vous dans le cas où vous utilisez un datafogion 2 avec une destination un Lake House ou un data warehouse. Donc il y a tout est décrit au niveau de la documentation. Donc ça c'est un cas qu'on vient de prendre en compte. On va voir d'autres cas au niveau des items fabrique. Prenons cette fois-ci. Là, on voit bien que notre datafow se rafraîchit et se processe avec succès. Et maintenant, on va prendre un deuxième cas. Donc ici, on va s'intéresser à des pipelines. Comme vous pouvez constater ici, mon pipeline, il va faire appel à un ordonnancement de notebook et d'autres pipeline. Le pipeline ici, donc le l' réservation, il est dans le même espace de travail. Donc et on peut voir au niveau de la documentation que si je fais référence à un pipeline notebook data flow 2 SQL database, c'est autobind. Par contre, si je veux rafraîchir mon modèle sémantique ou si je veux faire référence à un data warehouse, ce n'est pas autobindé. Donc si j'avais ce type d'élément dans mon pipeline, il aurait fallu que je gère ça manuellement. Maintenant, prenons aussi le le scénario d'un like. Ici au niveau de mon like house, si je l'ouvre au niveau de mon nouveau nouvel espace de travail, au niveau des table, je retrouve ma table ma table fabrique émission que mon datafow a a créé et a alimenté. Mais je vois ici au niveau des files mes shirt cut. Donc ici, je peux déduire que dans le cadre d'un lake house avec des shortcut, il y a l'autobind. Donc ça déjà, c'est une excellente nouvelle. Ça veut dire que si au niveau de mon Lake House euh au niveau de Northy avait un shortcut, j'arrive à les reproduire assez facilement. Ici, bien évidemment euh j'ai toujours accès euh à la source de mon shortcut. Maintenant, essayons de d'alimenter ou de populer ou de copier en fait ou de créer les tables au niveau de mon Lhous. Pour ça, il n'y a pas 1000 solutions. On est obligé de faire la recopie de données. Donc ici, dans mon cas, je suis obligée d'aller relancer mon pipeline avec l'ensemble d'historique de données que je veux. Donc en l'occurrence ici, je veux récupérer les 20 derniers mois de de mes données de Phinops. Donc ça c'est obligatoire. C'est quelque chose qu'on est obligé de faire pour réalimenter ou pour reprocesser les données au niveau de du nouvel du nouvel espace de travail. Une fois qu'on a fait ça, vous pouvez me dire "Ah tiens très bien, j'ai copié les éléments, j'ai mis à jour mon datafogion 2, j'ai mis à jour mon lake house avec les tables et les fichiers. Donc a priori mon sémantique modèle qui est en direct lake versus Lake House est censé fonctionner sans problème. Et ben ce n'est pas tout à fait le cas parce que vous allez voir qu'au niveau d'un modèle sémantique qui est en direct lake et qui utilise comme source de données un un SQL end point lié au Lake House au niveau de la documentation de l'autobinding, ce n'est pas pris en charge. Et d'ailleurs là, on peut le constater au niveau du lineage, on peut voir que notre rapport qui est rattaché à notre modèle sémantique ici, il fait référence à un SQL point qui réside. dans mon espace de travail de Nord Europe. Donc dans ce genre de situation, il faudrait qu'on fasse le rebind de ce nouvel modèle modè modèle sémantique dans ce nouvel espace de travail vers le endp qui qui est rattaché au lake house euh du workspace West West West US. Et ça en fait il y a plusieurs façons de le faire. Soit on le fait en skiptant avec des API, soit dans mon cas ici, je vais utiliser le Team d'alview viiew et d'ailleurs c'est une fonctionnalité euh euh nouvelle qui est en preview actuellement sur l'édition euh des modèles sémantiques. Donc on va le voir. Excusez-moi, je n'ai pas mis ici. Donc j'accède donc j'essaie d'éditer mon modèle sémantique directement en ligne. Je n'ai pas besoin de mon descope comme vous pouvez le voir ici, ce n'est pas pris en en compte. Donc l'autobinding n'est pas pris en compte. Je dois gérer ça manuellement ou en skiptant. Ce que je vais faire, je vais ouvrir mon timnaldal view et ici je vais mettre la définition de tout mon modèle sémantique. Donc c'est la définition teamal de mon modèle sémantique. Et ça c'est documenté. Je vais chercher la partie expression qui permet de référencer la database du SQLP de mon Laps. Donc on va la retrouver un peu plus bas et vous allez voir ça fait référence à l'SQL point avec l'objet ID de mon Lake House. Et ça en fait il va falloir le modifier. Pour le modifier, je vais aller vers le Lake House de mon espace de travail de West US. Je vais aller récupérer le SQL Point. au niveau du des settings de mon layhouse. Donc ici, je copie le SQL point que je vais aller modifier au niveau de mon team et je vais aussi aller récupérer la la l'object de mon SQL endp aussi. Donc pareil, je vais accéder à mon end point de mon house. Donc ici, j'accède directement à mon à mon end point. SQL point et je vais aller récupérer l'ID au niveau de l'URL. Là c'est un sémantique modèle en direct le on SQL. D'où le fait que tu as récupéré le SQL on point, ce serait un on direct le lake on one le que faudrait juste changer le end point du Lou l'occurrence. Exactement. Exactement. Et donc selon les différents items fabriqu euh à chaque fois on doit confirmer s'il y a de l'autobinding ou pas. C'est du cas par cas. Exactement. cas par cas effectivement. Exactement. Donc il y a pas mal d'objets qui supportent l'autobinding, mais il y a plusieurs autres scénarios qui ne supportent pas et dans ce genre de situation il faut l'inclure dans votre dans votre planning de migration. Donc ici j'ai mis à jour des différents ID, j'ai appliqué et je peux vérifier au niveau de ma vue lineage si cette fois-ci mon modèle sémantique il est bien bindé au nouveau L. Donc en l'occurrence ici, on le voit bien, si je remonte plus haut, j'ai mon rapport vers le modèle sémantique et vers le SQL Point euh qui réside au niveau de mon espace de travail. Et du coup, à partir de ce moment-là, je peux venir rafraîchir mon modèle sémantique. Bien évidemment, euh j'ai toujours accès aux différentes connexions, donc j'ai toujours accès au Lust et j'ai la possibilité d'aller visualiser directement mes données au niveau de de mon rapport. Le résumé ici, c'est que à partir du moment où vous avez un espace de travail avec des items fabriques, il faudrait faire attention à remettre les connexions et à remettre le binding si vous êtes dans l'un des scénarios qui est très bien documenté au niveau au niveau de l'article qu'on vous partage qu'on vous partagera aussi au niveau des commentaires de cette vidéo. Super, merci beaucoup Manel. Super démo, on voit que c'est pas forcément simple suivant les types d'items. Ce qu'on peut rajouter, c'est que si vous utilisez Azure DevOps ou Azure Gitup, vous pouvez aussi synchroniser dans un guit tripo vos développements pour après les déployer dans une autre région. C'est aussi possible. Mais Akram, à ton tour de nous présenter

Démo 5

35:05certaines complexité quant à la migration d'une capacité vers une autre région. Merci [grognement] Romain et merci Manel encore pour cette démo. Alors concernant les datafow, c'est votre préparation de données mutualisé dans le service du power query hébergé dans le cloud que tous vos rapports viennent consommés. Et là, vous voyez sur la slide qu'il y a trois générations. Donc le datafow Jan 1, l'historique, il fonctionne mais euh il est en état legacy, ça veut dire qu'il ne va plus évoluer. Il n'a ni intégration avec fabrique complète ni CICD natif. C'est bien mentionné dans la doc. Je vous ai mis le lien ici le gen 2 et ça par contre c'est la version native de fabrique. Donc même power query qu'est-ce qu'il y avait avant mais vous choisissez votre destination. On a vu Manel comment elle était en train de choisir la destination Lakeout en sur en destin euh sur le sur la capacité cible donc one lake Lake House Warehouse et cetera. Et aussi nous avons après le gen 2 CICD. En fait, il ajoute juste la partie guit, les pipelines de déploiement, la promotion entre def, test et prod. Donc si vous avez des datafow Gen 2 ou Gen 2 CD, il faut faire ce que l'avait montré. Donc le passage d'item fabrique euh en cross region. Par contre concernant le data flowjan 1, ça va dépendre de quelques paramètres. Et donc pour comprendre ces spécificités spécificités pardon sur les datafow euh petit rappel sur le multio dont on a parler au départ. Ce qu'on a évoqué tout à l'heure c'est que le principe en fait votre tenant il a une région ici dans cet exemple on va dire c'est Europe mais vos capacités peuvent vivre dans d'autres régions France centrale South Asia dans les deux ici. Et donc chaque workspace il stock ses données dans la région de sa capacité. Donc le message clé tient en deux phrases, une capacité hors home region, elle garde le compute et le stockage dans la dans la région. Généralement, c'est la raison principale pour laquelle les clients ils changent de région. Donc vos données au repos sont bien là où vous les vouliez mais les métadonnées, permission, métadonné de rapport, créential, elles sont tenant du home region. Et donc là par rapport au datafow, si on regarde notre cas euh suivant du datafow pendant oui, vous voyez ici qu'il a trois capacités donc Europe, France centrale et South Asia. Et ici typiquement dans mes trois capacités, j'ai la même chaîne. Donc source, dat flow, modèle sémantique et rapport. Mais regardez les flèches, elles convergent toutes au même endroit. Donc par défaut, le stockage du data flow reste dans le home region, quelle que soit la région de la capacité. Donc c'est un peu un échec silencieux parce que vous allez le voir, tout fonctionne quand vous allez faire la migration. Aucune erreur mais la donnée n'est pas où vous la croyez. En fait, il va stocker euh au format CDM c'est datafow. Il va stocker les données au format CDM. C'est un fichier JSON qui décrit le schéma, les données à côté. C'est un format ouvert, lisible. Et donc là, la parade c'est le bring your own storage. Ça veut dire vous mettez votre propre compte de stockage là où vous le voulez pour que vos données soient conformes à ce que vous voulez et que vous pouvez aussi en crypter avec vos propres clés. C'est aussi un avantage effectivement. Et donc ce que je dis, ce n'est pas vraiment une interprétation. C'est écrit clair dans la documentation officielle. Vous voyez ici dans les considérations et limitations, ça dit que pour utiliser les datafowjan 1 en multigéo, ça veut dire flow dans une capacité cible et le homogen elle est dans une autre région, il faut you must, c'est ce qu'ils ont dit configurer le stockage vers un ADLS gen 2. Donc par défaut votre stockage reste dans la home region quelle que soit la capacité sauf si vous activez votre propre stockage qui se configure workspace par workspace. Et donc ce qu'il faut garder en tête, c'est que quand vous allez migrer un datafow, ça marche fonctionnellement mais ça ne place pas la donnée au repos dans la région multigéo. Et c'est c'est exactement là que le sujet en fait, il cesse d'être technique pour pour être vraiment un sujet de résidence de données ou souveraineté de données. Parce que là, on parle de résidence la votre donnée où est-ce qu'elle est stockée et aussi en rajoutant toute la gouvernance, les contrôles pour ne pas exfiltrer les données ou pour protéger les données, vous allez rajouter les paramètres pour avoir une souveraineté de données. On est maintenant dans le euh use case numéro 5. Donc là où on va configurer le stockage de notre datafow. Sur ce workspace, nous avons les trois items data flow, sémantique model et rapport. Nous avons dans le workspace aucune connexion. On n pas configuré d'ADLS Gen 2. On voit qu'il est dans le home region et on va essayer de le migrer tout simplement. On va juste lui changer de euh capacité euh ici et on voit que ça a marché sans problème. Donc là quand on va rafraîchir, on ouvre le rapport, tout fonctionne très bien. Le datafow, il a changé de région mais les données sont toujours stockées dans la home region. Sur cette deuxième démo, on voit notre workspace. Là, on va essayer de configurer un ADLS gen 2. Donc on vient ici, on va mettre la DLS Gen 2 pour sauvegarder et stocker nos données de datafow. Et vous allez voir qu'on a une erreur. On peut pas rajouter un stockage ADLS sur un workspace qui contient des datafow. Donc la solution c'est quoi ? On exporte la définition export Jon. Donc c'est un fichier qui qui a toute la définition de ce datafow. On est obligé de le supprimer pour qu'on fasse une migration de ce workspace sans datafow et rajouter ensuite le stockage. Donc là après migration, on peut voir qu'on peut rajouter la DLS sans problème parce qu'il n'y a pas de datafow et par conséquent on peut vraiment stocker les données dans le la DLS, dans le mode de stockage là où on veut. Si on veut passer en France centrale et ben on met la DLS en France centrale, on réimporte le Jason du Datafow et nos données se retrouve en France centrale. Dernier

Démo 6

41:32point sur euh les datafow, on parle du enhanced compute engine. C'est quoi en fait ? C'est juste le moteur de calcul amélioré de vos datafow. Il réduit fortement les temps de refraîches sur les entités calculées, jointure, filtres, les groupes bail et permet même le direct query sur les entités. C'est le mode un peu turbo du datafow d'où euh la moto supersonique qui est là. Ouais, mais il est utilisé uniquement si tu as un autre datafow qui réutilise le précédent sans quoi il est pas utilisé ton C'est effectivement et c'est le cas et c'est le cas justement qui pose un peu problème sur les migration cross region. Et donc il se règle dans les paramètres defow comme vous pouvez le voir ici à droite. Euh par défaut il est déjà à optimized. Donc optimized, c'est comme si il est activé, il est pas des donc problème il se situe où c'est que comme tu viens de le dire Romain, quand il y a deux datafow John 1 qui se chevauchent, si il y a ce paramètre de announced compute engine qui est on sur le parent datafow et ben post migration le refresh il va tomber en erreur. Et on va voir ça sur la démo juste ensuite. On peut voir ici sur le workspace, nous avons deux datafow. Donc on peut voir ici que nous avons une capacité qui est dans une fron centrale région F64. Et là nous avons nos deux datafow. Donc my DF Gen One c'est le datafow par an et l'autre c'est le data parent child datafow child. Et on peut voir bien sûr sur le lineage donc notre source les deux datafow qui se chauffent. Donc c'est vraiment le cas qui nous importe. C'est là où ça pose problème quand vous faites une migration cross region. Donc ce qu'on fait ici, c'est que euh on va voir le setting pour confirmer justement si euh si il est activé. On voit effectivement il est à on, il est activé. Faut savoir que même sur optimized s'il y a un enfant, il sera aussi à on soit-disant. Exactement. C'est ça. Même s'il est optimiz, donc ça soit on ou optimized, c'est pareil, il est activé. La seule fois où c'est pas activé, c'est quand il est vraiment euh désactivé. Donc là, ce qu'on fait, on change de région. Donc on est en train de faire la migration cross region et ça passe. Il y a pas de problème. Pour l'instant, tout fonctionne. Donc ce que je vais faire, c'est que je vais rafraîchir la page et je vais essayer de rafraîchir mes data flow. Donc là, je rafraîchis la page. La migration, elle est passée, mes item ils sont sur une autre région. Et là, je fais essayer de rafraîchir le datafow. Quand je rafraîchis le data flow euh contrairement à ce qui s'est passé avant, on va voir qu'on va avoir une erreur euh et on peut on peut l'avir ici. Donc quand on clique sur l'erreur, il va clairement nous dire que il y a eu l'erreur parce que il y a du datafow et on compute engine et c'est ce qui a bloqué. Donc là l'erreur, elle est sur ce fichier Excel. Je la télécharge pour vous la montrer encore une fois. euh ils doivent vraiment être chevauchés. Donc un datafow qui consomme un datafow. Et là vous voyez due across region migration, on peut pas faire le refresh des datafow. Comment les identifier ? Heureusement, nous avons encore notre fameuse bibliothèque euh euh linkab. Donc là, ce qu'on fait, c'est que euh on pourra pas vous passer aussi euh c'estes ce ce report, c'est que il va aller sur tous les workspace, euh il va avoir tous les datafow et donc il va détecter les datafow qui se chevachent, donc un datafow qui consomme d'un autre datafow qui est notre cas et il va aussi détecter euh les datafow qui ont un compute engine activé. Et donc là toujours on utilise le sémantique link laabs. Je vous ai dit que c'est un peu magique. Il y a toutes les fonctions que nous dont nous avons besoin pour manager et fabrique. Et là vous voyez que il m'a identifié mes deux mes deux mes deux datafow dans le workspace avec les items. Et donc là l'idée derrière c'est quoi ? C'est que après les avoir identifiés nous avons deux choses à faire. Et et c'est ce qui et c'est ce que je présente sur la slide suivante. Ce qu'on peut faire c'est que la la recommandation concrète c'est d'abord l'échelle du problème en cross region. Ça ne touche que les datafow avec Ece Computé et leur datafow en fond donc pas tout votre patrimoine. Donc les deux options c'est soit vous appliquez le contournement en préventif partout. Le contournement c'est quoi ? Vous les pas fait, vous les passez en disabled, vous faites la migration et vous les repassez en enled. Vous devez les faire partout. Possible d'automatiser ça, mais il y aura un certain risque. Il y a un effort considérable et surtout ce n'est pas obligatoire. Ce qu'il faut dire c'est que pour changer le ESE sur un data flow, c'est qu'il faut avoir des droits sur le workspace. Donc ça veut dire aussi donner euh à l'adminpaces dans lequels j'ai trouvé euh ces fameux datafow. Exactement. Et donc d'où il y a un certain effort à faire au niveau de euh du projet. Deuxème cas et là vous ne touchez rien. Euh et donc ce qu'il faut faire, c'est surtout prévenir les clients du risque et du plan de mitigation et surtout surveiller les refresh parce que sur les tests que nous avons fait, nous avons remarqué qu'il y a que le premier refresh qui tombe en erreur. L'erreur que je vous ai montré. Si je refais la même chose euh je lance le refresh de datafow une deuxième fois, ça va passer. Donc effectivement, peut-être vous allez faire cette migration, première journée, il y aura une erreur, le schedule du lendemain, il va passer. Donc, il y aura peut-être une latence sur le rafraîchissement de la donnée, d'où l'importance de prévenir le client, lui demander peut-être la première fois, il peut le passer manuellement ou attendre le deuxième refresh et donc le l'impact, il va être un peu minimisé grâce à ça. Donc deux approches, soit vous disable enable, soit vous faites la communication client. Mais vraiment, c'est les deux points que je voulais euh partager avec vous concernant la migration de ces datafow cross region. Super démo, merci Akram. On voit que la migration c'est vraiment un projet hein. Donc on vous a partagé ici quelques Rexes, quelques retours d'expérience parce que on l'a

Retours d'expériences

48:18vécu chez beaucoup de nos clients, c'est c'est migration cross région. Petite information he vous voyez ici des print screen de euh capacités qui ont migré. Ici, on migre toute la capacité, non pas seulement quelques workspace. Vous voyez l'ordre d'idée, hein, 9 secondes pour 70 workspace avec des vrais items dessus en production ou 3 minutes pour plus de 21000 workspace. Donc c'est plutôt rapide. Ça va dépendre de la complexité que vous avez, des différents items que vous avez. Il y en a d'autres où ça prendra un peu plus de temps parce qu'il y a des étapes en plus type backup, type configuration de certains items. Ce que je peux rajouter, c'est que dans le terrain, la majorité des migrations sont dans la même région. Donc il y a vraiment peu de cas qui font des cross region. Et sur les cross region, avec ce que nous avons présenté aujourd'hui, je pense on a fait le tour de tous les différents use case. Euh donc je pense si vous voulez attaquer une cross region très faible pourcentage de risque que vous avez de tomber sur une erreur qui est inconnue vu que nous avons fait beaucoup de tests avec beaucoup de clients, c'est ce qu'on a vu dans le terrain sur le terrain. Et aussi le maître mot, c'est vraiment de commencer et de planifier votre migration par VAC. Comme ça, vous pouvez catégoriser les espaces de travail qui rentrent dans le scénario 1 2 3 et vous dégrossissez petit à petit euh euh l'ensemble des éléments que vous devez migrer d'une région à une autre. Et et pardon et dans le pire des cas, même les datafow comme je vous l'ai dit avant, vous pouvez toujours faire le double run dans le sens où vous voulez pas faire la migration, vous redéployez directement dans un workspace cible capacité, vous confirmez, vous faites vos test, tout fonctionne bien et là vous allez enlever ce qu'il y avait déjà dans la partie source. C'est il y a plus de travail mais vous êtes plus sûr de le faire. Donc euh nous l'objectif c'est de vous présenter les différentes solutions qu'il y a et à vous de trancher selon votre contexte. Oui. Et pensez à l'observabilité. Euh c'est toujours bien d'avoir un monitoring déjà en place comme ça vous pouvez voir aussi l'impact euh qu'à cette migration. Vous avez maintenant

Conclusion

50:24une vision plus concrète de la migration cross région pour les capacités premium aux fabriques, hein. C'est les deux c'est pareil de ces enjeux et des principales étapes à anticiper. Une migration, on l'a vu, cross région ou cross tenant n'est pas un projet technique, c'est avant tout un projet de transformation. Il faut inventorer les dépendances, comprendre les besoins réglementaires, reconstruire certains éléments, réalimenter les données et accompagner les utilisateurs. Avant de migrer, posez-vous toujours cette question. Cherchons-nous réellement à déplacer le tenun tout simplement à résoudre un problème de résidence des données, de performance ou d'organisation. Dans tous les cas, la meilleure migration est celle qu'on a finalement pas besoin de faire, hein. Donc rappelez-vous aussi ça. Merci Manel, merci Akram. Super explication et démonstration. Si vous avez des questions vous souhaitez partager votre expérience, laissez-nous des commentaires. Et si cet épisode vous a été utile, pensez à vous abonner à Fardata. On vous dit à très bientôt. Ciao. Ciao. [musique] [musique]