Verwalten von Arbeitsauslastungen
Gilt für:
SQL-Endpunkt und Warehouse in Microsoft Fabric
In diesem Artikel wird die Architektur und die Workloadverwaltung hinter Data Warehousing in Microsoft Fabric beschrieben.
Wichtig
Microsoft Fabric befindet sich derzeit in der Vorschauversion. Diese Informationen beziehen sich auf eine Vorabversion des Produkts, an der vor der Veröffentlichung noch wesentliche Änderungen vorgenommen werden können. Microsoft übernimmt keine Garantie, weder ausdrücklich noch stillschweigend, für die hier bereitgestellten Informationen.
Datenverarbeitung
Warehouse und SQL-Endpunkt verwenden die gleiche zugrunde liegende Verarbeitungsarchitektur. Wenn Daten abgerufen oder erfasst werden, nutzt es eine verteilte Engine, die sowohl für kleine als auch große Daten 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 den besten Plan basierend auf der Datengröße und -komplexität zu ermitteln. Nachdem der Plan generiert wurde, wird er der DQP-Engine (Distributed Query Processing) zugewiesen. Der DQP orchestriert die verteilte Ausführung der Abfrage, indem sie in kleinere Abfragen unterteilt wird, die auf Back-End-Computeknoten ausgeführt werden. Jede kleine Abfrage wird als Aufgabe bezeichnet und stellt eine verteilte Ausführungseinheit dar. Es liest Dateien aus OneLake, verknüpft Ergebnisse aus anderen Aufgaben, Gruppen oder Auftragsdaten, die von anderen Aufgaben abgerufen wurden. Bei Erfassungsaufträgen werden auch Daten in die richtigen Zieltabellen geschrieben.
Wenn Daten verarbeitet werden, werden die Ergebnisse an das SQL-Front-End zurückgegeben, um sie an den Benutzer oder die aufrufende Anwendung zurückzugeben.
Elastizität und Resilienz
Die Back-End-Computekapazität profitiert von einer schnellen Bereitstellungsarchitektur. Obwohl es keine SLA für die Ressourcenzuweisung gibt, werden in der Regel innerhalb weniger Sekunden neue Knoten abgerufen. Mit steigendem Ressourcenbedarf nutzen neue Workloads die skalierte 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 verteilt.
Terminplanung und Ressourcenplanung
Der Verteilte Abfrageverarbeitungsplaner arbeitet auf Aufgabenebene . Abfragen werden für den Planer als gerichtetes azyklisches Diagramm (DAG) von Aufgaben dargestellt. Dieses Konzept ist Spark-Benutzern vertraut. Eine DAG ermöglicht Parallelität und 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 FIFO-Prinzipien (First-in-First-Out) geplant. Wenn Leerlaufkapazität vorhanden ist, kann der Planer einen "best fit"-Ansatz verwenden, um die Parallelität zu optimieren.
Wenn der Planer den Ressourcendruck erkennt, ruft er einen Skalierungsvorgang auf. Die Skalierung wird autonom verwaltet, und die Back-End-Topologie wächst, wenn die Parallelität zunimmt. Da das Abrufen von Knoten einige Sekunden dauert, ist das System nicht für eine konsistente Untersekundenleistung von Abfragen optimiert, die eine verteilte Verarbeitung erfordern.
Wenn der Druck nachlässt, wird die Back-End-Topologie zurückskaliert und die Ressource zurück in die Region freigegeben.
Erfassungsisolation
Gilt für: Warehouse in Microsoft Fabric
Im Back-End-Computepool von Warehouse in Microsoft Fabric werden 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 für Ressourcen konkurrieren.
Bewährte Methoden
Der Microsoft Fabric-Arbeitsbereich bietet eine natürliche Isolationsgrenze des verteilten Computesystems. Workloads können diese Grenze nutzen, um kosten- und leistungsseitig zu verwalten.
OneLake-Verknüpfungen können verwendet werden, um schreibgeschützte Replikate von Tabellen in anderen Arbeitsbereichen zu erstellen, um die Last auf mehrere SQL-Engines zu verteilen, um eine Isolationsgrenze zu erstellen.
