Abfragewarteschlangen einrichten - Amazon Redshift

Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im Blog-Posting.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Abfragewarteschlangen einrichten

Amazon Redshift Serverless unterstützt die warteschlangenbasierte Verwaltung von Abfrageressourcen. Sie können spezielle Abfragewarteschlangen mit benutzerdefinierten Überwachungsregeln für verschiedene Workloads erstellen. Diese Funktion bietet eine detaillierte Kontrolle über die Ressourcennutzung.

Query Monitoring Rules (QMR) gelten nur auf Redshift Serverless-Arbeitsgruppenebene und wirken sich einheitlich auf alle Abfragen aus, die in dieser Arbeitsgruppe ausgeführt werden. Mit dem warteschlangenbasierten Ansatz können Sie Warteschlangen mit unterschiedlichen Überwachungsregeln erstellen. Sie können diese Warteschlangen bestimmten Benutzerrollen und Abfragegruppen zuweisen. Jede Warteschlange arbeitet unabhängig, wobei sich die Regeln nur auf die Abfragen innerhalb dieser Warteschlange auswirken.

In Warteschlangen können Sie auf Metriken basierende Prädikate und automatisierte Antworten festlegen. Sie können beispielsweise Regeln so konfigurieren, dass Abfragen, die Zeitlimits überschreiten oder zu viele Ressourcen verbrauchen, automatisch abgebrochen werden.

Überlegungen

Beachten Sie Folgendes, wenn Sie serverlose Warteschlangen verwenden:

  • Die folgenden Workload Management (WLM) -Konfigurationsschlüssel, die in von Amazon Redshift bereitgestellten Clustern verwendet werden, werden in Redshift Serverless-Warteschlangen nicht unterstützt:max_execution_time,,,,,,,,,short_query_queue,,auto_wlm,concurrency_scaling,priority. queue_type query_concurrency memory_percent_to_use user_group user_group_wild_card

    Außerdem werden die Aktionen Hop und change_query_priority in Serverless nicht unterstützt.

  • Die Hop-Aktion (Verschieben von Abfragen zwischen Warteschlangen) wird in Amazon Redshift Serverless nicht unterstützt.

  • Warteschlangenprioritäten werden nur für von Amazon Redshift bereitgestellte Cluster unterstützt.

  • Amazon Redshift Serverless verwaltet automatisch die Skalierung und die Ressourcenzuweisung für eine optimale Leistung, sodass Sie die Warteschlangenprioritäten nicht manuell konfigurieren müssen.

Einrichten von Abfragewarteschlangen

Sie können Warteschlangen auf der Registerkarte Limits für eine serverlose Arbeitsgruppe mithilfe der AWS-Managementkonsole, AWS CLI, oder Redshift Serverless API erstellen.

Console

Gehen Sie wie folgt vor, um eine Warteschlange für Ihre serverlose Arbeitsgruppe zu erstellen.

  1. Navigieren Sie zu Ihrer Redshift Serverless-Arbeitsgruppe.

  2. Wählen Sie den Tab Limits aus.

  3. Wählen Sie unter Abfragewarteschlangen die Option Warteschlangen aktivieren aus.

    Wichtig

    Das Aktivieren von Abfragewarteschlangen ist eine permanente Änderung. Nach der Aktivierung können Sie nicht zur Überwachung ohne Warteschleife zurückkehren.

  4. Konfigurieren Sie Ihre Warteschlangen mit den folgenden Parametern:

    Parameter auf Warteschlangenebene

    • name- Warteschlangen-ID (erforderlich, eindeutig, nicht leer)

    • user_role- Reihe von Benutzerrollen (optional)

    • query_group- Array von Abfragegruppen (optional)

    • query_group_wild_card- 0 oder 1, um den Platzhalterabgleich zu aktivieren (optional)

    • user_group_wild_card- 0 oder 1, um den Platzhalterabgleich zu aktivieren (optional)

    • rules- Reihe von Überwachungsregeln (optional)

    Parameter auf Regelebene

    • rule_name- Eindeutiger Bezeichner, max. 32 Zeichen (erforderlich)

    • predicate- Reihe von Bedingungen, 1—3 Prädikate (erforderlich)

    • action- „Abort“ oder „Log“ (erforderlich)

    Parameter auf Prädikatebene

    • metric_name- Zu überwachende Metrik (erforderlich)

    • operator- „=“, „<“, or „>“ (erforderlich)

    • value- Numerischer Schwellenwert (erforderlich)

    Beschränkungen

    • Max. 8 Warteschlangen

    • Maximal 25 Regeln für alle Warteschlangen

    • Maximal 3 Prädikate pro Regel

    • Regelnamen müssen weltweit eindeutig sein

Beispiel für eine Konfiguration

Beispiel für drei Warteschlangen: eine für Dashboard-Abfragen mit einem kurzen Timeout, eine für ETL-Abfragen mit einem langen Timeout und eine Admin-Warteschlange:

[ { "name": "dashboard", "user_role": ["analyst", "viewer"], "query_group": ["reporting"], "query_group_wild_card": 1, "rules": [ { "rule_name": "short_timeout", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 60 } ], "action": "abort" } ] }, { "name": "ETL", "user_role": ["data_scientist"], "query_group": ["analytics", "ml"], "rules": [ { "rule_name": "long_timeout", "predicate": [ { "metric_name": "query_execution_time", "operator": ">", "value": 3600 } ], "action": "log" }, { "rule_name": "memory_limit", "predicate": [ { "metric_name": "query_temp_blocks_to_disk", "operator": ">", "value": 100000 } ], "action": "abort" } ] }, { "name": "admin_queue", "user_role": ["admin"], "query_group": ["admin"] } ]

In diesem Beispiel:

  • Dashboard-Abfragen werden abgebrochen, wenn sie länger als 60 Sekunden laufen

  • ETL-Abfragen werden protokolliert, wenn sie länger als eine Stunde laufen

  • Für die Admin-Warteschlange gibt es keine Ressourcenbeschränkungen

CLI

Sie können Warteschlangen mithilfe des Parameters CreateWorkgroup oder UpdateWorkgroup APIs mit dem Parameter wlm_json_configuration config verwalten, um Warteschlangen im JSON-Format anzugeben.

aws redshift-serverless create-workgroup \ --workgroup-name test-workgroup \ --namespace-name test-namespace \ --config-parameters '[{"parameterKey": "wlm_json_configuration", "parameterValue": "[{\"name\":\"dashboard\",\"user_role\":[\"analyst\",\"viewer\"],\"query_group\":[\"reporting\"],\"query_group_wild_card\":1,\"rules\":[{\"rule_name\":\"short_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":60}],\"action\":\"abort\"}]},{\"name\":\"ETL\",\"user_role\":[\"data_scientist\"],\"query_group\":[\"analytics\",\"ml\"],\"rules\":[{\"rule_name\":\"long_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":3600}],\"action\":\"log\"},{\"rule_name\":\"memory_limit\",\"predicate\":[{\"metric_name\":\"query_temp_blocks_to_disk\",\"operator\":\">\",\"value\":100000}],\"action\":\"abort\"}]},{\"name\":\"admin_queue\",\"user_role\":[\"admin\"],\"query_group\":[\"admin\"]}]"}]'

Best Practices

Beachten Sie die folgenden bewährten Methoden, wenn Sie serverlose Warteschlangen verwenden.

  • Verwenden Sie separate Warteschlangen für Workloads mit unterschiedlichen Grenzanforderungen (z. B. ETL, Berichterstattung oder Ad-hoc-Analysen).

  • Beginnen Sie mit einfachen Schwellenwerten und passen Sie sie je nach Abfrageverhalten und Nutzungsmustern an. Sie können die Nutzungsmuster von Abfragen mithilfe der Tabellen und Ansichten überwachen, die unter Systemtabellen und Ansichten für Regeln zur Abfrageüberwachung dokumentiert sind.