Microsoft OneLake-Muster und grundlegende Fähigkeiten

Dieser Artikel stellt gängige OneLake-Muster vor und die Plattformfunktionen, mit denen Sie sie implementieren können. Nutzen Sie die Informationen in diesem Artikel, um zu überlegen, wie Sie Ihre Datenumgebung organisieren möchten, und wählen Sie dann die Muster aus, die zu Ihren geschäftlichen, technischen und Governance-Anforderungen passen.

Jedes Muster beschreibt, wie Daten und Eigentumsrechte organisiert werden, um ein bestimmtes architektonisches Ziel zu erreichen. Um ein Muster umzusetzen, kombiniert man eine oder mehrere grundlegende OneLake-Fähigkeiten – Datenvirtualisierung, Open-Data-Interoperabilität, zentralisierte Governance sowie integrierte Analytik und KI. Jede Funktion basiert wiederum auf spezifischen Produktfunktionen wie Verknüpfungen, Spiegelung, OneLake-Sicherheit und Direct Lake-Modus. Die gleiche Fähigkeit und das gleiche Merkmal erscheinen oft in mehr als einem Muster.

Note

Dieser Artikel basiert auf Mustern, die im OneLake-Whitepaper für architektonische Leitlinien identifiziert wurden.

Betrachten Sie diese fünf Muster als Bausteine für Ihr OneLake-Design. Die meisten Umgebungen kombinieren mehr als eine. Wählen Sie die Muster, die zu Ihren Zielen passen:

Vereinheitlichter Datenzugriff mit minimaler Replikation

Wenn Ihre Daten über mehrere Clouds, lokale Systeme oder externe Seen verteilt sind, ist es möglicherweise nicht praktikabel – oder gar möglich, alles an einen Ort zu kopieren. Das einheitliche Datenzugriffsmuster mit minimaler Replikation behandelt OneLake als eine einzige logische Datenschicht über diese Quellen hinweg. Anstatt für jede Quelle Eingabepipelines zu bauen, nutzt du Shortcuts, um Daten vor Ort zu referenzieren und zu spiegeln, wenn du eine synchronisierte, abfragenoptimierte Kopie brauchst.

Verwenden Sie dieses Muster in folgenden Fällen:

  • Ihre Daten sind über mehrere Clouds, lokale Systeme oder externe Seen verteilt.
  • Die Replikation von Daten in einen zentralen Speicher würde zu übermäßigem Speicher, Latenz oder Compliance-Overhead führen.
  • Du musst neue Quellen schnell einschiffen, ohne vollständige Extract, Transform, Load (ETL)-Pipelines zu erstellen.
  • Man möchte Investitionen in bestehende Data Lakes, Lagerhäuser und operative Speicher erhalten.

Anwendung einheitlicher Datenzugriff

Um dieses Muster in die Praxis umzusetzen, beginnen Sie mit zwei primären Datenzugriffsansätzen, bei denen Sie keine Datenbewegungsprozesse erstellen oder betreiben müssen: Virtualisierung macht Quelldaten über OneLake verfügbar, ohne sie zu kopieren, und Zero-ETL-Mirroring bringt eine plattformverwaltete, synchronisierte Kopie als analytikbereite Delta-Tabellen in OneLake. Verwenden Sie Fabric-Datenbewegungstools nur, wenn diese Ansätze die Quelle nicht unterstützen oder Ihre Anforderungen nicht erfüllen. Weitere Hinweise zur Auswahl und Kombination dieser Ansätze finden Sie unter Unify Data with OneLake Shortcuts and Mirroring.

  1. Inventarisieren Sie Ihre Datenquellen, um herauszufinden, auf welche OneLake durch Virtualisierung oder Zero-ETL-Mirroring zugriffen kann: Cloud-Objektspeicherung, externe Kataloge, Betriebsdatenbanken und Dataverse. Markiere alle verbleibenden Quellen als notwendig für Datenübertragung.

  2. Wählen Sie für jede unterstützte Quelle die richtige Datenzugriffstechnik. Bevorzuge Virtualisierung, wenn der Quellcode keinen Kopierzugriff unterstützt. Verwenden Sie Zero-ETL-Spiegelung, wenn die Quelle eine synchronisierte, abfragenoptimierte Kopie benötigt:

Ursprungsdaten Wie man darauf zugeht Datenhandhabung
Cloud-Objektspeicher (Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage) und S3-kompatibler On-Premises-Speicher Abkürzungen Virtualisierung: Macht Quelldaten verfügbar, ohne sie zu kopieren
Daten, die in einem externen Katalog verwaltet werden, den Sie ohne Kopieren bereitstellen möchten (zum Beispiel Azure Databricks Unity Catalog) Metadatenspiegelung – synchronisiert nur Katalogmetadaten (Schemata, Tabellen) und greift über Verknüpfungen auf die Quelldaten zu. Virtualisierung: Macht Quelldaten verfügbar, ohne sie zu kopieren
Operationelle Datenbanken, die eine query-optimierte Kopie benötigen (Azure SQL-Datenbank, Azure Cosmos DB, Snowflake, PostgreSQL, SQL Server 2025, Oracle Database, Google BigQuery) Datenbankspiegelung oder offenes Spiegeln für unterstützte benutzerdefinierte und Partnerlösungen Zero-ETL Spiegelung: Erzeugt eine synchronisierte Delta-Kopie
Dataverse (Dynamics 365 und Power Platform Daten) Verknüpfungen oder Link zum Microsoft Fabric für Null-Kopierzugriff Virtualisierung: Macht Quelldaten verfügbar, ohne sie zu kopieren

  1. Transformieren Sie Quelldaten bei Bedarf. Shortcut-Transformationen können unterstützte Dateien verarbeiten, die über eine Verknüpfung freigelegt werden, egal ob die Dateien extern gespeichert sind oder bereits in OneLake abgelegt sind. Verwenden Sie Verknüpfungsdatei-Transformationen , um strukturierte Dateien in Delta-Tabellen umzuwandeln, oder KI-Transformationen , um unstrukturierten Text zu verarbeiten. Shortcut-Transformationen erzeugen transformierte Delta-Ausgabe und halten sie mit den vom Shortcut referenzierten Daten synchronisiert.

  2. Verwenden Sie Fabric-Datenbewegungstools, wenn Virtualisierung und Spiegelung keine Quellcode unterstützen oder wenn Sie komplexe Transformationen, Orchestrierung, einen geplanten Bewegungsrhythmus oder Streaming-Aufnahme benötigen. Für Hilfe bei der Auswahl zwischen Pipelines, Datenströmen, Copyjobs und Eventstreams siehe Choose a Data Movement strategy.

Wenn du Datenbewegung wählst, landkopiere Daten in einem offenen Tabellenformat, wie Delta Parquet oder Iceberg. Spiegelung und Shortcut-Transformationen erzeugen bereits Delta-Ausgabe. Die Verwendung offener Formate hält virtualisierte Daten, synchronisierte Kopien und transformierte Delta-Ausgaben von Fabric-Engines und externen Plattformen lesbar.

  1. Notieren Sie den Grund, wann immer Sie eine synchronisierte Kopie, eine transformierte Delta-Ausgabe oder eine Kopie über Fabric-Datenbewegungstools erstellen. Diese Aufzeichnung macht die Entscheidung prüfbar. Erstellen Sie eine Kopie nur, wenn eine Quelle ein physisches, abfragenoptimiertes Layout benötigt oder Ihre Anforderungen an Aktualität, Transformationskosten, Compliance oder Verarbeitung nicht virtuell erfüllen kann.

  2. Wenden Sie OneLake-Sicherheit auf die über OneLake bereitgestellten Daten an, sodass dieselben Richtlinien virtualisierte Daten, synchronisierte Kopien und transformierte Delta-Ausgaben abdecken.

  3. Empfehlen und beschreiben Sie die resultierenden Datenelemente im OneLake-Katalog , damit Verbraucher sie finden und vertrauen können.

Vereinheitlichte Datenzugriffsfunktionen

  • Datenvirtualisierung und Zero-ETL-Mirroring – Bereitstellen Sie Daten, die in anderen Systemen und Clouds leben, durch No-Copy-Referenzen oder synchronisierte, analysefähige Kopien bereit. Funktionen:
  • Zentrale Governance – Wenden Sie konsistente Sicherheit und Entdeckung auf virtualisierte Quellen an, genauso wie Sie es auf native OneLake-Daten tun würden. Funktionen:
  • Offene Dateninteroperabilität – Halte virtualisierte Daten und plattformverwaltete Kopien sowohl von Fabric-Engines als auch von externen Plattformen lesbar. Funktionen:

Medaillonarchitektur (Bronze, Silber, Gold)

Die Bereitstellung von Daten in OneLake ist nur der erste Schritt. Rohdaten aus Quellsystemen sind in der Regel nicht sicher, direkt für Analysen oder KI zu verwenden. Sie enthält oft Duplikate, Fehler, inkonsistente Formate oder sensible Felder. Wenn mehrere Teams auf denselben Quelldaten aufbauen, benötigen sie eine gemeinsame Definition dessen, wofür jede Datenstufe vertraut wird.

Das Medaillon-Architekturmuster ordnet die Daten in OneLake in drei Qualitätsschichten: Bronze für rohe, unveränderliche Quelldaten; Silber für gereinigte und konformierte Daten; und Gold für zertifizierte, geschäftsfähige Tabellen und semantische Modelle. Jede Schicht ist eine definierte Stufe, auf die sich nachgelagerte Konsumenten verlassen können. Silber- und Goldtabellen sind in BI-, Analytics- und KI-Workloads wiederverwendbar, sodass Teams nicht dieselbe Reinigungs- oder Modellierungslogik in separaten Tools neu aufbauen.

Verwenden Sie dieses Muster in folgenden Fällen:

  • Mehrere Teams bauen auf denselben Quelldaten auf und benötigen konsistente Qualität.
  • Du brauchst eine nachverfolgbare Abstammung von rohen Eingaben bis zu zertifizierten Ausgaben.
  • Du brauchst einen klaren Vertrag zwischen Data Engineering und Analytics oder KI-Konsumenten.

Weitere Informationen zu diesem Muster finden Sie unter Understand Medallion architecture for Fabric with OneLake. Dieser Artikel behandelt Layer-Design, Bereitstellungsmodelle, Speicherformate, materialisierte Seeansichten und Delta-Tabellenoptimierung.

Wie man es anwendet

Ein funktionierendes Medaillon basiert auf einer Idee: Jede Schicht ist ein Vertrag mit nachgelagerten Verbrauchern, und Daten gelangen erst nach Erfüllung der Qualitätsstandards dieser Schicht auf die nächste Schicht.

  1. Identifizieren Sie Ihre Rohquellen und die Verbraucher, die auf zertifizierte Daten angewiesen sind.

  2. Definieren Sie, was zu jeder Schicht gehört, und wenden Sie diese Definitionen konsistent über Domänen hinweg an:

    Ebene Inhalt Typische Verbraucher
    Bronze Rohe, unveränderliche Daten, die direkt aus Quellen ohne Schema-Durchsetzung erfasst werden Dateningenieure (eingeschränkter Zugang)
    Silber Gereinigt, dedupliziert und den gemeinsamen Geschäftsdefinitionen angepasst Dateningenieure und ausgebildete Analysten
    Gold Kuratierte, geschäftsfähige Tabellen und semantische Modelle Alle BI-, Analytics- und KI-Konsumenten

  3. Jede Schicht wird mit der richtigen Fabric-Arbeitslast erstellt – typischerweise Data Engineering (Spark) oder Data Factory für Bronze und Silber, und Data Warehouse- oder Power BI-Semantische Modelle für Gold. Bewahren Sie die Originaltreue in Bronze, indem Sie das Originalformat verwenden, eine Verknüpfung zu Daten, Parquet oder Delta, je nach Zweck. Verwenden Sie Delta-Tabellen für Silber und Gold, damit Fabric-Workloads die verfeinerten Daten zuverlässig lesen und schreiben können.

  4. Wenden schichtbewusste Zugriffsrichtlinien an. Verwenden Sie OneLake-Sicherheit für unterstützte Items sowie die entsprechenden Fabric- und SQL-Berechtigungen für Warehouses. Beschränken Sie den Zugang zu Bronze, stellen Sie Silber für Analysten zur Verfügung und gewähren Sie Zugang zu Gold basierend auf den Bedürfnissen der Verbraucher und den Mindestprivilegien.

  5. Nutze kuratierte Goldausgaben für Downstream-Analysen. Erstellen Sie Gold-Layer-Semantische Modelle im Direct Lake-Modus, damit Power BI OneLake-Daten lesen kann, ohne eine importierte Kopie zu erstellen oder geplante Aktualisierungen erforderlich zu machen.

  6. Bestätigen Sie, dass jede Goldproduktion eine nachweisbare Abstammung durch Silber zu ihren Bronzequellen hat. Anschließend empfehlen Sie Gold-Layer-Tabellen und semantische Modelle, wie sie im OneLake-Katalog zertifiziert sind. Diese Validierung hilft den Verbrauchern zu erkennen, welche Daten für die Produktion bereit sind.

  7. Verwenden Sie goldene semantische Modelle wieder, um Fabric-IQ-Ontologien neu zu starten. Dieser Schritt gibt KI-Agenten einen geregelten Geschäftskontext, der auf zertifizierten Daten basiert.

Grundlegende Funktionen

  • Integrierte Analysen und KI – Bronze-, Silber- und Goldschichten versorgen jede Analyse- und KI-Workload auf OneLake ohne engine-spezifische Kopien. Funktionen:
  • Zentrale Governance – Auf jeder Ebene werden unterschiedliche Zugriffsrichtlinien und Qualitätsgates angewendet, sodass Verbraucher nur Daten sehen, die zu ihrer Rolle passen. Funktionen:
  • Open Data Interoperabilität – Speichere die Schichten in offenen Formaten, damit externe Engines sie zusammen mit Fabric lesen können. Funktionen:

Domänenorientiertes Datenmesh auf einer gemeinsamen Plattform

Wenn Sie mehrere Geschäftsteams haben, die Daten erzeugen und konsumieren, kann die Weiterleitung jeder Anfrage durch ein zentrales Datenteam die Lieferung verlangsamen. Geschäftsteams verstehen ihre eigenen Daten und Anforderungen oft am besten, aber die Dezentralisierung des Eigentums ohne gemeinsame Governance kann zu inkonsistenter Sicherheit, Qualität und Abstammung führen.

Das domänenorientierte Datenmesh-Muster verleiht jeder Geschäftsdomäne das Eigentum an eigenen Datenprodukten, während alle Domänen gemeinsamen Standards auf OneLake-Basis folgen. Jede Domain veröffentlicht ihre eigenen Datenprodukte, und andere Domains greifen über Shortcuts darauf auf und nutzen sie mit Fabric-Analysen und KI-Workloads. Zentralisierte Identitäts-, Sicherheits- und Governance-Richtlinien gelten einheitlich in allen Domänen.

Verwenden Sie dieses Muster in folgenden Fällen:

  • Ein einziges zentrales Datenteam wird zu einem Engpass für die Auslieferung.
  • Verschiedene Geschäftsbereiche haben unterschiedliche Daten, Anforderungen und Veröffentlichungsrhythmus.
  • Man braucht klare Verantwortlichkeit für die Datenqualität auf Domänenebene, ohne auf unternehmensweite Governance zu verzichten.

Wenden Sie ein domänenorientiertes Datenmesh an

Finde die richtige Balance zwischen Dezentralisierung und Konsistenz. Übertragen Sie das Eigentum auf die Domain, die die Daten am besten kennt, und halten Sie Identität, Sicherheit und Abstammung zentral, damit die Datenprodukte jeder Domain denselben Standards entsprechen.

  1. Identifizieren Sie Ihre Geschäftsbereiche. Jede Domain sollte einen kohärenten Bereich des Unternehmens repräsentieren, mit einem Team, das seine Datenprodukte von Ende zu Ende besitzen und betreiben kann.

  2. Erstelle für jeden Geschäftsbereich eine Domain und weise Arbeitsbereiche zu. Richten Sie eine separate zentrale Domäne für gemeinsame Infrastruktur und wiederverwendbare Unternehmensdaten ein.

  3. Definieren Sie Datenproduktstandards, die jede Domäne erfüllen muss – zum Beispiel Endorsement- oder Zertifizierungsanforderungen, dokumentierte Schemata, Eigentumsmetadaten, Versionsmanagement und Service-Level Agreements (SLAs). Diese Standards machen jedes Produkt zu einem wiederverwendbaren, auffindbaren Vertrag und nicht nur zu einem Workspace-Ordner.

  4. Nutzen Sie OneLake Security , um rollenbasierte Datenzugriffskontrollen auf Ordner-, Tabellen-, Zeilen- und Spaltenebene anzuwenden, damit Produzenten Datenprodukte veröffentlichen können, ohne alles in ihrem Arbeitsbereich offenzulegen.

  5. Wenden Sie tenant-weite Governance mit dem OneLake-Katalog für domänenübergreifende Entdeckung und Stammung sowie Microsoft Purview für Sensitivitätslabels und Audits an. Erweitern Sie dasselbe Identitäts- und Richtlinienmodell auf KI-Agenten, die Domain-Datenprodukte konsumieren, sodass der Zugriff auf Agenten wie bei jedem anderen Verbraucher geregelt wird.

  6. Lassen Sie Consumer-Domains Verknüpfungen verwenden, um auf Produzentendatenprodukte zu referenzieren, anstatt sie zu kopieren. Verbraucher können dann die referenzierten Datenprodukte im Fabric-Workload verwenden, die zu ihren Bedürfnissen passen. Für Power BI-semantische Modelle verwenden Sie den Direct Lake-Modus, um Daten direkt aus OneLake auszulesen. Verwenden Sie Fabric Data Agents oder Fabric IQ, um KI-Erfahrungen zu schaffen, die auf Managed domain Data Products basieren.

  7. Wenn Domains in Katalogen außerhalb von Fabric veröffentlichen, planen Sie die Synchronisation der Zugriffskontrolle ein, damit die Berechtigungen zwischen OneLake und dem externen Katalog konsistent bleiben.

    Tip

    Der Open-Source-Beschleuniger Policy Weaver von Microsoft kann diese Synchronisation für Azure Databricks (Unity Catalog), Snowflake und Dataverse-Quellen automatisieren. Es spiegelt Datenzugriffsrichtlinien in OneLake-Sicherheitsrollen und ergänzt das Mirroring (das Daten bewegt, aber keine Berechtigungen).

Datenmesh-Fähigkeiten

  • Zentrale Verwaltung – Dezentralisierung des Eigentums auf Domains, während Identität, Sicherheit und Abstammung zentralisiert bleiben. Funktionen:
  • Datenvirtualisierung – Ermöglichen Sie Verbraucherdomänen, herstellereigene Datenprodukte über Referenzen statt Kopien zu verwenden. Funktionen:
    • Verknüpfungen ermöglichen das Teilen von Null-Kopien zwischen Domains.
  • Integrierte Analysen und KI – Machen die Datenprodukte aller Domänen verbrauchbar über Fabric-Workloads hinweg. Funktionen:

Plattformkonsolidierung für Analytics und KI

Wenn man mehrere Analyseplattformen nebeneinander betreibt – getrennte Tools für Data Warehousing, Business Intelligence, Data Science, Echtzeitanalyse und KI – hat jedes Tool seine eigenen Datenkopien, Pipelines und ein eigenes Governance-Modell. Diese Fragmentierung treibt die Kosten in die Höhe und erschwert es, einheitliche Sicherheit anzuwenden oder eine einzige Antwort auf eine Geschäftsfrage zu bekommen.

Das Plattformkonsolidierungsmuster bringt diese Workloads auf Fabric, wo OneLake eine gemeinsame, verwaltete Datenbasis bereitstellt. Fabric-Workloads greifen auf diese Basis auf Daten zu, transformieren, synchronisieren oder analysieren sie, anstatt sich auf separate Daten- und Governance-Modelle für jedes Tool zu verlassen.

Verwenden Sie dieses Muster in folgenden Fällen:

  • Du nutzt mehrere Analyseplattformen mit überlappenden Funktionen.
  • Engine-spezifische Datenkopien und -pipelines verursachen Kosten und Wartungskosten.
  • Sie benötigen ein einheitliches Governance- und Sicherheitsmodell für alle Analyse- und KI-Workloads.

Plattformkonsolidierung anwenden

Zielen Sie auf weniger Plattformen, nicht auf mehr Integrationen. Konsolidiere Arbeitslasten in Fabric, anstatt Werkzeuge zu verbinden, und überbrücke externe Engines nur, wenn du sie noch nicht ausmustern kannst.

  1. Inventarisieren Sie die Analytics-, Data-Warehousing-, Data Science-, Business Intelligence- (BI) und KI-Tools und -Pipelines, die Sie heute nutzen. Notieren Sie, welche Workloads jedes Tool bedient und welche Daten es kopiert.

  2. Fügen Sie jede bestehende Arbeitslast der Fabric-Arbeitslast zu, die sie ersetzen kann:

    Legacy-Arbeitslast Fabric-Arbeitslast
    Datenorchestrierung und ETL Datenfabrik
    Spark-Notizbücher und Lakehouse-Verarbeitung Datentechnik
    SQL Data Warehousing Datenlager
    Streaming und KQL-Analysen Real-Time Intelligenz
    ML-Modelltraining und Experimentverfolgung Datenwissenschaft
    Betriebsdatenbanken Datenbanken (SQL-Datenbank in Fabric und Cosmos DB in Fabric)
    BI-Visualisierung und semantische Modelle Power BI mit Direct Lake-Modus
    Konversationelle KI, die auf Unternehmensdaten basiert Fabric Data Agents, Copilot for Fabric, Fabric IQ

  3. Etabliert ein einheitliches Governance- und Sicherheitsmodell für alle Workloads mit OneLake-Sicherheit, Microsoft Purview und dem OneLake-Katalog. Konfigurieren Sie kundenverwaltete Schlüssel, wenn unterstützte Fabric-Items eine weitere Verschlüsselungsschicht benötigen.

  4. Konsolidiere analytische Daten in OneLake durch Verwendung des Delta- oder Iceberg-Formats, damit Workloads eine verwaltete Datenbasis teilen können. Integrieren Sie operative Workloads, indem Sie sie in Fabric-Datenbanken konsolidieren, die synchronisierte Analysedaten in OneLake verfügbar machen.

  5. Boden-KI auf die konsolidierten Daten. Baue Ontologien (Vorschau) über deiner kuratierten Datenschicht und stelle sie den Agenten über den Ontology MCP-Server zur Verfügung, damit Fabric Data Agents, Microsoft 365 Copilot und externe Tools über denselben regulierten Kontext argumentieren. Sie können Ontologie-Definitionen aus Power BI-semantischen Modellen im Import-, Direct Lake- oder DirectQuery-Modus generieren. Verwenden Sie den Direct Lake-Modus, wenn Sie generierte Bindungen für unterstützte OneLake-Daten benötigen, und überprüfen Sie die aktuellen Ontologie-Einschränkungen.

  6. Für externe Engines, die Sie noch nicht ausmustern können, stellen Sie OneLake-Daten über Azure Databricks-Integration, Iceberg-Interoperabilität mit Snowflake oder OneLake-Zugriff und APIs bereit.

  7. Stellen Sie die ersetzten Werkzeuge, Datenkopien und Pipelines zurück, nachdem Sie das Fabric-Äquivalent validiert haben. So beseitigt die Konsolidierung Kosten, Lizenzen und Übergaben, anstatt eine weitere Plattform hinzuzufügen.

Plattformkonsolidierungsfähigkeiten

Externe Datenübertragung zwischen Organisationen

Wenn Sie kontinuierlich Daten mit Partnern, Lieferanten, Kunden oder anderen Abteilungen austauschen, führen Batch-Exporte, Dateiübertragungen und duplizierte Downstream-Systeme zu Latenz-, Kosten- und Governance-Lücken. Das externe Datenaustauschmuster ermöglicht Verbrauchern außerhalb Ihrer Organisation oder Geschäftsabteilung direkten Zugriff auf kuratierte OneLake-Daten ohne wiederkehrende Exporte. Verbraucher können auf die Daten über Fabric-Cross-Tenant-Sharing oder über externe Analyseplattformen wie Snowflake und Azure Databricks über OneLake-Interoperabilitätsfunktionen zugreifen.

Verbraucher sehen Updates, sobald Sie sie veröffentlichen. Sie steuern den Zugriff auf die Quelldaten über den Sharing- oder Interoperabilitätsmechanismus, der die Plattform des Verbrauchers unterstützt.

Verwenden Sie dieses Muster in folgenden Fällen:

  • Sie tauschen kontinuierlich Daten mit externen Organisationen aus.
  • Batch-Exporte oder Dateiübertragungen fügen Latenz, Komplexität oder Governance-Lücken hinzu.
  • Du musst den externen Zugriff zentral verfolgen und widerrufen.

Externe Datenfreigabe anwenden

Externe Freigabe funktioniert am besten, wenn man Virtualisierung statt Datenexporte verwendet. Passen Sie die Zugriffsmethode an das ab, was jeder Verbraucher lesen kann, und wenden Sie die von diesem Teilungs- oder Interoperabilitätsmechanismus unterstützten Zugriffskontrollen an.

  1. Identifizieren Sie die Datenprodukte, die Sie extern teilen möchten, sowie die Verbraucher, die sie benötigen (Partner, Lieferanten, Kunden). Typischerweise teilt man kuratierte Tabellen und Dateien, die gut definiert und dokumentiert sind.

  2. Wählen Sie für jeden Verbraucher den richtigen Sharing-Ansatz:

    Verbrauchertyp Empfohlener Ansatz
    Fabric-Nutzer in einem anderen Tenant Externe Datenfreigabe für schreibgeschützten, virtualisierten tenantübergreifenden Zugriff
    Snowflake on Azure Users Iceberg-Interoperabilität mit Snowflake, um Fabric-Tabellen im Iceberg-Format zu lesen, die im Iceberg-Format sichtbar sind.
    Azure Databricks Users OneLake-Katalogföderation in Azure Databricks, um OneLake-Tabellen über Unity Catalog abzufragen, ohne Daten zu kopieren
    Anwendungen oder Werkzeuge, die ADLS Gen2 oder Blob APIs unterstützen OneLake-Zugang und APIs zum Zugriff auf OneLake-Daten über unterstützte APIs

    Um Dataverse-Daten vor dem Teilen in OneLake zu bringen, verwenden Sie das einheitliche Datenzugriffsmuster.

  3. Scope-External Access mit den vom gewählten Sharing-Mechanismus unterstützten Berechtigungen. Beim externen Datenaustausch von Fabric gewährt der Share jedem Benutzer im Home-Tenant des eingeladenen Nutzers schreibgeschützten Zugriff. Anbieterseitige Sicherheits- und Governance-Richtlinien, einschließlich OneLake-Sicherheit, Sensitivitätsetiketten und Richtlinien zur Verhinderung von Datenverlust, werden im Tenant des Verbrauchers nicht durchgesetzt. Der Verbraucher muss den nachgelagerten Zugang in seiner Umgebung steuern.

  4. Vereinbart euch von Anfang an auf die Bedingungen jeder Teilbeziehung – was geteilt wird, mit wem und wie lange. Für Fabric externe Datenfreigabe widerrufen Sie den Zugriff über den Tab Externe Datenfreigaben auf der Seite Berechtigungen verwalten. Für andere Ansätze widerrufen Sie den Zugriff über den ausgewählten Sharing-Mechanismus. Bestätigen Sie, dass der Verbraucher die Sicht verliert.

  5. Wenden Sie Sensitivitätsetiketten, Audits und Datenverlustprävention mit Microsoft Purview in der Fabric-Umgebung des Anbieters an.

  6. Unterstützen und dokumentieren Sie die Quelldatenprodukte im OneLake-Katalog , damit Anbieter sie vor dem Teilen finden und steuern können. Der OneLake-Katalog veröffentlicht keine Datenprodukte an externe Mieter oder Analyseplattformen.

Externe Datenfreigabefunktionen

  • Datenvirtualisierung – Daten über Referenzen ohne Kopierung zu teilen, ohne Exportpipelines zu verwalten. Funktionen:
    • Externe Datenfreigabe ermöglicht eine virtualisierte Freigabe zwischen Fabric-Tenants.
    • Abkürzungen ermöglichen es Partnern, veröffentlichte Daten zu konsumieren, ohne sie zu kopieren.
  • Open-Data-Interoperabilität – Teilen Sie sie mit Verbrauchern, die Fabric nicht nutzen, indem Sie in offenen Formaten veröffentlichen. Funktionen:
  • Zentralisierte Governance – Verwalten Sie Quelldaten in Fabric und kontrollieren Sie den externen Zugriff über jeden Sharing-Mechanismus. Funktionen:
    • Die OneLake-Sicherheit begrenzt den Zugriff auf Quelldaten in Fabric.
    • Microsoft Purview wendet Sensitivitätsetiketten, Audits und Datenverlustprävention in der Fabric-Umgebung des Anbieters an.
    • Der OneLake-Katalog unterstützt die anbieterseitige Entdeckung und Empfehlung vor dem Teilen.
  • Last updated on