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 Architektur und Workloadverwaltung für das Data Warehousing in Microsoft Fabric beschrieben.
Datenverarbeitung
Warehouse und SQL-Analyseendpunkt verwenden die gleiche zugrunde liegende Verarbeitungsarchitektur. Wenn Daten abgerufen oder erfasst werden, kommt eine verteilte Engine zum Einsatz, die sowohl für geringfügige als auch umfangreiche Datenmengen und Berechnungsfunktionen entwickelt wurde.
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. Nachdem der Plan generiert wurde, wird er der DQP-Engine (Distributed Query Processing, verteilte Abfrageverarbeitung) 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 wird als Aufgabe bezeichnet und stellt eine Einheit der verteilten Ausführung dar. Sie 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. Es gibt zwar keine SLA für die Ressourcenzuweisung, aber in der Regel werden neue Knoten innerhalb weniger Sekunden erworben. 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.
Warehouse- und SQL-Analyseendpunkt bieten burstfähige Kapazität, mit der Workloads mehr Ressourcen nutzen können, um eine bessere Leistung zu erzielen, und verwendenGlättung, um Kunden zu entlasten, die während ihrer Stoßzeiten plötzliche Spitzen erzeugen, während sie gleichzeitig eine Menge ungenutzter Kapazitäten 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 für den Planer als gerichteter azyklischer Graph (Directed Acyclic Graph, DAG) von Aufgaben dargestellt. Dieses Konzept ist Spark-Benutzer*innen vertraut. Ein DAG ermöglicht Parallelität, da Aufgaben, die nicht voneinander abhängen, gleichzeitig oder ungeordnet ausgeführt werden können.
Sobald Abfragen eintreffen, werden ihre Aufgaben basierend auf dem FIFO-Prinzip (First-In-First-Out) geplant. Wenn ungenutzte Kapazität vorhanden ist, kann der Planer einen „Best Fit“-Ansatz zum Optimieren der Parallelität verwenden.
Wenn der Planer eine hohe Ressourcenauslastung erkennt, ruft er einen Skalierungsvorgang 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.
Isolierung von Erfassungen
Gilt für:✅ Warehouse in Microsoft Fabric
Im Back-End-Computepool von Warehouse in Microsoft Fabric sind die Ressourcen für Ladeaktivitäten von analytischen Workloads isoliert. Dies verbessert die Leistung und Zuverlässigkeit, da Erfassungsaufträge auf dedizierten Knoten ausgeführt werden können, die für ETL optimiert sind, und nicht mit anderen Abfragen oder Anwendungen um Ressourcen konkurrieren.
Sitzungen
Für das Warehouse und den SQL-Analyseendpunkt gilt ein Grenzwert von 724 Benutzersitzungen 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 Überwachung mit 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 schreibgeschützte Abfragen ausführen, effektiv erhöhen.
