Auswählen eines Microsoft Fabric Bereitstellungsmusters

Wenn Sie Microsoft Fabric bereitstellen, müssen Sie entscheiden, wie Kapazitäten, Arbeitsbereiche und Elemente in Ihrer Organisation strukturiert werden sollen. Das richtige Bereitstellungsmuster hängt von Ihren Anforderungen für Governance, Sicherheit, Leistungsisolation und Kostenverwaltung ab. Dieser Leitfaden hilft Architekten und Plattformteams, vier Bereitstellungsmuster zu bewerten und die Überlegungen und Kompromisse für jeden zu verstehen.

Hierarchie mit vier Ebenen

Das folgende Diagramm zeigt die Hierarchie mit vier Ebenen, die alle Fabric Bereitstellungen definiert.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Die Bereitstellungshierarchie fließt von Ihrem Microsoft 365 Mandanten nach unten zu einzelnen Elementen. Die Auswahl des Bereitstellungsmusters bestimmt, wie Sie jede Ebene verwenden.

• Mandantenebene. Oben befindet sich Ihr Microsoft 365-Mandanten, der als Identitäts- und Verwaltungsgrenze für Ihre Organisation dient. Ihr Fabric-Mandant ist innerhalb dieses Microsoft 365-Mandanten enthalten, und alle Fabric-Ressourcen befinden sich innerhalb einer einzigen Mandantengrenze. Einstellungen auf Mandantenebene, einschließlich Microsoft Entra Conditional Access, Private Links und Sensitivitätsbezeichnungen, gelten für alle Kapazitäten und Arbeitsbereiche.

• Kapazitätsstufe. Richten Sie mindestens eine Fabric Kapazität innerhalb eines Microsoft 365 Mandanten ein. Jede Kapazität ist an eine bestimmte Azure Region gebunden und weist eine bestimmte F-SKU auf, die verfügbare Computeressourcen bestimmt, die in Kapazitätseinheiten (CUs) gemessen werden. Kapazitäten kontrollieren die Datenhaltung und definieren Abrechnungsgrenzen. Eine einzelne Kapazität kann mehrere Arbeitsbereiche hosten.

• Arbeitsbereichsebene. Jede Kapazität enthält einen oder mehrere Arbeitsbereiche. Arbeitsbereiche sind die primären Container für Zusammenarbeit und Governance. Sie definieren die Zugriffssteuerung über vier Arbeitsbereichsrollen (Administrator, Mitglied, Mitwirkender und Viewer), unterstützen die Git-Integration für die Versionssteuerung und dienen als Bereich für Bereitstellungspipelines. Ein Arbeitsbereich gehört jeweils zu einer Kapazität. Die Migration der Kapazität in derselben Region ist einfach. Die regionsübergreifende Migration ist möglich, aber Sie müssen die meisten Fabric Elemente entfernen und neu erstellen, einschließlich Seehäuser, Lagerhäuser, Notizbücher und Pipelines. Bevorzugen Sie daher die Migration innerhalb derselben Region.

• Elementebene Arbeitsbereiche enthalten Fabric-Elemente wie Lakehouses, Lager, Notizbücher, Pipelines, semantische Modelle, Berichte und Dashboards. Elemente erben standardmäßig Arbeitsbereichsberechtigungen. Microsoft OneLake-Sicherheitsrollen ermöglichen eine präzise Zugriffssteuerung auf Tabellen-, Ordner-, Spalten- und Zeilenebene, gelten jedoch nur für Benutzer in der Viewer-Rolle. Arbeitsbereichsadministratoren, Mitglieder und Mitwirkende umgehen OneLake-Sicherheitsrollen.

Die folgenden Lizenzierungs- und Arbeitsbereichstypeinschränkungen bestimmen häufig, welches Bereitstellungsmuster am praktischsten ist:

• Neue Arbeitsbereiche beginnen mit freigegebener Kapazität, es sei denn, Sie weisen sie neu zu. Jeder Mandant verfügt über eine freigegebene Kapazität, die "Meine Arbeitsbereiche" hostet und Power BI Pro oder PPU-Arbeitsbereiche (Premium Per User) hosten kann. Um ein geregeltes Fabric Bereitstellungsmuster für Produktionsworkloads zu implementieren, müssen Sie Arbeitsbereiche in der Regel einer dedizierten Fabric Kapazität im Mandanten neu zuweisen.

• PPU ist kein Ersatz für die Fabric-Kapazität. PPU bietet Power BI Premium-Features auf Einzelbenutzerbasis, enthält jedoch keine Fabric-Kapazität. Um andere Elemente als Power BI Fabric, wie Lakehouses, Warehouses und Notebooks, zu erstellen oder auszuführen, benötigen Sie eine F-Kapazität.

• Der Arbeitsbereichstyp wirkt sich darauf aus, was das Muster hosten kann. In den Fabric-Bereitstellungsmustern in diesem Artikel wird davon ausgegangen, dass F-SKU-gestützte Fabric-Arbeitsbereiche verwendet werden. A- und EM-SKUs unterstützen nur Power BI Elemente, sodass sie keine End-to-End-Fabric Bereitstellungsmuster unterstützen können.

• Power BI-Viewer-Lizenzierung kann die Kosten eines Modells ändern. Auf F64 und größeren Kapazitäten können Benutzer mit der Anzeigerolle auf Power BI-Inhalte mit einer kostenlosen Lizenz zugreifen. Bei kleineren Kapazitäten benötigen Power BI Verbraucher eine Pro-, PPU- oder Testlizenz. Dieser Schwellenwert kann die Kosteneffizienz eines zentralisierten Musters für große Leserpopulationen verringern.

• Power BI Erstellen und Teilen erfordert mindestens einen Pro- oder PPU-Benutzer. Auch wenn ein Arbeitsbereich Fabric Kapazität verwendet, benötigen Organisationen Benutzer mit Pro- oder PPU-Lizenzen, um Power BI Elemente zu erstellen und zu teilen.

Komponenten

• Microsoft 365 tenant: Eine Identitäts- und Verwaltungsgrenze für Ihre Organisation. Sie hostt Microsoft Entra ID (vormals Azure Active Directory) für die Authentifizierung und Autorisierung.

• Fabric capacity: Eine Rechen- und Abrechnungsressource, die in einer bestimmten Azure Region verwendet wird, z. B. Ost-USA oder Westeuropa. Um Kosten zu reduzieren, können Sie die Kapazitäten anhalten, wenn sie nicht verwendet werden.

• Fabric workspace: Ein Container für die Zusammenarbeit für Fabric Elemente. Es unterstützt rollenbasierte Zugriffssteuerung (RBAC), Git-Integration und Bereitstellungspipelinen. Für die logische Gruppierung können Sie Arbeitsbereiche Fabric-Domänen zuteilen.

• Fabric-Elemente: Daten- und Analyseartefakte wie Lakehouses, Data Warehouses, Notebooks, Pipelines, Datenströme, semantische Modelle, Berichte und Dashboards.

• Fabric Domains: Logische Gruppierungen, die Arbeitsbereiche nach Geschäftseinheit oder Betreffbereich organisieren. Domänen unterstützen delegierte Governance und werden im OneLake-Katalog zur Ermittlung und Aufsicht angezeigt.

• OneLake: Ein einheitlicher, hierarchischer Data Lake, in dem Mandanten Arbeitsbereiche mit Elementen enthalten. Fabric speichert Daten in OneLake. OneLake unterstützt Azure Data Lake Storage APIs, Verknüpfungen zum externen Speicher und Integration mit Data Lake Storage Tools, z. B. Azure Storage Explorer und AzCopy.

• OneLake-Katalog: Eine zentrale Schnittstelle zum Suchen, Steuern und Sichern von Fabric-Daten mandantenweit. Benutzer können mithilfe von Tools wie Microsoft Teams, Excel und Microsoft Copilot Studio auf den Katalog zugreifen.

Grundlegendes zu Fabric Bereitstellungsebenen

Struktur, Ziele, Sicherheitsanforderungen, Skalierung, Governancemodell und Anwendungslebenszyklus beeinflussen Entscheidungen auf jeder Bereitstellungsebene. Weitere Informationen zu den einzelnen Ebenen finden Sie unter Hierarchie auf vier Ebenen.

• Kapazitäten steuern die Datenhaltung und die geografische Verteilung. Organisationen, die an mehreren geografischen Standorten arbeiten, können Kapazitäten in verschiedenen Azure Regionen nutzen, um zu steuern, wo Daten gespeichert werden. Jede Kapazität ist an eine bestimmte Azure Region gebunden, die mehrere geografische Bereitstellungen in allen Regionen unterstützt. Um die zentrale Governance zu unterstützen, können Fabric Domänen Arbeitsbereiche und die zugehörigen Kapazitäten in allen Regionen gruppieren.

• Arbeitsbereiche dienen als primäre Governance- und Sicherheitsgrenze. Jeder Arbeitsbereich definiert die Zugriffssteuerung über vier Rollen, unterstützt die Versionssteuerung über die Git-Integration und dient als Bereich für Bereitstellungspipelines. Verwenden Sie den OneLake-Katalog, um die Zusammenarbeit und Inhaltsermittlung zu zentralisieren, um eine einheitliche Discovery- und Governance-Erfahrung über die OneLake-Daten des Mandanten zu implementieren. Benutzer können Inhalte aus Tools wie Teams und Excel über diesen Katalog suchen und mit ihnen interagieren.

• Jede Ebene beeinflusst die Auswahl des Anwendungslebenszyklus. Features wie Bereitstellungspipelinen und Lebenszyklusverwaltung sind in Einzelarbeitsbereichsmustern nicht verfügbar, da sie separate Arbeitsbereiche erfordern. Organisationen, die Domänen zum Gruppieren von Arbeitsbereichen verwenden, können die Verwaltung auf Domänenebene ohne Mandantenadministratorberechtigungen delegieren, was sich darauf auswirkt, wie Teams Versionen und Governance in allen Geschäftseinheiten verwalten.

Allgemeine Muster für alle Bereitstellungen

Alle Fabric-Bereitstellungsmodelle teilen die folgenden grundlegenden Merkmale:

• Arbeitsbereiche als Grenzen für Skalierung, Governance und Sicherheit. Bereitstellungskonzepte verwenden Fabric-Arbeitsbereiche als primäre Einheit für die Elementorganisation, Berechtigungen und den DevOps-Funktionsumfang. Unabhängig davon, welches Muster Sie auswählen, definieren Arbeitsbereiche die Grenze für die Zusammenarbeit und die Zugriffssteuerung.

• Fabric-Domänen für die Delegierung über mehrere Arbeitsbereiche und Geschäftseinheiten hinweg. Verwenden Sie Fabric Domänen für die Delegierung. Sie können mehrere Arbeitsbereiche verwalten, die möglicherweise derselben Geschäftseinheit angehören, oder Daten verwalten, die zu einer Geschäftsdomäne gehören und mehrere Arbeitsbereiche umfassen. Um Daten auf Domänenebene zu verwalten und zu steuern, können Sie Einstellungen auf Mandantenebene anpassen und eine domänenspezifische Konfiguration für diese Einstellungen verwenden.

• Kapazitäten für die Computerskalierung mit dedizierter Kapazität pro Arbeitsbereich, um Leistungsgarantien zu gewährleisten. Wenn Sie bestimmte Leistungsstufen erfüllen müssen, verwenden Sie Fabric Kapazitäten, um Computeressourcen zu skalieren und dedizierte Kapazitäten pro Arbeitsbereich anzubieten. Organisationen, die Arbeitsauslastungsisolation für leistungsabhängige Aufträge benötigen, können diese Arbeitsbereiche einer separaten Kapazität zuweisen, die eine garantierte CU-Zuordnung aufweist.

• OneLake-Katalog für die Ressourcenermittlung und die Registerkarte "Sicher" für Datensicherheitsrichtlinien. Verwenden Sie den OneLake-Katalog, um die Ermittlung und die Verwendung von Datenressourcen in Ihrem Mandanten zu fördern. Um Sicherheitsrollen für Arbeitsbereiche und Elemente anzuzeigen, zu überwachen und zu konfigurieren, verwenden Sie die Registerkarte "Sicher" im OneLake-Katalog.

• Erweiterung auf Microsoft Cloud Features, wenn systemeigene Fabric Features nicht verfügbar sind. Wenn ein systemeigenes Feature nicht verfügbar ist, können Bereitstellungsmuster erweitert werden, um gleichwertige Features aus dem Microsoft Cloud zu verwenden, z. B. Azure und Microsoft 365. Organisationen können z. B. Azure Pipelines oder GitHub Actions für eine kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD)-Orchestrierung verwenden, wenn Fabric Bereitstellungspipelines ihre arbeitsbereichübergreifenden Automatisierungsanforderungen nicht abdecken. Organisationen können auch Microsoft Purview für unternehmensweite Datengovernance verwenden, die Fabric und nicht Fabric Datenquellen umfasst.

Auswählen eines Bereitstellungsmusters

In den folgenden Szenarien werden allgemeine Geschäftsanforderungen und die Bereitstellungsmuster beschrieben, die sie erfüllen. Verwenden Sie diese Szenarien, um das Muster zu identifizieren, das am besten zu Ihrer Organisation passt.

• Szenario 1: Schnellere Markteinführungszeit mit teamübergreifender Zusammenarbeit. Wenn Ihre Organisation schnellere Zeit zum Markt, teamübergreifende Zusammenarbeit und geringere Einschränkungen bei der Datennutzung möchte, können Sie ein monolithisches Bereitstellungsmuster implementieren. In diesem Szenario arbeitet Ihre Organisation in einem einzigen Arbeitsbereich und verwaltet diesen.

  Verwenden Sie Muster 1: Monolithische Bereitstellung.

• Szenario 2: Isolierte Teamumgebungen mit zentraler Infrastrukturverwaltung. Wenn Ihre Organisation isolierte Teamumgebungen und ein zentrales Infrastrukturverwaltungsteam bereitstellen möchte, können Sie mehrere Arbeitsbereiche implementieren, die entweder eine gemeinsame Kapazität oder separate Kapazitäten verwenden. Dieses Szenario eignet sich auch für Organisationen, die eine Datengitterarchitektur implementieren möchten.

  Verwenden Sie Muster 2: Mehrere Arbeitsbereiche, einzelne Kapazität oder Muster 3: Mehrere Arbeitsbereiche, separate Kapazitäten.

• Szenario 3: Vollständige Geschäftseinheitsautonomie über Datenplattformen. Wenn Ihre Organisation ein völlig dezentrales Modell möchte, das Geschäftseinheiten oder Teams die Freiheit bietet, ihre eigenen Datenplattformen zu steuern und zu verwalten, können Sie ein Bereitstellungsmodell implementieren, das entweder separate Arbeitsbereiche mit dedizierter Kapazität oder mehreren Fabric Mandanten verwendet.

  Verwenden Sie Pattern 3: Mehrere Arbeitsbereiche, separate Kapazitäten oder Pattern 4: Mehrere Fabric-Tenants.

• Szenario 4: Hybridansatz, der mehrere Muster kombiniert. Wenn Ihre Organisation eine Hybridlösung möchte, die mehrere Muster verwendet, um ihre Anforderungen zu erfüllen, können Sie einen Hybridansatz implementieren. Sie können z. B. einen einzelnen Arbeitsbereich für bestimmte Geschäftseinheiten einrichten, z. B. in einem monolithischen Bereitstellungsmuster, sowie separate, dedizierte Arbeitsbereiche und separate Kapazitäten für andere Geschäftseinheiten.

Muster 1: Monolithische Bereitstellung

In diesem Bereitstellungsmuster weisen Sie für alle Anwendungsfälle einen Arbeitsbereich zu. Alle Geschäftseinheiten funktionieren innerhalb desselben Arbeitsbereichs.

Die folgenden Merkmale gelten für dieses Muster:

• Fabric-Komponenten haben dieselbe Kapazität. Die Zeit, die eine Abfrage oder ein Auftrag benötigt, variiert je nach den anderen Workloads, die dieselbe Kapazität verwenden.

• Die maximalen CUs eines Arbeitsbereichs sind auf die größtmögliche F-SKU beschränkt. Für Data-Engineering- und Data-Science-Anwendungen können Kapazitätsadministratoren die Autoscale-Abrechnung für Apache Spark konfigurieren, um die Rechenkapazität, die die Spark-Engine verwendet, außerhalb der zugewiesenen CUs zu verlagern.

• Features, die auf einen Arbeitsbereich angewendet werden, gelten für alle Geschäftseinheiten, die den Arbeitsbereich gemeinsam nutzen.

• Alle Arbeitsbereichselemente und Daten befinden sich in einer Region. Sie können dieses Muster nicht für mehrere geografische Szenarien verwenden.

• Features, die auf mehreren Arbeitsbereichen basieren, sind nicht verfügbar, z. B. Bereitstellungspipelinen und Lebenszyklusverwaltung.

• Einschränkungen für einzelne Arbeitsbereiche gelten.

• Es gelten spezifische SKU-Kapazitätsbeschränkungen.

Wann Sie dieses Muster verwenden sollten

Sie können dieses Bereitstellungsmuster implementieren, wenn:

• Ihre Organisation hat keine komplexen technischen Anforderungen, sie verfügt über eine kleine Benutzerbasis oder über kleine semantische Modelle.

• Ihr Unternehmen ist in einer einzigen Region tätig.

• Es geht Ihnen nicht in erster Linie um die organisatorische Trennung zwischen den Geschäftsbereichen.

• Ihr Unternehmen benötigt keine arbeitsbereichsspezifischen Funktionen, wie z. B. die gemeinsame Nutzung von Code-Repositorys mit Git.

• Sie möchten eine Lakehouse-Medallion-Architektur implementieren. Wenn Ihre Organisation einen einzelnen Arbeitsbereich verwendet, können Sie separate Lakehouses innerhalb des Arbeitsbereichs erstellen, um Bronze-, Silber- und Gold-Ebenen zu verwalten.

• Die Geschäftseinheiten Ihrer Organisation teilen Rollen, und Sie können über die gleichen Berechtigungen auf Arbeitsbereichsebene für Benutzer im Arbeitsbereich verfügen. Wenn beispielsweise mehrere Benutzer aus unterschiedlichen Geschäftseinheiten Administratoren eines einzelnen Arbeitsbereichs sind, haben sie dieselben Rechte für alle Elemente im Arbeitsbereich.

• Ihre Organisation toleriert variable Abschlusszeiten des Auftrags. Wenn eine Kapazität freigegeben ist, können Benutzer jederzeit Abfragen ausführen. Die Anzahl der verfügbaren CUs zum Ausführen eines Auftrags hängt von den anderen Abfragen ab, die auf der Kapazität ausgeführt werden, was zu variablen Abschlusszeiten für den Auftrag führen kann.

• Ihre Organisation kann ihre CU-Geschäftsanforderungen erfüllen, indem sie eine einzige Fabric-Kapazität verwenden.

Überlegungen zum Entwurfsbereich

Die folgende Tabelle enthält Überlegungen, die Ihre Entscheidung zur Verwendung dieses Bereitstellungsmusters beeinflussen können.

Muster 2: Mehrere Arbeitsbereiche, einzelne Kapazität

In diesem Bereitstellungsmuster weisen Sie mehrere Arbeitsbereiche einer einzigen freigegebenen Kapazität zu. Arbeitsbereiche teilen diese Kapazität, sodass sich gleichzeitige Workloads auf die Leistung von Aufträgen und interaktiven Abfragen auswirken können.

Die folgenden Merkmale gelten für dieses Muster:

• Fabric-Komponenten haben dieselbe Kapazität. Die Zeit, die eine Abfrage oder ein Auftrag benötigt, variiert je nach den anderen Workloads, die dieselbe Kapazität verwenden.

• Die maximalen CUs eines Arbeitsbereichs sind auf die größtmögliche F-SKU beschränkt. Für Data-Engineering- und Data-Science-Anwendungen können Kapazitätsadministratoren die Autoscale-Abrechnung für Spark konfigurieren, um die vom Spark Engine verwendete Rechenkapazität außerhalb der zugewiesenen CU-Kapazitäten zu verschieben.

• Funktionen, die auf einen Arbeitsbereich beschränkt sind, gelten für alle Geschäftseinheiten, die diesen Arbeitsbereich gemeinsam nutzen.

• Alle Arbeitsbereichselemente und Daten befinden sich in einer Region. Sie können dieses Muster nicht für mehrere geografische Szenarien verwenden.

• Sie können DevOps-Features verwenden, die separate Arbeitsbereiche erfordern, z. B. Bereitstellungspipelinen und Lebenszyklusverwaltung.

• Einschränkungen für einzelne Arbeitsbereiche gelten.

• Es gelten spezifische SKU-Kapazitätsbeschränkungen.

Wann Sie dieses Muster verwenden sollten

Sie können dieses Bereitstellungsmuster implementieren, wenn:

• Sie möchten eine Hub-Spoke-Architektur, die einige Aspekte des Betriebs der Analyseumgebung zentralisiert und andere dezentralisiert.

• Sie möchten eine variable betriebs- und managementdezentralisierung. Beispielsweise kann Ihre Organisation die Bronze- und Silberschichten einer Medaillenarchitektur in einem Arbeitsbereich hosten und die Goldschicht in einem separaten Arbeitsbereich hosten. Diese Trennung spiegelt oft unterschiedliche betriebliche Verantwortlichkeiten wider, z. B. wenn ein Team die Bronze- und Silberschichten verwaltet und ein anderes Team die Goldschicht verwaltet.

• Sie sind nicht in erster Linie besorgt um die Leistungsverwaltung und Workload-Isolation.

• Ihre Organisation muss keine Workloads in verschiedenen geografischen Regionen bereitstellen. Alle Daten müssen sich in einer Region befinden.

• Ihre Organisation erfordert möglicherweise separate Arbeitsbereiche, da:

  • Mitglieder des Teams, das für Arbeitsauslastungen verantwortlich ist, befinden sich in verschiedenen Arbeitsbereichen.

  • Sie möchten für jede Art von Arbeitsbelastung einen eigenen Arbeitsbereich einrichten. Sie können z. B. einen Arbeitsbereich für die Datenaufnahme erstellen, z. B. Datenpipelinen, Datenflüsse oder Datentechnik, und einen separaten Arbeitsbereich für den Verbrauch über ein Data Warehouse. Dieses Design funktioniert gut, wenn separate Teams für jede Arbeitsauslastung verantwortlich sind.

  • Sie möchten eine Datengitterarchitektur implementieren, die einen oder mehrere Arbeitsbereiche in einer Fabric Domäne gruppiert.

• Ihre Organisation kann separate Arbeitsbereiche basierend auf der Datenklassifizierung bereitstellen.

Überlegungen zum Entwurfsbereich

Die folgende Tabelle enthält Überlegungen, die Ihre Entscheidung zur Verwendung dieses Bereitstellungsmusters beeinflussen können.

Muster 3: Mehrere Arbeitsbereiche, separate Kapazitäten

In diesem Bereitstellungsmuster weisen Sie mehrere Workspaces über separate Fabric Kapazitäten hinweg zu, die die Governance und Leistungsisolation zwischen Geschäftseinheiten gewährleisten.

Die folgenden Merkmale gelten für dieses Muster:

• Die größtmögliche F-SKU oder P-SKU, die an einen Arbeitsbereich angefügt ist, bestimmt die maximale Anzahl von CUs, die ein Arbeitsbereich verwenden kann.

• Separate Arbeitsbereiche schaffen die Dezentralisierung der Organisation und Verwaltung.

• Organisationen können über eine Region hinaus skalieren, indem Sie Kapazitäten und Arbeitsbereiche in verschiedenen geografischen Regionen verwenden.

• Sie können die vollständigen Funktionen von Fabric verwenden, da Geschäftseinheiten mehrere Arbeitsbereiche in separaten Kapazitäten haben und über Fabric Domänen gruppiert werden können.

• Arbeitsbereichseinschränkungen für einen einzelnen Arbeitsbereich gelten, aber Sie können neue Arbeitsbereiche erstellen, die über diese Grenzen hinaus skaliert werden können.

• Spezifische SKU-Kapazitätsbeschränkungen gelten, Sie können jedoch CUs mithilfe separater Kapazitäten skalieren.

• Sie können den OneLake-Katalog verwenden, um Fabric Elemente und deren Zertifizierungsstatus zu ermitteln.

• Domänen können Arbeitsbereiche gruppieren, so dass eine einzelne Geschäftseinheit mehrere Arbeitsbereiche betreiben und verwalten kann.

• OneLake-Tastenkombinationen beseitigen physische Kopien von Daten, um die Datenverschiebung zu reduzieren. OneLake-Tastenkombinationen bieten auch kontrollierten, arbeitsbereichübergreifenden Zugriff über OneLake und übertragen nicht den Besitz der zugrunde liegenden Daten.

Wann Sie dieses Muster verwenden sollten

Sie können dieses Bereitstellungsmuster implementieren, wenn:

• Ihr Unternehmen möchte Architektur-Frameworks wie Data Mesh oder Data Fabric einsetzen.

• Bei der Strukturierung von Kapazitäten und Arbeitsbereichen sollten Sie auf Flexibilität Wert legen.

• Sie sind in verschiedenen geografischen Regionen tätig. Erstellen Sie in diesem Fall eine separate Kapazität und einen separaten Arbeitsbereich, um zu einem Mehrkapazitäts- und Multiworkspace-Bereitstellungsmuster zu wechseln.

• Sie arbeiten in großem Maßstab und müssen über die Grenzen einer Kapazität einer einzelnen SKU oder eines einzelnen Arbeitsbereichs hinaus skalieren.

• Sie verfügen über Workloads, die immer innerhalb einer bestimmten Zeit abgeschlossen werden müssen oder leistungsbasierte SLOs erfüllen müssen. Sie können einen separaten, von Fabric-Kapazität unterstützten Arbeitsbereich einrichten, um die SLOs für diese Workloads zu erfüllen.

Überlegungen zum Entwurfsbereich

Die folgende Tabelle enthält Überlegungen, die Ihre Entscheidung zur Verwendung dieses Bereitstellungsmusters beeinflussen können.

Muster 4: Mehrere Fabric Mandanten

In diesem Bereitstellungsmuster sind alle Instanzen von Fabric separate Entitäten in Bezug auf Governance, Verwaltung, Verwaltung, Skalierung und Speicher.

Die folgenden Merkmale gelten für dieses Muster:

• Die Mandantenressourcen sind streng getrennt.

• Die Verwaltungsebenen zwischen den Mandanten sind getrennt.

• Mandanten sind separate Entitäten, die eigene Governance- und Verwaltungsprozesse haben und jeweils unabhängig verwaltet werden.

• Sie können Datenpipelines oder Datenengineering-Fähigkeiten verwenden, um Daten zwischen Fabric-Mandanten gemeinsam zu nutzen oder darauf zuzugreifen.

Wann Sie dieses Muster verwenden sollten

Sie können dieses Bereitstellungsmuster implementieren, wenn:

• Ihre Organisation verfügt über mehrere Fabric-Tenants aufgrund einer Geschäftsübernahme.

• Ihre Organisation möchte einen Fabric-Mandanten speziell für eine Geschäftseinheit oder eine kleinere Tochtergesellschaft einrichten.

Auswerten alternativer Plattformen

Wenn die Anforderungen Ihrer Organisation nicht auf Fabric basierten Bereitstellungsmodellen ausgerichtet sind, sollten Sie Alternativen mit Einschränkungen in Betracht ziehen.

• Azure Data Factory mit Data Lake Storage oder OneLake, einschließlich hybrider Data Factory- und Fabric-Architekturen

  Organisationen, die explizite Orchestrierungskontrolle oder phasenweise Modernisierung benötigen, können Data Factory für Aufnahme und Pipeline-Orchestrierung und Data Lake Storage als Speichergrundlage verwenden. In einem Hybridmodell können von Data Factory verwaltete Datenpipelinen Daten in OneLake laden, während Fabric die Erstellung analytischer Datenressourcen verwaltet. Dieser Ansatz unterstützt die inkrementelle Akzeptanz von Fabric und behält etablierte Integrationsmuster bei.

• Data Lake Storage, Azure Databricks und Power BI

  Organisationen, die eine plattformbasierte Architektur (PaaS)-basierte Architektur anstelle einer einheitlichen Software as a Service (SaaS)-Plattform bevorzugen, können eine Datenmenge erstellen, indem sie Data Lake Storage für die Speicherung, Azure Databricks für Datentechnik und -analysen und Power BI für semantische Modellierung und Berichterstellung verwenden. Dieser Ansatz bietet maximale Kontrolle und Flexibilität, erfordert jedoch einen erhöhten Integrationsaufwand und erhöht die betriebliche Komplexität und den Governance-Overhead.

Überlegungen

Diese Überlegungen sind umgesetzt in den Säulen des Well-Architected-Frameworks, welches eine Reihe von Leitprinzipien darstellt, die Sie verwenden können, um die Qualität eines Workloads zu verbessern. Weitere Informationen finden Sie im Well-Architected Framework.

Die Mustertabellen weiter oben in diesem Artikel verwenden Designbereiche, die für Fabric Bereitstellungsentscheidungen spezifisch sind, z. B. Governance, Sicherheit, Verwaltung, DevOps, Benutzerfreundlichkeit, Leistung und Abrechnung. Die folgenden Unterabschnitte enthalten ergänzende Leitlinien, die nach den Säulen des Well-Architected Framework organisiert werden. Verwenden Sie die tabellen pro Muster, um Muster zu vergleichen. Verwenden Sie diese Unterabschnitte für querschneidende Architekturanleitungen, die unabhängig davon gelten, welches Muster Sie auswählen.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

• Integrierte regionale Resilienz. Fabric bietet integrierte regionale Resilienz über Verfügbarkeitszonen, sofern unterstützt. Fabric verteilt Ressourcen automatisch über mehrere Zonen ohne Kundenkonfiguration. Die Verfügbarkeitszonen-Unterstützung variiert je nach Azure-Region. Informationen dazu, ob Ihre Zielregion Verfügbarkeitszonen für Fabric unterstützt, finden Sie unter Fabric Regionsverfügbarkeit.

• Für die Notfallwiederherstellung (DR) ist eine Anmeldung erforderlich und es gibt Einschränkungen. Die regionsübergreifende Wiederherstellung ist über eine Opt-In-DR-Einstellung auf der Seite "Kapazitätseinstellungen" verfügbar. Aktivieren Sie die DR-Kapazitätseinstellung zum Replizieren von OneLake-Daten über Azure gekoppelte Regionen mithilfe der asynchronen Replikation.

  Von Bedeutung

  Einige Azure Regionen sind nicht mit Regionen gekoppelt, die Fabric unterstützen, was die DR-Funktionen beeinträchtigen kann, auch wenn Daten repliziert werden. Da die Datenreplikation asynchron ist, gehen daten, die unmittelbar vor einem regionalen Notfall geschrieben wurden, möglicherweise verloren. Weitere Informationen finden Sie unter Reliability in Fabric.

• Einzelkapazitätsmuster konzentrieren sich auf risiken in einer Region. In Muster 1 und 2 befinden sich Workloads in einer Azure Region. Wenn die Region einen Ausfall erlebt, sind alle Arbeitsbereiche gleichzeitig betroffen. Um vor regionalem Fehler zu schützen, konfigurieren Sie die Kapazitätseinstellung zum Replizieren von OneLake-Daten in eine gekoppelte Region. Planen Sie die Wiederherstellungszeit, die zum Wiederherstellen des Diensts in der gekoppelten Region erforderlich ist.

• Die Multicapacity-Muster bieten eine natürliche regionale Isolation. Bei den Mustern 3 und 4 bedeutet die Verteilung von Kapazitäten in verschiedenen Regionen, dass ein regionaler Ausfall nur die Kapazitäten in dieser Region betrifft. Workloads in anderen Regionen funktionieren weiterhin. Diese Muster unterstützen die Anforderungen an die Datenhaltung und stellen die Grundlage für regionale Strategien mit entweder aktiver-passiver oder aktiver-aktiver Umsetzung bereit.

• Das Anhalten der Kapazität wirkt sich auf die Zuverlässigkeit aus. Wenn Sie eine Fabric-Kapazität anhalten, um Kosten zu senken, sind alle Workloads auf dieser Kapazität nicht verfügbar. Berücksichtigen Sie den Zuverlässigkeitseffekt, bevor Sie eine Kapazität anhalten, die Produktionsworkloads unterstützt.

• OneLake-Verknüpfungen führen externe Abhängigkeiten ein. Verknüpfungen zu externen Datenquellen führen zu einer Abhängigkeit von der Verfügbarkeit der Quelle. Wenn die externe Quelle nicht verfügbar ist, können Elemente, die auf Verknüpfungen basieren, fehlschlagen. Überwachen Sie den Zustand externer Datenquellen und planen Sie eine gesteuerte Degradierung.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

• Das mehrschichtige Sicherheitsmodell umfasst drei Ebenen. Fabric implementiert ein mehrschichtiges Sicherheitsmodell, das die Mandanten-, Arbeitsbereichs- und Elementebenen umfasst. Die Auswahl des Bereitstellungsmusters bestimmt, wie Sie Sicherheitsgrenzen segmentieren. Muster für einzelne Arbeitsbereiche, z. B. Muster 1, erzwingen den einheitlichen Zugriff. Multiworkspace-Muster, z. B. Muster 2, 3 und 4, unterstützen pro Team oder pro Geschäftseinheit Sicherheitsgrenzen.

Identität und Zugriff

• Erzwingen Sie Authentifizierungsrichtlinien auf Mandantenebene mithilfe des bedingten Zugriffs. Verwenden Sie bedingten Zugriff , um Authentifizierungsrichtlinien auf Mandantenebene wie mehrstufige Authentifizierung, Gerätekompatibilität und standortbasierte Einschränkungen zu erzwingen. Bedingter Zugriff erfordert eine Microsoft Entra ID P1-Lizenz.

• Verwenden Sie Arbeitsbereichsrollen, um den Elementzugriff zu steuern. Weisen Sie Arbeitsbereichsrollen zu, um zu steuern, wer Elemente innerhalb eines Arbeitsbereichs erstellen, bearbeiten und nutzen kann. Verwenden Sie in Multiworkspace-Mustern wie Mustern 2, 3 und 4 separate Arbeitsbereiche, um Rollengrenzen zwischen Geschäftseinheiten zu erzwingen.

• Wenden Sie präzisen Zugriff auf Datenebene mithilfe von OneLake-Sicherheitsrollen an. Verwenden Sie OneLake-Sicherheitsrollen , um eine präzise Zugriffssteuerung auf Tabellen-, Ordner-, Spalten- und Zeilenebene für Benutzer in der Viewer-Rolle anzuwenden. Arbeitsbereichsadministratoren, Mitglieder und Mitwirkende umgehen diese Rollen.

Netzwerksicherheit

• Verwenden Sie private Links für eingehenden Datenverkehr. Verwenden Sie Private-Links, um eingehenden Datenverkehr über das Microsoft Backbone anstelle des öffentlichen Internets weiterzuleiten. Private Links auf Mandantenebene gelten für alle Arbeitsbereiche. Private Links auf Arbeitsbereichsebene bieten eine Granularität pro Arbeitsbereich.

• Verwenden Sie verwaltete private Endpunkte für ausgehende Spark-Verbindungen. Verwenden Sie verwaltete private Endpunkte, um ausgehende Verbindungen von Spark-Workloads zu durch Firewalls geschützten Datenquellen wie Data Lake Storage und Azure SQL Database zu sichern.

• Verwenden Sie virtuelle Netzwerkdatengateways, wenn private Links auf Mandantenebene lokale Gateways blockieren. Wenn Sie private Links auf Mandantenebene aktivieren, können sich lokale Datengateways nicht registrieren. Verwenden Sie ein Virtuelles Netzwerkdatengateway anstelle von Brücken, die lokale oder virtuelle netzwerkgeschützte Datenquellen verbinden.

Datenschutz

• Wenden Sie Vertraulichkeitsbezeichnungen für die End-to-End-Datenklassifizierung an. Wenden Sie für die Datenklassifizierung und den Schutz Sensitivitätsbezeichnungen von Microsoft Purview Information Protection auf Daten an, die über Fabric fließen. Labels folgen den Daten aus der Quelle bis zum Bericht.

• Verwenden Sie Überwachungsprotokolle und Compliancetools für die Richtlinienerzwingung. Um Richtlinienverletzungen zu erkennen und darauf zu reagieren, überprüfen Sie Auditprotokolle und verwenden Sie Microsoft Purview Compliance Manager.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

• Modellkosten vor der Bereitstellung. Bereitstellungsmuster wirken sich auf Ihre Kostenstruktur aus. Modellieren Sie die Kosten für Ihr Szenario mit Fabric Pricing und dem Fabric Kapazitätsschätzer.

• Stimmen Sie Ihre Kapazität passend ab, indem Sie die Produktkennzeichnung optimieren. Passen Sie Ihre F SKU basierend auf der Arbeitslastanforderung an. Beginnen Sie mit einer kleineren SKU, und skalieren Sie nach Bedarf. Überwachen Sie den Verbrauch und identifizieren Sie überlastete oder nicht bereitgestellte Kapazitäten mithilfe der Fabric Kapazitätsmetriken-App.

• Automatisieren sie das Anhalten der Kapazität für Nichtproduktionsumgebungen. Reduzieren Sie die Kosten, indem Sie F-SKU-Kapazitäten anhalten, wenn sie nicht verwendet werden. In Entwicklungs-/Testumgebungen sollten Sie die Kapazitäten außerhalb der Arbeitszeit anhalten. Das Anhalten macht alle Workloads nicht verfügbar. Ziehen Sie daher die Automatisierung über Azure Resource Manager Fabric-APIs oder geplante Pipelines in Betracht.

• Einzelkapazitätsmuster, wie Muster 1 und 2, zentralisieren die Abrechnung, beschränken jedoch die Rückbelastung. Eine Kapazität bedeutet eine Rechnung. Die Kostenverwaltung ist zentralisiert, aber Chargeback für einzelne Geschäftseinheiten ist nicht möglich, da alle Workloads die gleiche Kapazität aufweisen.

• Multicapacity-Muster, wie etwa Muster 3 und 4, unterstützen die Zurechnung pro Team. Jede Kapazität generiert einen eigenen Azure Abrechnungszähler. Sie können Kosten für die für jede Kapazität verantwortlichen Geschäftseinheit berechnen. Sie können jede Kapazität basierend auf der von ihr unterstützten Workload unabhängig anpassen oder pausieren.

• Verwalten Sie die OneLake-Speicherkosten unabhängig voneinander. OneLake-Speicher wird mit einem Pay-as-you-go-Tarif pro GB abgerechnet und verbraucht keine CUs. Löschen Sie regelmäßig nicht verwendete Daten, einschließlich vorläufig gelöschter Daten, und überwachen Sie den Speicher über die Fabric Kapazitätsmetriken-App.

• Überwachen Sie Spark-Compute separat. Für Daten-Engineering-Workloads können Sie separate Spark-Pools verwenden, um die Rechenleistung außerhalb des CU-Budgets auszugliedern. Um unerwartete Kosten zu vermeiden, überwachen Sie den Spark CU-Verbrauch.

Betriebliche Effizienz

Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie in der Checkliste zur Designüberprüfung für operationale Exzellenz.

• Verwenden Sie Bereitstellungspipelines für mehrstufige Heraufstufen. Verwenden Sie Fabric-Bereitstellungspipelines, um Inhalte über Entwicklungs-/Test- und Produktionsphasen zu fördern. Bereitstellungspipelines erfordern separate Arbeitsbereiche, sodass sie in Muster 1 nicht verfügbar sind. Erstellen Sie in Den Mustern 2, 3 und 4 dedizierte Arbeitsbereiche für jede DTAP-Phase. Die Kapazitätsstrategie variiert je nach Muster.

  • In Muster 2 teilen alle DTAP-Arbeitsbereiche die gleiche Kapazität, was kosteneffizient ist, aber keine Leistungsisolation zwischen Umgebungen bietet.

  • In Muster 3 können Sie dedizierte Kapazitäten pro Umgebung für die vollständige Isolation verwenden, oder Sie können Kosten und Isolation ausgleichen, indem Sie eine gemeinsame Kapazität für Entwicklungs-/Test mit einer separaten Produktionskapazität verwenden.

• Planen Sie Vorproduktionsumgebungen als Entwurfsentscheidung auf Arbeitsbereichsebene. Muster 1 bietet keine Präproduktionstrennung, da Dev/Test im Produktionsarbeitsbereich stattfindet. Muster 2 unterstützt separate Entwicklungs-, Test- und Produktionsarbeitsbereiche auf einer freigegebenen Kapazität, die zur funktionalen Validierung, aber nicht zu produktionsähnlichen Leistungs- oder Resilienztests passt. Muster 3 unterstützt die produktionsähnliche Vorproduktionsüberprüfung durch umgebungsorientierte Arbeitsbereiche mit Kapazitätsebenenisolation. Muster 4 umfasst separate Mandanten anstelle von Entscheidungen auf Arbeitsbereichsebene. Jeder Mandant kann unabhängig eine eigene Umgebungstopologie auswählen und muss nicht mit anderen Mandanten übereinstimmen.

• Verbinden sie Arbeitsbereiche mit Git-Repositorys für die Quellcodeverwaltung. In den Mustern 2 und 3 stimmen separate Arbeitsbereiche pro Team oder Arbeitslast mit Standard-Verzweigungsstrategien überein. In Pattern 1 teilen alle Teams ein einzelnes Repository, was zu Merge-Konflikten führen kann.

• Überwachen den Kapazitäts- und Arbeitsauslastungszustand. Verwenden Sie die App Fabric-Kapazitätsmetriken, um den Kapazitätsverbrauch zu überwachen, z.B. die CU-Nutzung, Drosselung und Überlastungen. Mithilfe der Arbeitsbereichsüberwachung können Sie auf detaillierte Telemetriedaten zu einzelnen Workloads zugreifen. In Mehrkapazitätsmustern, z. B. Muster 3 und 4, können Sie die Überwachung an das Team delegieren, das für jede Kapazität zuständig ist.

• Delegieren Sie die Verwaltung durch Fabric-Domänen. Delegieren Sie in Muster 2 und 3 Mandanteneinstellungen und Arbeitsbereichsverwaltung an Administratoren auf Domänenebene ohne Mandantenadministratorberechtigungen, indem Sie Fabric Domänen verwenden. Muster 1 kann keine Domänen verwenden, da sich alle Elemente in einem Arbeitsbereich befinden.

• Verwalten Sie Kapazitäten mithilfe von 'Infrastructure as Code' (IaC). Erstellen und verwalten Sie Fabric Kapazitäten mithilfe von Bicep oder Terraform. Speichern Von Infrastrukturdefinitionen in der Quellcodeverwaltung zusammen mit Anwendungscode.

Leistungseffizienz

Die Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Arbeitslast, die Anforderungen der Benutzer effizient zu skalieren und zu erfüllen. Weitere Informationen finden Sie in der Checkliste zur Entwurfsüberprüfung für die Leistungseffizienz.

• Verstehen des Kapazitätsdimensionierungs- und Drosselungsverhaltens. Jede Kapazität verfügt über eine feste CU-Zuordnung, die von ihrer SKU bestimmt wird. Wenn die Nachfrage die verfügbaren CUs überschreitet, wendet Fabric Drosselung und Warteschlangenanforderungen an. Überwachen Sie Drosselungsereignisse mithilfe der App Kapazitätsmetriken der Fabric und skalieren Sie die SKU-Einheit, oder verteilen Sie die Workloads nach Bedarf über mehrere Kapazitäten.

• Isolieren Sie leistungsempfindliche Workloads auf einer dedizierten Kapazität. In Pattern 1 und 2 konkurrieren alle Workloads um die gleichen CUs. Eine teure Abfrage- oder Datenpipeline kann die interaktive Abfrageleistung für andere Benutzer beeinträchtigen. In den Mustern 3 und 4 können Sie leistungsempfindliche Workloads auf einem dedizierten Kapazitätsbereich mit einer garantierten CU-Zuordnung isolieren.

• Konfigurieren Sie Spark-Pools für Daten-Engineering-Workloads. Verwenden Sie für Datenentwicklungsworkloads benutzerdefinierte Spark-Pools , um mindeste und maximale Knotenanzahl zu steuern und die automatische Skalierung zu unterstützen. Verwaltete virtuelle Netzwerke deaktivieren Starter-Pools oder vorgewärmte freigegebene Cluster, was die Startzeit der Sitzung von Sekunden auf 3 bis 5 Minuten verlängert.

• Stellen Sie Kapazitäten in der Nähe von Datenherstellern und Verbrauchern. In Muster 3 können Sie Kapazitäten in Regionen in der Nähe von Datenherstellern oder Verbrauchern verwenden, wodurch die regionsübergreifende Latenz reduziert wird. OneLake-Verknüpfungen können auf Daten in anderen Regionen verweisen, aber regionsübergreifende Lesevorgänge verursachen Latenz- und Ausgangskosten.

• Wenden Sie workloadspezifische Optimierungstechniken an. Verbessern Sie die Scanleistung mithilfe von Z-Order und V-Order für Seehäuser. Optimieren Sie abfragemuster für Lagerhäuser, um kleinere Batches zu lesen. Verringern Sie die Kapazität im Vergleich zum Importmodus, indem Sie Direct Lake Modus für Power BI Berichte verwenden.

Funktionsmatrix

In den folgenden Tabellen sind die wichtigsten Unterschiede in den Funktionen der einzelnen Muster zusammengefasst.

Führung und Verwaltung

¹ Arbeitsbereiche bieten eine gewisse Isolation, aber alle Arbeitsbereiche teilen eine einzige Kapazität, wodurch die Granularität der Nutzungsnachverfolgung und -verwaltung begrenzt wird.

² Muster 4 verwendet separate Mandanten anstelle von Domänen. Jeder Mandant verfügt über ein eigenes Verwaltungsmodell.

Sicherheit

DevOps- und Lebenszyklusverwaltung

³ Bereitstellungspipelines erfordern separate Arbeitsbereiche, die in einem monolithischen Einzelarbeitsbereich-Muster nicht verfügbar sind.

⁴ Git-Integration ist verfügbar, aber alle Teams teilen sich ein Repository, was Merge-Konflikte verursachen kann.

Leistung und Skalierbarkeit

⁵ Das Drosselungsrisiko ist gering, wenn Workloads auf dedizierten Kapazitäten liegen, aber die Drosselung kann immer noch innerhalb einer einzigen Kapazität auftreten, wenn die Nachfrage die verfügbaren CUs überschreitet.

Abrechnung und Kostenverwaltung

⁶ Jede Kapazität generiert einen eigenen Abrechnungszähler, sodass die Abrechnung über Kapazitäten verteilt wird und nicht zentralisiert wird.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

• Amanjeet Singh | Hauptprogramm-Manager

Andere Mitwirkende:

• Lorrin Ferdinand | Hauptberater
• Holly Kelly | Leitender Programmmanager
• Gabi Münster | Leitender Programmmanager
• Sarah Sasidharan | Senior Program Manager

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Fabric Konzepte und Lizenzen
• Fabric-Workspaces
• Fabric Domains
• Was ist OneLake?
• Fabric-Bereitstellungspipelines
• Reliability in Fabric
• Fabric Sicherheitsübersicht

Verwandte Ressourcen

• Übersicht über die Technologieauswahl
• End-to-End-Analytics mit Fabric
• Enterprise Business Intelligence mit Fabric
• Erstellen Sie ein neues Lakehouse mit Fabric