Aislamiento de cargas de trabajo en Apache Doris: optimización de la gestión de recursos y el rendimiento

Esta es una introducción detallada a las capacidades de aislamiento de cargas de trabajo de Apache Doris . Pero antes que nada, ¿por qué y cuándo es necesario aislar la carga de trabajo? Si se identifica con alguna de las siguientes situaciones, siga leyendo y terminará con una solución:

• Tiene diferentes departamentos comerciales o inquilinos que comparten el mismo clúster y desea evitar interferencias en la carga de trabajo.

  
  

• Tiene tareas de consulta con distintos niveles de prioridad y desea dar prioridad a sus tareas críticas (como análisis de datos en tiempo real y transacciones en línea) en términos de recursos y ejecución.

  
  

• Necesita aislar la carga de trabajo, pero también desea una alta rentabilidad y tasas de utilización de recursos.

  
  

Apache Doris admite el aislamiento de cargas de trabajo basado en etiquetas de recursos y grupos de cargas de trabajo. La etiqueta de recurso aísla los recursos de CPU y memoria para diferentes cargas de trabajo en el nivel de los nodos de backend, mientras que el mecanismo del grupo de carga de trabajo puede dividir aún más los recursos dentro de un nodo de backend para una mayor utilización de los recursos.

Aislamiento de recursos basado en etiqueta de recurso

Comencemos con la arquitectura de Apache Doris. Doris tiene dos tipos de nodos : frontends (FE) y backends (BE). Los nodos FE almacenan metadatos, administran clústeres, procesan solicitudes de usuarios y analizan planes de consulta, mientras que los nodos BE son responsables del cálculo y el almacenamiento de datos. Por tanto, los nodos BE son los principales consumidores de recursos.

La idea principal de una solución de aislamiento basada en etiquetas de recursos es dividir los recursos informáticos en grupos asignando etiquetas a los nodos BE en un clúster, donde los nodos BE de la misma etiqueta constituyen un grupo de recursos. Un grupo de recursos puede considerarse como una unidad para el almacenamiento y cálculo de datos. Para los datos ingeridos en Doris, el sistema escribirá réplicas de datos en diferentes grupos de recursos según las configuraciones. Las consultas también se asignarán a sus correspondientes grupos de recursos para su ejecución.

Por ejemplo, si desea separar las cargas de trabajo de lectura y escritura en un clúster 3-BE, puede seguir estos pasos:

1. Asigne etiquetas de recursos a nodos BE : vincule 2 BE a la etiqueta "Lectura" y 1 BE a la etiqueta "Escritura".

   
   

2. Asigne etiquetas de recursos a réplicas de datos : suponiendo que la Tabla 1 tiene 3 réplicas, vincule 2 de ellas a la etiqueta "Lectura" y 1 a la etiqueta "Escritura". Los datos escritos en la Réplica 3 se sincronizarán con la Réplica 1 y la Réplica 2, y el proceso de sincronización de datos consume pocos recursos de BE 1 y BE2.

   
   

3. Asigne grupos de cargas de trabajo a etiquetas de recursos : las consultas que incluyen la etiqueta "Lectura" en sus SQL se enrutarán automáticamente a los nodos etiquetados con "Lectura" (en este caso, BE 1 y BE 2). Para las tareas de escritura de datos, también debe asignarles la etiqueta "Write" para que puedan enrutarse al nodo correspondiente (BE 3). De esta manera, no habrá contención de recursos entre las cargas de trabajo de lectura y escritura, excepto los gastos generales de sincronización de datos de la réplica 3 a las réplicas 1 y 2.

Resource Tag también permite la tenencia múltiple en Apache Doris. Por ejemplo, los recursos informáticos y de almacenamiento etiquetados con "Usuario A" son solo para el Usuario A, mientras que aquellos etiquetados con "Usuario B" son exclusivos del Usuario B. Así es como Doris implementa el aislamiento de recursos multiinquilino con Etiquetas de Recursos en el lado BE. .

Dividir los nodos BE en grupos garantiza un alto nivel de aislamiento :

• La CPU, la memoria y las E/S de diferentes inquilinos están físicamente aisladas.

  
  

• Un inquilino nunca se verá afectado por las fallas (como fallas en el proceso) de otro inquilino.

  
  

Pero tiene algunas desventajas:

• En la separación de lectura y escritura, cuando se detiene la escritura de datos, los nodos BE etiquetados con "Escritura" quedan inactivos. Esto reduce la utilización general del clúster.

  
  

• En el modo multiinquilino, si desea aislar aún más diferentes cargas de trabajo del mismo inquilino asignando nodos BE separados a cada uno de ellos, deberá soportar costos significativos y una baja utilización de recursos.

  
  

• La cantidad de inquilinos está vinculada a la cantidad de réplicas de datos. Entonces, si tiene 5 inquilinos, necesitará 5 réplicas de datos. Esa es una enorme redundancia de almacenamiento.

  
  

Para mejorar esto, proporcionamos una solución de aislamiento de cargas de trabajo basada en Workload Group en Apache Doris 2.0.0 y mejorada en Apache Doris 2.1.0 .

Aislamiento de carga de trabajo basado en grupo de carga de trabajo

La solución basada en Workload Group logra una división más granular de los recursos. Además, divide los recursos de CPU y memoria dentro de los procesos en los nodos BE, lo que significa que las consultas en un nodo BE pueden aislarse entre sí hasta cierto punto. Esto evita la competencia de recursos dentro de los procesos de BE y optimiza la utilización de los recursos.

Los usuarios pueden relacionar consultas con grupos de cargas de trabajo, limitando así el porcentaje de recursos de CPU y memoria que puede utilizar una consulta. Bajo cargas de clúster elevadas, Doris puede eliminar automáticamente las consultas que consumen más recursos en un grupo de cargas de trabajo. Con cargas de clúster bajas, Doris puede permitir que varios grupos de cargas de trabajo compartan recursos inactivos.

Doris admite tanto el límite suave de CPU como el límite estricto de CPU. El límite flexible permite a los grupos de cargas de trabajo superar el límite y utilizar recursos inactivos, lo que permite una utilización más eficiente. El límite estricto es una garantía estricta de rendimiento estable porque evita el impacto mutuo de los grupos de cargas de trabajo.

(El límite flexible de CPU y el límite estricto de CPU son contradictorios entre sí. Puede elegir entre ellos según su propio caso de uso).

Sus diferencias con la solución basada en etiquetas de recursos incluyen:

• Los grupos de carga de trabajo se forman dentro de los procesos. Varios grupos de cargas de trabajo compiten por recursos dentro del mismo nodo BE.

  
  

• La consideración de la distribución de réplicas de datos está fuera de lugar porque Workload Group es solo una forma de gestión de recursos.

Límite suave de CPU

El límite suave de la CPU se implementa mediante el parámetro cpu_share , que es conceptualmente similar a los pesos. A los grupos de cargas de trabajo con mayor cpu_share se les asignará más tiempo de CPU durante un intervalo de tiempo.

Por ejemplo, si el Grupo A está configurado con un cpu_share de 1 y el Grupo B, 9. En un intervalo de tiempo de 10 segundos, cuando tanto el Grupo A como el Grupo B estén completamente cargados, el Grupo A y el Grupo B podrán consumir 1 s y 9 segundos de tiempo de CPU, respectivamente.

Lo que sucede en casos del mundo real es que no todas las cargas de trabajo del clúster se ejecutan a plena capacidad. Por debajo del límite flexible, si el Grupo B tiene una carga de trabajo baja o nula, entonces el Grupo A podrá utilizar las decenas de tiempo de CPU, lo que aumentará la utilización general de la CPU en el clúster.

Un límite suave aporta flexibilidad y una mayor tasa de utilización de recursos. Por otro lado, podría provocar fluctuaciones en el rendimiento.

Límite estricto de CPU

El límite estricto de CPU en Apache Doris 2.1.0 está diseñado para usuarios que requieren un rendimiento estable. En términos simples, el límite estricto de CPU define que un grupo de cargas de trabajo no puede utilizar más recursos de CPU que su límite, ya sea que haya recursos de CPU inactivos o no.

Así es como funciona:

Supongamos que el Grupo A está configurado con cpu_hard_limit=10% y el Grupo B con cpu_hard_limit=90% . Si tanto el Grupo A como el Grupo B se ejecutan a plena carga, el Grupo A y el Grupo B utilizarán respectivamente el 10% y el 90% del tiempo total de CPU. La diferencia radica en cuando disminuye la carga de trabajo del Grupo B. En tales casos, independientemente de qué tan alta sea la carga de consultas del Grupo A, no debe utilizar más del 10 % de los recursos de CPU que se le han asignado.

A diferencia de un límite suave, un límite estricto garantiza un rendimiento estable del sistema a costa de la flexibilidad y la posibilidad de una mayor tasa de utilización de recursos.

Límite de recursos de memoria

La memoria de un nodo BE consta de las siguientes partes:

• Memoria reservada para el sistema operativo.

  
  

• Memoria consumida por no consultas, que no se considera en las estadísticas de memoria del grupo de carga de trabajo.

  
  

• Las consultas consumen memoria, incluida la escritura de datos. Esto puede ser rastreado y controlado por Workload Group.

  
  

El parámetro memory_limit define la memoria máxima (%) disponible para un grupo de cargas de trabajo dentro del proceso BE. También afecta la prioridad de los grupos de recursos.

En el estado inicial, a un grupo de recursos de alta prioridad se le asignará más memoria. Al configurar enable_memory_overcommit , puede permitir que los grupos de recursos ocupen más memoria que los límites cuando hay espacio inactivo. Cuando la memoria es escasa, Doris cancelará tareas para recuperar los recursos de memoria que comprometen. En este caso, el sistema retendrá tantos recursos de memoria como sea posible para los grupos de recursos de alta prioridad.

cola de consultas

Sucede que el clúster está asumiendo más cargas de las que puede manejar. En este caso, enviar nuevas solicitudes de consulta no sólo será infructuoso sino que también interrumpirá las consultas en curso.

Para mejorar esto, Apache Doris proporciona el mecanismo de cola de consultas . Los usuarios pueden poner un límite a la cantidad de consultas que se pueden ejecutar simultáneamente en el clúster. Una consulta será rechazada cuando la cola de consultas esté llena o después de un tiempo de espera, lo que garantiza la estabilidad del sistema bajo cargas elevadas.

El mecanismo de la cola de consultas implica tres parámetros: max_concurrency , max_queue_size y queue_timeout .

Pruebas

Para demostrar la efectividad del límite suave y estricto de la CPU, realizamos algunas pruebas.

• Entorno: máquina única, 16 núcleos, 64 GB

  
  

• Despliegue: 1 FE + 1 BE

  
  

• Conjunto de datos: ClickBench, TPC-H

  
  

• Herramienta de prueba de carga: Apache JMeter

Prueba de límite suave de CPU

Inicie dos clientes y envíe consultas continuamente (ClickBench Q23) con y sin utilizar grupos de carga de trabajo, respectivamente. Tenga en cuenta que la caché de página debe desactivarse para evitar que afecte los resultados de la prueba.

Comparando los rendimientos de los dos clientes en ambas pruebas, se puede concluir que:

• Sin configurar grupos de carga de trabajo , los dos clientes consumen los recursos de la CPU en partes iguales.

  
  

• Al configurar grupos de cargas de trabajo y configurar cpu_share en 2:1, la relación de rendimiento de los dos clientes es 2:1. Con un cpu_share más alto, el Cliente 1 recibe una mayor porción de recursos de CPU y ofrece un mayor rendimiento.

Prueba de límite estricto de CPU

Inicie un cliente, establezca cpu_hard_limit=50% para el grupo de carga de trabajo y ejecute ClickBench Q23 durante 5 minutos con un nivel de simultaneidad de 1, 2 y 4, respectivamente.

A medida que aumenta la simultaneidad de las consultas, la tasa de utilización de la CPU se mantiene en torno al 800 %, lo que significa que se utilizan 8 núcleos. En una máquina de 16 núcleos, eso es un 50% de utilización , que es lo esperado. Además, dado que se imponen límites estrictos de CPU, el aumento de la latencia de TP99 a medida que aumenta la simultaneidad también es un resultado esperado.

Prueba en entorno de producción simulado.

En el uso del mundo real, los usuarios están particularmente preocupados por la latencia de las consultas en lugar de solo por el rendimiento de las consultas, ya que la latencia es más fácilmente perceptible en la experiencia del usuario. Por eso decidimos validar la eficacia de Workload Group en un entorno de producción simulado.

Seleccionamos un conjunto de SQL que consta de consultas que deben finalizarse en 1 segundo (ClickBench Q15, Q17, Q23 y TPC-H Q3, Q7, Q19), incluidas agregaciones de tabla única y consultas de unión. El tamaño del conjunto de datos TPC-H es de 100 GB.

De manera similar, realizamos pruebas con y sin configurar Grupos de cargas de trabajo.

Como muestran los resultados:

• Sin grupo de carga de trabajo (comparando las pruebas 1 y 2): al aumentar la simultaneidad del Cliente 2, ambos clientes experimentan un aumento de 2 a 3 veces en la latencia de las consultas.

  
  

• Configuración del grupo de cargas de trabajo (comparando las pruebas 3 y 4): a medida que aumenta la concurrencia del Cliente 2, la fluctuación de rendimiento en el Cliente 1 es mucho menor, lo que es una prueba de cómo está protegido eficazmente mediante el aislamiento de la carga de trabajo.

Recomendaciones y planes

La solución basada en etiquetas de recursos es un plan exhaustivo de aislamiento de cargas de trabajo. La solución basada en Workload Group logra un mejor equilibrio entre el aislamiento y la utilización de recursos y se complementa con el mecanismo de cola de consultas para garantizar la estabilidad.

Entonces, ¿cuál debería elegir para su caso de uso? Aquí está nuestra recomendación:

• Etiqueta de recurso : para casos de uso en los que diferentes líneas de negocio de departamentos comparten el mismo clúster, por lo que los recursos y los datos están físicamente aislados para diferentes inquilinos.

  
  

• Grupo de cargas de trabajo : para casos de uso en los que un clúster realiza varias cargas de trabajo de consultas para una asignación flexible de recursos.

  
  

En futuras versiones, seguiremos mejorando la experiencia del usuario del grupo de cargas de trabajo y las funciones de la cola de consultas:

• Liberar espacio en la memoria cancelando consultas es un método brutal. Planeamos implementar esto mediante el derrame de disco, lo que brindará una mayor estabilidad en el rendimiento de las consultas.

  
  

• Dado que la memoria consumida por no consultas en BE no se incluye en las estadísticas de memoria del grupo de cargas de trabajo, los usuarios pueden observar una disparidad entre el uso de la memoria del proceso BE y el uso de la memoria del grupo de cargas de trabajo. Abordaremos este tema para evitar confusiones.

  
  

• En el mecanismo de la cola de consultas, la carga del clúster se controla estableciendo la simultaneidad máxima de consultas. Planeamos habilitar la simultaneidad de consultas máxima dinámica según la disponibilidad de recursos en el BE. Esto crea contrapresión en el lado del cliente y, por lo tanto, mejora la disponibilidad de Doris cuando los clientes siguen enviando cargas elevadas.

  
  

• La idea principal de Resource Tag es agrupar los nodos BE, mientras que la de Workload Group es dividir aún más los recursos de un solo nodo BE. Para captar estas ideas, los usuarios primero deben aprender sobre el concepto de nodos BE en Doris. Sin embargo, desde una perspectiva operativa, los usuarios sólo necesitan comprender el porcentaje de consumo de recursos de cada una de sus cargas de trabajo y qué prioridad deben tener cuando la carga del clúster está saturada. Por lo tanto, intentaremos encontrar una manera de aplanar la curva de aprendizaje para los usuarios, como mantener el concepto de nodos BE en la caja negra.

  
  

Para obtener más ayuda sobre el aislamiento de cargas de trabajo en Apache Doris, únase a la comunidad de Apache Doris .