Benutzerdefinierte SQL-Pools

Gilt für:✅ SQL-Analyseendpunkt und Warehouse in Microsoft Fabric

Benutzerdefinierte SQL-Pools ermöglichen Administratoren mehr Kontrolle darüber, wie Back-End-Computeressourcen ihrem Lager- und SQL-Analyseendpunkt in einem Arbeitsbereich zugeordnet werden.

Fabric Data Warehouse bietet eine autonome Workloadverwaltung, die Computeressourcen in interne "SQL-Pools" trennt, die unabhängig nach Bedarf skaliert werden.

Standardmäßig sind die Isolationsgrenzen durch Datenaufnahme (nicht-SELECT-Anweisungstypen) und Abfrageverarbeitung (SELECT-Anweisungen) definiert. Mit benutzerdefinierten SQL-Pools können Administratoren:

• Ändern Sie die Anzahl der Isolationsgrenzen (fügen Sie weitere benutzerdefinierte SQL-Pools hinzu).
• Erstellen Sie anwendungsspezifische benutzerdefinierte Workloadklassifizierungen.
• Steuern der Ressourcenzuordnung für jeden Pool über einen maximalen Ressourcenprozentsatz.

Anwendungsfälle für benutzerdefinierte SQL-Pools

Benutzerdefinierte SQL-Pools haben zwei primäre Anwendungsfälle: Schutz von Workloads vor Ressourcenwettbewerb und Schutz vor Fabric-Kapazitätsdrosselung aufgrund hohen Verbrauchs.

Konkurrierende Workloads mit den autonomen Workloadpools

Dieses Szenario gilt, wenn unterschiedliche Arbeitslasten mit Ressourcen konkurrieren, was dazu führt, dass kritische Arbeitslasten ihre Leistungsziele nicht erreichen.

Beispielszenario

• Eine Unternehmensberichts-Workload funktioniert suboptimal, wenn Ad-hoc-Benutzerabfragen aus dem SQL-Abfrage-Editor im Fabric-Portal ausgeführt werden.

Empfohlener Ansatz

• Teilen Sie diese Workloads auf zwei separate benutzerdefinierte SQL-Pools auf.
• Weisen Sie dem Pool, der die Unternehmensberichtsanwendung bedient, einen größeren Prozentsatz von Ressourcen zu, und stellen Sie sicher, dass mehr Ressourcen für die geschäftskritische Anwendung verfügbar sind.

Kapazitätsdrosselung aufgrund eines hohen Verbrauchs

Dieses Szenario gilt, wenn ein hoher Fabric-Kapazitätsverbrauch eine Drosselung verursacht, die sich auf die Gesamtleistung des Lagers auswirkt.

Beispielszenario

• Mehrere Analyseworkloads verbrauchen eine hohe Anzahl von Fabric-Kapazitätseinheiten (CUs).

Empfohlener Ansatz

• Verringern Sie den gesamten Ressourcenanteil, der dem betroffenen Lager zugeordnet ist.
• Überwachen Sie, ob diese Änderung die Abfragedrosselung reduziert und die Gesamtleistung verbessert.

Unterschiede zwischen der autonomen Workloadverwaltung und benutzerdefinierten SQL-Pools

Burstfähige Kapazität

Benutzerdefinierte SQL-Pools ermöglichen es einem Administrator, den maximalen Ressourcenprozentsatz als die Menge der Computeressourcen zu konfigurieren, die zugeordnet werden können. Der Burstfaktor der SKU-Kapazität wird entsprechend dem angegebenen Prozentsatz für jeden Pool angewendet und verwendet.

Klassifizierer

Ein Klassifizierer ist ein Attribut einer SQL-Anforderung, das das System darüber informiert, wie es an den entsprechenden SQL-Pool weitergeleitet werden soll.

Fabric Data Warehouse bietet drei Möglichkeiten zum Klassifizieren von Anforderungen:

Leitlinien:

• Pro Arbeitsbereich kann nur ein Klassifizierertyp verwendet werden. Alle benutzerdefinierten SQL-Pools in einem einzigen Arbeitsbereich müssen denselben Klassifizierer verwenden.
• Im Fall eines regulären Ausdrucks-Klassifikators für Anwendungsnamen, wenn eine Anfrage zwei oder mehr Klassifizierungen erfüllt, ist die Auswahl des SQL-Pools zufällig und es gibt keine Priorisierungskriterien.

Erlaubnisse

• Mitglieder der Administratorarbeitsbereichrolle können benutzerdefinierte SQL-Pools für einen Arbeitsbereich aktivieren oder deaktivieren.
• Mitglieder der Administratorarbeitsbereichsrolle können die benutzerdefinierten SQL-Poolkonfigurationen aktualisieren.

Konfigurieren von benutzerdefinierten SQL-Pools

Sie können benutzerdefinierte SQL-Pools in Fabric Data Warehouse im Fabric-Portal oder über API-Aufrufe konfigurieren.

• Ein Beispiel für die Konfiguration im Fabric-Portal finden Sie unter Konfigurieren von benutzerdefinierten SQL-Pools im Fabric-Portal.
• Ein Beispiel für die Verwendung der REST-API für SQL-Pools finden Sie unter How to configure custom SQL pools by using the Fabric REST API.

Monitor

Sie können den Anwendungsnamen und den SQL-Pool sehen, der für eine Abfrage in den program_namesql_pool_name Feldern der queryinsights.exec_requests_history Systemansicht aufgezeichnet wurde.

Sie können program_name als Anwendungsname in einem Klassifizierer oder in einem regulären Ausdrucksmuster für einen Anwendungsname-Klassifizierer verwenden.

So suchen Sie beispielsweise alle program_name und die entsprechenden sql_pool_name in der aktuellen Historie:

SELECT DISTINCT 
         program_name
        ,sql_pool_name
FROM queryinsights.exec_requests_history;

Sie können ermitteln, welche SQL-Pools unter Druck stehen, indem Sie die queryinsights.sql_pool_insights Ansicht abfragen.

Beispielsweise finden Sie Zeiträume, in denen ein Pool in der letzten Woche unter Druck stand.

SELECT [timestamp]
        ,sql_pool_name
        ,max_resource_percentage
        ,is_pool_under_pressure
FROM queryinsights.sql_pool_insights
WHERE is_pool_under_pressure = 1
AND [timestamp] > DATEADD(WEEK, -1, GETDATE())
ORDER BY [timestamp] DESC, sql_pool_name;

Um Werte nach einigen Abfragekostenmetriken zu aggregieren program_name , können Sie die folgende Abfrage verwenden:

SELECT 
    program_name,
    sql_pool_name,
    [CPU] = SUM(allocated_cpu_time_ms), 
    [Disk] = SUM(data_scanned_disk_mb), 
    [Memory] = SUM(data_scanned_memory_mb), 
    [Remote storage] = SUM(data_scanned_remote_storage_mb)
FROM queryinsights.exec_requests_history
GROUP BY program_name, sql_pool_name
ORDER BY [CPU] desc, [Disk] desc, [Memory] desc, [Remote storage] desc;

Einschränkungen

• Ein Arbeitsbereich muss einen oder mehrere Lager- oder SQL-Analyseendpunkte enthalten, bevor die APIs ausgeführt werden.
• Sie können bis zu acht benutzerdefinierte SQL-Pools pro Arbeitsbereich erstellen.
• Wenn ein benutzerdefinierter SQL-Pool entfernt wird, während eine Abfrage im Pool ausgeführt wird, schlägt die Abfrage mit einer Meldung fehl: Request to perform an external distributed computation has failed with error "Query canceled by user.". Die Größenänderung eines benutzerdefinierten SQL-Pools verursacht kein Scheitern der Abfrage.

Änderungen der Größe der Fabric-Kapazität

Jeder Arbeitsbereich verfügt über eine Kapazität mit zugeordneten Kapazitätseinheiten (CUs), basierend auf der erworbenen SKU. Die platzbare Kapazität von benutzerdefinierten SQL-Pools hängt von der SKU-Größe ab. Wenn Sie also die Kapazität ändern, wirken Sie sich auf die maximale Menge an Ressourcen für jeden benutzerdefinierten SQL-Pool aus.

Wenn Sie die SKU-Kapazität ändern oder einem Arbeitsbereich eine andere Kapazität zuweisen, wenn benutzerdefinierte SQL-Pools aktiviert sind, werden sie automatisch auf die neue SKU-Größe skaliert.

Wenn beim Herunterskalieren ein SQL-Pool auf null Knoten zugewiesen wird, wird zur Laufzeit der folgende Fehler angezeigt: "Der zugewiesene SQL-Pool für diese Abfrage hat keine Ressourcen und muss neu konfiguriert werden." Ein Administrator muss benutzerdefinierte SQL-Pools neu konfigurieren, um diesen Fehler zu entfernen.

Nächster Schritt

Verwandte Inhalte

• Workload-Verwaltung
• Leistungsrichtlinien in Fabric Data Warehouse
• Konfigurieren von benutzerdefinierten SQL-Pools mithilfe der Fabric-REST-API