Priorità delle query

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à.

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à.

Con Amazon Redshift, puoi gestire la prioritizzazione delle query e l'allocazione delle risorse tra query e carichi di lavoro simultanei utilizzando Workload Management (WM). Le seguenti sezioni descrivono in dettaglio come configurare le code di query WM, definire le proprietà delle code come l'allocazione della memoria e la scalabilità simultanea e implementare 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, 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):

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_QUERY_PRIORITY, CHANGE_SESSION_PRIORITY e CHANGE_USER_PRIORITY. 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_SESSION_PRIORITY.

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 sul livello 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à 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 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.

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_wlm_query_state.

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_wlm_query.

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.