Introducción: El lago de datos puede ayudar a las empresas a hacer frente al creciente número de escenarios de datos, estructuras de datos cada vez más complejas y requisitos de procesamiento de datos cada vez más diversos. Alibaba Cloud ha estado implementando lagos de datos desde 2018 y lanzó el análisis de lagos de datos nativos de la nube Data Lake Analytics (DLA), que van desde la gestión de lagos de datos (ayudando a los clientes a administrar y construir lagos de datos de manera eficiente), Serverless Spark (que proporciona computación rentable a gran escala). ), SQL sin servidor (que proporciona un análisis interactivo en línea rentable) para ayudar a los clientes a aprovechar el valor de los datos. Este artículo comparte desafíos y soluciones técnicos relacionados.
Oportunidades y desafíos de un lago de datos
Los lagos de datos pueden ayudar a las empresas a hacer frente a los problemas actuales de cada vez más escenarios de datos, estructuras de datos cada vez más complejas y requisitos de procesamiento de datos más diversificados. Un informe publicado por Gartner en 2020 muestra que el 39% de los usuarios están utilizando actualmente el lago de datos, y el 34% de los usuarios están considerando usar el lago de datos dentro de un año.
Desde 2018, Alibaba Cloud ha comenzado a implementar lagos de datos y lanzó el producto Data Lake Analytics (DLA) de análisis de lago de datos nativo de la nube, combinado con el OSS de almacenamiento de objetos, para crear una plataforma para la expansión flexible, el pago a pedido y el servicio. Productos competitivos. Al adoptar el modelo de separación de almacenamiento y computación, el almacenamiento y la computación se pagan en su totalidad a pedido, y los usuarios solo necesitan pagar por los cálculos que realmente generan valor; DLA personaliza profundamente la elasticidad nativa de la nube para lograr flexibilidad a nivel de trabajo y puede rebotar 300 nodos en un minuto. El DLA de análisis de lago de datos nativo de la nube se ha mejorado en gran medida en comparación con las soluciones tradicionales de análisis de datos en términos de costo, flexibilidad y capacidades de entrega.
Miles de empresas también han utilizado servicios de lago de datos para encontrar aplicaciones de datos en la nube. Por ejemplo, la plataforma abierta de datos U-DOP de U-Meng +, basada en años de experiencia acumulada de U-Meng + en el campo de big data, ha creado aplicaciones, webs, pequeños programas y publicidad. Las capacidades de recopilación y procesamiento de datos de sujetos de múltiples extremos basadas en marketing, intercambio social y empuje, forman activos de datos de múltiples extremos estandarizados para los clientes. En particular, se utilizó la elasticidad del lago de datos para hacer frente a los cambios comerciales durante el período pico de Double Eleven. Por ejemplo, mediante la implementación del análisis de los cambios en las palabras clave de búsqueda, el cambio de la información recomendada en la página de inicio, los usuarios activos y los usuarios que realizaron pedidos se dividieron en diferentes canales Análisis y peinado y ajuste oportuno de estrategias preferenciales para atraer más clientes para nuevas compras y recompras.
La tendencia de integración de bases de datos y big data se está intensificando. Los usuarios de bases de datos tradicionales y los administradores de bases de datos también pueden utilizar y mantener sistemas de big data para resolver problemas de big data de manera integrada. Específicamente, DLA incorpora la integración perfecta de datos en la base de datos con big data, como la función de una tecla proporcionada por DLA para construir un almacén; DLA Serverless SQL es compatible con el protocolo MySQL y alguna sintaxis.
Para el formulario de producto DLA Serverless, los desarrolladores solo necesitan usar la interfaz de la plataforma, como usar la interfaz JDBC de DLA SQL para enviar SQL y OpenAPI de DLA Spark para enviar trabajos Spark. Los desarrolladores solo deben centrarse en la lógica empresarial en sí, no en la lógica compleja de la plataforma. Muchos de los puntos débiles que se encuentran al usar componentes de código abierto se pueden resolver fácilmente:
Altas barreras de entrada
El ecosistema de Hadoop a menudo requiere el uso simultáneo de varios componentes, como Yarn, HDFS, Spark, Hive, Kerberos, Zookeeper, etc. Los desarrolladores deben comprender todos los componentes, porque estos componentes a menudo se exponen durante el proceso de desarrollo.
Dificultad en desarrollo y mantenimiento.
Los desarrolladores encontrarán problemas de uso causados por varios componentes durante el proceso de desarrollo, y los desarrolladores deben comprender todos estos componentes para hacer frente a estos problemas. Estos aumentan la carga para los desarrolladores.
La estabilidad es difícil de garantizar
Los componentes de código abierto en sí deben ajustarse cuidadosamente y agregarse con la configuración de recursos de hardware adecuada para que funcionen bien, y muchos BUG deben solucionarse y no hay respuesta para los problemas.
Falta de optimización del rendimiento para la nube
El OSS, PolarDB y otros componentes en la nube son todos componentes nativos de la nube Los componentes de código abierto no están adecuadamente adaptados a la transformación de esta parte y no han aprovechado completamente para un mayor rendimiento.
DLA ayuda a los clientes a aprovechar el valor de los datos desde tres aspectos: gestión de lagos de datos (ayudando a los clientes a gestionar y construir lagos de datos de forma eficiente), Serverless Spark (que proporciona informática rentable a gran escala) y SQL sin servidores (que proporciona un análisis interactivo en línea rentable). La estructura general se muestra a continuación. A continuación, este artículo describirá los desafíos técnicos relacionados y las soluciones de estos tres aspectos.
2. ¿Cómo gestionar y construir un lago de datos?
La dificultad de la gestión de datos en el lago de datos se refleja principalmente en dos aspectos:
- ¿Cómo construir eficientemente metadatos para los datos almacenados en OSS en el lago de datos?
- ¿Cómo entran los datos que no son de OSS al lago de manera eficiente y construyen almacenes?
Las principales funciones relacionadas con la gestión del lago de datos incluyen la gestión de metadatos, el descubrimiento de metadatos, la entrada de bases de datos en el lago y el establecimiento del almacén, y la entrada de datos en tiempo real en el lago. A continuación, nos centraremos en dos tecnologías clave: "Tecnología de construcción automática de metadatos de archivos masivos" y "Tecnología de gestión de datos para la construcción de almacenes en el lago".
1 Tecnología de construcción automática de metadatos de archivos masivos
Cuando se utiliza OSS como almacenamiento de lago de datos, los archivos de datos almacenados tienen las siguientes características:
- Formatos ricos: incluidos CSV, Text, JSON, Parquet, Orc, Avro, hudi, Delta Lake y otros formatos. Entre ellos, CSV y Text contienen una variedad de separadores personalizados.
- La cantidad de archivos está en el nivel de un millón: OSS tiene una mejor escalabilidad y rentabilidad, y los archivos almacenados por los usuarios en OSS estarán en el nivel de un millón.
- Carga dinámica de archivos: Los archivos de datos almacenados en OSS tienen la característica de carga dinámica y continua, cómo modificar rápida e incrementalmente los metadatos de nuevos archivos.
Con el fin de construir de manera eficiente metadatos para los datos masivos en OSS, Alibaba Cloud DLA propuso e implementó la "Tecnología de construcción automática de metadatos de archivos masivos". La tecnología específica se muestra en la figura siguiente El núcleo resuelve los dos problemas: reconocimiento de decenas de miles de metros y decenas de miles de particiones, y detección incremental y actualización de metadatos.
Reconocimiento de múltiples metros y particiones
La cantidad de archivos en el OSS del usuario llegará a millones. Estos archivos no solo están en diferentes formatos, como JSON, CSV, Text, etc., sino que también los campos de esquema específicos del mismo formato son diferentes debido a diferentes atributos comerciales. Esta tecnología admite la generación automática de decenas de miles de tablas y decenas de miles de particiones mediante el reconocedor de esquemas de archivos y el clasificador de archivos. Entre ellos, el reconocedor de esquemas de archivos, por ejemplo, reconoce un solo archivo JSON en 0.15s y un solo archivo CSV reconoce en 0.2s. Con una estrategia de muestreo inteligente conectable y una estrategia distribuida, el reconocimiento de esquemas de millones de archivos puede alcanzar el nivel de minutos. El clasificador de archivos realiza agregación, poda y compresión a través de la estructura del árbol. Se necesitan aproximadamente 290 ms para clasificar y reconocer millones de archivos.
Actualización de conciencia incremental
Los usuarios continuarán cargando archivos al OSS. La construcción automática de metadatos no solo actualiza los cambios en el esquema de archivo que pertenecen a las tablas creadas a las tablas existentes, sino que también crea nuevas tablas para los archivos recién agregados. Aquí, por un lado, el "File Schema Recognizer" reconoce los archivos modificados obteniendo los cambios de adición y eliminación de los archivos en el OSS, y al mismo tiempo el "File Classifier" realiza la estrategia de generación y cambio para el esquema de archivo recién agregado y las tablas creadas. Actualmente, se admiten 4 estrategias para agregar particiones, agregar campos, mantener los campos sin cambios y no estar al tanto de la eliminación de archivos. Se pueden agregar nuevas estrategias continuamente en el futuro.
2 Tecnología de organización de datos para la construcción de almacenes en el lago
El almacenamiento unificado de la base de datos y los datos del servicio de registro de mensajes en el OSS de almacenamiento del lago de datos para la administración puede satisfacer las necesidades comerciales, como la aceleración de la computación, el archivo del almacén de datos del edificio y la separación de refrigeración y calefacción. La tecnología de organización de datos de DLA para la construcción de almacenes en el lago incluye tres modos de organización y administración de datos: modo espejo, modo de partición y modo incremental. Los tres modos pueden combinarse y ser amigables para soportar estos escenarios comerciales.
Modo espejo
Cada vez que los datos de todas las tablas de una base de datos en la base de datos de origen se sincronizan completamente con el OSS de almacenamiento del lago de datos, la carga de la base de datos de origen se puede controlar dentro del 10% durante la sincronización. El algoritmo de programación de fragmentación de datos unificada global se utiliza principalmente aquí. Mantenga los datos en el lago de datos coherentes con la base de datos de origen.
Modo de partición
Frente a los escenarios de archivo, admite la sincronización de los datos de la base de datos de origen con el lago de datos en su totalidad y en incrementos diarios, y los organiza por zonas horarias para facilitar la gestión de archivos. Este modo puede lograr un retraso de tiempo por hora.
Modo incremental
Este modo puede lograr una entrada de datos T + 10min en el lago a través de la tecnología de almacenamiento de filas y columnas mixtas, registro de confirmación y tecnología de gestión de índices. Entre ellos, el archivo incremental delta y la tecnología de compactación asincrónica resuelve el problema de los archivos pequeños; el archivo incremental delta y la tecnología de índice pueden admitir la escritura incremental en tiempo real de las actualizaciones de la escena de la base de datos y eliminar registros; registrar el mapeo de los archivos de partición a través del registro de confirmación, Resuelva el problema del rendimiento lento de millones de particiones en el modo de gestión de catálogo tradicional.
Tres plataformas de lago de datos nativas de la nube necesitan abrir la infraestructura de la nube
DLA en su conjunto es una arquitectura de múltiples inquilinos, implementada en regiones, y los usuarios de cada región comparten un conjunto de lógica de control. El VC del clúster virtual es una unidad de aislamiento lógico. La plataforma admite motores como Serverless Spark y Serverless SQL para crear servicios nativos en la nube.
Como se muestra en la figura anterior, los principales desafíos que enfrenta la plataforma son: suministro eficiente de recursos, protección de seguridad y garantía de ancho de banda para el acceso a las fuentes de datos.
1 Suministro eficiente de recursos
La plataforma nativa de la nube se basa en la base ECS & ACK & ECI de Alibaba Cloud, y está conectada con el grupo de recursos IAAS de Alibaba Cloud. Esta programación de recursos de zona de disponibilidad cruzada de la región garantiza el suministro de recursos. Admite 300 nodos en 1 minuto y garantiza los recursos de los nodos informáticos en una gran Región 5w para un solo cliente.
2 protección de seguridad
Los usuarios pueden escribir código arbitrario para que se ejecute dentro de la plataforma, lo que puede ser un ataque malicioso deliberado. Si no hay protección, la plataforma enfrenta riesgos de seguridad. En materia de seguridad, garantizamos la seguridad a través de las siguientes tecnologías:
- Clave única: cada tarea de trabajo irá a TokenServer para solicitar un token temporal. Si el trabajo falla, el token caducará. Si hay un ataque, la plataforma caducará directamente el token y se denegará el acceso a servicios como Meta.
- Prevención de DDOS y ataques de inyección: Todas las solicitudes de acceso a los servicios de la plataforma serán recibidas por el Centro de Protección de Seguridad El Centro de Protección de Seguridad detecta cualquier ataque o inyección y cierra directamente el puerto de red.
- Aislamiento de contenedores informáticos: el contenedor de seguridad de desarrollo propio de Alibaba Cloud se utiliza entre los nodos informáticos, y el contenedor en sí puede alcanzar el mismo nivel de aislamiento de seguridad que la máquina virtual.
- Lista blanca de seguridad: la red entre usuarios está completamente aislada.
- Tarjeta de red virtual ENI: para pasar por la VPC, debe configurar el grupo de seguridad y el conmutador virtual (VSwitch) en su cuenta. Después de la configuración, el contenedor del nodo de liquidación asignará la IP de la VPC del usuario correspondiente al segmento de red de VSwitch y montará el grupo de seguridad del usuario.
3 Ancho de banda de red de alto rendimiento
- El acceso a los servicios de OSS se realiza a través de servicios de ancho de banda de alto rendimiento.
- Usar la tecnología ENI para acceder a una VPC autosuficiente es lo mismo que implementar un motor informático en el ECS en una VPC autosuficiente para acceder a los datos en la VPC autosuficiente. El ancho de banda es también el ancho de banda de la intranet de la VPC.
Cuatro desafíos técnicos del servicio Spark sin servidor
Apache Spark es actualmente el motor de código abierto más popular en la comunidad. No solo tiene capacidades informáticas como transmisión, SQL, aprendizaje automático y gráficos, sino que también puede conectarse a fuentes de datos enriquecidas. Sin embargo, frente al escenario del lago de datos, la versión de clúster tradicional de la solución Spark enfrenta los problemas antes mencionados de dificultades en la administración de datos, costos de operación y mantenimiento, elasticidad insuficiente de los recursos informáticos y capacidades débiles a nivel empresarial, así como un rendimiento deficiente en el acceso al OSS. , Las operaciones complejas son difíciles de depurar y otros problemas.
Con la ayuda del mecanismo de gestión del lago de datos mencionado en el segundo capítulo, los problemas de gestión de datos se pueden resolver bien. Con la ayuda de la plataforma de seguridad multiinquilino mencionada en el Capítulo 3, DLA Spark implementa un nuevo formato de producto sin servidor nativo de la nube, que resuelve los problemas de elasticidad, los costos de operación y mantenimiento y los requisitos de nivel empresarial. Este capítulo amplía aún más la optimización del rendimiento del acceso de Spark a OSS con servicios de IU de múltiples inquilinos.
1 Spark acceso a la optimización de OSS
Problema de versión comunitaria
De forma predeterminada, la versión de código abierto de Spark usa la interfaz Hadoop FileFormat para conectarse directamente a OSSFileSystem para acceder a los datos de OSS. En la práctica, este método ha encontrado problemas como un rendimiento deficiente y dificultad para garantizar la coherencia.
(1) El acceso de Spark a OSS es deficiente
La razón principal es la diferencia entre el modelo OSS KV y el modelo de árbol de archivos HDFS. El algoritmo FileFormat se diseñó originalmente en base al sistema de archivos HDFS, pero el almacenamiento de objetos como OSS, para resolver la escalabilidad, utiliza esencialmente el modelo KV. El modelo KV es bastante diferente del sistema de archivos HDFS. Por ejemplo, la interfaz RenameDirectory es solo una operación de puntero en HDFS, pero en KV, todos los subarchivos y directorios deben cambiarse de nombre, lo que tiene un rendimiento costoso y no puede garantizar la atomicidad. Hadoop FileOutputFormat escribe primero en el directorio temporal cuando escribe datos y finalmente escribe en el directorio final. El proceso del directorio temporal al directorio final requiere la fusión del árbol de archivos. Hay muchas operaciones de cambio de nombre durante el proceso de fusión.
(2) La coherencia es difícil de garantizar
En el algoritmo FileFormat v1, todas las operaciones de fusión del árbol de archivos se realizan en un solo punto en AppMaster, lo cual es muy ineficiente, especialmente en escenarios de partición dinámica. Para resolver el punto único de AppMaster, la comunidad proporciona el algoritmo 2. Su idea central es hacer que el proceso de fusión sea paralelo a la Tarea para la ejecución, lo que mejorará el rendimiento hasta cierto punto. Sin embargo, si la ejecución del Trabajo falla, la Tarea parcialmente exitosa escribirá los datos El directorio de datos final conduce a problemas de datos sucios.
Optimización de acceso a Spark OSS
(1) Implementación de FileOutputFormat basado en MultipartUpload
Con el objetivo de las características del acceso de Spark a OSS, hemos implementado recientemente la interfaz Hadoop FileOutputFormat, como se muestra en la figura anterior. La mejora del algoritmo se centra en optimizar la operación de fusión El núcleo de la fusión es resolver el problema de cuándo el archivo es visible. OSS proporciona la interfaz MultipartUpload, es decir, la función de carga reanudable. Los archivos se pueden cargar en fragmentos. La carga no se completa y los archivos fragmentados son invisibles. Con esta función, podemos permitir que Task escriba datos directamente en el directorio final. Solo cuando el trabajo se realiza correctamente, el archivo puede finalmente ser visible. Este método no necesita escribir primero en el directorio temporal, lo que reduce considerablemente las operaciones de metadatos. Para los fragmentos temporales escritos por la tarea que no se pudo ejecutar, podemos eliminarlos ejecutando la operación Abort al final del trabajo, lo que reduce la ocupación de espacio.
Para el ETL Benchmark Terasort típico de Spark, con 1 TB de datos de entrada, el tiempo de ejecución de DLA FileOutputFormat se reduce en un 62% y el rendimiento se mejora en un 163%. Para escenarios de partición dinámica, el algoritmo de comunidad 1 falla y el algoritmo 2 se puede ejecutar con éxito En comparación con el algoritmo 2, el rendimiento de DLA FileOutputFormat se mejora aún más en un 124%.
(2) Caché de metadatos OSS
En el proceso de Spark leer OSS, en la fase ResolveRelation, Spark atravesará el directorio OSS, analizará la estructura de la tabla y la estructura de la partición, y analizará el esquema. También habrá una gran cantidad de operaciones de metadatos en el proceso, y los metadatos del mismo objeto OSS serán Ha sido visitado muchas veces. En respuesta a este problema, implementamos una caché de metadatos OSS. Los metadatos del objeto OSS al que se accede por primera vez se almacenarán en caché localmente, y el acceso posterior al objeto leerá directamente la caché local. Este método puede minimizar el acceso a los metadatos de OSS. El mecanismo de caché puede aumentar el rendimiento de ResolveRelation en aproximadamente 1 veces. Para los escenarios de consulta típicos de Spark, el mecanismo puede mejorar el rendimiento general en un 60%.
2 Servicio de interfaz de usuario multiusuario
Los servicios de interfaz de usuario son muy importantes para los desarrolladores, que confían en los servicios de interfaz de usuario para la depuración de trabajos y la resolución de problemas de trabajos de producción. Los buenos servicios de IU pueden acelerar la eficiencia de la investigación y el desarrollo.
Puntos de dolor de HistoryServer
El HistoryServer proporcionado por la comunidad Spark proporciona servicios de registro e interfaz de usuario para trabajos históricos de Spark. Se han encontrado muchos puntos débiles en aplicaciones prácticas. Los ejemplos típicos son los siguientes:
(1) La sobrecarga del espacio del registro de eventos es grande
HistoryServer se basa en el motor Spark para registrar toda la información del evento en ejecución en el sistema de archivos y luego reproducirla en segundo plano y dibujar la página de la interfaz de usuario. Para trabajos complejos y trabajos largos, la cantidad de Eventlog es grande, que puede alcanzar el nivel de 100 GB o incluso TB.
(2) No se admiten trabajos complejos ni trabajos largos
El registro de eventos de un trabajo complejo o de un trabajo largo es demasiado grande y HistoryServer no lo analizará, ni siquiera OOM. Junto con la sobrecarga de espacio grande, los usuarios generalmente solo pueden cerrar Eventlog.
(3) Baja eficiencia de reproducción y alta latencia
HistoryServer utiliza el método Replay Eventlog en segundo plano para restaurar la interfaz de usuario de Spark, que equivale a reproducir todos los eventos del motor Spark, que es caro y tiene un retraso. Especialmente en el caso de tareas más o más complicadas, el retraso puede llegar a minutos o incluso diez minutos.
SparkUI de varios inquilinos de DLA
El servicio SparkUI es un servicio de interfaz de usuario multiinquilino desarrollado por la plataforma DLA, que ha sido profundamente optimizado para soluciones comunitarias:
(1) Ir al registro de eventos
DLA Spark elimina la dependencia de Eventlog. Al final del trabajo, Spark Driver simplemente descarga el Meta de la IU en OSS y guarda la metainformación de la página antes de que finalice el trabajo. Esta parte de la información es sólo relativa a Eventlog, que se reducirá considerablemente, incluso los trabajos más complejos se encuentran sólo en el nivel de MB. UiServer lee el UI Meta en OSS y lo deserializa para mostrar la página SparkUI.
(2) Expansión horizontal de UIServer
UIServer es principalmente responsable de analizar UI Meta histórica y proporcionar servicios de registro Stderr y Stdout. Es liviano, sin estado y puede lograr una expansión horizontal, por lo que admite servicios en línea simultáneos para decenas de miles de clientes. La URL de UIServer utiliza un token cifrado como parámetros, el token representa la identidad del usuario, la identificación del trabajo, UIServer realiza un servicio de múltiples inquilinos basado en esto.
(3) El registro local se desplaza automáticamente
Para trabajos largos, la información Stderr o Stdout se acumulará con el tiempo y, finalmente, el disco puede incluso explotar. El contenedor seguro de DLA Spark tiene un proceso en segundo plano incorporado para implementar la transferencia de registros y guardar el registro reciente más valioso.
Cinco desafíos técnicos de los servicios SQL sin servidor
DLA Serverless SQL es un motor de lago de datos nativo de la nube basado en PrestoDB actualmente alojado en Linux Foundation. Alibaba también es miembro de Presto Foundation y ha estado contribuyendo y optimizando Presto. El motor PrestoDB en sí tiene excelentes características:
- La máxima velocidad que ofrece la computación con memoria completa.
- Apoye la poderosa expresividad que aporta la semántica SQL completa.
- El mecanismo de complemento fácil de usar nos permite realizar consultas relacionadas en cualquier fuente de datos.
- La comunidad fuerte hace que no tengamos preocupaciones después de su uso.
Sin embargo, la comunidad PrestoDB es un motor de un solo inquilino. Se asume que lo está utilizando dentro de una empresa, por lo que no hay demasiada inversión en aislamiento de potencia informática, alta disponibilidad, etc., lo que hace posible usarlo directamente como motor para servicios nativos de la nube. Preguntas:
- Si un usuario envía una gran cantidad de consultas grandes, es posible que ocupe todos los recursos del clúster, lo que hará que otros usuarios no estén disponibles.
- Single Coordinator hace imposible garantizar la disponibilidad de todo el servicio.
Hemos realizado una serie de optimizaciones y transformaciones para que pueda servir a todos los usuarios en forma nativa de la nube. Hoy, nos centraremos en las dos características principales de la tecnología de aislamiento multiinquilino y el multi-Coordinador.
Primero, veamos la arquitectura general de DLA Serverless SQL:
Hemos construido servicios como la capa de acceso y metadatos unificados alrededor del clúster central de PrestoDB para hacer que los usuarios sean estables y convenientes. A continuación analizaremos en detalle la introducción de la tecnología de aislamiento de múltiples inquilinos y la tecnología de múltiples coordinadores.
1 Tecnología de aislamiento multiusuario
PrestoDB es compatible de forma nativa con grupos de recursos. Puede soportar un cierto grado de restricciones de CPU y memoria entre diferentes grupos de recursos, pero tiene algunos problemas que nos hacen imposible darnos cuenta del aislamiento de la potencia informática basada en él:
- Nivel de programación global: incluso si un inquilino usa demasiada potencia informática, no será castigado a tiempo, solo se bloquearán las consultas nuevas.
- Nivel de programación del trabajador: las divisiones de todos los inquilinos se programan en la misma cola. Si un inquilino tiene demasiadas divisiones, afectará a otros inquilinos.
Nuestra solución multiusuario de potencia informática es la siguiente:
Hemos introducido un módulo ResourceManager en el clúster para recopilar información sobre el uso de recursos de todos los inquilinos de todos los coordinadores. ResourceManager compara la información recopilada sobre el uso de recursos con nuestros umbrales de potencia informática preestablecidos para calcular qué inquilinos deben ser Castigue y luego notifique a todos los trabajadores sobre la información del castigo. Cuando el trabajador está programando, se referirá a la información de penalización notificada por ResourceManager para determinar qué consultas de inquilinos están programadas y qué consultas de inquilinos no están programadas. De esta manera, se aislará la potencia de cálculo entre diferentes inquilinos. Probamos que si un inquilino usa en exceso los recursos, será castigado en un máximo de 1.3 segundos, liberando así recursos a otros inquilinos. La versión predeterminada de la comunidad de "penalización" "No llegará hasta que se ejecuten todas las consultas de los inquilinos. Solo cuando se aíslan los metadatos y la potencia informática podemos estar seguros de que podemos utilizar un clúster para atender a todos nuestros usuarios.
2 tecnología Multi-Coordinator
En la versión comunitaria de Presto, Coordinator es un solo punto, traerá dos problemas:
Peligros de disponibilidad: una vez que el Coordinador deja de funcionar, todo el grupo no estará disponible durante 5 a 10 minutos.
No se puede lograr una actualización sin problemas, el proceso de actualización afecta el uso de consultas de todos los usuarios.
Adoptamos el siguiente plan arquitectónico:
Primero, colocamos un nuevo módulo de FrontNode en el Coordinador de Presto para permitir que los usuarios se conecten a este módulo en lugar de conectarse directamente a nuestro Coordinador subyacente, entonces, cuántos Coordinadores tenemos en la parte inferior y qué Coordinador actualmente brinda servicios a los usuarios Todos son completamente transparentes para los usuarios, por lo que la arquitectura es más flexible, por lo que podemos expandir el Coordinador en la parte inferior.
Una vez que FrontNode recibe la consulta del usuario, enviará la solicitud a varios Coordinadores en la parte inferior a la manera de Round Robin, para que varios Coordinadores puedan compartir la presión, pero todo el clúster todavía tiene algunas cosas globales que debe hacer un solo Coordinador, como Monitoreo del estado del trabajador de Presto, OOM Killer, etc., por lo que presentamos un Zookeeper para que haga la elección del coordinador. Después de la elección, las responsabilidades del Coordinador principal serán similares a las de Presto de la comunidad: realizar el monitoreo global del estado del trabajador, OOM Killer y ejecución La consulta que se le asigna, la responsabilidad del Coordinador es relativamente liviana: solo se encarga de ejecutar la consulta que se le asigna.
Si uno de los Coordinadores falla debido a algún problema, Zookeeper encontrará el problema en segundos y volverá a elegir al maestro, los usuarios solo necesitan reintentar la consulta afectada. Y uno de los intentos que estamos haciendo es reintentar automáticamente la consulta. Para fallas determinadas como causadas por el sistema, hacemos reintentos automáticos. Tal Coordinador tendrá poco impacto en los usuarios.
Con la arquitectura de múltiples coordinadores, es muy simple para nosotros lograr una actualización sin problemas. Cuando realizamos la actualización, solo necesitamos tomar la iniciativa para eliminar un determinado Coordinador / Trabajador del clúster, realizar la actualización y luego unirnos al clúster después de la actualización. Percepción, porque siempre hay un clúster en funcionamiento que brinda servicios a los usuarios durante el proceso de actualización. Por ejemplo, cuando actualizamos desde Coordinator, todo el clúster es el siguiente:
A través de optimizaciones como la tecnología de aislamiento de múltiples inquilinos, la arquitectura de múltiples coordinadores, etc., basadas en PrestoDB, creamos el motor SQL sin servidor de Alibaba Cloud Cloud Native Data Lake que puede servir a todos los usuarios.
Seis mejores prácticas de lagos de datos nativos en la nube de extremo a extremo
Como se muestra en el esquema anterior, DLA proporciona una solución de extremo a extremo. Frente a las dificultades de administración y acceso al lago causadas por la apertura de datos OSS, la administración del lago de datos de DLA le ayuda a construir un lago de datos seguro en una sola parada.
- Proporcione un Meta servicio unificado y abierto para administrar los datos de OSS y admitir los permisos de las tablas de bases de datos.
- Con la función de rastreo de metadatos, puede crear información de metadatos en OSS con un solo clic, reconocer de manera fácil y automática formatos como CSV / JSON / Parquet, y establecer la información de la tabla de base de datos para facilitar los motores de cómputo posteriores.
- Sincronización con un clic de datos de bases de datos como RDS / PolarDB / MongoDB al almacenamiento OSS, construya una arquitectura empresarial jerárquica para datos calientes y fríos, y realice análisis de información sobre datos en datos masivos de múltiples fuentes.
- Admite la transmisión de formato Hudi para cumplir con el requisito de demora de 10 minutos T +, lo que mejora en gran medida la demora de análisis de un extremo a otro.
- El análisis SQL sin servidor le ayuda a abrir y utilizar el lago de datos de forma inmediata. Los usuarios no necesitan comprar ningún recurso para ejecutar la sintaxis SQL estándar para consultar datos.
- Admite la aceleración de OSS Cache para almacenamiento de lago de datos, mejorando el rendimiento en 10 veces.
- Admite el análisis de diez fuentes de datos de datos RDS, PolarDB, ADB y MongoDB.
- En comparación con las soluciones tradicionales de Presto e Impala, la relación rendimiento / precio aumenta 10 veces.
- La informática Spark sin servidor le ayuda a jugar con el lago de datos de forma independiente. Los usuarios no necesitan comprar ningún recurso para utilizar el servicio Spark nativo de la nube, que admite limpieza de datos OSS, aprendizaje automático, programable por el usuario y lagos de datos.
- Pueden aparecer 500 nodos cada minuto para participar en el cálculo.
- En comparación con la solución Spark tradicional de construcción propia, se mejora la mejora rentable de 3x.
Como DLA involucra muchos puntos técnicos, este artículo describe algunos detalles técnicos, por favor preste más atención al DLA de análisis de lago de datos nativo de la nube:
https://www.aliyun.com/product/datalakeanalytics
Enlace original: https://developer.aliyun.com/article/776439?
Declaración de derechos de autor: el contenido de este artículo es aportado espontáneamente por usuarios registrados de nombre real de Alibaba Cloud. Los derechos de autor pertenecen al autor original. La comunidad de desarrolladores de Alibaba Cloud no posee sus derechos de autor y no asume las responsabilidades legales correspondientes. Consulte el "Acuerdo de servicio al usuario de la comunidad de desarrolladores de Alibaba Cloud" y las "Directrices de protección de propiedad intelectual de la comunidad de desarrolladores de Alibaba Cloud" para conocer las reglas específicas. Si encuentra que existe una sospecha de plagio en esta comunidad, complete el formulario de queja por infracción para informarlo. Una vez verificado, la comunidad eliminará inmediatamente el contenido sospechoso de infracción.