Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Implementazione del WLM automatico
Con la gestione automatica del carico di lavoro (WLM), Amazon Redshift gestisce la simultaneità delle query e l'allocazione della memoria. Vengono create fino a otto code con identificatori della classe di servizio da 100 a 107. Ogni coda ha una priorità. Per ulteriori informazioni, consulta [Priorità delle query](query-priority.md).
Il WLM automatico determina la quantità di risorse necessaria alle query e regola la simultaneità in base al carico di lavoro. Quando nel sistema sono presenti query che richiedono quantità elevate di risorse (ad esempio, hash join tra tabelle di grandi dimensioni), il livello di simultaneità è inferiore. Se vengono inviate query più piccole (come inserimenti, eliminazioni, scansioni o semplici aggregazioni), il livello di simultaneità è maggiore.
WLM automatico è distinto dall'accelerazione di query brevi (short query acceleration, SQA) e valuta le query in modo diverso. WLM automatico e SQA lavorano insieme per consentire il completamento di query leggere e di breve esecuzione anche in presenza di code lunghe e che fanno un uso intensivo delle risorse. Per ulteriori informazioni su SQA, consultare [Accelerazione di query brevi](wlm-short-query-acceleration.md).
Amazon Redshift abilita la WLM automatica tramite gruppi di parametri:
+ Se i cluster utilizzano il gruppo di parametri di default, Amazon Redshift abilita la WLM automatica.
+ Se i cluster utilizzano gruppi di parametri personalizzati, puoi configurarli per l'abilitazione di WLM automatico. Ti consigliamo di creare un gruppo di parametri distinto per la configurazione di WLM automatico.
Per configurare WLM, modifica il parametro `wlm_json_configuration` in un gruppo di parametri che può essere associato a uno o più cluster. Per ulteriori informazioni, consultare [Modifica della configurazione WLM](cm-c-implementing-workload-management.md#cm-c-modifying-wlm-configuration).
Definisci le code di query all'interno della configurazione WLM. Puoi aggiungere altre code di query alla configurazione WLM predefinita, fino a un totale di otto code dell'utente. Per ogni coda di query puoi configurare le seguenti opzioni:
+ Priorità
+ Modalità dimensionamento simultaneo
+ Gruppi di utenti
+ Gruppi di query
+ Regole di monitoraggio delle query
## Priorità
Puoi definire l'importanza relativa delle query in un carico di lavoro impostando un valore di priorità. La priorità viene specificata per una coda e la ereditano tutte le query associate alla coda. Per ulteriori informazioni, consultare [Priorità delle query](query-priority.md).
## Modalità dimensionamento simultaneo
Quando il dimensionamento simultaneo è abilitato, Amazon Redshift aggiunge automaticamente ulteriore capacità del cluster quando necessario per elaborare un aumento delle query di lettura r scrittura simultanee. Gli utenti visualizzano sempre i dati più recenti, indipendentemente dal fatto che le query vengano eseguite nel cluster principale o in un cluster di dimensionamento simultaneo.
È possibile gestire le query inviate al cluster di dimensionamento simultaneo configurando le code di gestione del carico di lavoro. Quando abiliti il dimensionamento simultaneo per una coda, le query idonee vengono inviate al cluster di dimensionamento simultaneo anziché attendere in coda. Per ulteriori informazioni, consulta [Dimensionamento simultaneo](concurrency-scaling.md).
## Gruppi di utenti
Puoi assegnare un set di gruppi di utenti a una coda specificando il nome di ogni gruppo di utenti o utilizzando i caratteri jolly. Quando un membro di un gruppo utenti elencato esegue una query, quella query viene eseguita nella coda corrispondente. Non esiste un limite impostato per il numero di gruppi di utenti che possono essere assegnati a una coda. Per ulteriori informazioni, consulta [Assegnazione delle query alle code in base ai gruppi di utenti](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups).
## Ruoli utente
Puoi assegnare un set di ruoli utente a una coda specificando il nome di ogni ruolo utente o utilizzando i caratteri jolly. Quando un membro di un ruolo utente elencato esegue una query, tale query viene eseguita nella coda corrispondente. Non esiste un limite impostato per il numero di ruoli utente che possono essere assegnati a una coda. Per ulteriori informazioni, consulta [Assegnazione delle query alle code in base ai ruoli degli utenti](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles).
## Gruppi di query
Puoi assegnare un set di gruppi di query a una coda specificando il nome di ogni gruppo di query o utilizzando i caratteri jolly. Un *gruppo di query* è semplicemente un'etichetta. In fase di runtime, puoi assegnare l'etichetta del gruppo di query a una serie di query. Qualsiasi query che viene assegnata a un gruppo di query elencato verrà eseguita nella coda corrispondente. Non esiste un limite definito per il numero di gruppi di query che possono essere assegnati a una coda. Per ulteriori informazioni, consulta [Assegnazione di una query a un gruppo di utenti](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group).
## Caratteri jolly
Se i caratteri jolly sono abilitati nella configurazione della coda WLM, è possibile assegnare gruppi di utenti e gruppi di query a una coda individualmente o utilizzando i caratteri jolly nello stile shell Unix. La corrispondenza del modello fa distinzione tra maiuscole e minuscole.
Ad esempio, il carattere jolly “\$1” corrisponde a qualsiasi numero di caratteri. Pertanto, se aggiungi `dba_*` all'elenco dei gruppi di utenti di una coda, qualsiasi query eseguita dagli utenti che appartiene a un gruppo con un nome che inizia con `dba_` verrà assegnata a quella coda. Alcuni esempi sono `dba_admin` o `DBA_primary`. Il carattere jolly “?” corrisponde a qualsiasi carattere singolo. Pertanto, se la coda include il gruppo di utenti `dba?1`, i gruppi di utenti denominati `dba11` e `dba21` corrisponderanno, ma non quelli chiamati `dba12`.
Per impostazione predefinita, i caratteri jolly non sono abilitati.
## Regole di monitoraggio delle query
Le regole di monitoraggio delle query definiscono i limiti delle prestazioni basati sui parametri per le code WLM e specificano l'azione da intraprendere quando una query oltrepassa tali limiti. Ad esempio, per una coda dedicata alle query di breve durata, puoi creare una regola che annulla le query eseguite per più di 60 secondi. Per tracciare le query mal progettate, potresti avere un'altra regola che registra le query che contengono cicli annidati. Per ulteriori informazioni, consultare [Regole di monitoraggio delle query WLM](cm-c-wlm-query-monitoring-rules.md).
## Controllo di WLM automatico
Per controllare se WLM automatico è abilitato, esegui la seguente query. Se la query restituisce almeno una riga, WLM automatico è abilitato.
```
select * from stv_wlm_service_class_config
where service_class >= 100;
```
La seguente query mostra il numero di query che hanno sostato in ciascuna coda di query (classe di servizio). Mostra anche il tempo medio di esecuzione, il numero di query con tempo di attesa al 90° percentile e il tempo medio di attesa. Le query di WLM automatico utilizzano le classi di servizio da 100 a 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;
```
Per sapere quali query sono state eseguite e completate correttamente da WLM automatico, esegui la seguente query.
```
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;
```
# Priorità delle query
Con Amazon Redshift puoi gestire l’assegnazione delle priorità delle query e l’allocazione delle risorse tra query e carichi di lavoro simultanei utilizzando la gestione dei carichi di lavoro. Nelle sezioni seguenti viene descritto nei dettagli come configurare le code di query della gestione dei carichi di lavoro, definire le proprietà delle code come l’allocazione della memoria e il dimensionamento simultaneo e implementare le regole di priorità personalizzate in base ai requisiti del carico di lavoro.
Non tutte le query hanno la stessa importanza; spesso le prestazioni di un carico di lavoro o di un set di utenti possono essere più importanti. Se hai abilitato [WLM automatico](automatic-wlm.md), puoi definire l'importanza relativa delle query in un carico di lavoro impostando un valore di priorità. La priorità viene specificata per una coda e la ereditano tutte le query associate alla coda. Le query vengono associate a una coda mappando gruppi di utenti e gruppi di query alla coda. Puoi impostare le seguenti priorità (elencate da quella più alta a quella più bassa):
1. `HIGHEST`
1. `HIGH`
1. `NORMAL`
1. `LOW`
1. `LOWEST`
Gli amministratori utilizzano queste priorità per illustrare l'importanza relativa dei carichi di lavoro quando query con priorità diverse si contendono le stesse risorse. Amazon Redshift utilizza la priorità quando lascia query nel sistema e per determinare la quantità di risorse allocate a una query. Per impostazione predefinita, le query vengono eseguite con priorità impostata su `NORMAL`.
Una priorità aggiuntiva, `CRITICAL`, superiore a `HIGHEST`, è disponibile per gli utenti con privilegi avanzati. Per impostare questa priorità, puoi utilizzare le funzioni [CHANGE\$1QUERY\$1PRIORITY](r_CHANGE_QUERY_PRIORITY.md), [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md) e [CHANGE\$1USER\$1PRIORITY](r_CHANGE_USER_PRIORITY.md). Per concedere a un utente di database l'autorizzazione per l'uso di queste funzioni, puoi creare una procedura archiviata e concedere l'autorizzazione a un utente. Per un esempio, consultare [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md).
**Nota**
Si può eseguire solo una query `CRITICAL` alla volta.
I rollback vengono sempre eseguiti con priorità CRITICA.
Prendiamo un esempio in cui la priorità di un carico di lavoro ETL (estrazione, trasformazione, carico) è superiore a quella del carico di lavoro analitico. Il carico di lavoro ETL viene eseguito ogni sei ore, mentre quello analitico è in esecuzione per tutto il giorno. Quando solo il carico di lavoro analitico è in esecuzione sul cluster, attira tutte le risorse su di sé, ottenendo un elevato throughput e un utilizzo ottimale del sistema. Tuttavia, quando si avvia il carico di lavoro ETL, questo ha la precedenza, dal momento che ha una priorità maggiore. Le query eseguite come parte del carico di lavoro ETL hanno la precedenza durante l'ammissione e un'allocazione preferenziale delle risorse dopo l'ammissione. Di conseguenza, il carico di lavoro ETL ottiene prestazioni prevedibili indipendentemente da qualsiasi altra operazione in esecuzione nel sistema. Pertanto, offre prestazioni prevedibili e la possibilità per gli amministratori di fornire accordi sui livelli di servizio (SLAs) per i propri utenti aziendali.
All'interno di un determinato cluster, le prestazioni prevedibili di un carico di lavoro con priorità superiori vanno a scapito di altri carichi di lavoro con priorità minori. L'esecuzione dei carichi di lavoro con priorità inferiori può durare più a lungo perché le loro query attendono il completamento di query più importanti. O perché ricevono una frazione più piccola di risorse quando vengono eseguite simultaneamente a query con priorità maggiore. Le query con priorità minore non soffrono un uso eccessivo delle risorse, ma progrediscono a un ritmo più lento.
Nell'esempio precedente, l'amministratore può abilitare il [dimensionamento della simultaneità](concurrency-scaling.md) per il carico di lavoro analitico. In questo modo il carico di lavoro mantiene il proprio throughput anche se il carico di lavoro ETL viene eseguito con priorità elevata.
## Configurazione della priorità di coda
Se hai abilitato WLM automatico, ogni coda ha un valore di priorità. Le query vengono instradata in base ai gruppi di utenti e ai gruppi di query. Iniziare con una priorità della coda impostata su `NORMAL`. Imposta la priorità come maggiore o minore in base al carico di lavoro associato ai gruppi di utenti e ai gruppi di query della coda.
È possibile modificare la priorità di una coda nella console Amazon Redshift. Nella console Amazon Redshift, la pagina **Gestione del carico di lavoro** visualizza le code e permette la modifica delle proprietà come **Priorità**. Per impostare la priorità tramite la CLI o le operazioni API; utilizza il parametro `wlm_json_configuration`. Per informazioni, consulta [Configurazione della gestione del carico di lavoro](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) nella *Guida alla gestione di Amazon Redshift*.
Il seguente esempio `wlm_json_configuration` definisce tre gruppi di utenti (`ingest`, `reporting` e `analytics`). Le query inviate dagli utenti di uno di questi gruppi vengono eseguite rispettivamente con priorità `highest`, `normal` e `low`.
```
[
{
"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
}
]
```
## Modifica della priorità delle query con le regole di monitoraggio delle query
Le regole di monitoraggio delle query (QMR) ti permettono di modificare la priorità di una query in base al suo comportamento durante l'esecuzione. Ciò avviene quando, oltre a un'operazione, specifichi l'attributo di priorità in un predicato QMR. Per ulteriori informazioni, consulta [Regole di monitoraggio delle query WLM](cm-c-wlm-query-monitoring-rules.md).
Ad esempio, puoi definire una regola per annullare tutte le query classificate con priorità `high` che vengono eseguite per più di 10 minuti.
```
"rules" :[
{
"rule_name":"rule_abort",
"predicate":[
{
"metric_name":"query_cpu_time",
"operator":">",
"value":600
},
{
"metric_name":"query_priority",
"operator":"=",
"value":"high"
}
],
"action":"abort"
}
]
```
Un altro esempio è quello di definite una regola che modifica la priorità in `lowest` per tutte le query con priorità attuale `normal` che riversano su disco più di 1 TB.
```
"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"
}
]
```
## Monitoraggio della priorità delle query
Per visualizzare la priorità delle query in esecuzione e in attesa, osserva la colonna `query_priority` nella tabella di sistema stv\$1wlm\$1query\$1state.
```
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
```
Per un elenco della priorità delle query completate, visualizza la colonna `query_priority` nella tabella di sistema stl\$1wlm\$1query.
```
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
```
Per ottimizzare la velocità effettiva del carico di lavoro, Amazon Redshift potrebbe modificare la priorità delle query inviate dall'utente. Amazon Redshift utilizza algoritmi avanzati di machine learning per determinare quando questa ottimizzazione avvantaggia il carico di lavoro e la applica automaticamente quando vengono soddisfatte tutte le seguenti condizioni.
+ La gestione automatica del carico di lavoro (WLM) è abilitata.
+ È definita una sola coda WLM.
+ Non sono state definite regole di monitoraggio delle interrogazioni (QMRs) che impostino la priorità delle interrogazioni. Tali regole includono il parametro QMR `query_priority` o l'operazione QMR `change_query_priority`. Per ulteriori informazioni, consultare [Regole di monitoraggio delle query WLM](cm-c-wlm-query-monitoring-rules.md).