Evaluación y reflexión en profundidad sobre el modo de tolerancia a fallas de Trino

Este artículo es compartido por la comunidad de la nube de Huawei " Hacia la integración del análisis interactivo y el procesamiento por lotes: evaluación y reflexión en profundidad sobre el modo de tolerancia a fallas Trino ", autor: Respaldo de nivel 9 de HetuEngine.

Este artículo fue creado originalmente por el equipo de I + D de Big Data de Huawei Cloud. Autor original: Wenbo, Mengyue

1 Introducción a Trino

El 27 de diciembre de 2020, los líderes de la comunidad de Presto, Martin Traverso, Dain Sundstrom y David Phillips, anunciaron que el nombre del proyecto de código abierto PrestoSQL se cambiaría a TrinoDB (denominado Trino en este artículo).

Trino es un motor de consultas SQL distribuido, de alto rendimiento y de código abierto diseñado para ejecutar consultas analíticas interactivas en una variedad de fuentes de datos heterogéneas, admitiendo volúmenes de datos que van desde GB hasta PB. Trino está especialmente diseñado para análisis interactivos. Puede realizar consultas combinadas sobre datos de diferentes fuentes de datos (incluidos: Hive, AWS S3, Alluxio, MySQL, Kafka, ES, etc.) y proporciona un buen marco de extensión de programación de conectores personalizados. Ideal para escenarios de analistas donde se esperan tiempos de respuesta desde menos de segundos hasta minutos.

En el momento de su nacimiento, Trino fue diseñado para llenar el vacío entre las consultas internas en tiempo real de Facebook y el procesamiento ETL. El objetivo principal de Trino es proporcionar consultas interactivas, que es lo que a menudo llamamos consultas ad-hoc. Muchas empresas lo utilizan como motor informático OLAP. En los últimos años, los escenarios comerciales se han vuelto cada vez más complejos. Además de los escenarios de consultas interactivas, muchas empresas también deben tener en cuenta las operaciones de procesamiento por lotes. Los líderes tecnológicos han comenzado a pensar en cómo utilizar Trino para el procesamiento por lotes de grandes conjuntos de datos. .

2 Limitaciones de la arquitectura tradicional Trino

En la arquitectura de ejecución tradicional de Trino, Trino planifica previamente todas las tareas para procesar consultas específicas. Estas tareas están relacionadas entre sí y el resultado de una tarea es el aporte de la siguiente. Para los motores MPP, esta interdependencia es necesaria. Una vez que cualquier tarea falla durante este proceso, toda la cadena de tareas se destruirá, lo que provocará que se cierre toda la ejecución de SQL.

El proceso de ejecución de tareas SQL por parte de Trino se muestra a continuación (del sitio web oficial de Trino):

ventaja:

Los datos se transmiten a través de tareas sin puntos de control intermedios, lo que da como resultado un alto rendimiento y una baja latencia.

insuficiente:

• Falta de recuperación de fallas detallada: si ocurre un problema, solo puede ejecutar la consulta completa desde cero
• Depende completamente de los recursos de memoria para la carga e intercambio de datos.
• Una vez que se determina el plan de ejecución, no se puede ajustar de manera flexible de acuerdo con el progreso real de la implementación.

3 Arquitectura de ejecución tolerante a fallos (FTE) de Trino

La comunidad de código abierto Trino ha diseñado una nueva arquitectura de ejecución tolerante a fallas que nos permite implementar una programación avanzada basada en recursos con reintentos detallados. El proyecto lleva el nombre en código "Tardigrade".

El Proyecto Tardigrade tiene como objetivo romper la antigua barrera de implementación del todo o nada. Brinda muchas oportunidades nuevas para la gestión de recursos, la optimización adaptativa de consultas y la recuperación de fallas. El proyecto lleva el nombre del tardígrado, la criatura más indestructible del mundo, similar a la robustez que FTE aporta a Trino.

Los siguientes son algunos efectos intuitivos que aporta el proyecto Tardigrade:

• Cuando una consulta SQL de larga duración encuentra un error, no es necesario ejecutarla desde cero;
• Cuando Query requiere más memoria de la que está disponible actualmente en el clúster, aún puede ejecutarse correctamente;
• Cuando se envían varias consultas al mismo tiempo, pueden compartir recursos de manera justa y ejecutarse de manera constante.

Desde una perspectiva de implementación de código, Trino implementa funciones básicas como tolerancia a fallas a nivel de tarea, reintento automático y reproducción aleatoria directamente en el kernel. Como se muestra en la siguiente imagen (del sitio web oficial de Trino):

Trino dividirá la ejecución de una consulta en varias etapas. En el modo tolerante a fallas, los datos aleatorios de la etapa ascendente se escribirán en el disco (admite la escritura en AWS S3, HDFS y almacenamiento local). La etapa descendente lee los datos requeridos del almacenamiento intermedio y vuelve a optimizar y asignar tareas posteriores en el proceso.

Mejoras aportadas:

• Planificación adaptativa : los planes de consulta se pueden ajustar dinámicamente mientras se almacenan los datos en el buffer.
• Gestión de recursos : ajuste la asignación de recursos mientras se ejecuta la consulta. Cuando el clúster está inactivo, podemos permitir que una única consulta utilice todos los recursos disponibles en el clúster. Cuando comienza más carga de trabajo, la asignación de recursos para la consulta inicial se puede reducir gradualmente.
• Recuperación de fallas detallada : permite que las tareas fallidas se reinicien de forma transparente, lo que hace que los tiempos de finalización de ETL sean más predecibles.

A continuación, este artículo lo llevará a experimentar en profundidad el modo de ejecución tolerante a fallas de Trino.

4 Prueba de rendimiento básica

Primero, realice una prueba de rendimiento básica en un escenario con suficientes recursos informáticos. Seleccione TPCDS con un volumen de datos de 1 TB y la especificación de recursos informáticos es 2CN+16Worker 136 GB/proceso. Pruebe antes y después de activar la tolerancia a fallas y ejecute TPCDS99. Las estadísticas que consumen mucho tiempo son las siguientes:

Para probar el rendimiento de escritura, seleccione catalog_sales, la tabla más grande en la tabla TPCDS, para probar el rendimiento de escritura. El SQL es:

--- crear tabla catalog_sales_copy como select * from catalog_sales;

Los datos de la prueba son los siguientes:

conjunto de datos	Recursos informáticos	Tiempo de ejecución (unidad: segundos)
Deshabilitar la tolerancia a fallas y el derrame	Tolerancia a fallos de tarea	Tolerancia a fallas de tarea + derrame
1TB	1CN+2Trabajador,20GB/proceso	622.2	673	687
10TB	1CN+3Trabajador,136GB/proceso	3445	1485	1486

resumen:

• Habilitar la tolerancia a fallos de la tarea hará que los resultados del área de intercambio intermedia se vacíen en el disco, lo que provocará una pérdida de rendimiento y el tiempo de ejecución será aproximadamente el doble que antes;
• La tolerancia a fallas de consultas no tiene un proceso de ubicación de disco y el rendimiento es el mismo que no habilitar la tolerancia a fallas.
• Cuando se utiliza un conjunto de datos de 1 TB, el rendimiento de escritura tolerante a fallos de la tarea también sufrirá una pérdida del 8% al 10 %, pero cuando se utiliza un conjunto de datos de 10 TB, el rendimiento mejorará, lo que debe analizarse en profundidad;

5 Prueba de estabilidad para escenarios de grandes volúmenes de datos

Esta sección llevará a cabo una prueba de estrés de TPCDS en un escenario donde los recursos informáticos son muy insuficientes. Los resultados de la prueba son los siguientes:

La cantidad de datos	Recursos informáticos	Tasa de error
Sin tolerancia a fallos	Tolerancia a fallos de tarea	Tolerancia a fallas de tareas + derrame al disco
1TB	1CN+2Trabajador, 40GB/proceso	7,07%	0%	0%
1CN+2Trabajador,20GB/proceso	12,12%	0%	0%
1CN+2Trabajador,10GB/proceso	16,16%	4,04%	0%
10TB	1CN+3Trabajador,136GB/proceso	8,08%	0%	0%
50TB	1CN+16Trabajador,136GB/proceso	13,13%	6,06%	5,05%

resumen:

• El uso de la tolerancia a fallas de tareas cuando la memoria es insuficiente puede mejorar en gran medida la tasa de éxito de la ejecución de SQL. Utilizado junto con la función de derrame en disco, puede brindar una mejor tolerancia a fallas;
• Cuando se utiliza un conjunto de datos de 50 TB, la tolerancia a fallas de la tarea aún puede mejorar la tasa de éxito de la ejecución, pero algunos SQL complejos pueden tener un cuello de botella en un solo punto. Actualmente se observa que el principal cuello de botella es la agregación de un solo punto.

6 Pruebas de escenarios de alta concurrencia

6.1 Conjunto de datos estándar TPCD de 1 TB

Especificaciones de recursos informáticos: 1CN+8Worker, 136GB/proceso

Caso de uso de prueba de SQL: P01 (consulta de asociación de tablas de múltiples hechos, P29 en TPCDS99)

Los resultados de la prueba se muestran en la siguiente tabla:

escenarios de prueba	1 concurrente	100 concurrentes	200 concurrentes
Deshabilitar la tolerancia a fallos	CONSULTA tolerancia a fallos	TAREA tolerancia a fallos	Deshabilitar la tolerancia a fallos	CONSULTA tolerancia a fallos	TAREA tolerancia a fallos	Deshabilitar la tolerancia a fallos	CONSULTA tolerancia a fallos	TAREA tolerancia a fallos
Consulta relacionada con varias tablas (tabla de múltiples hechos) Ronda Q01-1	4,1/min	5,2/min	2,6/min	7,3/min	7,2/min	8,1/min	17,50% falló	18% falló	7,9/min
Consulta relacionada con varias tablas (tabla de múltiples hechos) Ronda Q01-5	5,2/min	4,8/min	3,4/min	8,3/min	8,6/min	8,6/min	64,9% falló	74,9% falló	8,5/min

6.2 Conjunto de datos estándar TPCD de 10 TB

Especificaciones de recursos informáticos: 1CN+8Worker, 136GB/proceso

Caso de prueba SQL:

Consulta de clasificación de agregación de varias columnas de una sola tabla P02:

seleccionar

• ws_item_sk,
• ws_web_site_sk,
• suma(ws_sales_price) total

de

• web_ventas

dónde

• ws_fecha_venta_sk >= 2450815
• y ws_sold_date_sk <= 2451179

agrupar por

• ws_item_sk,
• ws_web_site_sk

teniendo

• suma(ws_sales_price) > 0

ordenar por

• descripción total

límite 100;

Activar la tolerancia a fallas de TASK se puede ejecutar con éxito. Los resultados de la prueba se muestran en la siguiente tabla:

escenarios de prueba	1 concurrente	100 concurrentes	200 concurrentes	300 concurrentes	400 concurrentes
Sin tolerancia a fallos	TAREA tolerancia a fallos	Sin tolerancia a fallos	TAREA tolerancia a fallos	Sin tolerancia a fallos	TAREA tolerancia a fallos	Sin tolerancia a fallos	TAREA tolerancia a fallos	Sin tolerancia a fallos	TAREA tolerancia a fallos
Consulta de clasificación de agregación de varias columnas de una sola tabla Q02_1 ronda	3,3/min	1,3/min	7,9/min	5,7/min	9,7/min	8,8/min	8,5/min	5,9/min	97,25% falló	6,8/min
Consulta de clasificación de agregación de varias columnas de una sola tabla Q02_5 ronda	7,1/min	2,0/min	10,7/min	9,5/min	10,3/min	9,3/min	8,20% falló	8,0/min	99,1% falló	6,6/min

resumen:

La tolerancia a fallas de tareas puede aumentar el límite de concurrencia del motor Trino y reducir en gran medida la aparición de errores como "Encontré demasiados errores al hablar con un nodo trabajador".

7 pruebas de comparación horizontal de múltiples motores

Primero, seleccione los casos de uso de SQL de TPCDS99 que fallarán al 100% si Trino no habilita la tolerancia a fallas cuando los recursos informáticos son limitados, incluidos:

Q04,Q11,Q23,Q38,Q64,Q65,Q67,Q74,Q75,Q78,Q80,Q81,Q85,Q87,Q93,Q95,Q97.

Con base en los mismos recursos informáticos (memoria, CPU, cantidad de contenedores), compare horizontalmente el rendimiento de Trino, Spark y Hive (TEZ).

Nota: Al probar Trino, en realidad se utilizó la versión del kernel de Huawei Cloud HetuEngine 2.0.

7.1 Conjunto de datos estándar TPCD de 1 TB

 

Se puede ver que con 1 TB de datos y usando los mismos recursos, Trino puede ejecutar con éxito el SQL que originalmente falló cuando se activa la tolerancia a fallas de la tarea, y su rendimiento es aproximadamente tres veces mayor que el de Spark y docenas de veces mayor que el de Hive ( TEZ).

7.2 Conjunto de datos estándar TPCDS de 10 TB

Realice una prueba comparativa con el conjunto de datos estándar TPCDS de 10 TB:

Se puede ver que, bajo la condición de un volumen de datos de 10 TB y utilizando los mismos recursos, Trino puede ejecutar con éxito el SQL que originalmente falló cuando se activó la tolerancia a fallas de la tarea, y el rendimiento es aproximadamente 3 veces mayor que el de Spark.

8 Evaluación integral

En resumen, según los datos de la prueba, el resumen es el siguiente:

Rendimiento básico concurrente único

1. Recursos de memoria suficientes: deshabilitar la tolerancia a fallas = Consultar tolerancia a fallas> Tolerancia a fallas de tarea
2. Recursos de memoria insuficientes: se puede ejecutar la tolerancia a fallas de tareas, pero la tolerancia a fallas no está habilitada/la tolerancia a fallas de consultas no puede producir resultados.

Estabilidad en escenarios de grandes volúmenes de datos

Tolerancia a fallos de tarea + derrame en disco > Tolerancia a fallos de tarea > Deshabilitar tolerancia a fallos

• Conjunto de datos de 1 a 10 TB: el rendimiento de la tolerancia a fallas de la tarea es muy estable y la tasa de aprobación es del 100%
• Conjunto de datos de 50 TB: combinar la tolerancia a fallos de tareas y la transferencia al disco funciona mejor que usar solo la tolerancia a fallos de tareas (un caso de uso fallido menos)

Estabilidad en escenarios concurrentes

Tolerancia a fallos de tarea > Desactivar tolerancia a fallos

Comparación de rendimiento horizontal de múltiples motores

• Conjunto de datos TPCDS de 1 TB: Trino (tolerancia a fallos de tareas) > Spark > Hive (TEZ)
• Conjunto de datos TPCDS de 10 TB: Trino (tolerancia a fallos de tareas) > Spark

En general, la función FTE de Trino superó las expectativas en términos de rendimiento y estabilidad. Con la evolución y mejora gradual de esta capacidad, creo que Trino desempeñará un papel más importante en escenarios de análisis y procesamiento de datos integrales.

9 Pensamientos y mejoras

Después de tener datos de prueba de primera mano y conclusiones de análisis, a continuación pensaremos en cómo hacer un buen uso del modo de tolerancia a fallas de Trino y maximizar su valor, al mismo tiempo que debemos identificar posibles problemas de antemano y explorar soluciones.

9.1 Decisión de habilitación del modo Fault Tolerance

De los datos de prueba anteriores se puede ver que activar el modo de tolerancia a fallas tiene un cierto impacto en el rendimiento de consultas cortas (por el contrario, existe la posibilidad de optimizar el rendimiento de consultas grandes). Por lo tanto, debemos pensar en cuándo y cómo activar el modo de tolerancia a fallos.

Hay las siguientes ideas para elegir——

• Los usuarios pueden optar por activar

La forma más sencilla es permitir que los usuarios empresariales elijan habilitar o deshabilitar el modo de tolerancia a fallas a su propia discreción. Normalmente, los usuarios experimentados saben qué consultas probablemente serán costosas desde el punto de vista computacional o tardarán mucho en ejecutarse. Pueden cambiar de manera flexible entre "modo interactivo" y "modo tolerante a fallas" cambiando los parámetros de sesión de la conexión JDBC;

• toma de decisiones basada en costos

Puede decidir si habilitar el "modo de tolerancia a fallos" según el costo previsto de ejecución de SQL. Generalmente, esta técnica se basa en estadísticas a nivel de columna obtenidas mediante la implementación de estadísticas. Sin embargo, las estadísticas a nivel de columna a veces no están disponibles y la precisión de la predicción basada en estimaciones de costos a menudo no es ideal;

• tecnología de selección adaptativa

De forma predeterminada, la consulta se puede iniciar en "modo interactivo" y luego, después de ejecutarse durante N minutos, después de un período de aprendizaje, el núcleo del motor tomará una decisión independiente para iniciar o desactivar el "modo tolerante a fallas" según recursos disponibles, características del negocio y otra información dimensional. Esta idea requiere combinar el motor Trino con el aprendizaje automático y la tecnología de inteligencia artificial para implementar la ruta de integración de la inteligencia digital;

• Toma de decisiones basada en información histórica

Para ciertos tipos de consultas contra fuentes de datos específicas, los registros históricos en ejecución se pueden recopilar con anticipación, analizarlos y modelarlos. Según el modelo de conocimiento previo aprendido de antemano, se selecciona el modo de ejecución óptimo antes de la ejecución de SQL.

9.2 Aplicaciones de escala de expansión horizontal

Trino tiene un modo de ejecución tolerante a fallas y los datos de prueba muestran buenos resultados, entonces todos pensarán: ¿Podemos proporcionar servicios de aceleración de consultas de análisis a mayor escala basados ​​​​en esta capacidad?

En escenarios comerciales reales, es posible que las empresas necesiten enviar tareas y programación elástica de recursos según demanda, especialmente en entornos nativos de la nube a gran escala. Incluso si el modo de tolerancia a fallas está activado, para un solo clúster Trino, su nodo coordinador (Coordinador ) todavía puede tener capacidades de concurrencia. Además, desde la perspectiva de la arquitectura del software, existen ciertos riesgos en la disponibilidad de un único clúster Trino, lo que afecta el logro de los objetivos de SLA en un entorno de servicios en la nube.

En respuesta a los problemas anteriores, el motor de análisis interactivo de Huawei Cloud, HetuEngine, proporciona una arquitectura distribuida de tres niveles y proporciona una dirección de servicio JDBC globalmente única a la empresa a través de un portal de acceso SQL unificado: HSFabric .

A través del portal de acceso SQL unificado de HSFabric, HetuEngine desacopla la lógica de la capa empresarial de una instancia informática específica. Se pueden expandir horizontalmente varias instancias informáticas dentro de un solo inquilino de recursos y las tareas SQL dentro del mismo inquilino se pueden distribuir de manera flexible entre diferentes instancias informáticas.

Ya sea desde una perspectiva de múltiples inquilinos o de un solo inquilino, la capacidad concurrente de HetuEngine se puede expandir horizontalmente y al mismo tiempo mejorar la disponibilidad del servicio y la utilización de recursos.

Basado en la arquitectura anterior, HetuEngine permite a los administradores de servicios decidir libremente si activar o desactivar el modo de ejecución tolerante a fallas de un solo inquilino para satisfacer mejor los requisitos comerciales de diferentes escenarios.

9.3 Solución de problemas y recuperación

Durante la ejecución tolerante a fallas de Trino, una gran cantidad de datos aleatorios entre etapas caerán en el sistema de archivos distribuido. Puede haber problemas al analizar HDFS como ejemplo.

Supuesto: durante la ejecución de un SQL grande, Trino está escribiendo datos aleatorios en HDFS y, de repente, ocurre un accidente en el nodo de la máquina física donde se encuentra Trino (por ejemplo, corte de energía, desconexión de la red, falla del sistema operativo, etc.). o el propio Trino falla y deja de funcionar (por ejemplo, sobrecarga, etc.). Esto puede provocar que todo el clúster Trino deje de funcionar por completo. En este momento, se requiere la intervención manual del administrador para restaurar el estado de funcionamiento normal del clúster Trino.

Obviamente, para Trino, hay al menos dos problemas que es necesario pensar y resolver:

• Cómo lograr una emergencia y una recuperación rápida del clúster Trino
• Asegúrese de que los archivos residuales en HDFS se limpien a tiempo para evitar quedarse sin espacio de almacenamiento.

El motor de análisis interactivo de Huawei Cloud, HetuEngine, se basa en una arquitectura en contenedores + basada en servicios de tres capas y puede abordar de manera efectiva los desafíos anteriores:

Respecto a la pregunta 1 :

Con la ayuda de la arquitectura de implementación completamente en contenedores, cuando cualquier proceso de software en cualquier instancia informática de HetuEngine (correspondiente a 1 clúster Trino distribuido) falla o ocurre accidentalmente, la capa de Servicio puede lanzar rápida y automáticamente un nuevo proceso de contenedor. compensar las deficiencias del servicio y completar rápidamente la autocuración de fallas antes de la intervención manual.

Cuando los recursos disponibles pueden ser insuficientes, HetuEngine admite el escalado elástico en línea de instancias informáticas, equilibrando dinámicamente la utilización de recursos ajustando automáticamente la cantidad de trabajadores y reponiendo rápidamente los recursos del nodo trabajador perdidos debido a fallas.

Cuando falla el nodo Coordinador, HetuEngine responde desde tres aspectos:

1. Los nodos trabajadores en la misma instancia informática se conectan inmediatamente con el coordinador de respaldo;
2. El Coordinador de reserva es ascendido a nuevo Coordinador principal;
3. El portal SQL unificado dirige inmediatamente las nuevas solicitudes SQL al nuevo coordinador principal.

Respecto a la pregunta 2 :

La capa de servicio de HetuEngine monitorea las 24 horas del día, rastrea, descubre y limpia rápidamente los residuos del trabajo en todos los niveles (incluidos: datos, archivos, directorios, metadatos, etc.).

Al mismo tiempo, proporciona información detallada multidimensional sobre tareas históricas, genera gráficos de operación y mantenimiento de SQL de alto valor e información de recomendaciones para la toma de decisiones y, finalmente, los presenta en la página de la consola.

Los servicios integrales y considerados proporcionados por la capa de Servicio reducen en gran medida los requisitos de conocimiento profesional para los administradores de plataformas de análisis de datos y resuelven las preocupaciones de los administradores sobre las operaciones a largo plazo.

9.4 Expansión y contracción flexible del negocio de plataformas de big data sin pérdidas

En términos generales, la solución de escalamiento elástico de la plataforma de big data solo cubre motores de procesamiento por lotes como Hive y Spark. Debido a que Hive y Spark tienen capacidades de ejecución tolerantes a fallas, incluso si el plano de administración y control de la plataforma de big data emite una instrucción para reducir por la fuerza un nodo físico que está ejecutando un trabajo de Hive/Spark, esto no afectará el éxito de la ejecución final. del trabajo relacionado. Como máximo, solo provocará reintentos de tareas locales y aumentará el tiempo de ejecución. Por lo tanto, la solución de escalamiento elástico de la plataforma de big data para los motores Hive y Spark es relativamente fácil y solo necesita concentrarse en las operaciones de administración a nivel de recursos.

Sin embargo, para motores de arquitectura MPP como Trino, el modelo de gestión de escalamiento elástico de la plataforma de big data anterior puede enfrentar los siguientes desafíos:

• El motor SQL de la arquitectura MPP generalmente es residente. Si algún nodo se elimina por la fuerza durante el proceso de reducción, la tarea SQL que se ejecuta en el nodo puede fallar;
• El Coordinador del nodo de coordinación de Trino es 1 de forma predeterminada. Durante el proceso de escalado, eliminar el nodo donde se encuentra el Coordinador hará que todo el clúster de Trino no esté disponible y todas las tareas SQL en ejecución fallen;
• La expansión del clúster Trino requiere una comprensión profunda del mecanismo de trabajo y descubrimiento de servicios internos del clúster Trino desde el lado de la administración de la plataforma, y ​​configuraciones personalizadas para la IP y los números de puerto del clúster específico, de modo que se puedan agregar nuevos nodos con éxito. a un clúster Trino existente.

En resumen, para lograr un escalamiento elástico del motor ecológico Trino en el servicio de la plataforma de big data y lograr un negocio libre de pérdidas, es necesario abstraer un inquilino de múltiples recursos + múltiples cálculos entre la capa de servicio de la plataforma de big data y la Capa de kernel Trino Capa de servicio de acceso empresarial y gestión de recursos de instancias (clúster Trino).

La capa de servicio de HetuEngine protege los detalles subyacentes del kernel de Trino de la capa de servicio de la plataforma de big data, proporciona llamadas Rest API y convierte los requisitos de administración y operación de la capa de servicio de la plataforma de big data en cambios reales a clústeres de Trino específicos. Al mismo tiempo, se debe lograr el monitoreo diario del estado y el automantenimiento de múltiples clústeres Trino.

Según la arquitectura anterior, la capacidad de ejecución tolerante a fallas de Trino se puede utilizar para reducir aún más el tiempo de espera para el escalado elástico a nivel de plataforma de big data cuando el escalado elástico está habilitado.

Una idea factible es, a grandes rasgos, que la capa de servicio de la plataforma de big data emita instrucciones de reducción a la capa de servicio de HetuEngine. El servicio determina la instancia informática que se ejecuta en el nodo que está a punto de reducirse y la cambia dinámicamente al modo tolerante a fallas. . En circunstancias normales, la capa de servicio puede responder rápidamente a la capa de servicio superior que la operación de reducción está lista para continuar sin esperar a que se ejecute la tarea SQL.

9.5 Resumen

Con base en la arquitectura y las ideas anteriores, Huawei Cloud HetuEngine puede hacer frente a nuevos problemas que pueden ser introducidos por el modelo de ejecución tolerante a fallas, mejorar significativamente la eficiencia real de operación y mantenimiento del entorno de producción y ayudar a los usuarios a disfrutar fácilmente de los nuevos dividendos. de ejecución tolerante a fallos.

A continuación, HetuEngine introducirá y mejorará gradualmente la capacidad de cambiar de forma inteligente entre dos modos de ejecución diferentes, mejorará aún más la adaptación del escenario del escalamiento elástico de los servicios en la nube de big data y continuará innovando y evolucionando en el campo del análisis SQL integral en el lago de datos. .

10 Vista previa de la versión HetuEngine 2.0

Se espera que HetuEngine 2.0 se lance oficialmente con Huawei Cloud MRS 3.3.0-LTS el 30 de septiembre de 2023. En esta versión, puedes ver una serie de nuevas habilidades, como:

• Al ejecutar un nuevo kernel basado en Java17, el rendimiento básico y la estabilidad se han llevado a un nuevo nivel y la velocidad de TPCDS aumenta en un 30 %.
• Defensa activa de Big SQL: aviso previo/interceptación, disyuntor a mitad del evento, estadísticas posteriores al evento
• Admite el modo de ejecución tolerante a fallos: ámbito de aplicación más amplio, lo que permite el procesamiento y análisis de SQL en un solo lugar
• Arquitectura de instancias de múltiples computadoras dentro del inquilino: equilibrio de carga automático, escalabilidad horizontal de capacidades de concurrencia para una sola empresa
• Nuevos tipos de fuentes de datos: Hudi, MySQL
• Se agregó soporte para crear nuevas tablas Hudi e insertar datos.
• Se agregó soporte para que Hue se conecte a HetuEngine, proporcionando una página de edición visual de SQL.
• Se agregó soporte para el modo de usuario proxy para admitir la autenticación de proxy y la auditoría de los propios sistemas de usuario de los clientes.

Enlaces relacionados: https://support.huaweicloud.com/intl/zh-cn/cmpntguide-lts-mrs/mrs_01_1711.html

Haga clic para seguir y conocer las nuevas tecnologías de Huawei Cloud lo antes posible ~

El autor del marco de código abierto NanUI pasó a vender acero y el proyecto fue suspendido. La primera lista gratuita en la App Store de Apple es el software pornográfico TypeScript. Acaba de hacerse popular, ¿por qué los grandes empiezan a abandonarlo? Lista de octubre de TIOBE: Java tiene la mayor caída, C# se acerca Java Rust 1.73.0 lanzado Un hombre fue alentado por su novia AI a asesinar a la Reina de Inglaterra y fue sentenciado a nueve años de prisión Qt 6.6 publicado oficialmente Reuters: RISC-V La tecnología se convierte en la clave de la guerra tecnológica entre China y Estados Unidos. Nuevo campo de batalla RISC-V: no controlado por ninguna empresa o país, Lenovo planea lanzar una PC con Android.

{{o.nombre}}

{{m.nombre}}