Freigeben über

Auswerten und Optimieren der Microsoft Fabric-Kapazität

  • Artikel

In diesem Artikel wird erläutert, wie Sie die Auslastung Ihrer Microsoft Fabric-Kapazitäten auswerten und optimieren können. Außerdem werden Strategien zur Bewältigung von Überlastungssituationen beschrieben, und Sie erhalten Anleitungen zum Optimieren der Computenutzung für jede der Fabric-Umgebungen.

Auch wenn das Fabric-Kapazitätsmodell die Einrichtung vereinfacht und die Zusammenarbeit ermöglicht, kann es doch mit großer Wahrscheinlichkeit vorkommen, dass die freigegebenen Compute-Ressourcen einer Kapazität erschöpft sind. Es kann auch sein, dass Sie mehr Ressourcen bezahlen, als sie brauchen. Solche Situationen können entstehen, wenn Fabric-Umgebungen nicht nach bewährten Methoden konzipiert sind.

Es ist wichtig, die Gefahr erschöpfter freigegebener Ressourcen zu verringern. Fabric hat als verwalteter Dienst zwei Möglichkeiten zum Bewältigen solcher Situationen.

  • Durch Bursting und Glättung wird sichergestellt, dass CPU-intensive Aktivitäten schnell abgeschlossen werden, ohne dass eine höhere SKU erforderlich ist (und dass sie zu beliebiger Zeit ausgeführt werden können).
  • Durch Drosselung werden Vorgänge verzögert oder abgelehnt, wenn bei einer Kapazität ein anhaltend hoher CPU-Bedarf zu verzeichnen ist (über dem SKU-Grenzwert).

Die Glättung reduziert die Wahrscheinlichkeit einer Drosselung (obwohl dennoch eine Drosselung erfolgen kann). Die Glättung betrifft die Zuordnung des Verbrauchs hinsichtlich der Grenzwerte, ist jedoch unabhängig von der Ausführung von Jobs. Die Glättung ändert nichts an der Leistung. Sie verteilt lediglich die Abrechnung der verbrauchten Computeleistung über einen längeren Zeitraum, sodass zur Bewältigung des Spitzenbedarfs keine größere SKU benötigt wird.

Weitere Informationen zur Fabric-Kapazität finden Sie unter Microsoft Fabric-Konzepte und -Lizenzen und Fabric-Kapazitäten: Alles, was Sie über Neuigkeiten und Zukünftiges wissen müssen.

Planungs- und Budgetierungstools

Die Planung der Größe einer Kapazität kann eine Herausforderung sein. Das liegt daran, dass die erforderliche Computeleistung je nach ausgeführten Vorgängen, Qualität der Ausführung (z. B. Effizienz einer DAX-Abfrage oder des Python-Codes in einem Notebook) oder Grad der Nebenläufigkeit stark variieren kann.

Um die Bestimmung der richtigen Kapazitätsgröße zu erleichtern, können Sie Testkapazitäten oder F-SKUs mit nutzungsbasierter Zahlung bereitstellen und die tatsächlich erforderliche Kapazitätsgröße messen, bevor Sie eine reservierte F-SKU-Instanz erwerben.

Tipp

Es ist immer eine gute Strategie, klein anzufangen und dann die Größe Ihrer Kapazität nach Bedarf schrittweise zu erhöhen.

Überwachen von Kapazitäten

Sie sollten die Nutzung überwachen, damit Sie Ihre Kapazitäten optimal einsetzen können. In erster Linie ist es wichtig zu verstehen, dass es sich bei Fabric-Vorgängen entweder um interaktive Vorgänge oder um Hintergrundvorgänge handelt. So sind z. B. DAX-Abfragen aus einem Power BI-Bericht bedarfsgesteuerte Anforderungen, bei denen es sich um interaktive Vorgänge handelt, während semantische Modellaktualisierungen Hintergrundvorgänge sind. Weitere Informationen zu Vorgängen und ihren Ressourcenverbrauch in Fabric finden Sie unter Fabric-Vorgänge.

Durch die Überwachung kann festzustellen sein, dass eine Drosselung stattfindet. Eine Drosselung kann sich ergeben, wenn es zahlreiche oder zeitintensive interaktive Vorgänge gibt. Hintergrundvorgänge im Zusammenhang mit SQL- und Spark-Umgebungen werden normalerweise geglättet, das heißt sie werden auf einen Zeitraum von 24 Stunden verteilt.

Die Fabric-Kapazitätsmetrik-App ist die beste Möglichkeit zum Überwachen und Visualisieren der aktuellen Nutzung. In der App erfolgt eine Aufgliederung nach Elementtyp (semantisches Modell, Pipeline, Pipeline und anderes), sodass Sie Elemente oder Vorgänge mit hoher Computenutzung erkennen (und optimieren) können.

Administratoren können im Administrator-Überwachungsarbeitsbereich mehr über häufig verwendete Elemente (und die allgemeine Nutzung) erfahren. Sie können zudem im Überwachungshub aktuelle und kürzlich erfolgte Aktivitäten im Mandanten anzeigen lassen. Weitere Informationen zu einigen Vorgängen finden Sie eventuell auch in Log Analytics oder in den Protokollen des lokalen Datengateways.

Verwalten der hohen Computenutzung

Wenn eine Kapazität stark genutzt wird und mit der Drosselung oder Ablehnung beginnt, gibt es drei mögliche Strategien: Optimieren, Hochskalieren und horizontale Skalierung.

Es empfiehlt sich, Benachrichtigungen einzurichten, um zu erfahren, wann die Kapazitätsauslastung einen festgelegten Schwellenwert überschreitet. Sie sollten außerdem workloadspezifische Einstellungen in Erwägung ziehen, um die Größe von Vorgängen zu begrenzen (z. B. Power BI-Abfragetimeout oder Zeilenbeschränkungen oder Spark-Arbeitsbereichseinstellungen).

Optimieren

Inhaltsersteller sollten ihre Fabric-Elemente immer optimal konzipieren, sodass sie effizient sind und möglichst wenig Compute-Ressourcen verbrauchen. Konkrete Anleitungen für jede Fabric-Umgebung finden Sie weiter unten in diesem Artikel.

Hochskalieren

Sie können eine Kapazität hochskalieren, um die SKU-Größe vorübergehend oder dauerhaft zu erhöhen (mit mehr Computekapazität). Durch das Hochskalieren wird sichergestellt, dass für alle Elemente in einer Kapazität genügend Compute-Ressourcen verfügbar sind und eine Drosselung vermieden werden kann.

Sie können Fabric-F-SKUs auch entsprechend den Verbrauchsmustern in der Größe verändern, anhalten und fortsetzen.

Aufskalieren

Bei der horizontalen Skalierung verlagern Sie einige Ihrer Arbeitsbereiche oder Elemente in eine andere Fabric-Kapazität, um die Workload zu verteilen. Das kann eine gute Option sein, wenn unterschiedliche Kapazitätsstrategien, Einstellungen oder Administratoren erforderlich sind. Die Bereitstellung mehrerer Kapazitäten ist auch eine gute Strategie zur Compute-Isolierung für Elemente mit hoher Priorität und auch für Self-Service- oder Entwicklungsinhalte. Die Führungskräfte in Ihrer Organisation erwarten zum Beispiel sehr reaktionsschnelle Berichte und Dashboards. Diese Berichte und Dashboards können in einer separaten Kapazität untergebracht sein, die speziell für die Berichterstattung an die Geschäftsleitung dient.

Sie können auch in Betracht ziehen, Power BI-Arbeitsbereiche in eine gemeinsame Kapazität zu verlagern, sofern die Verbraucher über Power BI Pro-Lizenzen verfügen, mit denen sie weiterhin auf die Inhalte zugreifen können.

Konfigurieren des Überspannungsschutzes

Der Überlastungsschutz trägt dazu bei, die übermäßige Nutzung Ihrer Kapazität zu begrenzen, indem die von Hintergrundaufträgen verbrauchte Menge an Computeressourcen eingeschränkt wird. Dadurch wird der gesamte Computeverbrauch reduziert, sodass interaktive Verzögerungen oder Ablehnungen weniger wahrscheinlich sind. Diese Funktion trägt auch dazu bei, die Kapazität schneller wiederherzustellen, wenn Drosselungen oder Ablehnungen erfolgen. Sie konfigurieren den Überspannungsschutz für jede Kapazität. Der Überspannungsschutz verhindert Drosselungen und Ablehnungen, ist aber kein Ersatz für die Kapazitätsoptimierung, Hochskalierung und Aufskalierung.

Wenn der Überspannungsschutz aktiv ist, werden Hintergrundaufträge abgelehnt. Dies bedeutet, dass die Kapazität auch dann beeinträchtigt wird, wenn der Schutz vor Überspannung aktiviert ist. Durch die Verwendung des Überspannungsschutzes optimieren Sie Ihre Kapazität, um in einem Nutzungsbereich zu bleiben, der die Computeanforderungen innerhalb der Kapazität optimal ausgleicht. Um kritische Lösungen vollständig zu schützen, wird empfohlen, sie in einer korrekt dimensionierten Kapazität zu isolieren.

Compute-Optimierung nach Fabric-Umgebung

Die Umgebungen und Elemente in Fabric arbeiten auf unterschiedliche Weise und können deshalb nicht unbedingt auf die gleiche Weise optimiert werden. In diesem Abschnitt werden Fabric-Elemente entsprechend der Umgebung und die zu ihrer Optimierung möglichen Aktionen aufgeführt.

Fabric Data Warehouse

Data Warehouse hat eine serverlose Architektur, und die Knoten werden automatisch vom Dienst verwaltet. Die Kapazitätsauslastung wird nach den für Abfragen aktiven Kapazitätseinheiten in Sekunden berechnet und nicht nach der Zeit der Bereitstellung der Frontend- und Back-End-Knoten.

Alle Data Warehouse-Vorgänge sind Hintergrundvorgänge und werden über einen Zeitraum von 24 Stunden geglättet.

Der SQL-Analyseendpunkt zielt auf eine Standardleistung ab. Zu diesem Zweck stehen weniger Abfrageoptimierungsoptionen zur Verfügung als bei dedizierten SQL-Pools in SQL Server oder Azure Synapse Analytics.

Die folgenden Punkte sind zu berücksichtigen, um die Computenutzung zu minimieren.

  • Schreiben Sie Abfragen mithilfe der optimalsten T-SQL-Daten. Beschränken Sie nach Möglichkeit die Anzahl von Spalten, Berechnungen, Aggregationen und anderen Vorgängen, die den Ressourceneinsatz von Abfragen unnötig erhöhen könnten.
  • Konzipieren Sie Tabellen so, dass die kleinstmöglichen Datentypen verwendet werden. Die Auswahl des Datentyps kann die von der SQL-Engine generierten Abfragepläne stark beeinflussen. So kann z. B. durch Verkürzen der Länge eines VARCHAR-Felds von 500 auf 25 oder durch Ändern von DECIMAL(32, 8) in DECIMAL(10, 2) die Ressourcenzuteilung für eine Abfrage erheblich verringert werden.
  • Mit dem Sternschema können Sie die Anzahl der gelesenen Zeilen reduzieren und Abfrageverknüpfungen minimieren.
  • Vergewissern Sie sich, dass Statistiken vorhanden und auf dem neuesten Stand sind. Statistiken spielen eine wichtige Rolle beim Generieren eines optimalen Ausführungsplans. Sie werden zur Laufzeit automatisch erstellt, müssen aber gegebenenfalls manuell aktualisiert werden, insbesondere nach dem Laden oder Aktualisieren von Daten. Erwägen Sie das Erstellen von Statistiken mit der Option FULLSCAN, anstatt sich auf die automatisch generierten Statistiken mit Sampling zu verlassen.
  • Verwenden Sie integrierte Ansichten zum Überwachen von Abfragen und Verbrauch, insbesondere bei der Problembehandlung.
    • Die dynamische Verwaltungssicht (DMV) sys.dm_exec_requests liefert Informationen zu allen aktiv ausgeführten Abfragen, speichert jedoch keine historischen Informationen. Die Fabric-Toolbox stellt eine Abfrage bereit, die diese DMV verwendet, und macht das Abfrageergebnis benutzerfreundlicher, weil durch Verknüpfung mit anderen Ansichten Details wie der Abfragetext zur Verfügung stehen.
    • Die Abfrageerkenntnisse, ein Feature von Fabric Data Warehouse, vermitteln eine ganzheitliche Sicht der historischen Abfrageaktivität auf dem SQL-Analyseendpunkt. Insbesondere stellt die Ansicht queryinsights.exec_requests_history Informationen zu jeder abgeschlossenen SQL-Anforderung bereit. Sie enthält alle relevanten Details zu jeder Abfrageausführung, die mit den Vorgangs-IDs aus der Kapazitätsmetrik-App in Beziehung gesetzt werden können. Die wichtigsten Spalten für die Überwachung der Kapazitätsauslastung sind: distributed_statement_id, Befehl (Abfragetext), start_time und end_time.

Fabric-Datentechnik und Fabric Data Science

Die Data Engineering- und Data Science-Umgebungen nutzen Spark-Compute zum Verarbeiten, Analysieren und Speichern von Daten in einem Fabric-Lakehouse. Spark-Compute wird in Bezug auf virtuelle Kerne eingerichtet und gemessen. Fabric verwendet jedoch CUs als Maß für die Computenutzung durch verschiedene Elemente, einschließlich Spark-Notebooks, Spark-Auftragsdefinitionen und Lakehouse-Aufträgen.

In Spark entspricht eine CU zwei virtuellen Spark-Kernen für Compute. Wenn ein Kunde beispielsweise eine F64-SKU erwirbt, stehen 128 virtuelle Spark-Kerne für Spark-Umgebungen zur Verfügung.

Alle Spark-Vorgänge sind Hintergrundvorgänge und werden über einen Zeitraum von 24 Stunden geglättet.

Weitere Informationen finden Sie unter Abrechnungs- und Nutzungsberichte in Fabric Spark.

Die folgenden Punkte sind zu berücksichtigen, um die Computenutzung zu minimieren.

  • Bemühen Sie sich immer, effizienten Spark-Code zu schreiben. Weitere Informationen finden Sie unter Optimieren von Apache Spark-Aufträgen in Azure Synapse Analytics und Die Notwendigkeit, das Schreiben auf Apache Spark zu optimieren.
  • Reservieren Sie die erforderlichen Executors für Ihre Spark-Aufträge, um Ressourcen für andere Spark-Aufträge oder Workloads freizusetzen. Andernfalls nimmt die Wahrscheinlichkeit zu, dass Spark-Aufträge mit einem HTTP 430-Status fehlschlagen, was zu viele Anforderungen für die Kapazität bedeutet. Die Anzahl der einem Notebook zugeordneten Executors finden Sie im Fabric-Überwachungshub, wo Sie auch die tatsächliche Anzahl der vom Notebook genutzten Executors ermitteln können. Spark-Aufträge reservieren nur die erforderlichen Knoten und lassen parallele Übermittlungen nur innerhalb der SKU-Grenzwerte zu.
  • Der Spark-Pool kann nur auf die Verwendung der maximalen Anzahl der von der SKU unterstützten virtuellen Kerne konfiguriert werden. Sie können datentechnische Workloads jedoch horizontal skalieren, indem Sie parallele Spark-Aufträge innerhalb der SKU-Grenzwerte akzeptieren. Diese Methode wird allgemein als Burst-Faktor bezeichnet und ist für Spark-Workloads auf Kapazitätsebene standardmäßig aktiviert. Weitere Informationen finden Sie unter Parallelitätsdrosselung und Warteschlangen.
  • Aktive Spark-Sitzungen können die CU-Auslastung für eine Kapazität erhöhen. Aus diesem Grund ist es wichtig, aktive Spark-Sitzungen zu beenden, wenn sie nicht genutzt werden. Beachten Sie dass die Ablaufzeit für Spark-Sitzungen standardmäßig auf 20 Minuten festgelegt ist. Benutzer können das Sitzungstimeout in einem Notebook oder in der Spark-Auftragsdefinition ändern.

Real-Time-Intelligence

Der CU-Verbrauch der KQL-Datenbank wird nach der Anzahl der Sekunden, in denen die Datenbank aktiv ist, und nach der Anzahl der genutzten virtuellen Kerne berechnet. Wenn Ihre Datenbank z. B. vier virtuelle Kerne nutzt und 10 Minuten lang aktiv ist, verbrauchen Sie 2.400 (4 x 10 x 60) Sekunden CU.

Alle KQL-Datenbankvorgänge sind interaktive Vorgänge.

Die Größe Ihrer KQL-Datenbank wird mit einem Autoskalierungsmechanismus bestimmt. Anhand von Nutzungsmustern wird sichergestellt, dass eine kostenoptimierte und bestmögliche Leistung erzielt wird.

Damit Daten für andere Fabric-Engines verfügbar werden können, wird die KQL-Datenbank mit OneLake synchronisiert. Basierend auf der Anzahl der von Ihrer KQL-Datenbank ausgeführten Lese- und Schreibvorgänge werden CUs aus Ihrer Kapazität verbraucht. Es werden die OneLake-Lese- und Schreib-Verbrauchseinheiten verwendet, die den Lese- und Schreibvorgängen für Azure Data Lake Storage (ADLS) Gen2-Konten entsprechen.

Data Factory

Dieser Abschnitt befasst sich mit Optimierungen für Dataflows und Datenpipelines in Data Factory.

Alle Vorgänge sind Hintergrundvorgänge und werden über einen Zeitraum von 24 Stunden geglättet.

Die folgenden Punkte sind zu berücksichtigen, um die Computenutzung zu minimieren.

  • Vermeiden Sie eine ineffiziente Power Query-Logik, um kostspielige Datentransformationen wie Zusammenführen und Sortieren zu minimieren und zu optimieren.
  • Streben Sie nach Möglichkeit Query Folding an. Die Leistung Ihrer Dataflows kann sich dann dadurch verbessern, dass die Menge der Daten reduziert wird, die zwischen der Datenquelle und dem Ziel übertragen werden müssen. Ohne Query Folding ruft Power Query alle Daten aus der Datenquelle ab und nimmt Transformationen lokal vor, was ein ineffizienter und langsamer Vorgang sein kann.
  • Deaktivieren Sie das Staging, wenn Sie mit kleinen Datenvolume arbeiten und/oder einfache Transformationen vornehmen. Das Staging kann in manchen Fällen erforderlich sein, z. B. beim Laden eines Data Warehouse.
  • Vermeiden Sie es, Daten häufiger zu aktualisieren, als für die Datenquelle erforderlich. Wenn die Datenquelle z. B. nur alle 24 Stunden aktualisiert wird, ist es nicht sinnvoll, die Daten stündlich zu aktualisieren. Achten Sie stattdessen auf eine Aktualisierung der Daten in angemessenen Intervallen, damit sie aktuell und korrekt sind.

Power BI

Power BI-Vorgänge sind entweder interaktive Vorgänge oder Hintergrundvorgänge.

Die folgenden interaktiven Vorgänge führen in der Regel zu einer hohen Computenutzung.

  • Semantikmodelle, die nicht den bewährten Methoden entsprechen. Sie könnten z. B. nicht dem Starschema mit 1:N-Beziehungen entsprechen. Oder sie könnten komplexe und kostspielige Sicherheitsfilter auf Zeilenebene (RLS) enthalten. Sie sollten mit dem Tabular Editor und dem Best Practice Analyzer bestimmen, ob bewährte Methoden befolgt werden.
  • DAX-Measures sind ineffizient.
  • Die Berichtsseiten enthalten zu viele visuelle Objekte, was eine langsame visuelle Aktualisierung zur Folge haben kann.
  • Die visuellen Objekte des Berichts stellen Ergebnisse mit hoher Kardinalität dar (zu viele Zeilen oder Spalten) oder sie enthalten zu viele Measures.
  • Die Kapazität erfährt eine hohe Nebenläufigkeit, weil es zu viele Benutzer für die Kapazitätsgröße gibt. Sie sollten die horizontale Skalierung von Abfragen aktivieren, um das Benutzererlebnis bei Semantikmodellen mit hoher Nebenläufigkeit zu verbessern (wodurch sich die Computenutzung insgesamt aber nicht erhöht).

Die folgenden Hintergrundvorgänge führen in der Regel zu einer hohen Computenutzung.

  • Ineffiziente oder übermäßig komplexe Datentransformationen in der Power Query-Logik.
  • Kein Query Folding oder inkrementelle Aktualisierung für große Faktentabellen.
  • Bericht-Bursting, das gegeben ist, wenn eine hohe Anzahl von Power BI-Berichten oder paginierten Berichten gleichzeitig generiert wird.

Zugehöriger Inhalt

Weitere Fragen? Versuchen Sie, die Fabric-Community zu fragen.