Patrons et capacités fondamentales de Microsoft OneLake

Cet article présente les patrons OneLake courants et les capacités de plateforme que vous pouvez utiliser pour les implémenter. Utilisez les informations de cet article pour réfléchir à la manière dont vous souhaitez organiser votre environnement de données, puis choisissez les schémas qui correspondent à vos besoins métier, techniques et de gouvernance.

Chaque modèle décrit comment organiser les données et la propriété afin d’atteindre un objectif architectural spécifique. Pour mettre en œuvre un schéma, vous combinez une ou plusieurs capacités fondamentales d’OneLake : virtualisation des données, interopérabilité des données ouvertes, gouvernance centralisée, ainsi que l’intégration de l’analytique et de l’IA. Chaque fonctionnalité repose à son tour sur des fonctionnalités spécifiques du produit telles que les raccourcis, le miroir, la sécurité OneLake et le mode Direct Lake. Les mêmes capacités et caractéristiques apparaissent souvent dans plusieurs motifs.

Considérez ces cinq motifs comme des éléments de construction pour votre design OneLake. La plupart des environnements en combinent plusieurs. Choisissez les modèles qui correspondent à vos objectifs :

• Accès unifié aux données avec une réplication minimale - Utilisez OneLake pour exposer des données provenant de nombreux systèmes sources sans les copier.
• Architecture Medallion (bronze, argent, or) - Organiser les données pour qu’elles circulent à travers trois couches de qualité, de l’ingestion brute aux données certifiées prêtes à l’entreprise.
• Maillage de données orienté domaine sur une plateforme partagée - Permettre aux domaines métier de posséder et de publier leurs propres produits de données sur une seule base gouvernée.
• Consolidation de plateforme pour l’analytique et l’IA - Configurez les charges de travail analytiques, de data science et d’IA pour fonctionner sur une seule copie des données.
• Partage externe de données entre organisations - Donner aux partenaires et clients accès aux données OneLake sans exportations ni copies en double.

Accès unifié aux données avec une réplication minimale

Si vos données sont réparties sur plusieurs clouds, systèmes locaux ou lacs externes, tout reproduire en un seul endroit peut ne pas être pratique – voire possible. L’accès unifié aux données avec un schéma de réplication minimal considère OneLake comme une couche logique unique à travers ces sources. Au lieu de créer des pipelines d’ingestion pour chaque source, vous utilisez des raccourcis pour référencer les données sur place et recourez à la mise en miroir lorsque vous avez besoin d’une copie synchronisée et optimisée pour les requêtes.

Utilisez ce modèle dans les situations suivantes :

• Vos données sont réparties sur plusieurs clouds, systèmes locaux ou lacs externes.
• La réplication des données dans un stockage central créerait un stockage excessif, une latence ou une surcharge de conformité.
• Vous devez intégrer rapidement de nouvelles sources sans créer des pipelines complets d’extraction, transformation, charge (ETL).
• Vous souhaitez préserver les investissements dans les lacs de données, les entrepôts de données et les bases de données opérationnelles existants.

Appliquer un accès unifié aux données

Pour mettre ce schéma en pratique, commencez par deux approches principales d’accès aux données qui ne nécessitent pas de construire ou d’exploiter des processus de transfert de données : la virtualisation rend les données sources accessibles via OneLake sans les copier, et le mirroring zéro-ETL apporte une copie synchronisée gérée par la plateforme dans OneLake sous forme de tables Delta prêtes pour l’analytique. N'utilisez les outils de transfert de données Fabric que lorsque ces approches ne prennent pas en charge la source ou ne répondent pas à vos besoins. Pour des conseils supplémentaires sur le choix et la combinaison de ces approches, voir Unification des données avec des raccourcis OneLake et du miroir.

1. Inventez vos sources de données pour déterminer lesquelles OneLake peut accéder via virtualisation ou miroir zéro-ETL : stockage d’objets cloud, catalogues externes, bases de données opérationnelles et Dataverse. Signalez les sources restantes comme nécessitant une approche de transfert de données.

2. Choisissez la bonne technique d’accès aux données pour chaque source prise en charge. Privilégiez la virtualisation lorsque le code source supporte un accès sans copie. Utilisez la mise en miroir zéro ETL lorsque la source nécessite une copie synchronisée optimisée pour les requêtes :

1. Transformez les données sources lorsque c’est nécessaire. Les transformations de raccourcis peuvent traiter les fichiers pris en charge exposés via un raccourci, qu’ils soient stockés en externe ou déjà dans OneLake. Utilisez des transformations de fichiers raccourcis pour convertir des fichiers structurés en tables Delta ou des transformations IA raccourcis pour traiter du texte non structuré. Les transformations de raccourci créent une sortie Delta transformée et la synchronisent avec les données référencées par le raccourci.

2. Utilisez les outils de déplacement de données Fabric lorsque la virtualisation et le miroir ne prennent pas en charge une source ou lorsque vous avez besoin de transformations complexes, d'orchestration, d'une cadence de mouvement programmée ou d'une ingestion de streaming. Pour obtenir de l’aide dans le choix entre pipelines, dataflows, jobs de copie et eventstreams, voir Choisir une stratégie de déplacement de données.

Si vous optez pour un déplacement de données, stockez les données copiées dans un format de table ouvert, tel que Delta Parquet ou Iceberg. La mise en miroir et les transformations des raccourcis créent déjà une sortie au format Delta. L’utilisation de formats ouverts permet de rendre lisibles les données virtualisées, les copies synchronisées et la sortie transformée Delta par les moteurs Fabric et les plateformes externes.

1. Notez la raison chaque fois que vous créez une copie synchronisée, une sortie Delta transformée ou une copie via les outils de déplacement de données Fabric. Ce dossier permet de faire auditable la décision. Créez une copie uniquement lorsqu’une source a besoin d’une mise en page physique, optimisée pour les requêtes, ou ne peut pas répondre virtuellement à vos exigences de fraîcheur, de coûts de transformation, de conformité ou de traitement.

2. Appliquez la sécurité OneLake aux données mises à disposition via OneLake afin que les mêmes politiques couvrent les données virtualisées, les copies synchronisées et la sortie Delta transformée.

3. Approuvez et décrivez les données résultantes du catalogue OneLake afin que les consommateurs puissent les trouver et les faire confiance.

Capacités d’accès unifiées aux données

• Virtualisation des données et miroirement zéro-ETL - Exposer les données qui vivent dans d’autres systèmes et clouds via des références sans copie ou des copies synchronisées prêtes à l’analyse. Fonctionnalités:
  • Les raccourcis permettent d’accéder aux données source dans OneLake sans les copier.
  • Le miroir des métadonnées synchronise les métadonnées du catalogue externe et accède aux données sources via des raccourcis.
  • Les transformations de fichiers raccourcis et les transformations IA raccourcis convertissent les données sources en sorties Delta synchronisées.
• Gouvernance centralisée - Appliquer une sécurité et une découverte cohérentes aux sources virtualisées, tout comme vous le feriez pour les données natives OneLake. Fonctionnalités:
  • La sécurité de OneLake et le modèle de contrôle d’accès aux données appliquent des politiques d’accès cohérentes aux données de OneLake.
  • Le catalogue OneLake prend en charge la découverte et l’approbation.
• Interopérabilité des données ouvertes - Gardez les données virtualisées et les copies gérées par la plateforme lisibles à la fois par les moteurs Fabric et les plateformes externes. Fonctionnalités:
  • Les tables d’iceberg dans OneLake rendent les données des icebergs accessibles à Fabric et aux moteurs externes.
  • Delta Parquet est un format de table ouverte pour stocker des données prêtes à l’analyse.
  • L’accès et les API OneLake permettent aux applications et outils externes d’accéder aux données OneLake.

Architecture en médaillon (bronze, argent, or)

Rendre les données disponibles dans OneLake n’est que la première étape. Les données brutes provenant des systèmes sources ne sont généralement pas sûres à utiliser directement pour l’analytique ou l’IA. Il contient souvent des doublons, des erreurs, des formats incohérents ou des champs sensibles. Lorsque plusieurs équipes s’appuient sur la même source de données, elles ont besoin d’une définition partagée de ce pour quoi chaque étape des données est fiable.

Le modèle d’architecture en médaillon organise les données de OneLake en trois couches de qualité : bronze pour les données sources brutes et immuables ; argent pour les données nettoyées et harmonisées ; et or pour les tables certifiées prêtes à l’usage métier et les modèles sémantiques. Chaque couche est une étape définie sur laquelle les consommateurs en aval peuvent compter. Les tables Silver et Gold sont réutilisables pour les charges de travail BI, d’analytique et d’IA, afin que les équipes n’aient pas à reconstruire la même logique de nettoyage ou de modélisation dans des outils distincts.

Utilisez ce modèle dans les situations suivantes :

• Plusieurs équipes s’appuient sur les mêmes données sources et ont besoin d’une qualité constante.
• Il faut une lignée traçable, des entrées brutes aux sorties certifiées.
• Il faut un contrat clair entre l’ingénierie des données et les consommateurs d’analytique ou d’IA.

Pour plus d’informations sur ce modèle, consultez Comprendre l’architecture médaillon dans Fabric avec OneLake. Cet article traite de la conception des couches, des modèles de déploiement, des formats de stockage, des vues matérialisées sur les lacs et de l’optimisation des tables Delta.

Comment l’appliquer

Un médaillon fonctionnel repose sur une idée : chaque couche est un contrat avec les consommateurs en aval, et les données ne passent à la couche suivante qu’après avoir respecté les standards de qualité de cette couche.

1. Identifiez vos sources brutes et les consommateurs qui dépendent des données certifiées.

2. Définissez ce qui appartient à chaque couche, et appliquez ces définitions de manière cohérente à travers les domaines :

   Couche	Contenu	Consommateurs typiques
   Bronze	Données brutes et immuables capturées directement à partir de sources sans application de schéma	Ingénieurs de données (accès limité)
   Argent	Purifié, dédupliqué et conforme aux définitions commerciales partagées	Ingénieurs de données et analystes formés
   Or	Tables et modèles sémantiques sélectionnés, prêts pour les affaires	Tous les consommateurs de BI, d’analytique et d’IA

3. Créez chaque couche avec la charge de travail Fabric appropriée – généralement Data Engineering (Spark) ou Data Factory pour les couches bronze et silver, et Data Warehouse ou les modèles sémantiques Power BI pour la couche gold. Préservez la fidélité à la source en bronze en utilisant le format d’origine, un raccourci vers les données source, Parquet ou Delta, selon le cas. Utilisez des tables Delta pour l’argent et l’or afin que les charges de travail Fabric puissent lire et écrire de manière fiable les données raffinées.

4. Appliquez des politiques d’accès sensibles aux couches. Utilisez la sécurité OneLake pour les éléments pris en charge ainsi que les permissions Fabric et SQL applicables pour les entrepôts. Restreignez l’accès au bronze, rendez l’argent disponible pour les analystes et accordez l’accès à l’or en fonction des besoins des consommateurs et des critères de moindre privilège.

5. Utilisez des sorties or sélectionnées pour l’analyse en aval. Construisez des modèles sémantiques de couche or en mode Direct Lake afin que Power BI puisse lire les données OneLake sans créer une copie importée ni nécessiter de rafraîchissements programmés.

6. Confirmez que chaque production d’or a une lignée traçable via l’argent jusqu’à ses sources de bronze. Ensuite, approuvez les tables de couche d’or et les modèles sémantiques tels que certifiés dans le catalogue OneLake. Cette validation aide les consommateurs à identifier quelles données sont prêtes à être utilisées en production.

7. Réutilisez des modèles sémantiques en or pour lancer les ontologies Fabric IQ. Cette étape offre aux agents d’IA un contexte d’entreprise gouverné par des données certifiées.

Fonctions de base

• L’analyse intégrée et l’IA – les couches Bronze, Argent et Or alimentent toutes les charges d’analyse et d’IA sur OneLake sans copies spécifiques au moteur. Fonctionnalités:
  • L’architecture des maisons lacustres Medallion à OneLake fournit des conseils de conception pour les trois niveaux.
  • Le mode Direct Lake permet aux modèles sémantiques Power BI de lire directement les données de couche or depuis OneLake.
  • Les charges de travail Fabric telles que l’ingénierie des données et le Data Warehouse produisent et affinent les couches.
• Gouvernance centralisée - Appliquer différentes politiques d’accès et portes de qualité à chaque couche afin que les consommateurs ne voient que les données adaptées à leur rôle. Fonctionnalités:
  • La sécurité OneLake applique des politiques d’accès tenant compte des couches.
  • Le catalogue OneLake prend en charge la découverte et la certification en fonction des couches.
  • Microsoft Purview applique des étiquettes de sensibilité et un audit.
• Interopérabilité des données ouvertes - Stockez les couches dans des formats ouverts afin que les moteurs externes puissent les lire en même temps que Fabric. Fonctionnalités:
  • Delta Parquet est un format de table ouverte pour stocker des données de couches raffinées.
  • Les tables Iceberg dans OneLake mettent les données des couches à la disposition des moteurs compatibles avec Iceberg.
  • L’accès OneLake et les API permettent aux applications et outils externes d’accéder aux données de couche.

Maillage de données orienté domaine sur une plateforme partagée

Si plusieurs équipes métier produisent et consomment des données, faire passer chaque requête par une seule équipe centrale de données peut ralentir la livraison. Les équipes métier comprennent souvent mieux leurs propres données et exigences, mais décentraliser la propriété sans gouvernance partagée peut entraîner une sécurité, une qualité et une lignée incohérentes.

Le modèle maillage de données orienté domaine donne à chaque domaine métier la propriété de ses propres produits de données, tandis que tous les domaines suivent des standards partagés sur une base OneLake. Chaque domaine publie ses propres produits de données, et d’autres domaines y accèdent via des raccourcis et les consomment grâce à des analyses Fabric et des charges de travail d’IA. Les politiques centralisées d’identité, de sécurité et de gouvernance s’appliquent uniformément dans tous les domaines.

Utilisez ce modèle dans les situations suivantes :

• Une seule équipe centrale de données devient un goulot d’étranglement pour la livraison.
• Différents domaines métier ont des données, des exigences et des cadences de publication distinctes.
• Il faut une responsabilité claire de la qualité des données au niveau du domaine sans renoncer à la gouvernance à l’échelle de l’entreprise.

Appliquer un maillage de données orienté domaine

Trouvez le bon équilibre entre décentralisation et cohérence. Transférer la propriété au domaine qui connaît le mieux les données, et garder l’identité, la sécurité et la lignée centralisées afin que chaque produit de données respecte les mêmes standards.

1. Identifiez vos domaines d’activité. Chaque domaine doit représenter une zone cohérente de l’entreprise, avec une équipe capable de posséder et d’exploiter ses produits de données de bout en bout.

2. Créez un domaine pour chaque zone d’activité et attribuez-lui des espaces de travail. Mettez en place un domaine central séparé pour l’infrastructure partagée et les données d’entreprise réutilisables.

3. Définir des normes de produits de données que chaque domaine doit respecter – par exemple, les exigences d’approbation ou de certification, les schémas documentés, les métadonnées de propriété, le versionnement et les accords de niveau de service (SLA). Ces normes font de chaque produit un contrat réutilisable et découvrable, plutôt qu’un simple dossier d’espace de travail.

4. Utilisez la sécurité OneLake pour appliquer des contrôles d’accès aux données basés sur des rôles au niveau des dossiers, des tables, des lignes et des colonnes, afin que les producteurs puissent publier des produits de données sans exposer tout ce qui se trouve dans leur espace de travail.

5. Appliquez la gouvernance à l’échelle du locataire avec le catalogue OneLake pour la découverte et la lignée inter-domaines, ainsi que Microsoft Purview pour les labels de sensibilité et l’audit. Étendre le même modèle d’identité et de politique aux agents IA qui consomment des produits de données de domaine, afin que l’accès aux agents soit régi comme pour tout autre consommateur.

6. Faites en sorte que les domaines consommateurs utilisent des raccourcis pour référencer les produits de données producteurs plutôt que de les copier. Les consommateurs peuvent alors utiliser les produits de données référencés dans la charge de travail Fabric qui correspondent à leurs besoins. Pour les modèles sémantiques Power BI, utilisez le mode Direct Lake pour lire directement les données de OneLake. Utilisez Fabric Data Agents ou Fabric IQ pour créer des expériences d’IA fondées sur des produits de données à domaine régi.

7. Si des domaines publient sur des catalogues hors Fabric, prévoyez une synchronisation du contrôle d’accès afin que les permissions restent cohérentes entre OneLake et le catalogue externe.

   Tip

   L’accélérateur open source de Microsoft Policy Weaver peut automatiser cette synchronisation pour Azure Databricks (Unity Catalog), Snowflake et Dataverse sources. Il répercute les stratégies d’accès aux données dans les rôles de sécurité OneLake, en complément de la mise en miroir (qui déplace les données, mais pas les autorisations).

Capacités de maillage de données

• Gouvernance centralisée - Décentralisez la propriété des domaines tout en maintenant l’identité, la sécurité et la lignée centralisées. Fonctionnalités:
  • Les domaines regroupent les espaces de travail par zone d’activité.
  • La sécurité OneLake offre des contrôles d’accès basés sur les rôles aux dossiers, aux tables, aux lignes et aux colonnes.
  • Le catalogue OneLake permet la découverte et la lignée inter-domaines.
  • Microsoft Purview applique des étiquettes de sensibilité et un audit.
• Virtualisation des données - Laissez les domaines consommateurs utiliser des produits de données appartenant aux producteurs via des références plutôt que par des copies. Fonctionnalités:
  • Les raccourcis permettent le partage sans copie entre les domaines.
• Analyse intégrée et IA - Rendre les produits de données de chaque domaine consommables sur les charges de travail Fabric. Fonctionnalités:
  • Le mode Direct Lake permet aux modèles sémantiques Power BI de lire directement les produits de données de domaine depuis OneLake.
  • Les charges de travail Fabric telles que l’ingénierie des données, l’entrepôt de données, l’intelligence en temps réel et la science des données traitent et analysent les produits de données du domaine.
  • Fabric Data Agents et Fabric IQ supportent des expériences d’IA ancrées dans des produits de données de domaine.

Consolidation de plateformes pour l’analytique et l’IA

Si vous faites fonctionner plusieurs plateformes d’analyse côte à côte – des outils distincts pour l’entrepôt de données, l’intelligence économique, la data science, l’analyse en temps réel et l’IA – chaque outil est accompagné de ses propres copies de données, pipelines et modèle de gouvernance. Cette fragmentation augmente les coûts et rend difficile l’application d’une sécurité cohérente ou l’obtention d’une réponse unique à une question métier.

Le modèle de consolidation de plateforme transfère ces charges de travail sur Fabric, où OneLake fournit une base de données partagée et gouvernée. Les charges de travail Fabric accèdent, transforment, synchronisent ou analysent les données via cette base, au lieu de s’appuyer sur des modèles de données et de gouvernance distincts pour chaque outil.

Utilisez ce modèle dans les situations suivantes :

• Vous utilisez plusieurs plateformes d’analyse avec des capacités qui se chevauchent.
• Les copies de données spécifiques au moteur et les pipelines entraînent des coûts et des charges de maintenance.
• Il faut un modèle unique de gouvernance et de sécurité pour toutes les charges de travail analytiques et d’IA.

Appliquer la consolidation de plateformes

Visez moins de plateformes, pas plus d’intégrations. Consolidez les charges de travail dans Fabric au lieu de créer des ponts entre les outils, et ne créez des ponts avec des moteurs externes que lorsque vous ne pouvez pas encore les retirer.

1. Inventez les outils et pipelines d’analytique, d’entrepôt de données, de data science, d’intelligence économique (BI) et d’IA que vous utilisez aujourd’hui. Notez les charges de travail que chaque outil propose et quelles données il copie.

2. Associez chaque charge de travail existante à la charge de travail Fabric qui peut la remplacer :

   Charge de travail héritée	Charge de travail Fabric
   Orchestration de données et ETL	Usine de données
   Notebooks Spark et traitement dans un lakehouse	Ingénierie des données
   Entreposage de données SQL	Entrepôt de données
   Streaming et analyses KQL	Real-Time Intelligence
   Entraînement de modèles ML et suivi des expériences	Science des données
   Bases de données opérationnelles	Bases de données (base de données SQL dans Fabric et Cosmos DB dans Fabric)
   Visualisation BI et modèles sémantiques	Power BI avec mode Direct Lake
   IA conversationnelle fondée sur des données d’entreprise	Fabric Data Agents, Copilot pour Fabric, Fabric IQ

3. Établissez un modèle de gouvernance et de sécurité unique pour toutes les charges de travail en utilisant la sécurité OneLake, Microsoft Purview et le catalogue OneLake. Configurez les clés gérées par le client lorsque les éléments Fabric pris en charge nécessitent une couche supplémentaire de chiffrement.

4. Consolidez les données analytiques dans OneLake en utilisant le format Delta ou Iceberg afin que les charges de travail puissent partager une base de données gouvernée. Incluez les charges de travail opérationnelles en les consolidant dans des bases de données Fabric, qui rendent les données analytiques synchronisées disponibles dans OneLake.

5. Appuyez l’IA sur des données consolidées. Construisez des ontologies (aperçu) sur votre couche de données sélectionnée et exposez-les aux agents via le serveur Ontology MCP, afin que les agents de données Fabric, Microsoft 365 Copilot et les outils externes raisonnent dans le même contexte gouverné. Vous pouvez générer des définitions d’ontologie à partir de modèles sémantiques Power BI en mode Import, Direct Lake ou DirectQuery. Utilisez le mode Direct Lake lorsque vous avez besoin de liaisons générées vers des données OneLake prises en charge, et examinez les limitations actuelles de l’ontologie.

6. Pour les moteurs externes que vous ne pouvez pas encore retirer, exposez les données OneLake via l'intégration Azure Databricks, l'interopérabilité Iceberg avec Snowflake, ou l'accès et les API OneLake.

7. Retirez les outils, copies de données et pipelines remplacés après avoir validé l’équivalent Fabric. Ainsi, la consolidation élimine les coûts, les licences et les transferts au lieu d’ajouter une autre plateforme à la pile.

Capacités de consolidation de plateformes

• Analytique intégrée et IA - Réunir les charges de travail en analytique, en data science et en IA sur une base OneLake partagée. Fonctionnalités:
  • Les charges de travail Fabric telles que Data Factory, Data Engineering, Data Warehouse, Real-Time Intelligence, Data Science, Databases et Power BI accèdent aux données, les transforment, les synchronisent ou les analysent grâce à la base partagée.
  • Le mode Direct Lake permet aux modèles sémantiques Power BI de lire directement les données OneLake.
  • Fabric Data Agents, Copilot for Fabric et Fabric IQ supportent des expériences d’IA fondées sur les données OneLake.
  • Les ontologies et le serveur MCP d’Ontologie fournissent un contexte métier régi aux agents d’IA.
  • OneLake, en tant que source de connaissances pour Microsoft Foundry, permet à Foundry d’indexer les fichiers OneLake pour l’utilisation par des agents IA.
• Interopérabilité des données ouvertes - Laissez les plateformes externes que vous ne mettez pas à la retraite continuer à lire les mêmes données. Fonctionnalités:
  • Les tables Iceberg dans OneLake et Delta Parquet conservent les données dans des formats de table ouverts.
  • L’accès et les API OneLake permettent aux applications et outils externes d’accéder aux données OneLake.
  • L’intégration Azure Databricks et l’interopérabilité Iceberg avec Snowflake permettent aux plateformes d’analyse externes de lire les données OneLake.
• Gouvernance centralisée - Remplacez les modèles de sécurité par outil par un modèle de gouvernance et d’audit couvrant toutes les charges de travail. Fonctionnalités:
  • La gouvernance Fabric offre un cadre de gouvernance commun à travers les charges de travail Fabric.
  • La sécurité OneLake applique des contrôles d’accès aux données cohérents.
  • Le catalogue OneLake permet la découverte et le lignage dans l’ensemble des charges de travail.
  • L’intégration Microsoft Purview applique des étiquettes de sensibilité et un audit.
  • Les clés gérées par le client ajoutent une couche supplémentaire de chiffrement aux éléments Fabric pris en charge.

Partage externe de données entre organisations

Si vous échangez des données avec des partenaires, fournisseurs, clients ou d’autres divisions de manière continue, les exportations par lots, les transferts de fichiers et les systèmes en aval dupliqués ajoutent des lacunes de latence, de coût et de gouvernance. Le mode de partage externe des données donne aux consommateurs extérieurs à votre organisation ou division commerciale un accès direct aux données OneLake sélectionnées sans exportations récurrentes. Les consommateurs peuvent accéder aux données via le partage interlocataire Fabric ou depuis des plateformes d’analyse externes telles que Snowflake et Azure Databricks en utilisant les capacités d’interopérabilité OneLake.

Les consommateurs voient les mises à jour au fur et à mesure que vous les publiez. Vous contrôlez l’accès aux données sources via le mécanisme de partage ou d’interopérabilité qui soutient la plateforme du consommateur.

Utilisez ce modèle dans les situations suivantes :

• Vous échangez des données avec des organisations externes de manière continue.
• Les exportations par lots ou les transferts de fichiers ajoutent de la latence, de la complexité ou des lacunes de gouvernance.
• Vous devez suivre et révoquer l’accès externe de manière centralisée.

Appliquer le partage externe des données

Le partage externe fonctionne mieux lorsque vous utilisez la virtualisation plutôt que l’exportation de données. Associez la méthode d’accès à ce que chaque consommateur peut lire, et appliquez les contrôles d’accès supportés par ce mécanisme de partage ou d’interopérabilité.

1. Identifiez les produits de données que vous souhaitez partager à l’extérieur ainsi que les consommateurs qui en ont besoin (partenaires, fournisseurs, clients). En général, vous partagez des tables et des fichiers soigneusement sélectionnés, bien définis et documentés.

2. Choisissez la bonne approche de partage pour chaque consommateur :

   Type de consommateur	Approche recommandée
   Utilisateurs de Fabric dans un autre locataire	Partage externe de données pour un accès interlocataire virtualisé en lecture seule
   utilisateurs de Snowflake sur Azure	Interopérabilité Iceberg avec Snowflake pour lire les tables Fabric exposées au format Iceberg
   Utilisateurs d’Azure Databricks	Fédération du catalogue OneLake dans Azure Databricks pour interroger les tables OneLake via Unity Catalog sans copier de données
   Applications ou outils prenant en charge les API ADLS Gen2 ou Blob	Accès OneLake et API pour accéder aux données OneLake via des API prises en charge

   Pour intégrer les données Dataverse dans OneLake avant de les partager, utilisez le modèle d’accès unifié aux données.

3. Limiter l’accès externe aux autorisations prises en charge par le mécanisme de partage sélectionné. Pour le partage externe de données Fabric, ce partage accorde un accès en lecture seule à tout utilisateur du locataire d’origine de l’utilisateur invité. Les politiques de sécurité et de gouvernance côté fournisseur, y compris la sécurité OneLake, les étiquettes de sensibilité et les politiques de prévention des pertes de données, ne sont pas appliquées dans le tenant du consommateur. Le consommateur doit régir l’accès en aval dans son environnement.

4. Mettez d’accord dès le départ sur les termes de chaque relation de partage : ce qui est partagé, avec qui, et pour combien de temps. Pour le partage de données externes Fabric, révoquez l’accès depuis l’onglet Partages de données externes sur la page Gérer les permissions. Pour d’autres approches, révoquez l’accès via le mécanisme de partage sélectionné. Confirmez que le consommateur perd sa visibilité.

5. Appliquez les labels de sensibilité, l'audit et la prévention des pertes de données avec Microsoft Purview dans l'environnement Fabric du fournisseur.

6. Approuvez et documentez les produits de données sources dans le catalogue OneLake afin que les fournisseurs puissent les trouver et les gérer avant de les partager. Le catalogue OneLake ne publie pas de produits de données sur des locataires externes ni sur des plateformes d’analyse.

Capacités externes de partage de données

• Virtualisation des données - Partagez les données via des références sans copie sans gérer les pipelines d’exportation. Fonctionnalités:
  • Le partage externe de données permet un partage virtualisé entre locataires Fabric.
  • Les raccourcis permettent aux partenaires de consommer des données publiées sans les copier.
• Interopérabilité des données ouvertes - Partager avec les consommateurs qui n'utilisent pas Fabric en publiant dans des formats ouverts. Fonctionnalités:
  • Les tables Iceberg dans OneLake permettent de publier des données partagées dans un format de table ouvert.
  • L’interopérabilité Iceberg avec Snowflake permet aux consommateurs de Snowflake de lire les données partagées de OneLake.
  • La fédération du catalogue OneLake dans Azure Databricks permet aux consommateurs d’Azure Databricks de consulter les tables OneLake via Unity Catalog sans copier les données.
  • L’accès OneLake et les API permettent aux applications et outils compatibles d’accéder aux données OneLake.
• Gouvernance centralisée - Gouverner les données sources dans Fabric et contrôler l’accès externe via chaque mécanisme de partage. Fonctionnalités:
  • La sécurité OneLake définit la portée de l’accès aux données sources dans Fabric.
  • Microsoft Purview applique des étiquettes de sensibilité, un audit et la prévention de la perte de données dans l'environnement Fabric du fournisseur.
  • Le catalogue OneLake permet la découverte et l’approbation par le fournisseur avant le partage.