Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Implementación de WLM automática Con la administración de cargas de trabajo (WLM) automática, Amazon Redshift administra la simultaneidad de consultas y la asignación de memoria. Puede crear hasta ocho colas con los identificadores de clase de servicio 100-107. Cada cola tiene una prioridad. Para obtener más información, consulte [Prioridad de consulta](query-priority.md). La WLM automática determina la cantidad de recursos que necesitan las consultas y ajusta la simultaneidad en función de la carga de trabajo. Cuando en el sistema hay consultas que requieren grandes cantidades de recursos (por ejemplo, combinaciones hash entre tablas grandes), la simultaneidad es inferior. Cuando se envían consultas más ligeras (como por ejemplo inserciones, eliminaciones, exámenes o agregaciones sencillas), la simultaneidad es superior. La WLM automática es independiente de la aceleración de consultas cortas (SQA) y evalúa las consultas de forma diferente. La WLM automática y la SQA funcionan conjuntamente para permitir que las consultas ligeras y de corta ejecución se completen incluso si hay activas consultas de uso intensivo de recursos y de ejecución prolongada. Para obtener más información acerca de SQA, consulte [Aceleración de consultas cortas](wlm-short-query-acceleration.md). Amazon Redshift habilita la WLM automática a través de grupos de parámetros: + Si los clústeres utilizan el grupo de parámetros predeterminado, Amazon Redshift habilita la WLM automática para ellos. + Si los clústeres utilizan grupos de parámetros personalizados, puede configurar los clústeres para habilitar la WLM automática. Le recomendamos que cree un grupo de parámetros independiente para la configuración de WLM automática. Para configurar WLM, edite el parámetro `wlm_json_configuration` en un grupo de parámetros que se puede asociar a uno o varios clústeres. Para obtener más información, consulte [Modificación de la configuración de WLM](cm-c-implementing-workload-management.md#cm-c-modifying-wlm-configuration). Puede definir colas de consultas dentro de la configuración de WLM. Puede añadir colas de consultas adicionales a la configuración de WLM predeterminada, hasta llegar a un total de ocho colas de usuario. Para cada cola de consultas, puede configurar lo siguiente: + Prioridad + Modo de escalado de simultaneidad + Grupos de usuarios + Grupos de consultas + Reglas de monitorización de consultas ## Prioridad 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. Para obtener más información, consulte [Prioridad de consulta](query-priority.md). ## Modo de escalado de simultaneidad Cuando el escalado de simultaneidad está habilitado, Amazon Redshift agrega capacidad del clúster de manera automática si se necesita para procesar un aumento de las consultas de lectura y escritura simultáneas. Los usuarios ven siempre los datos más actualizados, tanto si las consultas se ejecutan en el clúster principal como si se ejecutan en un clúster de escalado de simultaneidad. Puede administrar qué consultas se envían al clúster de escalado de simultaneidad configurando colas de WLM. Cuando habilita el escalado de simultaneidad para una cola, las consultas elegibles se envían al clúster de escalado de simultaneidad en lugar de esperar en la cola. Para obtener más información, consulte [Escalado de simultaneidad](concurrency-scaling.md). ## Grupos de usuarios Puede asignar un conjunto de grupos de usuarios a una cola especificando cada nombre de grupo de usuarios o utilizando comodines. Cuando un miembro de un grupo de usuarios de la lista ejecuta una consulta, esa consulta se ejecuta en la cola correspondiente. No hay un límite establecido en cuanto al número de grupos de usuarios que se pueden asignar a una cola. Para obtener más información, consulte [Asignación de consultas a las colas en función de los grupos de usuarios](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-groups). ## Funciones de usuario Puede asignar un conjunto de roles de usuarios a una cola especificando cada nombre de rol de usuarios o utilizando comodines. Cuando un miembro de un rol de usuario de la lista ejecuta una consulta, esa consulta se ejecuta en la cola correspondiente. No hay un límite establecido en cuanto al número de roles de usuarios que se pueden asignar a una cola. Para obtener más información, consulte [Asignación de consultas a las colas en función de los roles de usuarios](cm-c-executing-queries.md#cm-c-executing-queries-assigning-queries-to-queues-based-on-user-roles). ## Grupos de consultas Puede asignar un conjunto de grupos de consultas a una cola especificando cada nombre de grupo de consultas o utilizando comodines. Un *grupo de consultas* es sencillamente una etiqueta. En tiempo de ejecución, puede asignar la etiqueta de grupo de consultas a un conjunto de consultas. Cualquier consulta que se asigne a un grupo de consultas de la lista se ejecuta en la cola correspondiente. No hay un límite establecido para el número de grupos de consultas que se pueden asignar a una cola. Para obtener más información, consulte [Asignación de una consulta a un grupo de consultas](cm-c-executing-queries.md#cm-c-executing-queries-assigning-a-query-to-a-query-group). ## Caracteres comodín Si los comodines están habilitados en la configuración de la cola de WLM, puede asignar grupos de usuarios y de consultas a una cola individualmente o utilizando los comodines de estilo shell Unix. La coincidencia de patrones no distingue entre mayúsculas y minúsculas. Por ejemplo, el comodín «\$1» coincide con cualquier número de caracteres. Así, si añade `dba_*` a la lista de grupos de usuario para una cola, cualquier consulta ejecutada por un usuario que pertenece a un grupo con un nombre que comienza por `dba_` se asigna a esa cola. Algunos ejemplos son `dba_admin` o `DBA_primary`. El comodín «?» coincide con cualquier carácter individual. Así, si la cola incluye el grupo de usuarios `dba?1`, entonces los grupos de usuarios denominados `dba11` y `dba21` coinciden, pero `dba12` no coincide. De forma predeterminada, los comodines no están habilitados. ## Reglas de monitorización de consultas Las reglas de monitorización de consultas definen los límites de rendimiento basados en métricas para las colas de WLM y especifican la acción que se debe realizar cuando una consulta va más allá de esos límites. Por ejemplo, para una cola dedicada a consultas de ejecución corta, puede crear una regla que cancele las consultas que se ejecuten durante más de 60 segundos. Para hacer un seguimiento de las consultas mal diseñadas, puede disponer de otra regla que registre las consultas que contienen bucles anidados. Para obtener más información, consulte [Reglas de monitoreo de consultas de WLM](cm-c-wlm-query-monitoring-rules.md). ## Comprobación de WLM automática Para saber si la WLM automática está habilitada, ejecute la consulta siguiente. Si la consulta devuelve al menos una fila, la WLM automática está habilitada. ``` select * from stv_wlm_service_class_config where service_class >= 100; ``` En la consulta siguiente, se muestra el número de consultas que pasaron por cada cola de consultas (clase de servicio). También se muestra el tiempo de ejecución medio, el número de consultas con un tiempo de espera establecido en el percentil 90 y el tiempo de espera medio. Las consultas de WLM automática utilizan las clases de servicio 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; ``` Para saber qué consultas se han ejecutado mediante la WLM automática y se han completado correctamente, ejecute la consulta siguiente. ``` 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; ``` # Prioridad de consulta Con Amazon Redshift, puede administrar la priorización de consultas y la asignación de recursos entre consultas y cargas de trabajo simultáneas mediante la administración de la carga de trabajo (WM). En las siguientes secciones se detalla cómo configurar las colas de consultas de WM, definir las propiedades de las colas, como la asignación de memoria y el escalado de simultaneidad, e implementar reglas de prioridad adaptadas a sus requisitos de carga de trabajo. 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](automatic-wlm.md), 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` 1. `HIGH` 1. `NORMAL` 1. `LOW` 1. `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\$1QUERY\$1PRIORITY](r_CHANGE_QUERY_PRIORITY.md), [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md) y [CHANGE\$1USER\$1PRIORITY](r_CHANGE_USER_PRIORITY.md). 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, consulta [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md). **nota** Solo se puede ejecutar una consulta `CRITICAL` a la vez. Las reversiones siempre tienen prioridad CRÍTICA. 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](concurrency-scaling.md) 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](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) 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](cm-c-wlm-query-monitoring-rules.md). 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\$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 ``` Para enumerar la prioridad de consulta para consultas completadas, vea la columna `query_priority` en la tabla del 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 ``` 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](cm-c-wlm-query-monitoring-rules.md).