Handbuch

Abfragen einer massiven (über 500 Millionen Zeilen) Delta-Tabelle in einem Fabric Lakehouse mit optimaler Leistung und nahezu Echtzeit-Datenzugriff.

→Verwenden Sie ein semantisches Modell im Direct Lake-Modus.

Warum: Direct Lake liest Parquet-Dateien direkt aus OneLake, wodurch Datenimport oder Abfrageübersetzung umgangen werden. Es bietet eine importähnliche Leistung ohne Datenreplikation oder Aktualisierungslatenz. DirectQuery ist langsamer; der Importmodus führt zu Latenzzeiten.

Anwenden gängiger Zeitintelligenz-Berechnungen (YTD, QTD, MTD) auf Dutzende von Basis-Measures (Umsatz, Gewinn, Menge), ohne Hunderte von DAX-Measures erstellen zu müssen.

→Implementieren Sie eine Berechnungsgruppe mit Berechnungselementen für YTD, QTD und MTD.

Warum: Berechnungsgruppen eliminieren die Ausbreitung von Measures. Sie definieren einen Satz generischer Berechnungen, die dynamisch auf jedes ausgewählte Measure angewendet werden können, wodurch die Modellwartung drastisch vereinfacht wird.

Mehrere semantische Modelle in einem Arbeitsbereich müssen gemeinsame Dimensionstabellen (z. B. Datum, Kunde) teilen, um Konsistenz zu gewährleisten und Datenredundanz zu reduzieren.

→Erstellen Sie ein "Kern"-semantisches Modell, das die gemeinsamen Dimensionen enthält. Erstellen Sie andere "zusammengesetzte" Modelle, die über DirectQuery mit dem Kernmodell und über Direct Lake/Import mit Faktentabellen verbunden sind.

Warum: Diese "Hub-and-Spoke"-Architektur fördert eine einzige Quelle der Wahrheit für Dimensionen. Zusammengesetzte Modelle ermöglichen die Kombination von Daten aus verschiedenen Quellen und Speichermodi in einem einheitlichen Modell.

Eine Faktentabelle hat mehrere Datumsspalten (z. B. OrderDate, ShipDate), die alle mit einer einzigen Datumsdimensionstabelle in Beziehung stehen müssen.

→Erstellen Sie eine aktive Beziehung und mehrere inaktive Beziehungen zwischen den Fakten- und Datumstabellen. Verwenden Sie die DAX-Funktion `USERELATIONSHIP()` in Measures, um die entsprechende inaktive Beziehung zu aktivieren.

Warum: Power BI erlaubt nur eine aktive Beziehung zwischen zwei Tabellen. Dieses Muster ermöglicht die Analyse nach verschiedenen Datumsrollen, ohne die Dimensionstabelle zu duplizieren.

Ein semantisches Modell mit einer großen Faktentabelle (Milliarden von Zeilen) benötigt zu lange zum Aktualisieren. Nur die Daten der letzten 30 Tage ändern sich häufig.

→Konfigurieren Sie die inkrementelle Aktualisierung für die Faktentabelle. Legen Sie die Parameter `RangeStart` und `RangeEnd` fest. Definieren Sie eine Richtlinie zum Archivieren alter Daten (z. B. Speichern der letzten 5 Jahre) und zum Aktualisieren neuer Daten (z. B. Aktualisieren der letzten 30 Tage).

Warum: Dies reduziert die Aktualisierungszeit und den Ressourcenverbrauch drastisch, indem nur Partitionen mit neuen oder geänderten Daten verarbeitet werden, anstatt die gesamte Tabelle neu zu laden.

Ein komplexes DAX-Measure ist langsam, da es innerhalb seiner Formel wiederholt denselben Zwischenwert berechnet.

→Verwenden Sie Variablen (`VAR`), um das Ergebnis der Zwischenberechnung einmal zu speichern, und verweisen Sie dann mehrmals in der `RETURN`-Anweisung auf die Variable.

Warum: Variablen verhindern, dass die Engine dieselbe Logik innerhalb einer einzigen Measure-Ausführung mehrmals neu bewertet, was die Leistung erheblich verbessert, insbesondere in iterativen Kontexten.

Erstellen eines Measures zur Berechnung des Beitragsanteils eines Werts (z. B. Produktumsatz) zu einem größeren Gesamtbetrag (z. B. aller Produktumsätze), unter Berücksichtigung anderer Filter (wie Datum).

→Verwenden Sie `DIVIDE([Sales], CALCULATE([Sales], ALLEXCEPT(Product, Product[Category])))` für den Prozentsatz der Kategorie oder `CALCULATE([Sales], ALL(Product))` für den Prozentsatz des Gesamtbetrags.

Warum: `CALCULATE` in Kombination mit `ALL`, `ALLEXCEPT` oder `REMOVEFILTERS` ermöglicht es Ihnen, den Filterkontext zu ändern, um den korrekten Nenner für die Prozentberechnung zu erhalten.

Ein Bericht benötigt einen Slicer, der es Benutzern ermöglicht, auszuwählen, welche Metrik (z. B. "Umsatz", "Kosten", "Gewinn") ein Visual anzeigen soll.

→Erstellen Sie eine getrennte Tabelle mit den Metriknamen. Erstellen Sie ein einzelnes DAX-Measure mit `SWITCH(SELECTEDVALUE(MetricTable[Metric]), "Revenue", [Total Revenue], "Cost", [Total Cost], ...)`.

Warum: Dieses Muster, oft unter Verwendung eines Feldparameters, bietet eine dynamische und benutzerfreundliche Möglichkeit, Berechnungen zu wechseln, ohne Lesezeichen oder mehrere Visuals zu benötigen, wodurch Berichte interaktiver und prägnanter werden.

Ein Enterprise-BI-Team muss professionelle Tools (wie Visual Studio, Tabular Editor, SQL Profiler) verwenden, um ein Fabric-semantisches Modell zu verwalten, bereitzustellen und Fehler zu beheben.

→Aktivieren Sie den XMLA-Lese-/Schreibendpunkt für den Arbeitsbereich.

Warum: Der XMLA-Endpunkt stellt das semantische Modell als eine Standard-Analysis Services-Instanz bereit und ermöglicht die Konnektivität von einem breiten Ökosystem fortschrittlicher BI- und ALM-Tools für den programmatischen Zugriff und komplexe Modellierungsaufgaben.

Ein Direct Lake-Modell arbeitet langsam. Untersuchungen zeigen, dass es in den DirectQuery-Modus zurückfällt.

→Verwenden Sie DAX Studio oder Performance Analyzer, um die Abfrage zu identifizieren, die den Fallback verursacht. Häufige Ursachen sind nicht unterstützte DAX-Funktionen, komplexe RLS oder ein unoptimiertes/veraltetes Lakehouse.

Warum: Direct Lake hat Einschränkungen. Wenn eine Abfrage eine nicht unterstützte Funktion verwendet, fällt sie stillschweigend auf die langsamere DirectQuery-Engine zurück. Die Identifizierung und Behebung der Ursache (z. B. Optimierung von DAX, Ausführen von OPTIMIZE auf der Delta-Tabelle) ist entscheidend für die Wiederherstellung der Leistung.

Ein Modell hat eine Many-to-Many-Beziehung (z. B. Verkäufe und Aktionen über eine Brückentabelle). Measures liefern falsche Gesamtsummen, wenn nach der "Many"-Seite gefiltert wird.

→Stellen Sie sicher, dass die Kreuzfilterrichtung der Beziehungen (Dimension -> Brücke -> Fakt) korrekt eingestellt ist (typischerweise unidirektional). Verwenden Sie bei Bedarf DAX-Funktionen wie `TREATAS` oder `INTERSECT` für komplexere M2M-Berechnungen.

Warum: Eine falsche Kreuzfilterrichtung ist eine häufige Ursache für falsche Ergebnisse in M2M-Modellen. Während bidirektionales Filtern scheinbar funktioniert, führt es oft zu Mehrdeutigkeiten und doppelter Zählung. Ein gut definiertes Modell mit expliziten DAX-Mustern ist robuster.

Ein zusammengesetztes Modell, das DirectQuery für eine massive Faktentabelle verwendet, ist langsam. Die meisten Benutzerabfragen erfolgen auf einer aggregierten Ebene (z. B. monatliche Verkäufe nach Kategorie).

→Erstellen Sie eine benutzerdefinierte Aggregationstabelle im Importmodus. Die Aggregationstabelle sollte vorab zusammengefasste Daten auf der Ebene gängiger Abfragen (Monat, Kategorie) enthalten.

Warum: Die Abfrage-Engine leitet Abfragen, wenn möglich, automatisch an die kleinere, im Speicher befindliche Aggregationstabelle um, was massive Leistungssteigerungen ermöglicht. Sie greift nur für Abfragen, die eine geringere Detaillierung erfordern, auf die DirectQuery-Quelle zu.

Berechnung komplexer gleitender Summen oder gleitender Durchschnitte in DAX, die mit herkömmlichen filterbasierten Ansätzen schlecht funktionieren.

→Verwenden Sie DAX-Fensterfunktionen wie `WINDOW` oder `OFFSET`.

Warum: Diese Funktionen sind speziell für Positionsberechnungen über eine sortierte Menge von Zeilen optimiert. Sie sind oft leistungsfähiger und syntaktisch einfacher als ältere Muster, die auf starkes Filtern und Kontextübergänge angewiesen sind.

Berechnung von Year-to-Date (YTD)-Gesamtsummen für ein Unternehmen mit einem Geschäftsjahr, das am 1. Juli beginnt.

→Verwenden Sie die Funktionen `TOTALYTD` oder `DATESYTD` mit dem optionalen Parameter `YearEndDate`. Beispiel: `TOTALYTD([Sales], 'Date'[Date], "6/30")`.

Warum: Die Angabe des Jahresenddatums als Parameter ist der korrekte und einfachste Weg, DAX-Zeitintelligenzfunktionen für den benutzerdefinierten Geschäftsjahreskalender nutzbar zu machen.

Bewerbung eines semantischen Modells über Entwicklungs-, Test- und Produktionsphasen hinweg, wobei jede Phase eine andere Datenbankverbindungszeichenfolge hat.

→Verwenden Sie Fabric-Bereitstellungspipelines mit Bereitstellungsregeln.

Warum: Bereitstellungsregeln automatisieren die Änderung von Datenquellenverbindungen, Parametern und anderen Einstellungen für jede Umgebung. Dies vermeidet manuelle, fehleranfällige Änderungen nach der Bereitstellung.

Referenz↗

Implementierung einer dezentralen Data-Mesh-Architektur, bei der Geschäftsbereiche ihre eigenen Datenprodukte besitzen und verwalten.

→Erstellen Sie domänenspezifische Arbeitsbereiche. Verwenden Sie OneLake-Shortcuts, um den datenübergreifenden Datenaustausch und -verbrauch zu ermöglichen, ohne die Datenhoheit zu zentralisieren.

Warum: Dieses Muster entspricht den Data-Mesh-Prinzipien der Domänenverantwortung und Daten-als-Produkt. Arbeitsbereiche bilden die Grenze für die Eigentümerschaft, während Shortcuts die Interoperabilitätsschicht bereitstellen.

Ein Entwicklerteam muss an Fabric-Elementen (semantische Modelle, Berichte, Notebooks) mit Quellcodeverwaltung und Versionshistorie zusammenarbeiten.

→Konfigurieren Sie die Git-Integration für den Fabric-Arbeitsbereich und verbinden Sie ihn mit einem Azure DevOps- oder GitHub-Repository.

Warum: Die Git-Integration speichert Fabric-Elementdefinitionen als Textdateien (JSON, TMDL) und ermöglicht so standardmäßige DevOps-Praktiken wie Branching, Pull Requests und Versionsverfolgung. Dies ist entscheidend für das Application Lifecycle Management (ALM) auf Unternehmensebene.

Bevor ein Techniker eine Lakehouse-Tabelle ändert, muss er alle nachgelagerten Berichte und semantischen Modelle identifizieren, die betroffen sein werden.

→Verwenden Sie die Lineage View und wählen Sie "Auswirkungsanalyse" für das Lakehouse-Element aus.

Warum: Diese Funktion bietet eine vollständige, automatisierte Ansicht aller Abhängigkeiten. Sie ist ein kritisches Governance-Tool für die Verwaltung von Änderungen in einer komplexen Analyseumgebung, das unerwartete Ausfälle verhindert.

Ein Team muss ein semantisches Modell in einem textbasierten, menschenlesbaren Format versionieren, das einfach zu diffen und zusammenzuführen ist.

→Speichern Sie die Power BI-Datei als Power BI-Projekt (.pbip). Dies speichert die Modelldefinition im Format der Tabular Model Definition Language (TMDL).

Warum: TMDL ist ein entwicklerfreundliches Format, das das Modell als Ordnerstruktur mit einzelnen Textdateien für Tabellen, Measures usw. darstellt. Dies ist der binären .bim-Datei für die Git-basierte Zusammenarbeit und CI/CD weit überlegen.

Implementierung einer Medaillon-Architektur (Bronze, Silver, Gold) und der Notwendigkeit, auf Daten über Schichten hinweg ohne physische Datenverdopplung zuzugreifen.

→Verwenden Sie OneLake-Shortcuts, um auf Daten in anderen Lakehouses oder Schichten zu verweisen.

Warum: Shortcuts sind symbolische Links in OneLake. Sie bieten einen einheitlichen Namensraum und ermöglichen den Zugriff auf Daten ohne Kopieren, was ideal für ein logisches Data Mesh oder eine Medaillon-Architektur ist.

Referenz↗

Migration einer bestehenden, T-SQL-lastigen Analyse-Workload von Azure Synapse zu Fabric.

→Verwenden Sie ein Fabric Data Warehouse.

Warum: Das Fabric Warehouse bietet volle T-SQL-Kompatibilität und ist somit das ideale Ziel für die Migration bestehender SQL-Skripte, gespeicherter Prozeduren und Analystenabfragen mit minimalen Änderungen. Der Lakehouse SQL-Endpunkt hat schreibgeschützten T-SQL-Zugriff und verwendet Spark SQL für Schreibvorgänge.

Erfassen und Abfragen von hochvolumigen, hochfrequenten Streaming-Daten (z. B. IoT-Telemetrie) mit Latenzzeiten im Sub-Sekundenbereich.

→Verwenden Sie Fabric Eventstream für die Erfassung und eine KQL-Datenbank für Speicherung und Analyse.

Warum: Dies ist der speziell für Streaming-Analysen entwickelte Stack in Fabric. KQL (Kusto Query Language) ist für die Zeitreihenanalyse von Streaming-Daten optimiert und bietet eine wesentlich geringere Latenz als Batch-orientierte Lakehouses oder Warehouses.

Implementierung von Slowly Changing Dimension (SCD) Typ 2, um eine vollständige Historie von Dimensionsänderungen in einem Lakehouse zu pflegen.

→Verwenden Sie eine `MERGE INTO`-Anweisung in einem Spark-Notebook oder einer Pipeline. Gleichen Sie den Geschäftsschlüssel ab; `WHEN MATCHED` aktualisiert den alten Datensatz (setzt `IsCurrent` auf false, `EndDate` auf jetzt); `WHEN NOT MATCHED` fügt den neuen Datensatz ein.

Warum: Die `MERGE`-Operation von Delta Lake bietet atomare Upsert-Funktionen, was sie zur Standard- und effizientesten Methode zur Implementierung von SCD-Logik in einem Fabric Lakehouse macht.

Replikation von Daten nahezu in Echtzeit aus einer operativen Datenbank (z. B. Azure SQL DB) in ein Fabric Lakehouse für Analysen.

→Verwenden Sie Fabric Mirroring.

Warum: Mirroring ist eine in Fabric integrierte CDC-Lösung (Change Data Capture) mit geringer Latenz und geringem Impact. Es repliziert Daten- und Schemaänderungen automatisch in OneLake als Delta-Tabellen, wodurch die Notwendigkeit komplexer ETL-Pipelines entfällt.

Erfassen und Transformieren komplexer, verschachtelter JSON-Daten aus einer API in eine abgeflachte, strukturierte Delta-Tabelle.

→Verwenden Sie ein PySpark-Notebook. Verwenden Sie Funktionen wie `from_json` zum Parsen des Schemas und `explode` zum Abflachen von Arrays in Zeilen.

Warum: PySpark bietet die leistungsstärksten und flexibelsten Tools zur programmatischen Handhabung komplexer und sich entwickelnder JSON-Strukturen, weit über die Fähigkeiten einer Standard-Kopieraktivität hinaus.

Erfassen von Daten in Fabric aus einer lokalen SQL Server-Datenbank, die sich hinter einer Unternehmensfirewall befindet.

→Installieren und konfigurieren Sie ein lokales Datengateway auf einem Server innerhalb des lokalen Netzwerks. Fügen Sie das Gateway als Datenquelle in Fabric hinzu.

Warum: Das Gateway fungiert als sichere Brücke, die Abfragen und Daten zwischen Fabric-Cloud-Diensten und lokalen Datenquellen weiterleitet, ohne dass eingehende Firewall-Ports geöffnet werden müssen.

Die Abfrageleistung einer großen, häufig aktualisierten Delta-Tabelle hat sich aufgrund der Ansammlung vieler kleiner Datendateien verschlechtert.

→Führen Sie den Befehl `OPTIMIZE` aus, um kleine Dateien zu größeren zu verdichten. Verwenden Sie optional `ZORDER BY` für häufig gefilterte Spalten, um verwandte Daten zusammenzufassen.

Warum: Weniger, größere Dateien sind für Spark wesentlich effizienter zu lesen. Die Z-Sortierung verbessert das Überspringen von Daten, wodurch Abfragen noch weniger Daten lesen können. Dies ist eine kritische Wartungsaufgabe für Delta-Tabellen.

Aggregieren von Streaming-Zeitreihendaten in feste, nicht überlappende Zeitintervalle (z. B. Durchschnittstemperatur pro Sensor alle 5 Minuten).

→Verwenden Sie eine KQL-Abfrage mit dem Operator `summarize` und der Funktion `bin()`. Beispiel: `SensorData | summarize avg(temperature) by sensor_id, bin(timestamp, 5m)`.

Warum: Die Funktion `bin()` ist in KQL die standardmäßige, hochoptimierte Methode, um Ereignisse für die Aggregation in feste Zeitfenster (Tumbling Windows) zu gruppieren.

Die Aktualisierung eines Dataflow Gen2 ist langsam. Die Datenquelle ist eine relationale Datenbank wie Azure SQL.

→Überprüfen Sie die Transformationsschritte im Power Query-Editor, um sicherzustellen, dass Query Folding aktiv ist. Ordnen oder ändern Sie Schritte, um das Folding zu maximieren.

Warum: Query Folding verschiebt die Transformationslogik zurück zur Quelldatenbank, um als einzelne native Abfrage ausgeführt zu werden. Dies ist wesentlich effizienter, als alle Rohdaten in die Dataflow-Engine zu ziehen und sie im Speicher zu transformieren.

Ein Spark-Notebook führt einen langsamen Join zwischen einer sehr großen Faktentabelle (Milliarden von Zeilen) und einer kleinen Dimensionstabelle (Tausende von Zeilen) durch.

→Verwenden Sie einen Broadcast-Join, indem Sie einen Hinweis (`spark.sql.functions.broadcast`) geben oder den Optimierer basierend auf Statistiken auswählen lassen.

Warum: Broadcasting sendet die gesamte kleine Tabelle an jeden Executor-Knoten. Dies vermeidet einen kostspieligen "Shuffle"-Vorgang, bei dem die Daten der großen Tabelle neu partitioniert und über das Netzwerk gesendet werden müssen, was die Leistung drastisch verbessert.

Eine Datenpipeline orchestriert mehrere Aktivitäten. Eine Aktivität kann fehlschlagen, aber nachfolgende, unabhängige Aktivitäten sollten weiterhin ausgeführt werden, und der Gesamtfehler sollte protokolliert werden.

→Konfigurieren Sie Aktivitätenabhängigkeiten. Aktivitäten, die unabhängig vom Ergebnis ausgeführt werden sollen, sollten von der vorherigen Aktivität mit der Bedingung "Abschluss" abhängen.

Warum: Dies ermöglicht den Aufbau robuster, paralleler Ausführungspfade. Sie können separate Branches für "Erfolgreich" und "Fehlgeschlagen" Bedingungen erstellen, um benutzerdefinierte Protokollierungs- oder Benachrichtigungslogik zu implementieren.

Eine Pipeline zum inkrementellen Laden von Daten aus einer Quelle mit einem `last_modified`-Zeitstempel.

→Implementieren Sie ein Wasserzeichen-Muster. Speichern Sie den `max(last_modified)` des letzten erfolgreichen Laufs. Fragen Sie beim nächsten Lauf die Quelle nach Datensätzen ab, bei denen `last_modified` größer als das gespeicherte Wasserzeichen ist.

Warum: Dies ist das effizienteste Muster für inkrementelle Ladevorgänge aus Quellen, die einen Änderungszeitstempel bereitstellen, wodurch sichergestellt wird, dass nur neue oder aktualisierte Daten verarbeitet werden, was Datenübertragung und Rechenaufwand minimiert.

Analysieren Sie einen Echtzeitstrom von IoT-Daten, um ungewöhnliche Spitzen oder Einbrüche bei Sensorwerten zu erkennen.

→Verwenden Sie die Funktion `series_decompose_anomalies()` in einer KQL-Abfrage innerhalb einer Eventhouse/KQL-Datenbank.

Warum: Diese integrierte KQL-Funktion wurde speziell für die Anomalieerkennung in Zeitreihen entwickelt. Sie zerlegt die Reihe automatisch in saisonale, Trend- und Restkomponenten, um statistisch signifikante Ausreißer zu identifizieren, was nur minimale manuelle Konfiguration erfordert.

Daten aus einem Warehouse, einem Lakehouse und einer gespiegelten Azure SQL-Datenbank in einer einzigen T-SQL-Abfrage verknüpfen müssen, ohne Daten zu verschieben.

→Verwenden Sie dreiteilige Namenskonventionen (`database.schema.table`) in einer Abfrage, die vom Warehouse- oder Lakehouse SQL-Endpunkt ausgeführt wird. Verwenden Sie Shortcuts, um auf die gespiegelte Datenbank zu verweisen.

Warum: Fabric bietet eine vereinheitlichte Abfrage-Engine, die über verschiedene Fabric-Elemente innerhalb desselben Arbeitsbereichs mit einer einzigen SQL-Anweisung auf Daten zugreifen kann, was die Datenvirtualisierung ermöglicht.

Ein Dataflow muss eine Datei verarbeiten, in der einige Zeilen ungültig sein können. Der gesamte Flow sollte nicht fehlschlagen; gültige Zeilen sollten geladen und ungültige Zeilen protokolliert werden.

→Fügen Sie in Power Query einen Schritt hinzu, um Zeilen zu validieren und eine Spalte "IsValid" zu erstellen. Erstellen Sie dann von diesem Punkt aus zwei Referenzabfragen: eine, die nach `IsValid = true` filtert, um in das Ziel zu laden, und eine weitere, die nach `IsValid = false` filtert, um in ein Fehlerprotokoll zu laden.

Warum: Dieses Muster bietet eine robuste Fehlerbehandlung durch Aufteilung des Datenstroms. Es verhindert, dass einige fehlerhafte Zeilen den gesamten Prozess stoppen und bietet einen klaren Mechanismus zur Überprüfung von Datenqualitätsproblemen.

Implementierung von Row-Level Security (RLS), bei der Benutzer nur Daten sehen sollen, die ihrer Identität entsprechen (z. B. ein Vertriebsleiter sieht nur seine Filialen).

→Erstellen Sie eine Sicherheitstabelle, die Benutzer Datenentitäten zuordnet. Verwenden Sie in der RLS-Rolle einen DAX-Filterausdruck wie `[ManagerEmail] = USERPRINCIPALNAME()`.

Warum: Dynamische RLS ist skalierbar. Sie verwendet einen datengesteuerten Ansatz, anstatt für jede Person oder Entität eine statische Rolle zu erstellen. `USERPRINCIPALNAME()` löst die Azure AD-Identität korrekt auf.

Ausblenden sensibler Spalten oder ganzer Tabellen (z. B. Gehalt) vor einer bestimmten Benutzergruppe, während diesen der Zugriff auf den Rest des semantischen Modells gestattet wird.

→Definieren Sie Sicherheitsrollen und konfigurieren Sie Object-Level Security (OLS) mit einem externen Tool wie Tabular Editor, um Tabellen-/Spaltenberechtigungen auf "Keine" zu setzen.

Warum: OLS bietet eine granulare Kontrolle über die Sichtbarkeit von Modell-Metadaten. Im Gegensatz zu RLS, das Zeilen filtert, blendet OLS das gesamte Objekt aus. Es muss über den XMLA-Endpunkt konfiguriert werden.

Benutzer melden langsame Leistung und Drosselung in Fabric. Der Administrator muss die Ursache ermitteln.

→Verwenden Sie die Fabric Capacity Metrics App.

Warum: Diese App bietet detaillierte Einblicke in den Verbrauch von Kapazitätseinheiten (CU), Drosselungsereignisse und die Ressourcennutzung nach Workload-Typ (z. B. Abfrage eines semantischen Modells, Dataflow-Aktualisierung). Es ist das primäre Tool für Leistungsüberwachung und Kapazitätsplanung.

Eine Datenklassifizierungsrichtlinie durchsetzen, bei der Berichte und Dashboards automatisch das Sensitivitätslabel des semantischen Modells erben, mit dem sie verbunden sind.

→Aktivieren Sie die Mandanteneinstellung für die nachgelagerte Vererbung von Sensitivitätslabels.

Warum: Dies automatisiert die Daten-Governance und stellt sicher, dass auf die Datenquelle angewendete Schutzmaßnahmen (z. B. "Streng vertraulich") konsistent auf alle nachgelagerten Inhalte angewendet werden, wodurch das Risiko von Datenlecks reduziert wird.

In einem Fabric Warehouse sollten allgemeine Benutzer maskierte PII-Daten sehen (z. B. `XXX-XX-1234`), während privilegierte Benutzer die vollständigen, unmaskierten Daten sehen.

→Wenden Sie Dynamic Data Masking (DDM) auf die sensiblen Spalten im Warehouse an. Erteilen Sie privilegierten Benutzerrollen `UNMASK`-Berechtigungen.

Warum: DDM ist eine Sicherheitsfunktion auf Datenbankebene, die Daten basierend auf Benutzerberechtigungen dynamisch redigiert. Sie schützt sensible Daten direkt, ohne separate Ansichten oder Kopien der Daten zu erfordern.