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](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 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. # Implementieren von automatischem WLM Anhand des automatischen Workload Management (WLM) verwaltet Amazon Redshift die Abfragenebenläufigkeit sowie die Speicherzuweisung. Sie können bis zu acht Warteschlangen mit den Serviceklassen-IDs 100 bis 107 erstellen. Jede Warteschlange besitzt eine Priorität. Weitere Informationen finden Sie unter [Abfragepriorität](query-priority.md). Das automatische WLM legt die Menge der Ressourcen fest, die von Abfragen benötigt werden, und passt die Nebenläufigkeit entsprechend dem Workload an. Befinden sich Abfragen im System, die große Mengen an Ressourcen benötigen (z. B. Hash-Joins zwischen großen Tabellen), ist die Nebenläufigkeit geringer. Werden leichtere Abfragen (wie Einfügen, Löschen, Scannen oder einfache Aggregationen) übermittelt, ist die Nebenläufigkeit höher. Das automatische WLM unterscheidet sich von der Short Query Acceleration (SQA) und wertet Abfragen auf andere Weise aus. Automatisches WLM und SQA arbeiten zusammen, damit kurz ausgeführte und einfache Abfragen abgeschlossen werden können, auch wenn ressourcenintensive Abfragen aktiv sind. Weitere Informationen zu SQA finden Sie unter [Short Query Acceleration](wlm-short-query-acceleration.md). Amazon Redshift ermöglicht automatisches WLM über Parametergruppen: + Wenn Ihre Cluster die Standardparametergruppe verwenden, aktiviert Amazon Redshift das automatische WLM für sie. + Wenn Ihre Cluster benutzerdefinierte Parametergruppen verwenden, können Sie diese Cluster für die Unterstützung des automatischen WLM konfigurieren. Sie sollten eine eigene Parametergruppe für Ihre Konfiguration des automatischen WLM verwenden. Um WLM zu konfigurieren, bearbeiten Sie den Parameter `wlm_json_configuration` in einer Parametergruppe, die mit einem oder mehreren Clustern verknüpft werden kann. Weitere Informationen finden Sie unter [Modifizieren der WLM-Konfiguration](cm-c-implementing-workload-management.md#cm-c-modifying-wlm-configuration). Sie können Abfragewarteschlangen innerhalb der WLM-Konfiguration definieren. Sie können der WLM-Standardkonfiguration weitere Abfragewarteschlangen (bis zu acht Benutzerwarteschlangen) hinzufügen. Für jede Abfragewarteschlange kann Folgendes konfiguriert werden: + Priorität + Nebenläufigkeitsskalierungsmodus + Benutzergruppen + Abfragegruppen + Abfrageüberwachungsregeln ## Priorität Sie können die relative Wichtigkeit der Abfragen in einem Workload definieren, indem Sie einen Prioritätswert festlegen. Die Priorität wird für eine Warteschlange angegeben und von allen Abfragen geerbt, die mit der Warteschlange verknüpft sind. Weitere Informationen finden Sie unter [Abfragepriorität](query-priority.md). ## Nebenläufigkeitsskalierungsmodus Bei aktivierter Nebenläufigkeitsskalierung fügt Amazon Redshift automatisch zusätzliche Cluster-Kapazität hinzu, wenn diese benötigt wird, um eine gestiegene Zahl von gleichzeitigen Lese- und Schreibabfragen zu verarbeiten. Ihre Benutzer sehen stets die jeweils aktuellen Daten, unabhängig davon, ob die Abfragen auf dem Haupt- oder einem Nebenläufigkeitsskalierungs-Cluster ausgeführt werden. Sie können verwalten, welche Abfragen an das Nebenläufigkeitsskalierungs-Cluster gesendet werden, indem Sie WLM-Warteschlangen konfigurieren. Wenn die Nebenläufigkeitsskalierung für eine Warteschlange aktiviert ist, werden entsprechend qualifizierte Abfragen an das Nebenläufigkeitsskalierungs-Cluster übermittelt, anstatt in einer Warteschlange zu warten. Weitere Informationen finden Sie unter [Nebenläufigkeitsskalierung](concurrency-scaling.md). ## Benutzergruppen Sie können einer Warteschlange einen Satz von Benutzergruppen zuweisen, indem Sie die einzelnen Namen der Benutzergruppen angeben oder Platzhalter verwenden. Wenn ein Mitglied einer aufgeführten Benutzergruppe eine Abfrage ausführt, wird diese in der entsprechenden Warteschlange ausgeführt. Es gibt keine Grenze für die Anzahl der Benutzergruppen, die einer Warteschlange zugewiesen werden können. Weitere Informationen finden Sie unter [Zuweisen von Abfragen zu Warteschlangen auf der Grundlage von Benutzergruppen](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups). ## Benutzerrollen Sie können einer Warteschlange einen Satz von Benutzerrollen zuweisen, indem Sie die einzelnen Namen der Benutzerrollen angeben oder Platzhalter verwenden. Wenn ein Mitglied einer aufgeführten Benutzerrolle eine Abfrage ausführt, wird diese in der entsprechenden Warteschlange ausgeführt. Es gibt keine Grenze für die Anzahl der Benutzerrollen, die einer Warteschlange zugewiesen werden können. Weitere Informationen finden Sie unter [Zuweisen von Abfragen zu Warteschlangen auf der Grundlage von Benutzerrollen](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles). ## Abfragegruppen Sie können einer Warteschlange einen Satz von Abfragegruppen zuweisen, indem Sie die einzelnen Namen der Abfragegruppen angeben oder Platzhalter verwenden. Eine *Abfragegruppe* ist einfach eine Beschriftung. Während der Laufzeit können Sie die Beschriftung der Abfragegruppe einer Serie von Abfragen zuweisen. Alle einer aufgeführten Abfragegruppe zugewiesenen Abfragen werden in der entsprechenden Warteschlange ausgeführt. Es gibt keine Grenze für die Anzahl der Abfragegruppen, die einer Warteschlange zugewiesen werden können. Weitere Informationen finden Sie unter [Zuweisen einer Abfrage zu einer Abfragegruppe](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group). ## Platzhalter Wenn in der WLM-Warteschlangenkonfiguration Platzhalter aktiviert sind, können Sie Benutzergruppen und Abfragegruppen einzeln oder mithilfe von Platzhaltern im Unix-Shell-Typ einer Warteschlange zuweisen. Der Musterabgleich beachtet die Groß- und Kleinschreibung. So entspricht beispielsweise das Platzhalterzeichen „\$1“ einer beliebigen Anzahl von Zeichen. Wenn Sie dementsprechend `dba_*` zur Liste der Benutzergruppen für eine Warteschlange hinzufügen, wird dieser Warteschlange jede Benutzerabfrage zugeordnet, die zu einer Gruppe gehört, deren Name mit `dba_` beginnt. Beispiele sind `dba_admin` oder `DBA_primary`. Das Platzhalterzeichen „?“ entspricht einem einzelnen Zeichen. Wenn die Warteschlange also die Benutzergruppe `dba?1`enthält, dann passen die Benutzergruppen mit Namen `dba11` und `dba21`, `dba12` jedoch nicht. Standardmäßig sind Platzhalter nicht aktiviert. ## Abfrageüberwachungsregeln Sie können auf Metriken basierende Leistungsgrenzen für WLM-Warteschlangen definieren und angeben, welche Aktion durchgeführt werden soll, wenn eine Abfrage diese Grenzwerte überschreitet. So können Sie etwa für eine für kurze Abfragen dedizierte Warteschlange eine Regel erstellen, die Abfragen abbricht, die länger als 60 Sekunden ausgeführt werden. Zur Nachverfolgung schlecht gestalteter Abfragen können Sie eine weitere Regel verwenden, die Abfragen mit eingebetteten Schleifen protokolliert. Weitere Informationen finden Sie unter [WLM-Abfrageüberwachungsregeln](cm-c-wlm-query-monitoring-rules.md). ## Überprüfen auf automatisches WLM Führen Sie die folgende Abfrage aus, um zu überprüfen, ob das automatische WLM aktiviert ist. Wenn für die Abfrage mindestens eine Zeile zurückgegeben wird, ist das automatische WLM aktiviert. ``` select * from stv_wlm_service_class_config where service_class >= 100; ``` Die folgende Abfrage zeigt die Anzahl der Abfragen, die die einzelnen Abfragewarteschlangen durchlaufen haben (Service-Klasse). Sie zeigt zudem die durchschnittliche Ausführungsdauer, die Anzahl der Abfragen mit einer Wartezeit ab der 90. Perzentile und die durchschnittliche Wartezeit. Automatische WLM-Abfragen verwenden die Serviceklassen 100 bis 107. ``` select final_state, service_class, count(*), avg(total_exec_time), percentile_cont(0.9) within group (order by total_queue_time), avg(total_queue_time) from stl_wlm_query where userid >= 100 group by 1,2 order by 2,1; ``` Um herauszufinden, welche Abfragen von dem automatischen WLM ausgeführt und erfolgreich abgeschlossen wurden, führen Sie die folgende Abfrage aus. ``` select a.queue_start_time, a.total_exec_time, label, trim(querytxt) from stl_wlm_query a, stl_query b where a.query = b.query and a.service_class >= 100 and a.final_state = 'Completed' order by b.query desc limit 5; ``` # Abfragepriorität Mit Amazon Redshift können Sie die Priorisierung von Abfragen und die Ressourcenzuweisung für gleichzeitige Abfragen und Workloads mithilfe von Workload Management (WM) verwalten. In den folgenden Abschnitten wird beschrieben, wie Sie WM-Abfragewarteschlangen konfigurieren, Warteschlangeneigenschaften wie Speicherzuweisung und Parallelitätsskalierung definieren und Prioritätsregeln implementieren, die auf Ihre Workload-Anforderungen zugeschnitten sind. Nicht alle Abfragen sind gleich wichtig und häufig ist die Leistung eines bestimmten Workloads oder Benutzersatzes von höherer Wichtigkeit. Wenn Sie [automatisches WLM](automatic-wlm.md) aktiviert haben, können Sie die relative Wichtigkeit der Abfragen in einem Workload definieren, indem Sie einen Prioritätswert festlegen. Die Priorität wird für eine Warteschlange angegeben und von allen Abfragen geerbt, die mit der Warteschlange verknüpft sind. Sie verknüpfen Abfragen mit einer Warteschlange, indem Sie der Warteschlange Benutzer- und Abfragegruppen zuordnen. Sie können die folgenden Prioritäten festlegen (von höchster zu niedrigster Priorität): 1. `HIGHEST` 1. `HIGH` 1. `NORMAL` 1. `LOW` 1. `LOWEST` Administratoren verwenden diese Prioritäten, um die relative Wichtigkeit von Workloads anzugeben, wenn es Abfragen mit unterschiedlicher Priorität gibt, die dieselben Ressourcen benötigen. Amazon Redshift verwendet die Priorität bei der Annahme von Abfragen für das System und zur Festlegung der Menge der Ressourcen, die einer Abfrage zugeordnet werden. Standardmäßig wird die Priorität von Abfragen auf festgelegt `NORMAL`. Für Superuser ist zusätzlich die Priorität `CRITICAL` verfügbar. Diese Priorität hat einen höheren Rang als `HIGHEST`. Um diese Priorität festzulegen, können Sie die Funktionen [CHANGE\$1QUERY\$1PRIORITY](r_CHANGE_QUERY_PRIORITY.md), [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md) und [CHANGE\$1USER\$1PRIORITY](r_CHANGE_USER_PRIORITY.md) verwenden. Um einem Datenbankbenutzer die Berechtigung zur Nutzung dieser Funktionen zu erteilen, können Sie eine gespeicherte Prozedur erstellen und diesem Benutzer die entsprechende Berechtigung erteilen. Ein Beispiel finden Sie unter [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md). **Anmerkung** Es kann jeweils nur eine Abfrage mit der Priorität `CRITICAL` ausgeführt werden. Rollbacks werden immer mit der Priorität CRITICAL ausgeführt. Betrachten wir ein Beispiel, in dem ein Workload zum Extrahieren, Transformieren und Laden (Extract, Transform, Load; ETL) eine höhere Priorität als der Analytics-Workload hat. Der ETL-Workload wird alle sechs Stunden ausgeführt. Der Analytics-Workload wird während des gesamten Tages ausgeführt. Wenn nur der Analytics-Workload für das Cluster ausgeführt wird, kann er das gesamte System nutzen und einen hohen Durchsatz bei optimaler Systemnutzung erzielen. Wenn jedoch der ETL-Workload gestartet wird, erhält dieser Priorität, da er eine höhere Priorität hat. Abfragen, die als Teil des ETL-Workloads ausgeführt werden, erhalten Priorität bei der Annahme. Nach der Annahme werden ihnen die Ressourcen bevorzugt zugeteilt. Daher wird der ETL-Workload planbar ausgeführt, unabhängig davon, welche weiteren Aufgaben im System ausgeführt werden. Somit bietet sie eine vorhersehbare Leistung und bietet Administratoren die Möglichkeit, Service Level Agreements (SLAs) für ihre Geschäftsanwender bereitzustellen. Innerhalb des jeweiligen Clusters geht die planbare Leistung eines Workloads mit hoher Priorität zu Lasten anderer Workloads mit einer niedrigeren Priorität. Workloads mit einer niedrigeren Priorität benötigen für die Ausführung möglicherweise mehr Zeit, da ihre Abfragen warten, bis wichtigere Abfragen abgeschlossen sind. Ein anderer Grund für die längere Ausführungszeit kann darin bestehen, dass sie einen kleineren Anteil an den Ressourcen erhalten, wenn sie gleichzeitig mit Abfragen höherer Priorität ausgeführt werden. Abfragen mit einer niedrigeren Priorität werden jedoch nicht angehalten, sondern lediglich langsamer ausgeführt. Im vorherigen Beispiel kann der Administrator für den Analytics-Workload die [Nebenläufigkeitsskalierung](concurrency-scaling.md) aktivieren. Hierdurch kann dieser Workload seinen Durchsatz bewahren, auch wenn der ETL-Workload mit höherer Priorität ausgeführt wird. ## Konfigurieren der Warteschlangenpriorität Wenn Sie automatisches WLM aktiviert haben, besitzt jede Warteschlange einen Prioritätswert. Abfragen werden auf der Grundlage von Benutzer- und Abfragegruppen an Warteschlangen geleitet. Beginnen Sie mit der Warteschlangenpriorität `NORMAL`. Sie können eine höhere oder niedrigere Priorität festlegen, abhängig von dem Workload, der mit den Benutzer- und Abfragegruppen des Workloads verknüpft ist. Sie können die Priorität einer Warteschlange in der Amazon-Redshift-Konsole ändern. Sie können in der Amazon-Redshift-Konsole auf der Seite **Workload Management (Workload-Verwaltung)** die Warteschlangen anzeigen und Warteschlangeneigenschaften wie **Priority (Priorität)** bearbeiten. Um die Priorität über die CLI oder API-Operationen festzulegen, verwenden Sie den Parameter `wlm_json_configuration`. Weitere Informationen finden Sie unter [Workload-Management-Konfiguration](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) im *Amazon-Redshift-Verwaltungshandbuch*. Im folgenden `wlm_json_configuration`-Beispiel werden drei Benutzergruppen definiert (`ingest`, `reporting` und `analytics`). Die Abfragen, die von den Benutzern dieser Gruppen übermittelt werden, werden jeweils mit den Prioritäten `highest`, `normal` und `low` ausgeführt. ``` [ { "user_group": [ "ingest" ], "priority": "highest", "queue_type": "auto" }, { "user_group": [ "reporting" ], "priority": "normal", "queue_type": "auto" }, { "user_group": [ "analytics" ], "priority": "low", "queue_type": "auto", "auto_wlm": true } ] ``` ## Ändern der Abfragepriorität mittels Abfrageüberwachungsregeln Abfrageüberwachungsregeln (Query Monitoring Rules, QMR) ermöglichen Ihnen die Änderung der Priorität einer Abfrage basierend auf ihrem Verhalten während der Ausführung. Hierzu geben Sie zusätzlich zu einer Aktion das Prioritätsattribut in einem QMR-Prädikat an. Weitere Informationen finden Sie unter [WLM-Abfrageüberwachungsregeln](cm-c-wlm-query-monitoring-rules.md). Sie können beispielsweise eine Regel definieren, nach der Abfragen mit der Priorität `high` abgebrochen werden, wenn sie länger als 10 Minuten ausgeführt werden. ``` "rules" :[ { "rule_name":"rule_abort", "predicate":[ { "metric_name":"query_cpu_time", "operator":">", "value":600 }, { "metric_name":"query_priority", "operator":"=", "value":"high" } ], "action":"abort" } ] ``` Sie können auch eine Regel definieren, nach der die Priorität aller Abfragen mit der Priorität `lowest` in `normal` geändert wird, wenn sie mehr als 1 TB auf der Festplatte belegen. ``` "rules":[ { "rule_name":"rule_change_priority", "predicate":[ { "metric_name":"query_temp_blocks_to_disk", "operator":">", "value":1000000 }, { "metric_name":"query_priority", "operator":"=", "value":"normal" } ], "action":"change_query_priority", "value":"lowest" } ] ``` ## Konfigurieren der Abfragepriorität Um die Priorität für wartende und ausgeführte Abfragen anzuzeigen, zeigen Sie die Spalte `query_priority` in der Systemtabelle „stv\$1wlm\$1query\$1state“ an. ``` query | service_cl | wlm_start_time | state | queue_time | query_priority ---------+------------+----------------------------+------------------+------------+---------------- 2673299 | 102 | 2019-06-24 17:35:38.866356 | QueuedWaiting | 265116 | Highest 2673236 | 101 | 2019-06-24 17:35:33.313854 | Running | 0 | Highest 2673265 | 102 | 2019-06-24 17:35:33.523332 | Running | 0 | High 2673284 | 102 | 2019-06-24 17:35:38.477366 | Running | 0 | Highest 2673288 | 102 | 2019-06-24 17:35:38.621819 | Running | 0 | Highest 2673310 | 103 | 2019-06-24 17:35:39.068513 | QueuedWaiting | 62970 | High 2673303 | 102 | 2019-06-24 17:35:38.968921 | QueuedWaiting | 162560 | Normal 2673306 | 104 | 2019-06-24 17:35:39.002733 | QueuedWaiting | 128691 | Lowest ``` Um die Abfragepriorität abgeschlossener Abfragen anzuzeigen, zeigen Sie die Spalte `query_priority` in der Systemtabelle „stl\$1wlm\$1query“ an. ``` select query, service_class as svclass, service_class_start_time as starttime, query_priority from stl_wlm_query order by 3 desc limit 10; ``` ``` query | svclass | starttime | query_priority ---------+---------+----------------------------+---------------------- 2723254 | 100 | 2019-06-24 18:14:50.780094 | Normal 2723251 | 102 | 2019-06-24 18:14:50.749961 | Highest 2723246 | 102 | 2019-06-24 18:14:50.725275 | Highest 2723244 | 103 | 2019-06-24 18:14:50.719241 | High 2723243 | 101 | 2019-06-24 18:14:50.699325 | Low 2723242 | 102 | 2019-06-24 18:14:50.692573 | Highest 2723239 | 101 | 2019-06-24 18:14:50.668535 | Low 2723237 | 102 | 2019-06-24 18:14:50.661918 | Highest 2723236 | 102 | 2019-06-24 18:14:50.643636 | Highest ``` Um den Durchsatz Ihres Workloads zu optimieren, kann Amazon Redshift die Priorität der von Benutzern übermittelten Abfragen ändern. Amazon Redshift verwendet fortschrittliche Machine-Learning-Algorithmen, um zu ermitteln, wann diese Optimierung Ihrem Workload zugutekommt, und wendet sie automatisch an, wenn alle folgenden Bedingungen erfüllt sind. + Automatisches WLM ist aktiviert. + Es ist nur eine WLM-Warteschlange definiert. + Sie haben keine Regeln zur Abfrageüberwachung (QMRs) definiert, die die Abfragepriorität festlegen. Dazu gehören zum Beispiel die QMR-Metrik `query_priority` oder die QMR-Aktion `change_query_priority`. Weitere Informationen finden Sie unter [WLM-Abfrageüberwachungsregeln](cm-c-wlm-query-monitoring-rules.md).