Prioridade da consulta

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 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):

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

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 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” 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 ter mais informações, consulte Regras de monitoramento de consulta do WLM.

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