Prioridad de consulta

No todas las consultas tienen la misma importancia y, con frecuencia, el rendimiento de una carga de trabajo o de un conjunto de usuarios podría ser más importante. Si ha habilitado la WLM automática, puede definir la importancia relativa de las consultas en una carga de trabajo estableciendo un valor de prioridad. La prioridad se especifica para una cola y la heredan todas las consultas asociadas a la cola. Asocie las consultas a una cola asignando grupos de usuarios y grupos de consultas a la cola. Puede establecer las propiedades siguientes (enumeradas de prioridad más alta a más baja):

1. HIGHEST

2. HIGH

3. NORMAL

4. LOW

5. LOWEST

Los administradores utilizan estas prioridades para mostrar la importancia relativa de las cargas de trabajo cuando hay consultas con distintas prioridades que compiten por los mismos recursos. Amazon Redshift utiliza la prioridad cuando permite que se ingresen consultas en el sistema y también para determinar la cantidad de recursos asignados a una consulta. De forma predeterminada, las consultas se ejecutan con su prioridad establecida en NORMAL.

Una prioridad adicional, CRITICAL, que es una prioridad mayor que HIGHEST, está disponible para los superusuarios. Para establecer esta prioridad, puede utilizar las funciones CHANGE_QUERY_PRIORITY, CHANGE_SESSION_PRIORITY y CHANGE_USER_PRIORITY. Para conceder a una base de datos permisos de usuario para utilizar estas funciones, puede crear un procedimiento almacenado y conceder un permiso a un usuario. Para ver un ejemplo, consulte CHANGE_SESSION_PRIORITY.

nota

Solo se puede ejecutar una consulta CRITICAL a la vez.

Veamos un ejemplo donde la prioridad de una carga de trabajo de extracción, transformación, carga (ETL) es superior a la prioridad de la carga de trabajo de análisis. La carga de trabajo ETL se ejecuta cada seis horas y la carga de trabajo de análisis se ejecuta a lo largo del día. Cuando solo se ejecuta la carga de trabajo de análisis en el clúster, consigue todo el sistema para sí produciendo un rendimiento alto con una utilización óptima del sistema. Sin embargo, cuando se inicia la carga de trabajo de ETL, obtiene el derecho de paso ya que tiene una prioridad más alta. Las consultas que se ejecutan como parte de la carga de trabajo de ETL obtienen el derecho de paso durante la admisión además de la asignación de recursos preferente después de que se admitan. En consecuencia, la carga de trabajo de ETL tiene un rendimiento predecible con independencia de los demás elementos que se estén ejecutando en el sistema. De este modo, proporciona un rendimiento predecible y la capacidad para los administradores de proporcionar acuerdos de nivel de servicio (SLA) para sus usuarios empresariales.

Dentro de un clúster determinado, el rendimiento predecible para una carga de trabajo de alta prioridad se hace a expensas de otras cargas de trabajo de menor prioridad. Las cargas de trabajo de prioridad inferior podrían tardar más tiempo en ejecutarse ya que sus consultas esperan a que se completen consultas más importantes. O, podrían tardar más tiempo, dado que están obteniendo una fracción de recursos inferior cuando se ejecutan de forma simultánea con consultas de prioridad más alta. Las consultas de prioridad inferior no sufren el agotamiento, sino que siguen avanzando a un ritmo más lento.

En el ejemplo anterior, el administrador puede habilitar el escalado simultáneo para la carga de trabajo de análisis. Esto permite que la carga de trabajo mantenga su rendimiento, incluso aunque la carga de trabajo de ETL se está ejecutando con prioridad alta.

Configuración de prioridad de colas

Si ha habilitado la WLM automática, cada cola tiene un valor de prioridad. Las consultas se direccionan a las colas en función de los grupos de usuarios y de consultas. Comience con una prioridad de cola configurada como NORMAL. Defina la prioridad más alta o más baja en función de la carga de trabajo asociada a los grupos de usuario de la cola y los grupos de consulta.

Puede cambiar la prioridad de una cola en la consola de Amazon Redshift. En la consola de Amazon Redshift, la página Workload Management (Administración de cargas de trabajo) muestra las colas y habilita la edición de sus propiedades, como Priority (Prioridad). Para establecer la prioridad utilizando las operaciones de la CLI o de la API, utilice el parámetro wlm_json_configuration. Para obtener más información, consulte Configuración de la administración de cargas de trabajo en la Guía de administración de Amazon Redshift.

El siguiente ejemplo de wlm_json_configuration define tres grupos de usuarios (ingest, reporting y analytics). Las consultas enviadas de los usuarios de uno de estos grupos se ejecutan con prioridad highest, normal y 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
    }
]

Cambio de la prioridad de consulta con reglas de monitoreo de consultas

Las reglas de monitorización de consultas (QMR) le permiten cambiar la prioridad de una consulta en función de su comportamiento mientras está en ejecución. Esto se hace especificando el atributo de prioridad en un predicador de QMR además de una acción. Para obtener más información, consulte Reglas de monitoreo de consultas de WLM.

Por ejemplo, puede definir una regla para cancelar cualquier consulta clasificada como prioridad high que se ejecute durante más 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"
  }
]

Otro ejemplo consiste en definir una regla para cambiar la prioridad de consulta a lowest para cualquier consulta con la prioridad actual normal que vierte más de 1 TB en 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"
  }
]

Monitoreo de la prioridad de consulta

Para mostrar la prioridad para consultas en espera y en ejecución, vea la columna query_priority en la tabla del 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           

Para enumerar la prioridad de consulta para consultas completadas, vea la columna query_priority en la tabla del 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            

Para optimizar el rendimiento de la carga de trabajo, es posible que Amazon Redshift modifique la prioridad de las consultas enviadas por el usuario. Amazon Redshift utiliza algoritmos avanzados de machine learning para determinar cuáles son los momentos en que esta optimización beneficia a la carga de trabajo y la aplica automáticamente cuando se cumplen todas las condiciones que se indican a continuación.

• La WLM automática está habilitada.

• Solo se define una cola de WLM.

• No ha definido reglas de monitoreo de consultas (QMR) que establezcan la prioridad de las consultas. Estas reglas incluyen la métrica de QMR query_priority o la acción de QMR change_query_priority. Para obtener más información, consulte Reglas de monitoreo de consultas de WLM.