Bearbeiten

Share via

Microsoft Fabric-Bereitstellungsmuster

Microsoft Fabric

In diesem Artikel werden vier Bereitstellungsmuster beschrieben, aus denen Sie bei der Bereitstellung von Microsoft Fabric wählen können. Erfahren Sie mehr über Überlegungen, Empfehlungen und potenzielle nicht umkehrbare Entscheidungen für jedes Bereitstellungsmuster.

Die folgenden Designbereiche werden für jedes Fabric-Bereitstellungsmuster skizziert:

  • Governance
  • Sicherheit
  • Verwaltung
  • DevOps
  • Benutzerfreundlichkeit
  • Leistung und Skalierbarkeit
  • Abrechnung und Kostenverwaltung

Ebenen in einer Fabric-Bereitstellung

Eine Fabric-Bereitstellung hat vier Ebenen: Tenant, Capacity, Workspace und Item. Auf der obersten Ebene steht der Fabric-Mandant. Jeder Mandant kann eine oder mehrere Kapazitäten haben, jede Kapazität kann einen oder mehrere Arbeitsbereiche enthalten, und jeder Arbeitsbereich kann null oder mehr Stoffelemente enthalten.

Die Struktur oder die Ziele eines Unternehmens in den Bereichen Sicherheit, Umfang, Governance und Anwendungslebenszyklus können die Wahl des Bereitstellungsmusters beeinflussen. Die verschiedenen Einsatzmuster bieten unterschiedliche Flexibilität und Schwerpunkte in den einzelnen Stufen eines Einsatzes.

Eine Organisation kann zum Beispiel domains verwenden, um Arbeitsbereiche in Fabric zu gruppieren. Wenn eine Organisation eine zentrale Option für die Zusammenarbeit und das Auffinden von Inhalten benötigt, bietet die OneLake Datendrehscheibe in Fabric einen zentralen Zugangspunkt und ist in andere bekannte Produkte wie Microsoft Teams und Excel integriert.

In Fabric kann ein großes Unternehmen mit Geschäftseinheiten an verschiedenen geografischen Standorten Kapazitäten nutzen, um zu kontrollieren, wo seine Daten gespeichert sind. Durch die Verwendung von Fabric-Domänen kann eine Geschäftseinheit, die von einem anderen geographischen Standort aus operiert, als eine einzige Einheit verwaltet werden, da Domänen Arbeitsbereiche umfassen können, die sich in verschiedenen Regionen befinden.

Weitere Informationen über Fabric-Stufen und ihre Rolle bei der Auswahl eines Bereitstellungsmusters finden Sie unter Microsoft Fabric-Konzepte und -Lizenzen.

Wie Fabric-Bereitstellungsmuster angepasst werden

Alle Muster für den Einsatz von Stoffen:

  • Verwenden Sie Fabric Workspaces als Grenzen für Skalierung, Governance und Sicherheit.
  • Verwenden Sie Fabric Domains für die Delegation, um mehrere Arbeitsbereiche zu verwalten, die zur gleichen Geschäftseinheit gehören können, oder wenn sich Daten, die zu einer Geschäftsdomäne gehören, über mehr als einen Arbeitsbereich erstrecken. Sie können einige Einstellungen auf Mandantenebene für die Verwaltung und Steuerung von Daten auf der Domänenebene festlegen und die domänenspezifische Konfiguration für diese Einstellungen verwenden.
  • Nutzen Sie Fabric-Kapazitäten zur Skalierung von Rechenressourcen und stellen Sie gleichzeitig dedizierte Kapazitäten pro Arbeitsbereich bereit, wenn bestimmte Leistungsanforderungen erfüllt werden müssen.
  • Erweitern Sie, um gleichwertige Funktionen aus einer Microsoft-Cloud (Microsoft Azure, Microsoft 365 und andere) zu verwenden, wenn eine Funktion in Fabric nicht verfügbar ist.
  • Nutzen Sie die OneLake-Datendrehscheibe, um das Auffinden und die Nutzung von Datenbeständen zu fördern.
  • Verwenden Sie OneSecurity, um Datensicherheitsrichtlinien für Datenbestände einzurichten.

Szenarien auf der Grundlage von Geschäftsanforderungen

In diesem Artikel wird anhand der folgenden Szenarien beschrieben, wie die einzelnen Bereitstellungsmuster verschiedene Geschäftsanforderungen erfüllen können:

  • Szenario 1: Für Unternehmen, die eine schnellere (oder langsamere) Markteinführung anstreben, indem sie Teams organisieren, die übergreifend zusammenarbeiten können, mit geringeren Einschränkungen bei der Datennutzung. In diesem Szenario kann ein Unternehmen von der Verwendung eines monolithischen Bereitstellungsmusters profitieren. Die Organisation betreibt und verwaltet einen einzigen Arbeitsbereich. Weitere Informationen finden Sie unter Muster 1: Monolithische Bereitstellung.
  • Szenario 2: Für Unternehmen, die isolierte Umgebungen für die Arbeit von Teams bereitstellen möchten, wobei ein zentrales Team für die Bereitstellung und Verwaltung der Infrastruktur zuständig ist. Dieses Szenario eignet sich auch für Unternehmen, die ein Datennetz einrichten wollen. In diesem Szenario kann ein Unternehmen mehrere Arbeitsbereiche implementieren, die entweder eine gemeinsame Kapazität nutzen oder über separate Kapazitäten verfügen. Weitere Informationen finden Sie unter Muster 2: Mehrere Arbeitsbereiche, unterstützt durch eine einzige Stoffkapazität und Muster 3: Mehrere Arbeitsbereiche mit separaten Kapazitäten.
  • Szenario 3: Für Unternehmen, die ein vollständig dezentrales Modell wünschen, das Geschäftseinheiten oder Teams die Freiheit gibt, ihre eigenen Datenplattformen zu kontrollieren und zu verwalten. In diesem Szenario kann sich ein Unternehmen für ein Bereitstellungsmodell entscheiden, bei dem es separate Arbeitsbereiche mit jeweils dedizierter Kapazität oder möglicherweise mit mehreren Fabric-Tenants verwendet. Weitere Informationen finden Sie unter Muster 3: Mehrere Arbeitsbereiche mit separaten Kapazitäten und Muster 4: Mehrere Fabric-Tenants.
  • Szenario 4: Eine Organisation könnte sich für einen hybriden Ansatz entscheiden, bei dem sie mehrere Muster kombiniert, um ihre Anforderungen zu erfüllen. So kann ein Unternehmen beispielsweise einen einzigen Arbeitsbereich für bestimmte Geschäftsbereiche einrichten (ein monolithisches Bereitstellungsmuster), während es für andere Geschäftsbereiche separate, dedizierte Arbeitsbereiche und separate Kapazitäten verwendet.

Muster 1: Monolithische Bereitstellung

Bei diesem Bereitstellungsmuster stellen Sie einen einzigen Arbeitsbereich bereit, der alle Ihre Anwendungsfälle abdeckt. Alle Geschäftsbereiche arbeiten in einem einzigen Arbeitsbereich.

Diagramm, das einen einzelnen Fabric-Tenants zeigt, der eine einzelne Kapazität und einen einzelnen Arbeitsbereich hat.

Wenn Sie eine einzelne Fabric-Kapazität bereitstellen und ihr einen einzelnen Arbeitsbereich zuordnen, gelten die folgenden Punkte:

  • Alle Fabric-Artikel haben die gleiche bereitgestellte Kapazität. Die Zeit, die eine Abfrage oder ein Auftrag zum Abschluss benötigt, variiert, da andere Workloads dieselbe Kapazität nutzen.
  • Die maximalen Kapazitätseinheiten (CUs) des Arbeitsbereichs sind auf die größtmögliche F SKU oder P SKU begrenzt. Für Data-Engineering-Erfahrungen können Sie separate Spark-Pools bereitstellen, um die von Fabric Spark benötigte Rechenkapazität außerhalb der bereitgestellten CUs 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 Multi-Geo-Szenarien verwenden.
  • Funktionen, die sich auf mehrere Arbeitsbereiche stützen, wie deployment pipelines und lifecycle management, sind nicht verfügbar.
  • Es gelten die Einschränkungen, die mit einem einzelnen Arbeitsbereich verbunden sind.
  • Es gelten die Kapazitätsbeschränkungen, die mit einer bestimmten SKU verbunden sind.

Sie können sich aus einem oder mehreren der folgenden Gründe für die Implementierung dieses Bereitstellungsmusters entscheiden:

  • Ihr Unternehmen hat keine komplexen technischen Anforderungen, es hat eine kleine Benutzerbasis, oder seine semantischen Modelle sind klein.
  • 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 wollen eine Seehaus-Medaillon-Architektur umsetzen. Wenn Ihre Organisation auf einen einzigen Arbeitsbereich beschränkt ist, können Sie eine Trennung zwischen Bronze-, Silber- und Goldebenen erreichen, indem Sie innerhalb des Arbeitsbereichs separate Seekammern erstellen.
  • Die Geschäftsbereiche Ihres Unternehmens haben gemeinsame Rollen, und es ist akzeptabel, wenn die Benutzer im Arbeitsbereich dieselben Berechtigungen auf Arbeitsbereichsebene haben. Wenn z. B. mehrere Benutzer, die verschiedenen Geschäftsbereichen angehören, Administratoren eines einzigen Arbeitsbereichs sind, haben sie dieselben Rechte für alle Elemente im Arbeitsbereich.
  • Ihr Unternehmen kann variable Auftragsabwicklungszeiten tolerieren. Wenn ein Unternehmen keine Leistungsgarantien verlangt (z. B. muss ein Auftrag innerhalb eines bestimmten Zeitraums abgeschlossen werden), ist es akzeptabel, eine einzige bereitgestellte Kapazität für alle Geschäftsbereiche gemeinsam zu nutzen. Wenn eine Kapazität gemeinsam genutzt wird, können die Nutzer ihre Abfragen jederzeit durchführen. Die Anzahl der CUs, die für die Ausführung eines Auftrags zur Verfügung stehen, hängt davon ab, welche anderen Abfragen auf der Kapazität laufen. Dies kann zu variablen Auftragsabwicklungszeiten führen.
  • Ihr Unternehmen kann alle Geschäftsanforderungen (aus Sicht der CU) mit einer einzigen Fabric-Kapazität erfüllen.

Die folgende Tabelle enthält Überlegungen, die Ihre Entscheidung für dieses Bereitstellungsmuster beeinflussen könnten:

Aspekt Überlegungen
Governance – Es sind weniger Governance-Mandate und Einschränkungen für die Plattform erforderlich.
– Sie eignet sich für kleinere Unternehmen, die eine schnellere Markteinführung bevorzugen.
– Herausforderungen können sich ergeben, wenn die Anforderungen an die Governance immer komplexer werden.
Sicherheit–Datenebene – Daten können von allen Teams gemeinsam genutzt werden, so dass es keine Beschränkungen für Daten zwischen Teams geben muss.
– Die Teams haben Eigentumsrechte an den semantischen Modellen. Sie können Daten in OneLake lesen, bearbeiten und ändern.
Sicherheit–Kontrollebene – Alle Benutzer können im selben Arbeitsbereich zusammenarbeiten.
– Es gibt keine Einschränkungen für Gegenstände. Alle Benutzer können alle Einträge lesen und bearbeiten.
Verwaltung Die Organisation hat:

– Geringere Verwaltungskosten.
– Es besteht keine Notwendigkeit, den Zugriff und die Nutzung pro Team zu verfolgen und zu überwachen.
– Weniger strenge Überwachung der Stoffauslastung in den Teams.
DevOps DevOps profitiert davon:

– Ein einziges Release für die gesamte Plattform.
– Weniger komplizierte Release-Pipelines.
Benutzerfreundlichkeit–Administratoren – Die Verwaltung ist für die Administratoren einfacher, da sie weniger Elemente zu verwalten haben.
– Es ist kein weiteres Provisioning oder die Bearbeitung von Anfragen von Teams nach neuen Kapazitäten oder Arbeitsbereichen erforderlich.
– Kapazitätsadministratoren können Tenant-Administratoren sein, so dass es nicht notwendig ist, andere Gruppen oder Teams zu erstellen oder zu verwalten.
Benutzerfreundlichkeit–Andere Rollen – Es ist zulässig, den Arbeitsbereich mit anderen Benutzern zu teilen.
– Die Zusammenarbeit zwischen den Nutzern wird gefördert.
Leistung – Die Isolierung von Arbeitslasten ist nicht zwingend erforderlich.
– Es müssen keine strengen Leistungsvereinbarungen (SLAs) eingehalten werden.
– Eine Drosselung ist unwahrscheinlich.
Abrechnung und Kostenverwaltung – Ein einziges Team kann die Kosten übernehmen.
– Es besteht keine Notwendigkeit, verschiedene Teams zu beauftragen.

Muster 2: Mehrere Arbeitsbereiche, die durch eine einzige Fabric-Kapazität gesichert sind

Bei diesem Bereitstellungsmuster verwenden Sie separate Arbeitsbereiche. Da eine einzige Kapazität von mehreren Arbeitsbereichen gemeinsam genutzt wird, können Arbeitslasten, die gleichzeitig ausgeführt werden, die Leistung von Aufträgen und interaktiven Abfragen beeinträchtigen.

Diagramm, das einen einzelnen Fabric-Tenants zeigt, der eine Einzelkapazität und zwei Arbeitsbereiche enthält.

Wenn Sie eine einzelne Fabric-Kapazität bereitstellen und ihr mehrere Arbeitsbereiche zuordnen, gelten die folgenden Punkte:

  • Alle Fabric-Artikel haben die gleiche bereitgestellte Kapazität. Die Zeit, die eine Abfrage oder ein Auftrag zum Abschluss benötigt, variiert, da andere Workloads dieselbe Kapazität nutzen.
  • Die maximale Anzahl der Einheiten, die ein Arbeitsbereich verwenden kann, ist auf die größtmögliche F-SKU oder P-SKU begrenzt. Für Data-Engineering-Erfahrungen können Sie separate Spark-Pools bereitstellen, um die von Fabric Spark benötigte Rechenkapazität außerhalb der bereitgestellten CUs 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 Multi-Geo-Szenarien verwenden.
  • Sie können DevOps-Funktionen verwenden, für die separate Arbeitsbereiche erforderlich sind, z. B. für Bereitstellungspipelines und Lebenszyklusmanagement.
  • Es gelten die Einschränkungen, die mit einem einzelnen Arbeitsbereich verbunden sind.
  • Es gelten die Kapazitätsbeschränkungen, die mit einer bestimmten SKU verbunden sind.

Sie können sich aus einem oder mehreren der folgenden Gründe für die Implementierung dieses Bereitstellungsmusters entscheiden:

  • Sie möchten eine Hub-and-Spoke-Architektur, in der Ihr Unternehmen einige Aspekte des Betriebs der Analyseumgebung zentralisiert und andere dezentralisiert.
  • Sie wollen eine Dezentralisierung in operativer und verwaltungstechnischer Hinsicht, aber in unterschiedlichem Maße. So können Sie beispielsweise die Bronze- und Silberschicht einer Medaillon-Architektur in einem Arbeitsbereich und die Goldschicht in einem anderen Arbeitsbereich bereitstellen. Ihr Grundgedanke könnte sein, dass ein Team für die Bronze- und Silberschicht und ein anderes Team für den Betrieb und die Verwaltung der Goldschicht zuständig ist.
  • Es geht Ihnen nicht in erster Linie um das Leistungsmanagement und die Isolierung von Workloads unter Leistungsgesichtspunkten.
  • Aus der Perspektive der Medaillenarchitektur eines Seehauses kann Ihre Organisation separate Arbeitsbereiche schaffen, um Bronze-, Silber- und Goldschichten zu implementieren.
  • Ihr Unternehmen muss keine Workloads in verschiedenen geografischen Regionen bereitstellen (alle Daten müssen sich in einer Region befinden).
  • In Ihrem Unternehmen kann die Trennung von Arbeitsbereichen aus einem oder mehreren der folgenden Gründe erforderlich sein:
    • Die Mitglieder des Teams, das für die Arbeitsbelastung verantwortlich ist, befinden sich in verschiedenen Arbeitsbereichen.
    • Sie möchten für jede Art von Arbeitsbelastung einen eigenen Arbeitsbereich einrichten. So können Sie beispielsweise einen Arbeitsbereich für die Dateneingabe (Datenpipelines, Dataflow Gen2 oder Data Engineering) und einen separaten Arbeitsbereich für die Nutzung durch ein Data Warehouse erstellen. Dieses Konzept funktioniert gut, wenn getrennte Teams für die einzelnen Arbeitslasten zuständig sind.
    • Sie möchten eine Data-Mesh-Architektur implementieren, in der ein oder mehrere Arbeitsbereiche in einer Fabric Domain gruppiert sind.
  • Ihr Unternehmen kann sich dafür entscheiden, getrennte Arbeitsbereiche auf der Grundlage der Datenklassifizierung einzurichten.

Die folgende Tabelle enthält Überlegungen, die Ihre Entscheidung für dieses Bereitstellungsmuster beeinflussen könnten:

Aspekt Überlegungen
Governance – Mittlere Governance-Mandate und Einschränkungen für die Plattform sind erforderlich.
– Die Organisation benötigt eine detailliertere Kontrolle, um Abteilungen, Teams und Rollen zu steuern.
Sicherheit–Datenebene – Datenbeschränkungen sind erforderlich, und Sie müssen den Datenschutz auf der Grundlage von Zugriffskontrollen für Abteilungen, Teams und Mitglieder gewährleisten.
Sicherheit–Kontrollebene – Um versehentliche Beschädigungen oder Aktionen von böswilligen Benutzern zu vermeiden, müssen Sie möglicherweise einen kontrollierten Zugriff auf Gewebeelemente nach Rollen vorsehen.
Verwaltung – Sie brauchen keine Kapazitäten zu verwalten, da es sich um ein Modell mit einer Kapazität handelt.
– Sie können Arbeitsbereiche verwenden, um Abteilungen, Teams und Benutzer zu isolieren.
DevOps – Sie können unabhängige Freigaben pro Abteilung, Team oder Arbeitsbelastung durchführen.
– Es ist einfacher, die Anforderungen an Entwicklung, Test, Abnahme und Produktion (DTAP) für Teams zu erfüllen, wenn mehrere Arbeitsbereiche für jede Release-Umgebung bereitgestellt werden.
Benutzerfreundlichkeit–Administratoren – Sie müssen nicht mehrere Kapazitäten bereitstellen.
– Mandantenadministratoren verwalten in der Regel Kapazitäten, so dass Sie keine anderen Gruppen oder Teams verwalten müssen.
Benutzerfreundlichkeit–Andere Rollen – Für jede Medaillenebene sind Arbeitsbereiche verfügbar.
– Stoffteile werden pro Arbeitsbereich isoliert, was eine versehentliche Beschädigung verhindert.
Leistung – Strenge Leistungs-SLAs müssen nicht eingehalten werden.
– In Spitzenzeiten ist eine Drosselung akzeptabel.
Abrechnung und Kostenverwaltung – Es gibt keine spezifische Vorschrift, die eine Rückerstattung pro Team vorschreibt.
– Ein zentrales Team trägt alle Kosten.
– Die Infrastrukturteams sind Eigentümer der Fabric-Kapazitäten im Unternehmen.

Muster 3: Mehrere Arbeitsbereiche, die durch separate Kapazitäten gesichert sind

Bei diesem Bereitstellungsmuster erreichen Sie eine Trennung zwischen den Geschäftsbereichen für Governance und Leistung.

Diagramm, das einen einzelnen Fabric-Tenant zeigt, der zwei Kapazitäten enthält. Die erste Kapazität hat zwei Arbeitsbereiche. Die zweite Kapazität hat einen Arbeitsbereich.

Wenn Sie mehrere Fabric-Kapazitäten mit ihren eigenen Arbeitsbereichen bereitstellen, gelten die folgenden Punkte:

  • Die größtmögliche F-SKU oder P-SKU, die einem Arbeitsbereich zugeordnet ist, bestimmt die maximale Anzahl an CUs, die ein Arbeitsbereich verwenden kann.
  • Die Dezentralisierung von Organisation und Verwaltung wird durch die Bereitstellung separater Arbeitsbereiche erreicht.
  • Unternehmen können über eine Region hinaus skalieren, indem sie Kapazitäten und Arbeitsbereiche in verschiedenen geografischen Regionen bereitstellen.
  • Sie können den vollen Funktionsumfang von Fabric nutzen, da Geschäftseinheiten über einen oder mehrere Arbeitsbereiche verfügen können, die sich in separaten Kapazitäten befinden und über Fabric-Domänen gruppiert sind.
  • Einschränkungen, die mit einem einzelnen Arbeitsbereich verbunden sind, gelten, aber Sie können über diese Grenzen hinaus skalieren, indem Sie neue Arbeitsbereiche erstellen.
  • Es gelten die Kapazitätsbeschränkungen, die mit einer bestimmten SKU verbunden sind, aber Sie können CUs skalieren, indem Sie separate Kapazitäten bereitstellen.
  • Alle Fabric-Elemente in allen Arbeitsbereichen des Mandanten und deren Zertifizierungsstatus können mit Hilfe einer OneLake-Datendrehscheibe ermittelt werden.
  • Domänen können Arbeitsbereiche gruppieren, so dass eine einzelne Geschäftseinheit mehrere Arbeitsbereiche betreiben und verwalten kann.
  • OneLake-Verknüpfungen reduzieren die Datenbewegungen und die Verwendbarkeit der Daten in verschiedenen Arbeitsbereichen.

Sie können sich aus einem oder mehreren der folgenden Gründe für die Implementierung dieses Bereitstellungsmusters entscheiden:

  • 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. In diesem Fall ist die Bereitstellung einer separaten Kapazität und eines separaten Arbeitsbereichs die treibende Kraft, um zu diesem Bereitstellungsmuster mit mehreren Kapazitäten und mehreren Arbeitsbereichen überzugehen.
  • Sie arbeiten in großem Maßstab und müssen über die Grenzen einer SKU mit einer Kapazität oder eines einzelnen Arbeitsbereichs hinaus skalieren.
  • Sie haben Workloads, die immer innerhalb einer bestimmten Zeit beendet werden müssen oder eine bestimmte Leistungs-SLA erfüllen müssen. Sie können einen separaten Arbeitsbereich bereitstellen, der durch eine Fabric-Kapazität unterstützt wird, um die Leistungsgarantien für diese Workloads zu erfüllen.

Die folgende Tabelle enthält Überlegungen, die Ihre Entscheidung für dieses Bereitstellungsmuster beeinflussen könnten:

Aspekt Überlegungen
Governance – Sie haben ein hohes Maß an Governance und Management, und Sie brauchen Unabhängigkeit für jeden Arbeitsbereich.
– Sie können die Nutzung pro Abteilung oder Geschäftseinheit verwalten.
– Sie können die Anforderungen an die Datenresidenz erfüllen.
– Sie können Daten auf der Grundlage gesetzlicher Vorschriften isolieren.
Sicherheit–Datenebene – Der Datenzugriff kann pro Abteilung, Team oder Benutzer gesteuert werden.
– Sie können Daten auf der Grundlage des Stoffartikels isolieren.
Sicherheit–Kontrollebene – Sie können den Zugriff auf Fabric-Objekte nach Rollen kontrollieren, um versehentliche Beschädigungen oder Aktionen von böswilligen Benutzern zu vermeiden.
Verwaltung – Granulare Administratorfunktionen sind auf Abteilungen, Teams oder Benutzer beschränkt.
– Sie haben Zugang zu detaillierten Überwachungsanforderungen bezüglich der Nutzung oder der Muster von Arbeitslasten.
DevOps – Sie können DTAP-Umgebungen durch die Verwendung unterschiedlicher Kapazitäten isolieren.
– Unabhängige Freigaben basieren auf einer Abteilung, einem Team oder einer Arbeitsbelastung.
Benutzerfreundlichkeit–Administratoren – Sie erhalten einen detaillierten Einblick in die Nutzung nach Abteilung oder Team.
– Sie haben Kapazitätsrechte an Kapazitätsadministratoren pro Abteilung oder Team delegiert, was bei der Skalierung und granularen Konfiguration hilft.
Benutzerfreundlichkeit–Andere Rollen – Arbeitsbereiche sind pro Medaillon-Ebene und Kapazität verfügbar.
– Stoffteile werden pro Arbeitsbereich isoliert, was eine versehentliche Beschädigung verhindert.
– Sie haben mehr Möglichkeiten, um Drosselungen zu verhindern, die durch Überlastungen der gemeinsam genutzten Kapazitäten verursacht werden.
Leistung – Die Leistungsanforderungen sind hoch, und die Workloads müssen höhere SLAs erfüllen.
– Sie haben die Möglichkeit, die individuelle Arbeitslast pro Abteilung oder Team flexibel zu skalieren.
Abrechnung und Kostenverwaltung – Cross-Charging-Anforderungen können leicht erfüllt werden, indem einer Organisationseinheit (Abteilung, Team oder Projekt) dedizierte Kapazitäten zugewiesen werden.
– Das Kostenmanagement kann an die jeweiligen Teams delegiert werden, die es verwalten.

Muster 4: Mehrere Fabric-Tenants

Wenn separate Fabric-Tenants eingesetzt werden, sind alle Instanzen von Fabric in Bezug auf Governance, Management, Verwaltung, Skalierung und Speicherung separate Einheiten.

Die folgenden Punkte gelten, wenn Sie mehrere Fabric-Tenants verwenden:

  • Die Ressourcen des Mandanten sind streng getrennt.
  • Die Verwaltungsebenen zwischen den Mandanten sind getrennt.
  • Mandanten sind eigenständige Einheiten und können ihre eigenen Prozesse für Governance und Management haben, aber Sie können sie separat verwalten.
  • Sie können data pipelines oder Data Engineering verwenden, um Daten zwischen Fabric-Tenants zu teilen oder darauf zuzugreifen.

Sie könnten sich aus den folgenden Gründen für die Implementierung dieses Bereitstellungsmusters entscheiden:

  • Die Organisation könnte aufgrund einer Unternehmensübernahme mehrere Stoffmieter haben.
  • Das Unternehmen könnte sich dafür entscheiden, einen Fabric Tenant speziell für eine Geschäftseinheit oder eine kleinere Tochtergesellschaft einzurichten.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben: