Volcano Engine ByteHouse: resumen de 4000 palabras, cinco pensamientos sobre la aplicación de Serverless en el campo OLAP

Para más intercambios técnicos y oportunidades laborales, siga la cuenta oficial de WeChat de ByteDance Data Platform y responda [1] para ingresar al grupo de comunicación oficial.

Como próxima versión de la computación en la nube, Serverless permite a los desarrolladores centrarse más en crear aplicaciones en productos sin tener que considerar problemas subyacentes de la pila. A medida que la madurez de las tecnologías relacionadas ha aumentado en los últimos años, la aceptación de Serverless por parte del mercado también se ha vuelto cada vez mayor. Se puede decir que hoy, Serverless ha entrado en una vía de desarrollo de alta velocidad hacia la madurez y la estabilidad.

Como almacén de datos nativo de la nube lanzado por Volcano Engine, ByteHouse se basa en ClickHouse de código abierto y ha mejorado aún más las capacidades, el rendimiento, la operación y el mantenimiento y la arquitectura del motor OLAP bajo la prueba de los escenarios internos y externos de ByteDance. Además, ByteHouse también está explorando la dirección de Serverless. Ha construido una nueva generación de almacén de datos basado en el concepto de nativo de la nube. La arquitectura se ha desacoplado en tres niveles. Se espera que con el apoyo de Serverless, proporcionará servicios de análisis más estables, confiables y confiables, liberará el tiempo y la energía de los desarrolladores de la optimización de la operación y el mantenimiento de la infraestructura y se centrará más en las funciones comerciales principales.

Este artículo proviene del intercambio de Li Qun, gerente de producto de ByteHouse de Volcano Engine, e introduce el pensamiento de aplicación sin servidor en el campo OLAP desde cinco aspectos: selección de escena, umbral de aplicación y aplicación de inicio.

¿Qué escenarios de aplicación son adecuados para elegir la arquitectura sin servidor?

En el campo del análisis de datos OLAP, primero veamos qué modos de análisis no son adecuados para la arquitectura sin servidor:

  1. Tareas largas, trabajos grandes: si la tarea de análisis necesita ejecutarse durante mucho tiempo (por ejemplo, más de 20 minutos), el uso de la tecnología Serverless será limitado. Debido a que las plataformas sin servidor generalmente establecen límites en el tiempo máximo de ejecución, exceder el límite provocará la interrupción de la tarea.

  2. Computación intensiva : la tecnología sin servidor suele ser adecuada para procesar tareas livianas, mientras que para tareas altamente computacionales se requieren más recursos informáticos. Sin embargo, actualmente no existe ningún almacén de datos comercial sin servidor en la industria que pueda proporcionar una escala de potencia informática de más de 2000. vcore., y 2000 vcore, convertidos en una máquina física de uso general o bare metal, tienen solo la potencia informática de 20 servidores. A menudo, los requisitos de potencia informática de algunos sistemas analíticos de tamaño mediano superan con creces esta escala.

  3. Tipo de lectura y escritura de alta concurrencia : La tecnología sin servidor se caracteriza por compartir recursos. Para tareas de análisis con requisitos de alta concurrencia, es probable que se produzcan cuellos de botella en el rendimiento. Por un lado, esto se debe al límite superior del tamaño del recurso compartido. pool y, por otro lado, la competencia entre múltiples inquilinos por el uso de recursos compartidos.

  4. Patrón de carga estable con pocas fluctuaciones : las plataformas sin servidor generalmente se ejecutan bajo demanda y, si se requieren aplicaciones de larga duración, la tecnología sin servidor no es adecuada.

En resumen, la tecnología sin servidor es adecuada para procesar negocios de análisis livianos, de corto plazo y de baja concurrencia , y es adecuada para empresas con características obvias de volatilidad en los patrones de carga; también es adecuada para empresas de tipo canalización y tipo middleware, como Flink Computación en tiempo real, cola de mensajes Kafka y ejecución de tareas ETL, etc.

La tecnología sin servidor no es adecuada para servicios de análisis de lectura y escritura de alta concurrencia, uso intensivo de computación y larga duración que requieren un funcionamiento continuo.

¿Cuáles son las barreras para aplicar la tecnología Serverless?

En el campo de OLAP, ya sea el camino de evolución desde la arquitectura MPP clásica a la arquitectura sin servidor, o la arquitectura sin servidor recientemente construida basada en el concepto nativo de nube Cloud-Native, todos enfrentan los mismos desafíos técnicos:

  1. Separación de almacenamiento y cálculo.

Desacoplar la informática y el almacenamiento es un primer paso fundamental en la arquitectura sin servidor, pero los desafíos técnicos son muy grandes, como por ejemplo: cómo garantizar que el rendimiento se degrade menos o incluso no se degrade; la tecnología Near Data Computing (NDP), que los operadores están empujando hacia abajo. En lo que respecta al almacenamiento, cómo la tecnología de caché distribuida mejora la tasa de aciertos de la caché, todo lo cual tiene como objetivo reducir la sobrecarga de la red entre la informática y el almacenamiento tanto como sea posible.

Además, desde redes 25GE hasta redes de alta velocidad como RDMA/RoCE, y luego al siguiente paso de integración de redes de memoria, cómo reducir los retrasos y mejorar el rendimiento es también una de las dificultades que la industria continúa resolviendo en la red. nivel de comunicación.

  1. Calcular sin estado

El lado informático generalmente adopta la arquitectura clásica de nada compartido, que tiene buena escalabilidad horizontal, pero el grado de apatridia en el lado informático está directamente relacionado con la calidad de la elasticidad, incluida la gestión y sincronización de metadatos y la automatización de información estadística. ., La inteligencia del optimizador son dificultades técnicas clave.

Para describirlo vívidamente, en el proceso elástico, cuantas más cosas lleve, más pesado será el estado, menor será la eficiencia elástica y peor será la experiencia del usuario.

  1. Programación de recursos globales

En el futuro se implementarán la agrupación de recursos de almacenamiento, la agrupación de computación, la agrupación de redes y la agrupación de memoria. Además, la arquitectura sin servidor ideal debe poder realizar automáticamente un escalado dinámico inteligente de acuerdo con la carga solicitada por el usuario y liberar recursos automáticamente cuando no son necesarios Asigne automáticamente más recursos durante los aumentos repentinos del negocio. Lo anterior plantea requisitos más altos para las capacidades de programación de recursos globales.

  1. carga mixta

Bajo la arquitectura sin servidor, diferentes inquilinos envían varios tipos de tareas de análisis en el mismo grupo de recursos informáticos. La forma de proporcionar garantías SLA estables y confiables para aplicaciones de capa superior amplifica aún más la dificultad de la gestión de carga mixta.

Es difícil implementar una estrategia de carga de cuota estática en el modo multiinquilino sin servidor y es necesario superar dificultades técnicas en la gestión de carga, como la asignación inteligente y dinámica de recursos, la limitación de corriente y los disyuntores.

Por ejemplo, el radio de impacto del problema de larga data de "SQL ineficiente que se queda sin recursos" se amplificará en el modo sin servidor y puede incluso tener efectos catastróficos.

  1. Límite superior del grupo de recursos

En el modo sin servidor, varios inquilinos comparten un grupo de recursos. Idealmente, este grupo de recursos debería ser infinitamente ampliable. Sin embargo, actualmente solo el lado del almacenamiento puede lograr esto básicamente. El grupo de recursos del lado informático todavía está limitado por las capacidades del software y habrá un límite Por ejemplo, los almacenes de datos sin servidor actuales de varios proveedores de nube convencionales aún no han superado la escala de potencia informática de 2000 vCPU. Si se agregan factores de concurrencia de múltiples inquilinos, será difícil promover la arquitectura sin servidor actual a gran escala en el campo del análisis OLAP.

Además, la introducción de nuevo hardware y la prestación de servicios de agrupación, como grupos de recursos FPGA, destinados a reducir aún más la carga en el lado informático, también son la dirección de los escenarios de nube actuales. La seguridad de los datos en escenarios completos y multinivel bajo la arquitectura sin servidor también es una cuestión clave a considerar.

Aquí me gustaría compartir brevemente con ustedes algunos de los pensamientos y prácticas de ByteHouse al respecto:

imagen.png

ByteHouse construye una nueva generación de almacén de datos basado en el concepto nativo de la nube, con tres capas de desacoplamiento en la arquitectura. Mirando de abajo hacia arriba,

  1. En la capa de almacenamiento, ByteHouse ha logrado un escalamiento elástico, sin servidor y una expansión de capacidad ilimitada. Para mejorar los problemas de rendimiento bajo la separación de la arquitectura de almacenamiento y computación, se han realizado una serie de optimizaciones técnicas en el lado del almacenamiento, como

    Para la semántica HDFS, la combinación de archivos pequeños para reducir la cantidad de archivos, la lectura de cobertura mejorada, la lectura de cambio rápido, etc. pueden reducir la latencia 3 veces y aumentar el ancho de banda en solo un 10%;

    Para la semántica de S3, el rendimiento del acceso a datos se mejora mediante tecnologías como la memoria caché y el grupo de subprocesos de E/S independiente.

  2. En términos de comunicaciones de red, tecnologías como la multiplexación de conexiones, RDMA y la compresión de transmisión han aliviado en gran medida el problema de la amplificación de la red.

  3. En la capa informática intermedia, ByteHouse proporciona a los usuarios servicios informáticos flexibles a través de un almacén virtual y un modelo de contabilidad de pago por uso para ahorrar costos a los usuarios.

    Técnicamente, ByteHouse no tiene estado y se basa en la implementación en contenedores, el escalado elástico de segundo nivel y el inicio y detención bajo demanda de segundo nivel. La tecnología de almacenamiento en caché local mejorada de ByteHouse hace que el precalentamiento y la captación previa de datos sean más inteligentes y eficientes, y la tasa de aciertos de los datos almacenados en caché también es mayor. En la capa informática, ByteHouse utiliza diferentes VW para aislar la carga, como el aislamiento por lectura y escritura, el aislamiento por categoría de aplicación. Aunque este modo de aislamiento de carga consciente del inquilino no es un modo sin servidor, se puede utilizar hasta cierto punto. las necesidades de los usuarios es también uno de los caminos para evolucionar hacia una arquitectura sin servidor.

  4. En la capa superior de servicios en la nube, ByteHouse proporciona servicios centralizados de metadatos de catálogo, servicios de gestión de clústeres, etc. Desacoplamos los metadatos de la capa informática, haciendo que la capa informática sea sin estado y logrando capacidades de arranque y parada elásticas de segundo nivel. El almacenamiento de metadatos basado en KV distribuido y una tecnología eficiente de almacenamiento en caché de piezas también mejora aún más el rendimiento del acceso a los metadatos.

¿Cómo ve el conflicto entre la observabilidad y la filosofía sin servidor?

Con la profundización de Serverless, la gente ha descubierto que la localización de problemas en la arquitectura Serverless es más difícil que en las aplicaciones tradicionales. En este sentido, algunas personas creen que se debe apoyar la necesidad de observabilidad, mientras que otras creen que la observabilidad es contraria a la esencia de Serverless: Serverless está diseñado para evitar que los usuarios se preocupen por los recursos informáticos subyacentes.

Creo que este problema está esencialmente relacionado con la madurez actual de la tecnología Serverless. Por ejemplo, ahora utilizamos agua y electricidad todos los días, pero pocas personas prestan atención a cómo generar electricidad, cómo distribuirla, el tratamiento del agua potable, etc., porque los estándares de servicio de agua y electricidad que recibimos son estables. , creíble y confiable, por lo que ya no se centrará en los detalles del proceso.

De manera similar, el objetivo de Serverless es proporcionar servicios de análisis estables, confiables y confiables, de modo que los desarrolladores ya no gasten tiempo y energía en la infraestructura subyacente y la optimización de la operación y el mantenimiento, sino que se concentren en la realización de las funciones comerciales anteriores.

Sin embargo, la madurez actual de la tecnología Serverless en el campo del análisis de datos OLAP está lejos de alcanzar este objetivo. La serie de dificultades técnicas mencionadas anteriormente aún no se han resuelto por completo. El ejemplo más simple es cómo resolver el "agotamiento ineficiente de recursos de SQL". " que ha afectado a la industria durante más de 40 años. En el modelo sin servidor, la facturación está estrechamente relacionada con el uso de recursos. La racionalidad y credibilidad del uso de recursos en la factura son actualmente las mayores preocupaciones de los clientes.

Además, brindar a los usuarios observabilidad de los procesos a través de herramientas técnicas como registros, monitoreo de seguimiento e indicadores visuales también es una capacidad que debería tener una plataforma sin servidor y también puede aumentar la confianza de los usuarios en el sistema.

Por tanto, ambos no son contradictorios. Creemos que algún día Serverless brindará a los usuarios servicios de análisis estándar, estables, confiables y dignos de confianza, tal como usamos el agua y la electricidad hoy.

Al implementar Serverless, ¿cómo elegir entre soluciones de desarrollo propio y de proveedores en la nube?

Lo más valioso en el siglo XXI es el talento. Para las empresas, el objetivo de cada inversión es obtener conocimientos analíticos más profundos, percepciones de control de riesgos y alertas tempranas más sensibles y un crecimiento más rápido de los usuarios. Por lo tanto, la TI empresarial se trata más de Ver las decisiones de inversión desde una perspectiva de desarrollo, habilitar negocios, y dar un paso más para permitir que la TI evolucione de un centro de costos tradicional a un centro de empoderamiento y un centro de ganancias. El enfoque de las reservas de talento es la dirección del desarrollo tecnológico.

La lógica empresarial de los proveedores de nube es proporcionar a los usuarios servicios de tecnología de computación en la nube estándar y servicios de nube diferenciados a través de una inversión sostenida y de alta intensidad en I + D. El foco de las reservas de talento está en la I + D tecnológica. Sólo hay una palabra que diferencia entre desarrollo e investigación y desarrollo, pero los significados son muy diferentes.

Especialmente para la implementación de la tecnología sin servidor en el campo OLAP, que involucra puntos técnicos casi completos en campos de TI como almacenamiento, redes, sistemas operativos, bases de datos e inteligencia artificial, requiere que los fabricantes realicen inversiones continuas y de alto costo en I + D. y estas inversiones Es difícil ver el rendimiento del mercado en el corto plazo. Una vez que se detiene a mitad de camino, significa que toda la inversión inicial se ha desperdiciado.

Por lo tanto, para las pequeñas y medianas empresas, todavía se recomienda mantener una actitud cautelosa al invertir en tecnología sin servidor en el campo OLAP. La investigación y el desarrollo tecnológico, la evolución y la iteración de Serverless deben dejarse en manos de los grandes proveedores de nube con capacidades técnicas más sólidas. reservas de talento y más inversión en tecnología profesional.

¿Qué tan lejos está Serverless de las aplicaciones a gran escala?

En el campo del análisis de datos OLAP, aunque ya existen varios almacenes de datos de arquitectura comercial sin servidor, las dificultades técnicas mencionadas anteriormente aún existen y no se han superado, y la escala de potencia informática proporcionada en el futuro es difícil de soportar para medianas y grandes empresas. escalar almacenes de datos o analizar los requisitos de la plataforma.

Sin embargo, el concepto arquitectónico de Serverless todavía está orientado al futuro, y los desafíos técnicos tendrán mejores soluciones y medidas con el tiempo, y actualmente se puede aplicar y promover en algunos escenarios de carga de análisis pequeños y medianos.

Finalmente, me gustaría mencionar que además de la continua evolución e iteración del nivel técnico, otro factor muy crítico que afecta la aplicación a gran escala de Serverless es la estandarización de los servicios Serverless, especialmente en el campo del análisis OLAP. La intención original de Serverless es permitir a los usuarios centrarse en la implementación empresarial, pero sin una especificación estandarizada, los usuarios quedarán atrapados en la plataforma y no podrán realizar la traducción y la migración sin problemas de las aplicaciones. Por ejemplo, los usuarios no pueden migrar sin problemas aplicaciones basadas en MySQL. a PostgreSQL Porque la siguiente base de datos no tiene servidor, pero la interfaz para interactuar con la lógica empresarial aún no se ha estandarizado. Por lo tanto, la aplicación a gran escala de Serverless también requiere estándares y sistemas de especificaciones compatibles.

Con todo, la arquitectura sin servidor se ha vuelto cada vez más popular. Con el mayor desarrollo y mejora de la computación en la nube y la tecnología sin servidor, la arquitectura sin servidor se convertirá en una de las arquitecturas preferidas para aplicaciones a mayor escala en el futuro. Los usuarios utilizarán agua y electricidad tal como lo hacen hoy. Disfrute de manera conveniente y rápida de los servicios de análisis de datos OLAP sin servidor.

Haga clic para saltar a ByteHouse y obtener más información.

Microsoft lanza una nueva "aplicación de Windows" Xiaomi anuncia oficialmente que Xiaomi Vela es completamente de código abierto y el kernel subyacente es NuttX Vite 5. Se lanza oficialmente Alibaba Cloud 11.12. Se expone la causa de la falla: anomalía del servicio de clave de acceso (clave de acceso) Informe GitHub: TypeScript reemplaza a Java y se convierte en el tercero más popular La operación milagrosa del operador del lenguaje : desconectar la red en segundo plano, desactivar cuentas de banda ancha, obligar a los usuarios a cambiar de módem óptico ByteDance: usar IA para ajustar automáticamente los parámetros del kernel de Linux Código abierto de Microsoft Terminal Chat Spring Framework 6.1 oficialmente GA OpenAI, el ex director ejecutivo y presidente Sam Altman y Greg Brockman se unen a Microsoft
{{o.nombre}}
{{m.nombre}}

Supongo que te gusta

Origin my.oschina.net/u/5588928/blog/10143487
Recomendado
Clasificación