O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Prioridade da consulta Com o Amazon Redshift, é possível gerenciar a priorização de consultas e a alocação de recursos em workloads e consultas simultâneas usando o gerenciamento de workloads (WLM). As seções a seguir detalham como configurar filas de consulta do WM, definir propriedades da fila, como alocação de memória e escalabilidade simultânea, e implementar regras de prioridade adaptadas aos requisitos da workload. Nem todas as consultas têm a mesma importância e, geralmente, a performance de um workload ou de um conjunto de usuários pode ser mais importante. Se você habilitou o [WLM automático](automatic-wlm.md) pode definir a importância relativa de consultas em um workload ao configurar um valor de prioridade. A prioridade é especificada para uma fila e herdada por todas as consultas associadas à fila. Associe as consultas a uma fila mapeando grupo de usuários e de consultas à fila. É possível definir as seguintes prioridades (listadas da prioridade mais alta para a mais baixa): 1. `HIGHEST` 1. `HIGH` 1. `NORMAL` 1. `LOW` 1. `LOWEST` Os administradores usam essas prioridades para mostrar a importância relativa de seus workloads quando há consultas com prioridades diferentes competindo pelos mesmos recursos. O Amazon Redshift usa a prioridade ao permitir consultas no sistema e determinar a quantidade de recursos alocados a uma consulta. Por padrão, as consultas são executadas com a prioridade definida como `NORMAL`. Uma prioridade adicional, `CRITICAL`, que é uma prioridade mais alta que `HIGHEST`, está disponível para superusuários. Para definir essa prioridade, é possível usar as funções [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). Para conceder a um usuário de banco de dados permissão para usar essas funções, é possível criar um procedimento armazenado e conceder permissão a um usuário. Para ver um exemplo, consulte [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md). **nota** Somente uma consulta `CRITICAL` pode ser executada por vez. As reversões sempre são executadas com prioridade CRITICAL. Vamos ver um exemplo onde a prioridade de um workload de extração, transformação e carregamento (ETL) é mais alta que a prioridade do workload de análise. O workload de ETL é executado a cada seis horas, e o workload de análise é executado durante todo o dia. Quando somente o workload de análise estiver em execução no cluster, ele obterá o sistema todo para ele mesmo, gerando alta taxa de transferência com utilização ideal do sistema. No entanto, quando o workload de ETL é iniciado, ele obtém direito ao caminho, pois tem uma prioridade maior. As consultas em execução como parte do workload de ETL obtém direito ao caminho durante a admissão, além da alocação de recursos preferencial após serem admitidas. Como consequência, o workload de ETL é executado de maneira previsível, independentemente do que mais possa estar sendo executado no sistema. Assim, ela fornece performance previsível e a capacidade de os administradores oferecerem acordos de nível de serviço (SLAs) para os usuários de negócios. Em determinado cluster, a performance previsível para uma workload de prioridade alta ocorre em detrimento de outras workloads de prioridade baixa. Os workloads de prioridade baixa podem ser executados por mais tempo, pois suas consultas aguardam que consultas mais importantes sejam concluídas. Ou elas podem ser executadas por mais tempo porque recebem uma fração menor de recursos quando são executadas simultaneamente com consultas de prioridade mais alta. As consultas de prioridade mais baixa não sofrem esgotamento, mas continuam a progredir em um ritmo mais lento. No exemplo anterior, o administrador pode habilitar a [escalabilidade da simultaneidade](concurrency-scaling.md) para o workload de análise. Isso permite que o workload mantenha sua taxa de transferência, mesmo que o workload de ETL esteja sendo executado com uma prioridade alta. ## Configurar a prioridade da fila Se você habilitou o WLM automático, cada fila tem um valor de prioridade. As consultas são roteadas para as filas com base nos grupos de usuários e nos grupos de consultas. Comece com uma prioridade de fila definida como `NORMAL`. Defina a prioridade como mais alta ou mais baixa com base no workload associado aos grupos de usuários e aos grupos de consultas da fila. Você pode alterar a prioridade de uma fila no console do Amazon Redshift. No console do Amazon Redshift, a página **Gerenciamento de workload** exibe as filas e permite a edição das propriedades da fila, como **Prioridade**. Para definir a prioridade usando a CLI ou as operações de API, use o parâmetro `wlm_json_configuration`. Para obter mais informações, consulte “[Configurar o gerenciamento de workload](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html)” no *Guia de gerenciamento de clusters do Amazon Redshift*. O exemplo de `wlm_json_configuration` a seguir define três grupos de usuários (`ingest`, `reporting` e `analytics`). As consultas enviadas de usuários de um desses grupos são executadas com prioridade `highest`, `normal` e `low`, respectivamente. ``` [ { "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 } ] ``` ## Alterar a prioridade da consulta com as regras de monitoramento de consulta As regras de monitoramento de consulta (QMR) permitem alterar a prioridade de uma consulta com base no comportamento dela durante a execução. É possível fazer isso especificando o atributo de prioridade em um predicado QMR, além de uma ação. Para obter mais informações, consulte [Regras de monitoramento de consulta do WLM](cm-c-wlm-query-monitoring-rules.md). Por exemplo, é possível definir uma regra para cancelar qualquer consulta classificada como prioridade `high` que seja executada por mais de 10 minutos. ``` "rules" :[ { "rule_name":"rule_abort", "predicate":[ { "metric_name":"query_cpu_time", "operator":">", "value":600 }, { "metric_name":"query_priority", "operator":"=", "value":"high" } ], "action":"abort" } ] ``` Outro exemplo é definir uma regra para alterar a prioridade de consulta para `lowest` para qualquer consulta com a prioridade atual `normal` que derrame mais de 1 TB no disco. ``` "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" } ] ``` ## Monitorar a prioridade da consulta Para exibir a prioridade de consultas em espera e em execução, visualize a coluna `query_priority` na tabela stv\$1wlm\$1query\$1state do sistema. ``` 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 ``` Para listar a prioridade de consultas concluídas, consulte a coluna `query_priority` na tabela stl\$1wlm\$1query do sistema. ``` 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 ``` Para otimizar a taxa de transferência do workload, o Amazon Redshift pode modificar a prioridade das consultas enviadas pelo usuário. O Amazon Redshift usa algoritmos avançados de Machine Learning para determinar quando essa otimização beneficia seu workload e a aplica automaticamente quando todas as condições a seguir forem atendidas. + O WLM automático está habilitado. + Apenas uma fila WLM é definida. + Você não definiu regras de monitoramento de consulta (QMRs) que definem a prioridade da consulta. Tais regras incluem a métrica QMR `query_priority` ou a ação QMR `change_query_priority`. Para obter mais informações, consulte [Regras de monitoramento de consulta do WLM](cm-c-wlm-query-monitoring-rules.md).