Data Warehouse-Einheiten (DWUs) für den dedizierten SQL-Pool (früher SQL DW) in Azure Synapse Analytics

Dieses Dokument enthält Empfehlungen zum Auswählen der idealen Anzahl von Data Warehouse-Einheiten (Data Warehouse Units, DWUs) für dedizierte SQL-Pools (vormals SQL DW) zum Verringern der Kosten und Optimieren der Leistung sowie zum Ändern der Anzahl der Einheiten.

Was sind Data Warehouse-Einheiten?

Ein dedizierter SQL-Pool (früher SQL DW) ist eine Sammlung von Analyseressourcen, die bereitgestellt werden. Analyseressourcen werden als eine Kombination aus CPU, Arbeitsspeicher und E/A definiert.

Diese drei Ressourcen werden in Computeskalierungseinheiten gebündelt, die als „Data Warehouse-Einheiten“ (Data Warehouse Units, DWUs) bezeichnet werden. Eine DWU stellt ein abstraktes, normalisiertes Maß für Computeressourcen und -leistung dar.

Durch eine Änderung der Dienstebene wird die Anzahl von DWUs geändert, die für das System verfügbar sind. Hiermit werden dann die Leistung und die Kosten Ihres Systems angepasst.

Um die Leistung zu steigern, können Sie die Anzahl von Data Warehouse-Einheiten erhöhen. Verringern Sie die Anzahl von Data Warehouse-Einheiten, um die Leistung zu reduzieren. Speicher- und Computekosten werden separat in Rechnung gestellt. Das Ändern der Data Warehouse-Einheiten wirkt sich daher nicht auf die Speicherkosten aus.

Die Leistung für Data Warehouse-Einheiten basiert auf den folgenden Data Warehouse-Workloadmetriken:

• Wie schnell eine Standardabfrage im dedizierten SQL-Pool (früher SQL DW) eine große Anzahl von Zeilen überprüfen und dann eine komplexe Aggregation ausführen kann. Dies ist ein Vorgang mit hohem E/A- und CPU-Aufwand.
• Wie schnell der dedizierte SQL-Pool (früher SQL DW) Daten aus Azure Storage Blob-Instanzen oder Azure Data Lake erfassen kann. Dies ist ein Vorgang mit hohem Netzwerk- und CPU-Aufwand.
• Wie schnell mit dem T-SQL-Befehl CREATE TABLE AS SELECT eine Tabelle kopiert werden kann. Dieser Vorgang umfasst das Lesen von Daten aus dem Speicher, das Verteilen auf die Knoten der Anwendung und das erneute Schreiben in den Speicher. Dies ist ein Vorgang mit hohem CPU-, E/A- und Netzwerkaufwand.

Erhöhen der Anzahl der DWUs:

• Lineare Änderung der Systemleistung bei Scans, Aggregationen und CTAS-Anweisungen
• Erhöhen der Anzahl von Readern und Writern für PolyBase-Ladevorgänge
• Erhöht die maximale Anzahl von gleichzeitigen Abfragen und Parallelitätsslots

Servicelevelziel

Das Servicelevelziel (Service Level Objective, SLO) ist die Skalierbarkeitseinstellung, die die Kosten und Leistungsstufe Ihres dedizierten SQL-Pools (früher SQL DW) festlegt. Die Servicelevel für einen dedizierten Gen2-SQL-Pool (früher SQL DW) werden in Data Warehouse-Einheiten (DWUs) gemessen, z. B. DW2000c.

In T-SQL bestimmt die Einstellung „SERVICE_OBJECTIVE“ den Servicelevel und die Leistungsstufe für Ihren dedizierten SQL-Pool (früher SQL DW).

CREATE DATABASE mySQLDW
(Edition = 'Datawarehouse'
 ,SERVICE_OBJECTIVE = 'DW1000c'
)
;

Leistungsstufen und Data Warehouse-Einheiten

Jede Leistungsstufe verwendet eine etwas andere Maßeinheit für ihre Data Warehouse-Einheiten. Dieser Unterschied wird in der Rechnung berücksichtigt, weil die Skalierungseinheit direkt in eine Abrechnung übersetzt wird.

• Gen1-Data Warehouses werden in DWUs (Data Warehouse-Einheiten) gemessen.
• Gen2-Data Warehouses werden in cDWUs (Compute-Data Warehouse-Einheiten) gemessen.

Sowohl DWUs als auch cDWUs unterstützen das zentrale Herunterskalieren und Hochskalieren sowie Computepausen, wenn Sie das Data Warehouse nicht nutzen müssen. Diese Vorgänge werden alle bei Bedarf ausgeführt. Gen2 verwendet einen lokalen datenträgerbasierten Cache auf den Computeknoten, um die Leistung zu verbessern. Wenn Sie das System skalieren oder anhalten, wird der Cache für ungültig erklärt. Daher ist eine „Aufwärmphase“ des Caches erforderlich, bevor eine optimale Leistung erzielt wird.

Kapazitätsgrenzen

Jeder SQL-Server (z.B. myserver.database.windows.net) weist ein Kontingent für DTUs (Database Transaction Unit, Datenübertragungseinheiten) auf, das eine bestimmte Anzahl von Data Warehouse-Einheiten zulässt. Weitere Informationen finden Sie in den Kapazitätsgrenzen für die Workloadverwaltung.

Wie viele Data Warehouse-Einheiten benötige ich?

Die optimale Anzahl der Data Warehouse-Einheiten hängt in hohem Maß von Ihrer Arbeitsauslastung und der Datenmenge ab, die Sie in das System geladen haben.

Schritte zum Ermitteln der besten DWU-Anzahl für Ihre Arbeitsauslastung:

1. Beginnen Sie, indem Sie eine kleinere DWU auswählen.

2. Überwachen Sie die Anwendungsleistung, wenn Sie Datenmengen im System testen, und beobachten Sie dabei die Anzahl der ausgewählten DWUs im Vergleich zur beobachteten Leistung. Überprüfen durch Überwachen der Ressourcennutzung

3. Identifizieren Sie zusätzliche Anforderungen für periodische Zeiten mit Spitzenauslastung. Workloads, bei denen die Aktivität erhebliche Spitzen und Täler aufweist, müssen unter Umständen häufig skaliert werden.

Ein dedizierter SQL-Pool (früher SQL DW) ist ein horizontal skalierbares System, das große Mengen von Compute- und Abfragedaten bereitstellen kann.

Wenn Sie seine wahren Skalierungsfunktionen (insbesondere bei größeren DWUs) in Aktion sehen möchten, wird empfohlen, bei der Skalierung das Dataset zu skalieren, um sicherzustellen, dass genügend Daten zum Übertragen an die CPUs verfügbar sind. Es wird empfohlen, für die Skalierungstests mindestens 1 TB zu verwenden.

Berechtigungen

Zum Ändern der Data Warehouse-Einheiten sind die unter ALTER DATABASE beschriebenen Berechtigungen erforderlich.

Integrierte Azure-Rollen wie „Mitwirkender von SQL DB“ und „SQL Server-Mitwirkender“ können die DWU-Einstellungen ändern.

Anzeigen der aktuellen DWU-Einstellungen

So zeigen Sie die aktuellen DWU-Einstellungen an:

1. Öffnen Sie den Objekt-Explorer von SQL Server in Visual Studio.
2. Stellen Sie eine Verbindung mit der Masterdatenbank mit dem logischen SQL-Server her.
3. Treffen Sie eine Auswahl aus der dynamischen Verwaltungssicht „sys.database_service_objectives“. Beispiel:

SELECT  db.name [Database]
,        ds.edition [Edition]
,        ds.service_objective [Service Objective]
FROM    sys.database_service_objectives   AS ds
JOIN    sys.databases                     AS db ON ds.database_id = db.database_id
;

Ändern von Data Warehouse-Einheiten

Azure-Portal

So ändern Sie DWUs:

1. Öffnen Sie das Azure-Portal, öffnen Sie Ihre Datenbank, und klicken Sie dann auf Skalieren.

2. Verschieben Sie unter Skalieren den Schieberegler nach links oder rechts, um die DWU-Einstellung zu ändern.

3. Klicken Sie auf Speichern. Eine Bestätigungsmeldung wird angezeigt. Klicken Sie zur Bestätigung auf Ja oder zum Abbrechen auf Nein.

PowerShell

Zum Ändern der DWUs verwenden Sie das PowerShell-Cmdlet Set-AzSqlDatabase. Im folgenden Beispiel wird das Servicelevelziel für die Datenbank „MySQLDW“, die auf dem Server „MyServer“ gehostet wird, auf „DW1000“ festgelegt.

Set-AzSqlDatabase -DatabaseName "MySQLDW" -ServerName "MyServer" -RequestedServiceObjectiveName "DW1000c"

Weitere Informationen finden Sie unter PowerShell-Cmdlets für einen dedizierten SQL-Pool (früher SQL DW).

T-SQL

Mit T-SQL können Sie die aktuellen DWU-Einstellungen anzeigen, die Einstellungen ändern und den Fortschritt überprüfen.

So ändern Sie die DWUs

1. Stellen Sie eine Verbindung mit der Masterdatenbank mit Ihrem Server her.
2. Verwenden Sie die T-SQL-Anweisung ALTER DATABASE. Im folgenden Beispiel wird das Servicelevelziel für die Datenbank „MySQLDW“ auf „DW1000c“ gesetzt.

ALTER DATABASE MySQLDW
MODIFY (SERVICE_OBJECTIVE = 'DW1000c')
;

REST-APIs

Um die DWUs zu ändern, verwenden Sie die REST-API zum Erstellen oder Aktualisieren einer Datenbank. Im folgenden Beispiel wird der Servicelevel-Zielpunkt für die Datenbank MySQLDW, die auf dem Server „MyServer“ gehostet wird, auf „DW1000c“ gesetzt. Der Server befindet sich in einer Azure-Ressourcengruppe namens „ResourceGroup1“.

PUT https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Sql/servers/{server-name}/databases/{database-name}?api-version=2014-04-01-preview HTTP/1.1
Content-Type: application/json; charset=UTF-8

{
    "properties": {
        "requestedServiceObjectiveName": "DW1000c"
    }
}

Weitere REST-API-Beispiele finden Sie unter REST-APIs für einen dedizierten SQL-Pool (früher SQL DW).

Überprüfen des Status von DWU-Änderungen

Es kann mehrere Minuten in Anspruch nehmen, bis DWU-Änderungen abgeschlossen werden. Wenn Sie die Skalierung automatisch ausführen, empfiehlt es sich, eine Logik zu implementieren, die sicherstellt, dass bestimmte Vorgänge abgeschlossen wurden, bevor mit einer andern Aktion fortgefahren wird.

Überprüfen Sie den Datenbankzustand über verschiedene Endpunkte, um sicherzugehen, dass die Automatisierung ordnungsgemäß implementiert wird. Über das Portal erhalten Sie bei Abschluss eines Vorgangs eine Benachrichtigung sowie Informationen zum aktuellen Zustand der Datenbanken. Das Portal ermöglicht aber keine programmgesteuerte Überprüfung des Zustands.

Der Zustand der Datenbank für horizontale Hochskalierungsvorgänge kann nicht mit dem Azure-Portal überprüft werden.

So überprüfen Sie den Zustand von DWU-Änderungen:

1. Stellen Sie eine Verbindung mit der Masterdatenbank mit Ihrem Server her.

2. Übermitteln Sie die folgende Abfrage, um den Datenbankzustand zu überprüfen.

   SELECT    *
   FROM      sys.dm_operation_status
   WHERE     resource_type_desc = 'Database'
   AND       major_resource_id = 'MySQLDW'
   ;
   

Diese DMV gibt Informationen zu verschiedenen Verwaltungsvorgängen in Ihrem dedizierten SQL-Pool (früher SQL DW) zurück. Dazu gehören beispielsweise der Vorgang und der Status des Vorgangs, der „IN_PROGRESS“ oder „COMPLETED“ lauten kann.

Der Skalierungsworkflow

Wenn Sie einen Skalierungsvorgang starten, beendet das System zuerst alle geöffneten Sitzungen und führt ein Rollback aller offenen Transaktionen aus, um einen konsistenten Zustand zu gewährleisten. Bei Skalierungsvorgängen erfolgt die Skalierung nur ein Mal, nachdem das Rollback der Transaktionen abgeschlossen ist.

• Für einen Vorgang zum zentralen Hochskalieren trennt das System die Verbindung aller Computeknoten, stellt die zusätzlichen Computeknoten bereit und führt dann erneut das Anfügen an die Speicherebene aus.
• Für einen Vorgang zum zentralen Herunterskalieren trennt das System die Verbindung aller Computeknoten und fügt dann nur die benötigten Knoten wieder an die Speicherebene an.

Nächste Schritte

Weitere Informationen zum Verwalten der Leistung finden Sie unter Ressourcenklassen für die Workloadverwaltung und Grenzwerte für Arbeitsspeicher und Parallelität.