Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:✅ SQL-Analyseendpunkt und Warehouse in Microsoft Fabric
In diesem Artikel werden die Architektur- und Workloadverwaltung in Fabric Data Warehouse beschrieben.
Datenverarbeitung
Warehouse und SQL-Analyseendpunkt verwenden die gleiche zugrunde liegende Verarbeitungsarchitektur. Wenn Fabric Daten abruft oder einnimmt, verarbeitet ein verteiltes Modul sowohl kleine als auch umfangreiche Daten und Rechenfunktionen.
Das Verarbeitungssystem ist serverlos, da die Back-End-Computekapazität autonom hoch- und herunterskaliert wird, um die Workloadanforderungen zu erfüllen.
Wenn eine Abfrage übermittelt wird, führt das SQL-Front-End (FE) eine Abfrageoptimierung durch, um basierend auf Datengröße und -komplexität den besten Plan zu ermitteln. Sobald der Plan generiert wurde, wird er dem DQP-Modul (Distributed Query Processing) zugewiesen. Die DQP-Engine orchestriert die verteilte Ausführung der Abfrage, indem sie die Abfrage in kleinere Abfragen unterteilt, die auf Back-End-Computeknoten ausgeführt werden. Jede kleine Abfrage ist eine Aufgabe und stellt eine verteilte Ausführungseinheit dar. Es liest Dateien aus OneLake, verknüpft Ergebnisse aus anderen Aufgaben und gruppiert oder sortiert Daten, die aus anderen Aufgaben abgerufen wurden. Bei Erfassungsaufträgen schreibt sie auch Daten in die richtigen Zieltabellen.
Nach der Verarbeitung der Daten werden die Ergebnisse an das SQL-Front-End zurückgegeben, damit sie an den Benutzer bzw. die Benutzerin oder an die aufrufende Anwendung zurückgegeben werden können.
Elastizität und Resilienz
Die Back-End-Computekapazität profitiert von einer schnellen Bereitstellungsarchitektur. Obwohl keine SLA für die Ressourcenzuordnung vorhanden ist, werden in der Regel innerhalb weniger Sekunden neue Knoten abgerufen. Mit steigendem Ressourcenbedarf verbrauchen neue Workloads die aufskalierte Kapazität. Die Skalierung ist ein Onlinevorgang, und die Abfrageverarbeitung läuft unterbrechungsfrei.
Das System ist fehlertolerant, und wenn ein Knoten fehlerhaft wird, werden Vorgänge, die auf dem Knoten ausgeführt werden, zur Vervollständigung an fehlerfreie Knoten umverteilt.
Lager- und SQL-Analyseendpunkte bieten aufschwellbare Kapazität, mit der Workloads mehr Ressourcen nutzen können, um eine bessere Leistung zu erzielen, und nutzen Glättung, um Kunden zu entlasten, die während ihrer Spitzenzeiten plötzliche Lastspitzen erzeugen und zu anderen Zeiten ungenutzte Leerlaufkapazität haben. Die Glättung vereinfacht das Kapazitätsmanagement, indem die Auswertung der Berechnung verteilt wird, um sicherzustellen, dass Kundenaufträge reibungslos und effizient ausgeführt werden.
Zeit- und Ressourcenplanung
Der Planer für die verteilte Abfrageverarbeitung arbeitet auf Aufgabenebene. Abfragen werden als ein gerichteter azyklischer Graph (DAG) von Aufgaben für den Scheduler dargestellt. Dieses Konzept ist Spark-Benutzer*innen vertraut. Ein DAG ermöglicht Parallelität und Nebenläufigkeit, da Aufgaben, die nicht voneinander abhängen, gleichzeitig oder in beliebiger Reihenfolge ausgeführt werden können.
Sobald Abfragen eintreffen, werden ihre Aufgaben basierend auf dem FIFO-Prinzip (First-In-First-Out) geplant. Wenn eine Leerlaufkapazität vorhanden ist, kann der Planer einen "optimal geeigneten" Ansatz verwenden, um die Parallelität zu optimieren.
Wenn der Scheduler eine hohe Ressourcenauslastung erkennt, ruft er eine Skalierungsoperation auf. Die Skalierung wird autonom verwaltet, und die Back-End-Topologie wächst in dem Maß, in dem die Parallelität zunimmt. Da das Erwerben von Knoten einige Sekunden dauert, ist das System nicht für eine konsistente Leistung unterhalb einer Sekunde für Abfragen optimiert, die eine verteilte Verarbeitung erfordern.
Wenn die Auslastung abnimmt, wird die Back-End-Topologie wieder herunterskaliert, und die Ressource wird wieder in der Region freigegeben.
Rechenpool-Isolation
Gilt für:✅ Warehouse in Microsoft Fabric
Die einem Arbeitsbereich zugewiesene Kapazitäts-SKU bestimmt die Gesamtberechnung, die für den SQL-Analyseendpunkt verfügbar ist. Diese Computing-Ressourcen werden gleichmäßig (50/50) in zwei isolierte Ressourcenpools aufgeteilt, damit Benutzerabfragen auf sie zugreifen können.
-
SELECT-Pool – Behandelt alle
SELECTAbfragen. -
Nicht-SELECT-Pool – Behandelt alle nicht-SELECT-Abfragen, z. B. ETL- oder Datenerfassungsvorgänge
SELECT.
Jeder Pool wird unabhängig von der Abfragenachfrage skaliert, überschreitet jedoch nie 50% der Gesamtberechnung für den SQL-Analyseendpunkt. Diese Trennung verhindert Ressourcenkonflikte, und stellt sicher, dass die Aufnahmeworkloads auf dedizierter, für ETL optimierter Rechnerleistung ausgeführt werden, ohne dass Leseabfragen betroffen sind. Das Ergebnis ist eine verbesserte Leistung und Zuverlässigkeit für beide Abfragetypen.
Hinweis
Die SELECT- und Nicht-Poolisolation ist die standardmäßige autonome Workload-Verwaltung, die auf jeden Arbeitsbereich angewendet wird. Arbeitsbereichsadministratoren können dies jedoch mithilfe von benutzerdefinierten SQL-Pools anpassen.
Sitzungen
Der Warehouse- und SQL-Analyseendpunkt haben ein Benutzersitzungslimit von 724 pro Arbeitsbereich. Wenn dieser Grenzwert erreicht ist, wird der folgende Fehler zurückgegeben: The user session limit for the workspace is 724 and has been reached.
Hinweis
Da Microsoft Fabric eine SaaS-Plattform ist, gibt es viele Systemverbindungen, die ausgeführt werden, um die Umgebung kontinuierlich zu optimieren. DMVs zeigen sowohl System- als auch Benutzersitzungen an. Weitere Informationen finden Sie unter Überwachen von Verbindungen, Sitzungen und Anforderungen mithilfe von DMVs.
Bewährte Methoden
Der Microsoft Fabric-Arbeitsbereich bietet eine natürliche Isolationsgrenze des verteilten Computesystems. Workloads können diese Grenze nutzen, um sowohl Kosten als auch Leistung zu optimieren.
Mithilfe von OneLake-Verknüpfungen können schreibgeschützte Replikate von Tabellen in anderen Arbeitsbereichen erstellt werden, sodass die Last auf mehrere SQL-Engines verteilt werden kann, wodurch eine Isolationsgrenze entsteht. Dies kann die maximale Anzahl von Sitzungen, die Abfragen im Nur-Lesen-Modus ausführen, effektiv erhöhen.
