Moderne Data Warehouse-Medallion-Architektur in Microsoft Fabric

Microsoft Fabric

Power BI

Dieser Beispiel-Workload beschreibt eine SQL-first-Medallion-Architektur für ein modernes Data Warehouse (MDW). Ein modernes Data Warehouse verwendet SQL-basierte Datenspeicher, um strukturierte Daten für Analysen und Berichte zu organisieren. Diese Architektur implementiert die Bronze-, Silber- und Goldschichten in Fabric Data Warehouse und verwendet Fabric Data Factory, um Datenaufnahme und Transformation zu koordinieren.

Fabric Data Warehouse speichert relationale Daten im Delta-Format in OneLake und unterstützt die T-SQL-Entwicklung über Tabellen, Ansichten, Transaktionen und gespeicherte Prozeduren. Power BI, SQL-Clients und andere Anwendungen nutzen kuratierte Daten aus der Goldschicht.

Important

Die empfohlenen Fabric Medaillenmuster verwenden ein Seehaus für jede Schicht oder verwenden Seehäuser für die Bronze- und Silberschichten und ein Lager für die Goldschicht. Diese Architektur verwendet Lagerhäuser für alle drei Ebenen, da die Daten strukturiert bleiben und mithilfe von SQL während des gesamten Prozesses transformiert werden. Lakehouses eignen sich besser für Spark-basierte Verarbeitung, Data Science-Workloads und große Mengen unstrukturierter oder semistrukturierter Daten. Eine Lakehouse-first-Implementierung, die Spark- und unstrukturierte Daten unterstützt, finden Sie unter Greenfield Lakehouse auf Microsoft Fabric.

Architecture

Laden Sie eine PowerPoint-Datei zu dieser Architektur herunter.

Im Diagramm übernimmt Mirroring die operative Datenbankreplikation, und Fabric Data Factory-Pipelines laden nicht gespiegelte Quellen in den Bronze-Pfad.

Datenfluss

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

Betriebsdatenbanken, SaaS-Anwendungen, Dateien und andere Quellsysteme erzeugen Daten.
Die Datenerfassung führt Quelldaten über zwei Wege in Fabric ein. Für unterstützte Betriebsdatenbanken repliziert Spiegelung in Fabric kontinuierlich Daten in ein gespiegeltes Datenbankelement in OneLake. Ein Warehouse-CTAS- oder INSERT ... SELECT-Schritt persistiert diese Daten dann im Bronze-Warehouse. Verwenden Sie für Dateien, SaaS-Anwendungen und andere nicht gespiegelte Quellen Fabric Data Factory-Pipelines oder Warehouse-T-SQL, wie COPY INTO, zum Laden von Bronzetabellen.
Die Bronzeschicht speichert rohe, minimal verarbeitete Daten in Lagertabellen. Aufnahmemetadaten, z. B. Ladezeitstempel und Quellbezeichner, unterstützen die Überwachung und Erneute Verarbeitung.
Die erste Transformationsphase (Bronze to silver) überprüft und transformiert Bronzedaten in die Silberschicht.
Die Silberschicht enthält gereinigte, deduplizierte und konforme Daten. Wenn eine historische Analyse erforderlich ist, speichern Tabellen der Silver-Schicht Änderungen an den Quelldaten mit Gültigkeitsdaten und Kennzeichnungen für die aktuelle Zeile.
Gespeicherte Prozeduren oder dbt-Jobs implementieren typischerweise die Phase Bronze to silver mithilfe von SQL-Mustern wie CREATE TABLE AS SELECT (CTAS), INSERT ... SELECT und MERGE.
Die Goldschicht bietet verbrauchsfertige Sternschemas, Data Marts und voraggregierte Tabellen.
In der zweiten Transformationsphase (Silver to gold) werden Silberdaten in Geschäftsentitäten, Dimensionen, Fakten und Aggregate in der Goldschicht transformiert.
Power BI verwendet Gold-Daten mithilfe semantischer Modelle. Andere Verbraucher, z. B. SQL-Clients, Notizbücher und Anwendungen, können den SQL-Warehouse-Endpunkt abfragen.

Components

Fabric Data Warehouse stellt die T-SQL-Compute- und relationalen Tabellen für die Bronze-, Silber- und Goldschichten bereit.
OneLake speichert Warehousedaten im Delta-Format sowie Daten, die durch die Fabric-Spiegelung repliziert werden.
Mirroring in Fabric repliziert unterstützte operative Datenbanken fortlaufend in OneLake.
Fabric Data Factory erfasst Daten und orchestriert gespeicherte Prozeduren, Pipelines und andere Transformationsaktivitäten.
Power BI bietet semantische Modelle, Berichte und Dashboards über kuratierte Golddaten.

Entwurfsleitfäden

In den folgenden Anleitungen wird beschrieben, wie die Bronze-, Silber- und Goldschichten implementiert und die unterstützenden Arbeitsbereiche organisiert werden. Passen Sie diese Empfehlungen an die Datenquellen und Governanceanforderungen Ihrer Workload und die Fähigkeiten Ihres Teams an.

Bronzeschicht: Erfassung von Rohdaten

Die Bronzeschicht erfasst Rohdaten und erfasst alle Quelldaten in ihrer ursprünglichen Form, ohne geschäftslogik anzuwenden. Es dient als Datensatzsystem und ermöglicht die vollständige Rückverfolgbarkeit und Neuverarbeitung. Tabellen in dieser Ebene spiegeln Quellschemas genau wieder und vermeiden absichtlich Filterung, Deduplizierung oder Anreicherung. Optionale Metadatenspalten, z. B. Zeitstempel für die Aufnahme oder Quelldateinamen, unterstützen häufig die Überwachung.

Für unterstützte Betriebsdatenbanken verwenden Sie Spiegelung in Fabric, um Quelltabellen kontinuierlich in OneLake zu replizieren. Verwenden Sie für Datei-, SaaS- oder nicht unterstützte Quellen Fabric Data Factory-Pipelines, COPY INTO für die Massenerfassung oder OPENROWSET mit CTAS oder INSERT ... SELECT, um externe Dateidaten im Bronze-Warehouse zu speichern.

In dieser Phase bleibt die Aufnahme minimal umgestaltet, sodass die Bronzeschicht das wiederverspielbare System der Aufzeichnung bleibt. Bei Bedarf für nicht gespiegelte Quellen kann eine gespeicherte Prozedur mit Bronzelast (oder ein entsprechendes DBT-Modell) eingehende Datensätze standardisieren und Lademetadaten hinzufügen.

Bewährte Methoden für die Bronzeschicht betonen, dass alle Rohdaten, einschließlich ungültiger Datensätze, beibehalten werden, dass zur Vermeidung von Problemen mit kleinen Dateien eine Batcherfassung verwendet wird, dass die Schemata eng an den Quellsystemen ausgerichtet werden und dass Workflows zur Datenerfassung mithilfe von Fabric-Pipelines automatisiert werden, um Konsistenz und Zuverlässigkeit in großem Maßstab sicherzustellen.

Silberschicht: Datenbereinigung und -konformität

Die Silberschicht konzentriert sich auf die Datenbereinigung und -konformität, indem Sie Bronzedaten durch die Anwendung von Datenqualitätsregeln, Standardisierung, Deduplizierung und Integration über mehrere Quellen hinweg verfeinern. Es erzeugt letztendlich eine einzige Quelle der Wahrheit für bereinigte und zuverlässige Daten.

In der Regel implementieren Sie Transformationen in dieser Phase mithilfe von T-SQL mithilfe von Mustern wie CREATE TABLE AS SELECT (CTAS) INSERT … SELECTund MERGE Anweisungen zur Unterstützung von Batch- und inkrementeller Verarbeitung. Während Fabric Data Warehouse keine materialisierten Ansichten unterstützt, können Sie materialisierte Seeansichten verwenden, die mithilfe von Spark implementiert werden, um Delta-Tabellen zu generieren. Der SQL-Analyseendpunkt macht diese Delta-Tabellen als Tabellen verfügbar, die das Lager lesen kann.

Bewährte Methoden für die Silberschicht umfassen, Transformationen so zu gestalten, dass sie idempotent sind, Datenqualitätsregeln konsequent durchzusetzen und MERGE für inkrementelle Updates zu verwenden. Wenn die Workload Historisierung erfordert, behalten Sie Zeilenversionen mit effektiven Anfangs- und Enddaten und einem Indikator für aktuelle Zeilen bei. Golddimensionen können diesen Verlauf verwenden, um das Verhalten von Typ 1 oder Typ 2 langsam ändernde Dimension (SCD) zu implementieren.

Goldschicht: Kuratierte Daten für Analysen

Die Goldschicht liefert kuratierte, geschäftsfähige Daten, die für Analysen, Berichte und Nutzung durch BI-Tools wie Power BI optimiert sind. Diese Ebene basiert auf analytischen Modellierungsmustern, die häufig Sternschemas mit Fakten- und Dimensionstabellen, domänenspezifischen Data marts und vorab aggregierten Zusammenfassungstabellen verwenden, um performante Abfragen und intuitive Analysen zu unterstützen.

In der Regel leiten Sie Goldtabellen ausschließlich aus Silberdaten ab und machen sie Endbenutzern und Berichterstellungstools verfügbar.

Verwenden Sie stabile Ersatzschlüssel für Dimensionen, sodass Fakten nicht von änderbaren Quellsystemschlüsseln abhängen. Fabric Data Warehouse unterstützt BIGINT IDENTITY Spalten für die Ersatzschlüsselgenerierung. Identitätswerte sind eindeutig, sind jedoch nicht garantiert sequenziell oder sortiert, und Lücken können auftreten. Wenn diese Einschränkungen für die Workload nicht geeignet sind, generieren und beibehalten Sie Ersatzschlüssel in der Transformationslogik und verwalten Sie eine dauerhafte Zuordnung zu jedem natürlichen Schlüssel. Regenerieren Sie Surrogatschlüssel bei einer vollständigen Aktualisierung nicht.

Zu den bewährten Methoden für die Goldschicht gehören, die Daten eng an Analyse- und Geschäftsanwendungsfällen auszurichten, Daten nach Möglichkeit vorzuaggregieren, um die Leistung zu verbessern, Sicherheitskontrollen wie Sicherheit auf Zeilenebene (RLS), Sicherheit auf Spaltenebene (CLS) und Datenmaskierung anzuwenden sowie Datenherkunft und Transformationen umfassend zu dokumentieren.

Arbeitsbereichsstrategie

Eine Arbeitsbereichsstrategie definiert, wie Bronze-, Silber- und Goldschichten logisch und physisch voneinander getrennt sind, um Governance, Sicherheit und betriebliche Einfachheit auszugleichen. Sie können Ebenen implementieren, indem Sie separate Arbeitsbereiche pro Ebene verwenden, die empfohlen werden, wenn starke Sicherheitsgrenzen, klare Besitzrechte oder strikte Trennung von Zuständigkeiten erforderlich sind. Sie sollten z. B. rohe Datenaufnahme von kuratierten Geschäftsdaten isolieren.

Alternativ können Sie Schichten in einem einzigen Arbeitsbereich implementieren, indem Sie separate Lager für Bronze-, Silber- und Golddaten verwenden. Dieser Ansatz kann den Verwaltungsaufwand reduzieren und die schichtübergreifende Entwicklung und Tests vereinfachen und gleichzeitig die Trennung auf Lagerebene zwischen Medallion-Schichten beibehalten.

Die Wahl zwischen diesen Ansätzen hängt in der Regel von Faktoren wie organisatorischer Skalierung, Sicherheitsanforderungen, Teamstruktur und Governance-Reife ab. Viele Unternehmen übernehmen ein Hybridmodell, da sich ihre Fabric Implementierung weiterentwickelt. Es wird empfohlen, separate Arbeitsbereiche zu verwenden, wenn Isolations-, Governance- und Besitzergrenzen erforderlich sind.

Implementierungsleitfaden

Fabric Data Warehouse bietet transaktionsübergreifende Konsistenz und zuverlässige Datenverarbeitung über die Bronze-, Silber- und Goldschichten hinweg. Verwenden Sie batchorientierte Schreibvorgänge, um Kleine Dateiprobleme zu minimieren und die Speicher- und Abfrageeffizienz zu verbessern. Verwenden Sie MERGE-Anweisungen, um verspätet eintreffende oder geänderte Daten in Szenarien der inkrementellen Verarbeitung zu behandeln.

Halten Sie Transaktionen kurzlebig, um die Koncurrität zu reduzieren und die Parallelität zu optimieren, insbesondere in Umgebungen mit hoher Aufnahme. Überwachen Sie die Leistung und den Betriebszustand aktiv, indem Sie Fabric Abfrageeinblicke und dynamische Verwaltungsansichten (DYNAMIC Management Views, DMVs) verwenden. Die architektonische Trennung von Lese- und Schreibworkloads in Fabric ermöglicht zudem, dass Erfassungs- und Transformationsaufträge gleichzeitig ausgeführt werden können, ohne analytische Abfragen zu blockieren, und sorgt so für eine vorhersehbare Leistung bei nachgelagerten Analysen und Berichten.

Verwenden Sie gespeicherte T-SQL-Prozeduren und Fabric Data Factory-Pipelines für die native SQL-Transformation und -Orchestrierung. Teams, die modulare SQL-Modelle und -Tests bevorzugen, können den Microsoft verwalteten DBT-Adapter für Fabric Data Warehouse verwenden. Führen Sie Eindeutigkeits-, referenzielle Integritäts- und Akzeptiert-Wert-Tests als Bereitstellungs- oder Pipelinetore aus, bevor Sie Daten auf downstream-Ebenen veröffentlichen.

Alternatives

Diese Architektur umfasst mehrere Komponenten, die Sie je nach den funktionalen und nichtfunktionellen Anforderungen Ihrer Workload durch andere Azure-Dienste oder -Ansätze ersetzen können. Betrachten Sie die folgenden Alternativen und ihre Kompromisse.

Für Szenarien, die groß angelegte Datentechnik, erweiterte Analysen, maschinelles Lernen oder unstrukturierte Daten hervorheben, kann eine Lakehouse-first-Architektur auf Microsoft Fabric besser passen. Bei diesem Ansatz dient ein Fabric Lakehouse als primärer Datenspeicher in OneLake, und Transformationen werden in erster Linie mithilfe von Spark-basierten Tools wie Notizbüchern oder Dataflow Gen2 implementiert. Dieses Muster stellt die verteilte Datenverarbeitung, Notebook-Umgebungen und Werkzeuge für maschinelles Lernen bereit, die nicht im Mittelpunkt dieser SQL-first-Warehouse-Architektur stehen.

Für Organisationen mit starkem Fokus auf Data Science, KI oder komplexe verteilte Verarbeitung ist Azure Databricks eine weitere Alternative. Azure Databricks wird in der Regel ausgewählt, wenn Workloads eine umfassende Integration in Open-Source-Frameworks für maschinelles Lernen erfordern, eine differenzierte Kontrolle über Spark-Ausführung oder multicloud-Portabilität.

Bei nahezu echtzeit- oder ereignisgesteuerten Analysen sind Fabric Real-Time Intelligence, Azure Event Hubs oder Azure Stream Analytics möglicherweise besser geeignet als ein batchorientiertes Medallion-Design, das auf Fabric Data Warehouse ausgerichtet ist.

Szenariodetails

Fabric Data Warehouse eignet sich sehr gut für diese Medallion-Architektur, wenn das primäre Ziel darin besteht, governance-konforme, analysebereite Daten im großen Maßstab mithilfe vertrauter SQL-Muster bereitzustellen.

Szenario 1: Relationale Semantik und SQL-Leistung für kuratierte, analysebereite Datasets

Fabric Data Warehouse eignet sich gut, da sie relationale Tabellen und Ansichten, ACID-Transaktionen und T-SQL-Vorgänge über Delta-Daten bereitstellt. Dieser Featuresatz unterstützt Workloads, bei denen Daten bereits bereinigt und konform sind und konsistent über SQL abgefragt werden müssen.

Beispiel: Eine Fluggesellschaft erstellt kuratierte Gold-Datasets für Flugbetriebs- und Umsatzanalysen. Analysten sind auf eine stabile Leistung von SQL-Abfragen angewiesen, um Pünktlichkeitstrends, die Streckenrentabilität und die Crew-Auslastung zu bewerten. Die Verwendung von Lagertabellen und -ansichten gewährleistet transaktionsbezogene Konsistenz und zuverlässiges Abfrageverhalten, was mit ad-hoc dateibasiertem Zugriff schwieriger zu gewährleisten ist.

Szenario 2: Zentrale Governance mit einer SQL-ersten Erfahrung

Fabric Data Warehouse ermöglicht eine zentrale Governance durch Arbeitsbereichsberechtigungen, Sicherheit auf Objektebene und integrierte Linien, während Daten über eine SQL-Schnittstelle verfügbar sind, die den Analyse-Entwicklungsteams vertraut ist. Dieser Ansatz reduziert operative Reibungsverluste, vereinfacht die Zugriffssteuerung und beschleunigt die teamübergreifende Einführung, ohne neue Zugriffsparadigmen einzuführen.

Beispiel: Ein globales Unternehmen erzwingt strikte Trennung von Aufgaben: Plattformteams verwalten Aufnahme und Transformationen, und Analyseteams nutzen nur kuratierte Daten. Durch die Bereitstellung nur Goldschichttabellen über ein Lagerhaus und die Zentralverwaltung des Zugriffs verhindert die Organisation den unkontrollierten Zugriff auf Rohdaten oder Zwischendaten, während ein vertrauter SQL-basierter Workflow beibehalten wird.

Szenario 3: BI-optimierter Verbrauch für Berichte und Dashboards

Das Data Warehouse ist für hohe Parallelität und leselastige Workloads optimiert und daher eine gute Wahl, wenn zahlreiche Geschäftsanwender Dashboards und Berichte nutzen, die auf konsistenten semantischen Modellen basieren. Diese Optimierung ist besonders wichtig, wenn Leistung, Stabilität und vorhersehbares Abfrageverhalten während der Spitzenauslastung erforderlich sind.

Beispiel: Finanz- und Betriebsteams greifen während der Geschäftszeiten auf Power BI Dashboards zu, um KPIs wie Umsatz, betriebliche Effizienz und SLA-Compliance zu überwachen. Fabric Data Warehouse isoliert SELECT und Nicht-SELECT-Workloads in separate Compute-Pools, wodurch direkte Konflikte zwischen Dashboardabfragen und der Data-Warehouse-Erfassung reduziert werden.

Szenario 4: Dimensionale Modellierungsunterstützung für eine wiederverwendbare Goldschicht

Fabric Data Warehouse passt gut zu dimensionalen Datenmodellierungsmustern, einschließlich Fakten- und Dimensionstabellen, die Sie in der Goldschicht häufig verwenden, um geschäftsorientierte, wiederverwendbare Datensätze bereitzustellen. Diese Modelle vereinfachen Analysen, reduzieren die Logikduplizierung und fördern konsistente Metrikdefinitionen in allen Teams.

Beispiel: Eine Einzelhandelsorganisation erstellt gemeinsam genutzte Dimensionstabellen für Kunden, Produkte und Filialen sowie Faktentabellen für Vertrieb und Bestand. Diese Gold-Datasets werden in mehreren Power BI Berichten und Geschäftseinheiten wiederverwendet, um sicherzustellen, dass KPIs wie Nettoumsatz oder Bestandsumsatz einmal definiert und konsistent angewendet werden.

Considerations

Diese Überlegungen implementieren die Säulen des Azure Well-Architected Frameworks, bei dem es sich um eine Reihe von Leitsätzen handelt, die Sie verwenden können, um die Qualität einer Arbeitsauslastung zu verbessern.

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 in der Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Lesen Sie Zuverlässigkeit in Microsoft Fabric, um sich über das dokumentierte Resilienzmodell einschließlich des Verhaltens bei Ausfall einer Zone und regionaler Aspekte zu informieren. Überprüfen Sie die Erwartungen an die Wiederherstellung anhand dieser Anleitungen für Ihre Region und Ihre Workloadanforderungen.

Entwerfen und dokumentieren Sie für regionenübergreifende Notfallwiederherstellungsszenarien eine Wiederherstellungsstrategie, die den Organisationsanforderungen und dem Modell der gemeinsamen Verantwortung entspricht.

Fabric Data Warehouse unterstützt PRIMARY KEY, FOREIGN KEYund UNIQUETabelleneinschränkungen nur als NOT ENFORCED. Das Warehouse validiert weder Eindeutigkeit noch referenzielle Integrität. Aufnahme- und Transformationslogik muss doppelte oder verwaiste Datensätze erkennen und verhindern, dass sie nachgelagerte Ebenen erreichen.

Security

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie in der Prüfliste zur Entwurfsüberprüfung für Sicherheit.

Microsoft Fabric bietet Funktionen zum Verwalten, Steuern und Überwachen von Sicherheitseinstellungen basierend auf organisatorischen Anforderungen. Berücksichtigen Sie die folgenden Sicherheitspraktiken:

Verwenden Sie Microsoft Entra ID einmaliges Anmelden (Single Sign-On, SSO), um Benutzer zu authentifizieren und eine konsistente Identitätsverwaltung auf allen Geräten und Standorten bereitzustellen.
Wenden Sie arbeitsbereichbasierte Berechtigungen an, um zu steuern, wer Fabric Artefakte erstellen, ändern oder nutzen kann.
Verwenden Sie die Fabric-Netzwerksicherheitskontrollen für eingehenden und ausgehenden Datenverkehr, wenn Sie auf Daten oder Dienste innerhalb oder außerhalb Ihres Netzwerks zugreifen. Zu diesen Steuerelementen gehören bedingter Zugriff, private Links, vertrauenswürdiger Arbeitsbereichzugriff und verwaltete private Endpunkte.
Verwenden Sie Fabric Überwachungsprotokolle, um Benutzeraktivitäten, Konfigurationsänderungen und Datenzugriff auf die gesamte Plattform nachzuverfolgen.

Weitere Informationen finden Sie unter Sicherheit in Fabic.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie in der Prüfliste für die Entwurfsüberprüfung für die Kostenoptimierung.

Microsoft Fabric bietet Kapazitätsreservierungen für eine definierte Anzahl von Kapazitätseinheiten (CUs). Einjährige Reservierungen können dazu beitragen, die Kosten für vorhersagbare, stabile Arbeitslasten zu reduzieren.

Um Fabric Kapazitätsauslastung zu maximieren, sollten Sie die folgenden Methoden berücksichtigen:

Beginnen Sie mit Testkapazitäten oder pay-as-you-go F-SKUs , um das Arbeitsauslastungsverhalten zu verstehen. Führen Sie eine abgegrenzte Machbarkeitsstudie mit repräsentativen Datenaufnahme-, Transformations- und Reporting-Workloads durch. Überwachen Sie den CU-Verbrauch und extrapolieren Sie die Ergebnisse, um den Produktionsbedarf zu schätzen. Sie können Fabric-Kapazitäten mit steigender Nachfrage skalieren.
Analysieren Sie die historische Verwendung, um Spitzen- und Off-Peak-Zeiträume zu identifizieren. Planen Sie unkritische oder Hintergrundarbeitslasten in Zeiten geringerer Auslastung, um den anhaltenden CU-Druck zu reduzieren.
Reduzieren Sie die unnötige Berechnungsnutzung, indem Sie SQL-Abfragen, Datenanalyseausdrücke (DATA Analysis Expressions, DAX) und Hintergrundaufträge optimieren.
Fabric unterstützt das Abfangen von Lastspitzen und die Lastglättung, um kurzfristige Spitzen im Rechenbedarf zu absorbieren und den Ressourcenverbrauch von Hintergrundworkloads über die Zeit zu verteilen. Diese Funktionen helfen dabei, Kapazitäten für die durchschnittliche Auslastung statt für den Spitzenbedarf zu dimensionieren. Weitere Informationen finden Sie unter Auswerten und Optimieren der Microsoft Fabric-Kapazität.
Stimmen Sie lang andauernde Transformationen und Aktualisierungsvorgänge aufeinander ab, um sich überschneidende rechenintensive Workloads auf derselben Kapazität zu vermeiden. Weitere Informationen finden Sie unter Workload-Verwaltung in Fabric Data Warehouse.

Beachten Sie die folgenden Preisüberlegungen:

OneLake-Speichervolume, Aufbewahrungszeitraum und Datenzugriffsmuster wirken sich direkt auf die Gesamtkosten aus. Schätzen Sie das erwartete Datenwachstum pro Medallion-Ebene und richten Sie die Aufbewahrung an geschäfts- und Complianceanforderungen aus.
Microsoft Fabric Preise basieren auf einer zugewiesenen F-Kapazität, gemessen in CUs. Power BI lizenzen pro Benutzer sind getrennt und stellen keine Fabric Kapazität bereit.

Verwenden Sie die voreingestellte Schätzung im Azure Preisrechner, um eine Startkosten für diese Architektur zu erhalten. Passen Sie die Werte an Ihre erwartete Arbeitsauslastung an.

Operative Exzellenz

Operational Excellence deckt die betrieblichen Prozesse ab, die eine Arbeitsauslastung in der Produktion bereitstellen, überwachen und verwalten. Weitere Informationen finden Sie in der Prüfliste für die Designüberprüfung für Operational Excellence.

Microsoft Fabric bietet integrierte Betriebstransparenz über Datentechnik-, Data-Warehousing- und Analyseworkloads hinweg. Verwenden Sie die App Fabric Kapazitätsmetriken, um den Kapazitätsverbrauch zu überwachen, ressourcenintensive Artefakte zu identifizieren und zu verstehen, wie interaktive und Hintergrundworkloads zur Gesamtauslastung beitragen. Diese Erkenntnisse helfen Teams dabei, fundierte operative Entscheidungen über Skalierung, Planung und Optimierung zu treffen.

Richten Sie proaktive Warnungen ein, damit Kapazitätsadministratoren eine hohe Auslastung oder Drosselungszustände frühzeitig erkennen und darauf reagieren können, bevor Benutzer beeinträchtigt werden.

Leistungseffizienz

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

Microsoft Fabric umfasst mehrere Mechanismen zur Verwaltung der Leistung und Der Kapazitätsauslastung:

Bursting und Glättung ermöglichen es, kurzfristige Spitzen im Rechenbedarf schneller zu bewältigen und die Nutzung gleichzeitig über die Zeit zu verteilen. Interaktive Vorgänge werden in der Regel über Minuten reibungslos ausgeführt, und Hintergrundvorgänge werden über längere Fenster reibungslos ausgeführt.
Drosselung wird angewendet, wenn eine Kapazität eine dauerhafte Berechnungsauslastung erlebt, die über den Grenzwerten der zugewiesenen SKU liegt. Die Drosselung verzögert oder lehnt neue Vorgänge ab, um die Plattformstabilität zu schützen.
Die app Fabric Kapazitätsmetriken bietet detaillierte Einblicke in den Kapazitätsverbrauch und unterscheidet zwischen interaktiven Vorgängen (z. B. Berichtsabfragen) und Hintergrundvorgängen (z. B. Aufnahme oder Modellaktualisierung). Diese Unterscheidung ermöglicht gezielte Leistungsoptimierungen für verschiedene Workloadtypen.

Beitragende

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

Prabhjot Kaur | Senior Cloud Solution Architect

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

Nächste Schritte

Feedback

War diese Seite hilfreich?