Esta es una introducción detallada a las capacidades de aislamiento de cargas de trabajo de . 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: Apache Doris 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. https://www.youtube.com/watch?v=Wd3l5C4k8Ok&embedable=true Aislamiento de recursos basado en etiqueta de recurso Comencemos con la arquitectura de Apache Doris. Doris tiene dos : 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. tipos de nodos 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 para su ejecución. grupos de recursos Por ejemplo, si desea separar las cargas de trabajo de lectura y escritura en un clúster 3-BE, puede seguir estos pasos: : vincule 2 BE a la etiqueta "Lectura" y 1 BE a la etiqueta "Escritura". Asigne etiquetas de recursos a nodos BE : 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. Asigne etiquetas de recursos a réplicas de datos : 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. Asigne grupos de cargas de trabajo a etiquetas de recursos Resource Tag también permite 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. . la tenencia múltiple 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 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. Workload Group 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 , que es conceptualmente similar a los pesos. A los grupos de cargas de trabajo con mayor se les asignará más tiempo de CPU durante un intervalo de tiempo. cpu_share cpu_share Por ejemplo, si el Grupo A está configurado con un 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. cpu_share 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 y el Grupo B con . 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. cpu_hard_limit=10% cpu_hard_limit=90% 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 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. memory_limit En el estado inicial, a un grupo de recursos de alta prioridad se le asignará más memoria. Al configurar , 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. enable_memory_overcommit 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 . 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. de cola de consultas El mecanismo de la cola de consultas implica tres parámetros: , y . max_concurrency max_queue_size 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: , los dos clientes consumen los recursos de la CPU en partes iguales. Sin configurar grupos de carga de trabajo y configurar en 2:1, la relación de rendimiento de los dos clientes es 2:1. Con un más alto, el Cliente 1 recibe una mayor porción de recursos de CPU y ofrece un mayor rendimiento. Al configurar grupos de cargas de trabajo cpu_share cpu_share Prueba de límite estricto de CPU Inicie un cliente, establezca 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. cpu_hard_limit=50% 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 , 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. un 50% de utilización 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: (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. Sin grupo de carga 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. Configuración del grupo de cargas 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: : 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. Etiqueta de recurso : para casos de uso en los que un clúster realiza varias cargas de trabajo de consultas para una asignación flexible de recursos. Grupo de cargas de trabajo 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
