Workloadklassifizierung für dedizierte SQL-Pools in Azure Synapse Analytics

  • Artikel

In diesem Artikel wird der Workloadklassifizierungsprozess beim Zuweisen einer Workloadgruppe und Priorität für eingehende Anforderungen mit dedizierten SQL-Pools in Azure Synapse erläutert.

Klassifizierung

Durch die Klassifizierung der Workloadverwaltung können Richtlinien auf Anforderungen angewendet werden, wobei Ressourcenklassen und Prioritäten zugewiesen werden.

Data Warehousing-Workloads lassen sich auf viele Weisen klassifizieren. Die einfachste und gängigste Klassifizierung besteht allerdings im Laden und Abfragen von Daten. INSERT-, UPDATE- und DELETE-Anweisungen sind „Lasten“ für Daten. Mit SELECT-Anweisungen werden sie abgefragt. Für eine Data Warehousing-Lösung wird häufig eine Workloadrichtlinie für Ladeaktivitäten eingesetzt, wodurch z. B. eine höhere Ressourcenklasse und mehr Ressourcen zugewiesen werden können. Eine unterschiedliche Workloadrichtlinie könnte auf Abfragen angewendet werden, wodurch beispielsweise im Gegensatz zu Ladeaktivitäten eine niedrigere Priorität festgelegt wird.

Für Lade- und Abfrageworkloads können Sie auch Unterklassifizierungen erstellen. Durch diese erhalten Sie mehr Kontrolle über Ihre Workloads. Abfrageworkloads können beispielsweise aus Cubeaktualisierungen, Dashboardabfragen oder Ad-hoc-Abfragen bestehen. Sie können jede dieser Abfrageworkloads mit unterschiedlichen Ressourcenklassen oder Prioritätseinstellungen klassifizieren. Auch Ladevorgänge können von der Unterklassifizierung profitieren. Große Transformationen können größeren Ressourcenklassen zugewiesen werden. Durch eine höhere Priorität kann sichergestellt werden, dass wichtige Umsatzdaten vor Wetterdaten oder einem sozialen Datenfeed geladen werden.

Nicht alle Anweisungen sind klassifiziert, da sie keine Ressourcen oder Bedeutung erfordern, um die Ausführung zu beeinflussen. DBCC-Befehle, BEGIN-, COMMIT- und ROLLBACK TRANSACTION-Anweisungen werden nicht klassifiziert.

Klassifizierungsprozess

Die Klassifizierung für dedizierte SQL-Pools erfolgt zurzeit, indem Benutzern mithilfe von sp_addrolemember einer Rolle zugewiesen werden, der wiederum eine entsprechende Ressourcenklasse zugewiesen wurde. Die Möglichkeit, andere Anforderungen als eine Anmeldung bei einer Ressourcenklasse zu charakterisieren, ist bei dieser Funktion beschränkt. Mit der CREATE WORKLOAD CLASSIFIER-Syntax steht nun eine leistungsfähigere Klassifizierungsmethode zur Verfügung. Mit dieser Syntax können Benutzer dedizierter SQL-Pools Priorität zuweisen und angeben, wie viele Systemressourcen einer Anforderung über den Parameter workload_group zugewiesen werden.

Klassifizierungsgewichtung

Im Rahmen des Klassifizierungsprozesses wird mittels Gewichtung bestimmt, welche Arbeitsauslastungsgruppe zugewiesen wird. Die Gewichtung funktioniert wie folgt:

Klassifizierungsparameter Weight
MEMBERNAME:USER 64
MEMBERNAME:ROLE 32
WLM_LABEL 16
WLM_CONTEXT 8
START_TIME/END_TIME 4

Der Parameter MEMBERNAME ist obligatorisch. Handelt es sich bei dem angegebenen Mitgliedsnamen jedoch um einen Datenbankbenutzer und nicht um eine Datenbankrolle, ist die Gewichtung für Benutzer*innen höher, sodass dieser Klassifizierer ausgewählt wird.

Wenn ein Benutzer Mitglied mehrerer Rollen mit verschiedenen zugewiesenen Ressourcenklassen oder Übereinstimmungen in mehreren Klassifizierern ist, wird dem Benutzer die höchste Ressourcenklasse zugewiesen. Dies entspricht dem Verhalten für bereits vorhandene Ressourcenklassenzuweisungen.

Hinweis

Das Klassifizieren des Verhaltens von verwalteten Identitäten unterscheidet sich zwischen dem dedizierten SQL-Pool in Azure Synapse-Arbeitsbereichen und dem eigenständigen dedizierten SQL-Pool (vormals SQL DW). Während die verwaltete Identität des eigenständigen dedizierten SQL-Pools die zugewiesene Identität verwaltet, wird für Azure Synapse-Arbeitsbereiche die verwaltete Identität als dbo ausgeführt. Dies kann nicht geändert werden. Die dbo-Rolle ist standardmäßig als „smallrc“ klassifiziert. Das Erstellen eines Klassifizierers für die dbo-Rolle ermöglicht das Zuweisen von Anforderungen zu einer anderen Arbeitsauslastungsgruppe als „smallrc“. Wenn dbo allein zu generisch für die Klassifizierung ist und umfassendere Auswirkungen mit sich zieht, sollten Sie die Verwendung der bezeichnungs-, sitzungs- oder zeitbasierten Klassifizierung in Verbindung mit der dbo-Rollenklassifizierung in Betracht ziehen.

Mit Ausnahme von smallrc werden die dynamischen Ressourcenklassen als vordefinierte Datenbankrollen implementiert. Smallrc wird nicht als Datenbankrolle angezeigt, sondern ist die Standardressourcenklasse.

Systemklassifizierungen

Workloadklassifizierungen verfügen über Systemworkloadklassifizierungen. Letztere ordnen die Ressourcenklassen-Rollenmitgliedschaften den Ressourcenzuordnungen der Ressourcenklassen mit normaler Priorität zu. Systemklassifizierungen können nicht gelöscht werden. Sie können die folgende Abfrage ausführen, um Systemklassifizierungen anzuzeigen:

SELECT * FROM sys.workload_management_workload_classifiers where classifier_id <= 12

Kombinieren von Ressourcenklassenzuweisungen mit Klassifizierungen

Systemklassifizierungen, die in Ihrem Auftrag erstellt werden, stellen eine einfache Möglichkeit zum Migrieren einer Workloadklassifizierung bereit. Wenn Sie Ressourcenklassen-Rollenzuordnungen mit einer Klassifizierungsrangfolge verwenden, kann dies beim Erstellen neuer priorisierter Klassifizierungen zu Fehlklassifizierungen führen.

Nehmen Sie das folgende Szenario als Beispiel:

  • Ein vorhandenes Data Warehouse verfügt über den Datenbankbenutzer DBAUser, der der Ressourcenklassenrolle „largerc“ zugewiesen ist. Die Ressourcenklassenzuordnung wurde mit sp_addrolemember. durchgeführt.
  • Das Data Warehouse wird nun mit der Workloadverwaltung aktualisiert.
  • Zum Testen der neuen Klassifizierungssyntax wird über die Datenbankrolle „DBARole“ (von der DBAUser ein Mitglied ist) eine Klassifizierung für beide erstellt. Dabei wird eine Zuordnung zu „mediumrc“ mit hoher Priorität vorgenommen.
  • Wenn DBAUser sich anmeldet und eine Abfrage ausführt, wird diese „largerc“ zugewiesen, da ein Benutzer Vorrang vor einer Rollenmitgliedschaft hat.

Beim Erstellen von Workloadklassifizierungen wird empfohlen, Ressourcenklassen-Rollenzuordnungen zu entfernen, da Sie auf diese Weise Probleme mit Fehlklassifizierungen leichter beheben können. Der folgende Code gibt Ressourcenklassen-Rollenmitgliedschaften zurück. Führen Sie sp_droprolemember für alle Mitgliedsnamen aus, die von der entsprechenden Ressourcenklasse zurückgegeben werden.

SELECT  r.name AS [Resource Class]
,       m.name AS membername
FROM    sys.database_role_members rm
JOIN    sys.database_principals AS r ON rm.role_principal_id = r.principal_id
JOIN    sys.database_principals AS m ON rm.member_principal_id = m.principal_id
WHERE   r.name IN ('mediumrc','largerc','xlargerc','staticrc10','staticrc20','staticrc30','staticrc40','staticrc50','staticrc60','staticrc70','staticrc80');

--for each row returned run in the previous query
EXEC sp_droprolemember '[Resource Class]', membername;

Zugehöriger Inhalt