Li Auto x JuiceFS: Evolución y pensamiento de Hadoop a Cloud Native

La arquitectura técnica del automóvil ideal en la era Hadoop

Primero, repase brevemente el desarrollo de la tecnología de big data. Según mi comprensión personal, el desarrollo de big data se divide en cuatro períodos:

El primer período: 2006 a 2008. Alrededor de 2008, Hadoop se convirtió en el principal proyecto de Apache y lanzó oficialmente la versión 1.0. Su base se define principalmente en función de la troika de Google, GFS, MapReduce y BigTable.

El segundo período: de 2009 a 2013. Empresas como Yahoo, Alibaba y Facebook utilizan cada vez más grandes cantidades de datos. A finales de 2013, Hadoop lanzó oficialmente la versión 2.0. Tuve la suerte de ponerme en contacto con Big Data en 2012 y lo experimenté con Hadoop 1.0 más Hive. En ese momento, me sentí increíble. Big Data puede resolver rápidamente problemas que no se pueden resolver con SQL Server o MySQL con unas pocas máquinas. .

La tercera etapa: de 2014 a 2019, durante este período de desarrollo es muy rápido, durante el cual Spark y Flink se han convertido en los principales proyectos de Apache. Durante este rápido período de escalada, también intentamos usar Storm, que luego fue reemplazado por Flink.

La cuarta etapa: desde 2020 hasta el presente, después de que Hudi se graduó de Apache y se convirtió en un proyecto de primer nivel en 2020, entiendo personalmente que el lago de datos ha entrado en la etapa de madurez de todo el desarrollo y ha alcanzado la etapa de lago de datos 2.0 de grandes datos. El lago de datos tiene tres características principales, en primer lugar, almacenamiento unificado y abierto, en segundo lugar, un formato abierto y motores informáticos ricos.

En el proceso de desarrollo general, el big data tiene principalmente varias características, que son las cuatro "V" que todo el mundo suele decir: Volumen, Velocidad, Variedad y Valor. Ahora hay una quinta "V" (Veracidad), la exactitud y confiabilidad de los datos. La calidad de los datos siempre ha sido criticada. Espero que haya un conjunto de estándares en la industria para mejorar la calidad del lago de datos. Este puede ser el estándar para el surgimiento de Data Lake 2.0, porque proyectos como Hudi y Iceberg está destinado a mejorar la calidad de todo el lago de datos.La gestión del lago de datos se realiza bien.

Personalmente creo que Hadoop es sinónimo de big data, pero big data no es solo Hadoop. Big data es un conjunto de soluciones para procesar y utilizar una gran cantidad de datos formados después de la integración de múltiples componentes durante el proceso de desarrollo . En los últimos años, todo el mundo básicamente cree que Hadoop está yendo cuesta abajo. Primero, la fusión y exclusión de las empresas de comercialización de Hadoop, Cloudera y Hortonworks, el modelo de negocio original no puede continuar, los desafíos de usabilidad y la creciente complejidad del propio ecosistema de Hadoop.

Arquitectura actual de la plataforma de Big Data de Ideal Automobile

En esta etapa, la plataforma de big data de Li Auto se muestra en la figura anterior. Ideal Car utiliza muchos componentes de código abierto.

Capa de transporte: Kafka y Pulsar. Kafka se usó como un todo en la etapa inicial de construcción de la plataforma. Las capacidades nativas de la nube de Kafka son relativamente pobres. Pulsar se diseñó de acuerdo con la arquitectura nativa de la nube al comienzo de su diseño y tiene algunas capacidades que son muy adecuadas para IoT. escenarios, y también coincide con nuestros escenarios comerciales.Por lo tanto, recientemente presentamos Pulsar.
La capa de almacenamiento es HDFS + JuiceFS.
Los principales motores informáticos actuales de la capa informática son Spark y Flink, y estos motores informáticos se ejecutan en el Yarn actual. Los tres motores informáticos están gestionados por Apache Linkis, que es de código abierto de WeBank, y actualmente usamos mucho Linkis.
A la derecha hay tres bases de datos. La primera, MatrixDB, es una versión comercial de la base de datos de series temporales. TiDB se usa principalmente para escenarios mixtos de OLTP y OLAP. Actualmente, la usamos principalmente para escenarios TP. StarRocks es responsable del escenario OLAP.
ShardingSphere desea utilizar su concepto Database Plus para unificar las bases de datos subyacentes para la administración a nivel de puerta de enlace. Todavía está en la etapa exploratoria y hay muchas características nuevas que nos interesan mucho.
Más a la derecha, Thanos es una solución de monitoreo nativa de la nube Hemos integrado el monitoreo de componentes, motores y máquinas en la solución de Thanos.
La capa de aplicación son nuestros cuatro principales productos intermedios actuales, que incluyen aplicación de datos, desarrollo de datos, integración de datos y gobierno de datos.

características

A través del status quo de las plataformas de big data, se pueden encontrar algunas características:

Primero, hay muchos componentes en la solución completa, los usuarios tienen una fuerte dependencia de estos componentes y la dependencia mutua entre los componentes también es relativamente fuerte. Se recomienda que intente elegir componentes nativos de la nube más maduros cuando seleccione componentes en el futuro .
En segundo lugar, nuestros datos tienen picos y valles claros. La escena de viaje es generalmente en el pico de la mañana y en el pico de la tarde, y habrá más gente los sábados y domingos.
La tercera característica es que la popularidad de nuestros datos es básicamente la más popular y, por lo general, solo accedemos a los datos de los últimos días o la última semana. Sin embargo, se genera una gran cantidad de datos y, a veces, se puede requerir una gran cantidad de seguimiento, por lo que los datos también deben almacenarse durante mucho tiempo, por lo que la tasa de utilización de los datos es mucho peor.

Finalmente, todo el sistema de datos actualmente carece de algunos métodos efectivos de gestión a nivel de archivo. Desde la construcción hasta ahora, se basa básicamente en HDFS, y hay una gran cantidad de datos inútiles, lo que provoca un desperdicio de recursos, este es un problema que debemos resolver de manera urgente.

Puntos débiles de las plataformas de Big Data

Primero, hay muchos componentes, lo que hace que la implementación sea difícil e ineficiente . Hay más de 30 componentes de big data en torno a Hadoop, y hay más de 10 de uso común. Existen dependencias fuertes y débiles entre algunos componentes, y la configuración y administración unificadas se vuelven muy complicadas.
En segundo lugar, el costo de la máquina y el costo de mantenimiento son relativamente altos . Para el funcionamiento estable del negocio, los clústeres fuera de línea y en tiempo real se implementan por separado. Sin embargo, debido a las características comerciales mencionadas anteriormente, los picos y valles de nuestro negocio son obvios y la tasa de utilización general no es alta. Una gran cantidad de componentes del clúster requieren personal especializado para administrarlos y mantenerlos.
Tercero, capacidades de intercambio de datos multiplataforma . Actualmente, los datos compartidos entre clústeres solo se pueden sincronizar con otros clústeres de Hadoop a través de DistCp. No se puede sincronizar fácil y rápidamente con otras plataformas y servidores.
En cuarto lugar, la seguridad de los datos y el cumplimiento de la privacidad . En función de diferentes requisitos de seguridad de datos, los usuarios comunes se administran a través de Ranger, y los requisitos de seguridad especiales solo se pueden cumplir mediante la creación de diferentes clústeres y la configuración de políticas de VPC separadas, lo que genera muchas islas de datos y costos de mantenimiento.

La evolución y el pensamiento del coche ideal cloud native

En primer lugar, permítanme compartir brevemente mi comprensión personal de la nube nativa:

Primero, la nube nativa se deriva de la computación en la nube. Ahora todo el mundo utiliza proveedores de nube como Alibaba Cloud, AWS, Tencent Cloud, Baidu Cloud, etc., que inicialmente brindan servicios técnicos en la capa IaaS para ayudar a las empresas a empaquetar los elementos más básicos, como almacenamiento, computación y redes para una administración unificada. solo necesita solicitar un servidor en él. Después de solicitar servidores, estos servidores aún son administrados por proveedores de la nube, que es nuestra operación tradicional en la nube.

La nube nativa es inseparable de la computación en la nube. En términos generales, la nube nativa pertenece al servicio de capa PaaS de la computación en la nube, que es principalmente un tipo de aplicación para desarrolladores. Cloud native debe instalarse en la nube, y es un método de aplicación y desarrollo de software basado en la nube. Nube + nativa, la nube es computación en la nube, nativa es abandonar el marco tradicional de desarrollo de operación y mantenimiento, a través de contenedores, DevOps y arquitectura de microservicios para lograr escalado elástico e implementación automática de aplicaciones, aprovechando al máximo los recursos de computación en la nube para lograr en el menor espacio haz lo más grande. También puede resolver algunos puntos débiles de nuestro sistema de big data actual, como la escalabilidad y la capacidad de mantenimiento deficientes, que requieren mucha mano de obra y tiempo.

La figura anterior enumera brevemente varios puntos de tiempo de la nube nativa

En la primera etapa, AWS propuso el concepto de nube nativa y lanzó EC2 en 2006. Esta etapa es la etapa del servidor, la etapa de computación en la nube mencionada anteriormente.
La segunda etapa, la etapa de nube, es principalmente después del lanzamiento de Docker de código abierto y Kubernetes de código abierto de Google. Kubernetes es una plataforma de código abierto liviana y extensible para administrar aplicaciones y servicios en contenedores. La implementación y el escalado automáticos de las aplicaciones se pueden realizar a través de Kubernetes.
En la tercera etapa, la Fundación CNCF se estableció en 2015 para promover los conceptos nativos de la nube y ayudar al desarrollo nativo de la nube en su conjunto. El último es el código abierto de Knative.Un objetivo muy importante de Knative es desarrollar estándares de orquestación sin servidor multiplataforma nativos de la nube. Derivado a la actualidad, ya es la etapa de cloud native 2.0, es decir, la etapa de serverless. Personalmente, entiendo que el desarrollo de big data también debe desarrollarse en la dirección de Serverless . Por ejemplo, todo el servicio en línea de AWS es básicamente Serverless.

Arquitectura nativa de Big Data Cloud

A continuación, permítanme presentarles los cambios en los componentes de la plataforma ideal de big data para automóviles después de la nativoización de la nube:

En la capa de almacenamiento, todo el almacenamiento después de la nativoización de la nube es básicamente almacenamiento de objetos. El diagrama de arquitectura anterior conduce a Lustre, que se describirá en detalle a continuación. Puede entender que la capa de "almacenamiento en la nube" utiliza principalmente JuiceFS para administrar el almacenamiento de objetos y el sistema de archivos distribuidos en paralelo de Lustre (Nota: debido al problema de copia única de Lustre, actualmente estamos considerando usar sistemas de archivos paralelos proporcionados por los proveedores de servicios en la nube).
La capa de contenedor, principalmente encima de la informática, el almacenamiento y la red, se reemplaza por Kubernetes más Docker, y todos los componentes crecen en ella.
En cuanto a los componentes, el primero es el marco de computación de big data. Podemos abandonar Hive, usar directamente Spark y Flink, usar Hudi como soporte de capacidad subyacente de Data Lake 2.0 y reemplazar gradualmente a HDFS.
En la parte de middleware, además de Pulsar, está Kafka. Actualmente, la nativeización de la nube de Kafka no es particularmente buena. Personalmente, prefiero reemplazar Kafka con Pulsar. En la actualidad, Linkis se ha utilizado en línea para adaptar todos los motores Spark, y Flink se adaptará e integrará más adelante. ShardingSphere acaba de admitir la nube nativa en la versión 5.1.2 y realizaremos la verificación de escenarios y la exploración de capacidades según lo planeado.
La capa de la base de datos sigue siendo TiDB, StarRocks y MatrixDB. En la actualidad, estas tres bases de datos ya tienen capacidades nativas de la nube y todas admiten el almacenamiento de objetos. Pero esta pieza no se ha probado por separado, y todavía estamos usando máquinas físicas. Porque para la base de datos, las capacidades de IO proporcionadas por el almacenamiento de objetos actual no pueden cumplir con los requisitos de rendimiento de la base de datos, lo que reducirá en gran medida el rendimiento general de la base de datos.
En términos de operación y mantenimiento, se agrega un Loki adicional a la solución de Thanos, principalmente para la recopilación de registros nativos de la nube. Pero Loki y Thanos son solo dos de ellos. En el futuro, entiendo que se alinearán con las capacidades de SREWorks de código abierto de Ali y sellarán toda la calidad, la rentabilidad y la seguridad en las capacidades integrales de operación y mantenimiento, de modo que todo la gestión nativa de la nube se puede gestionar de forma permanente.
Observabilidad, un concepto recientemente popular en el campo de la nube nativa. Algunos de los componentes que todos están haciendo ahora comienzan a desarrollarse de forma nativa en la nube después de que se vuelven populares. No nacen en la nube al principio, pero solo esperan crecer en la nube más adelante. En este caso, se encontrará con algunos problemas.El primer problema es que no hay un monitoreo integral de la visibilidad. Consideramos cómo desarrollar un plan para estos componentes como un todo en el futuro, de modo que todos los componentes puedan monitorearse de manera efectiva después de que sean nativos de la nube.

En resumen, personalmente creo que la futura nube nativa del big data es básicamente:

Uso unificado del almacenamiento nativo en la nube como almacenamiento subyacente para todos los componentes (incluidas las bases de datos)
Todos los componentes se ejecutan en contenedores.
Use la arquitectura sin servidor para servir aplicaciones de capa superior

Pero esto también trae desafíos a los productos de plataforma de datos actuales, es decir, cómo diseñar productos con capacidades sin servidor para que los usen los usuarios.

Ventajas de Big Data Cloud Native

El primer punto es la separación de almacenamiento y cálculo, y la expansión y contracción elástica . Después de usar máquinas físicas para implementar Hadoop, si necesita expandir o reducir la capacidad, debe comunicarse con el operador y puede haber un ciclo largo.La separación del almacenamiento y el cálculo resuelve bien este problema. El segundo es el pago por uso, sin comprar recursos ociosos. En la actualidad, los datos de todo nuestro escenario comercial tienen picos y valles. Durante los picos, las máquinas deben estar preparadas y las máquinas deben retirarse durante los valles, pero esto no es posible ahora. Ahora básicamente apilamos todas las máquinas hasta el pico. Durante el pico, puede satisfacer la demanda y es estable sin fallas. Pero está inactivo durante al menos 12 horas durante el valle. En este caso, los recursos también se cobran. Después de la nube nativa, ya no tenemos que pagar por ella.

El segundo punto es la implementación y operatividad automatizadas . Kubernetes es compatible con las soluciones de implementación integradas de DevOps. De esta manera, nuestros componentes en su conjunto se pueden implementar rápidamente (por ejemplo, a través del gráfico de Helm), y las capacidades de operación y mantenimiento de los componentes se reducen a la plataforma nativa de la nube, de modo que Big Data no necesita considerar la operación y el mantenimiento de los componentes. escenarios.

El tercer punto es el almacenamiento de objetos . El almacenamiento de objetos es el producto central y más importante lanzado por la computación en la nube. Los beneficios del almacenamiento de objetos son evidentes, fáciles de expandir, espacio de almacenamiento ilimitado, precio unitario relativamente bajo, y el almacenamiento de objetos también se divide en almacenamiento de baja frecuencia, almacenamiento de archivos y otros tipos de almacenamiento, lo que reduce aún más los costos de almacenamiento, los datos pueden ser almacenado más largo tiempo. Al mismo tiempo, el costo controlable, la alta confiabilidad y la baja complejidad operativa también son ventajas del almacenamiento de objetos.

El cuarto punto es la seguridad y el cumplimiento . Después de la nube nativa, se pueden realizar espacios de nombres dedicados, aislamiento multiusuario y autenticación remota. En la actualidad, lo que hemos logrado es básicamente el aislamiento a nivel de Red. La solución ampliamente reconocida para la gestión de archivos HDFS es Ranger. El uso de Ranger para administrar los permisos del directorio HDFS también puede administrar algunos permisos, como el servidor Hive, HBase y Kafka, pero estos permisos son relativamente débiles.

Otra solución es Kerberos, se mejorará mucho la seguridad de todo el componente de big data, pero tiene muchos costos, y cualquier solicitud debe ser verificada. No hemos utilizado esta solución hasta ahora, y tiene algo que ver con nuestro entorno de clúster y escenarios. Básicamente estamos en la intranet y no brindamos servicios externos. Si su proyecto de big data necesita proporcionar algunos servicios a la red externa, aún necesita tener una autenticación sólida, de lo contrario, los datos se filtrarán fácilmente.

Dificultades de Big Data Nativo de la Nube

La dificultad del big data cloud native también existe.

Primero, hay muchos componentes relacionados con el big data, al mismo tiempo, la actualización de Kubernetes es relativamente rápida, después de que se cruzan los componentes, habrá problemas de compatibilidad, complejidad y escalabilidad.

En segundo lugar, la asignación y reasignación de recursos. Kubernetes es una herramienta de programación de recursos de contenedor de propósito general, y es difícil cumplir con los escenarios de uso de recursos de diferentes componentes de big data. En un escenario de big data, el uso de recursos será relativamente grande, la frecuencia de solicitud será alta y la cantidad de pods será relativamente grande cada vez. En este caso, actualmente no existe una buena solución. Actualmente estamos analizando la solución de Fluid. Fluid también implementa el tiempo de ejecución de JuiceFS. Esto es lo que investigaremos más adelante. Actualmente, Fluid afirma que puede admitir big data e IA, no solo escenarios de IA, porque big data e IA Los escenarios son similares, y todas son operaciones de uso intensivo de datos.Fluid ha logrado algunos avances en la eficiencia informática y la gestión de abstracción de datos.

En tercer lugar, el almacenamiento de objetos también tiene algunas desventajas. Las desventajas del almacenamiento de objetos son el bajo rendimiento de la operación de metadatos, la poca compatibilidad con los componentes de big data y la consistencia eventual.

El último punto son las aplicaciones de uso intensivo de datos. El modo de separación de computación y almacenamiento no puede cumplir con los requisitos de las aplicaciones de uso intensivo de datos, como big data e IA, en términos de eficiencia de operaciones informáticas y gestión de abstracción de datos.

La exploración e implementación de JuiceFS en soluciones nativas de nube de big data

Antes del código abierto de JuiceFS, hemos prestado atención y realizado algunas pruebas de aterrizaje. Después de que se lance la versión de código abierto, la usaremos de inmediato. Cuando se puso en línea, también encontré algunos problemas de permisos y algunos errores pequeños. La comunidad fue muy solidaria y nos ayudó a resolverlos rápidamente.

HDFS se desconecta debido a su escasa escalabilidad y, al mismo tiempo, nuestro volumen de datos es relativamente grande y el costo de almacenamiento de HDFS es relativamente alto. Después de almacenar varios lotes de datos, el espacio en la máquina física no es suficiente y se requieren muchos cálculos. En ese momento, el desarrollo de nuestro negocio aún estaba en pañales y, para obtener el mayor valor posible de los datos, queríamos conservar la mayor cantidad de datos posible. Además, HDFS requiere tres copias, luego lo cambiamos a dos copias, pero dos copias siguen siendo riesgosas.

Sobre esta base, probamos JuiceFS en profundidad y, una vez completada la prueba, presentamos rápidamente JuiceFS en nuestro entorno en línea. La migración de algunas tablas relativamente grandes de HDFS a JuiceFS alivió nuestra necesidad urgente.

Valoramos tres puntos de JuiceFS:

Primero, JuiceFS es compatible con múltiples protocolos . Es totalmente compatible con los protocolos POSIX, HDFS y S3, y es 100% compatible en el uso actual sin ningún problema.
En segundo lugar, la capacidad de cruzar las nubes . Cuando una empresa tiene cierta escala, para evitar riesgos sistémicos, no solo utilizará un proveedor de servicios en la nube. No estará atado a una nube, todo serán operaciones de múltiples nubes. En este caso, la capacidad de JuiceFS para sincronizar datos entre nubes juega un papel importante.
En tercer lugar, escenarios nativos de la nube . JuiceFS es compatible con CSI. En este momento, no hemos usado CSI en este escenario. Básicamente usamos POSIX para montar, pero usar CSI será más simple y más compatible. También estamos desarrollando hacia la nube nativa ahora, pero todo el componente realmente no lo ha hecho. llegado a Kubernetes todavía.

Aplicación de JuiceFS en Ideal Car

Persistir datos de HDFS al almacenamiento de objetos

Después de que JuiceFS fuera de código abierto, comenzamos a intentar sincronizar los datos de HDFS con JuiceFS. Al comienzo de la sincronización, se usó DistCp. Es muy conveniente sincronizar con Hadoop SDK de JuiceFS, y la migración general es relativamente fluida. El motivo de la migración de datos de HDFS a JuiceFS se debe a algunos problemas.

La primera es que el diseño de acoplamiento de computación y almacenamiento de HDFS tiene poca escalabilidad y no hay forma de resolver este problema. Mi comprensión personal de los grandes datos desde el principio es que los grandes datos deben implementarse en máquinas físicas, no en hosts en la nube. Incluyendo los diversos sistemas EMR lanzados por los proveedores de la nube más adelante, en realidad están encapsulando Hadoop. En los últimos uno o dos años, estos sistemas EMR se han deshabilitado gradualmente.

La segunda es que HDFS es difícil de adaptar a la nativoización de la nube. El HDFS actual es difícil de adaptar a la nube nativa, porque es relativamente pesado. Aunque la comunidad se ha centrado en la nube nativa, personalmente creo que la tendencia de desarrollo de Hadoop va cuesta abajo y el futuro debería basarse en el almacenamiento de objetos.

En tercer lugar, el almacenamiento de objetos también tiene algunas desventajas. No se puede adaptar bien a la API HDFS. Debido a la red y otras razones, el rendimiento también es muy diferente al de los discos locales. Además, las operaciones de metadatos, como la lista de directorios, también son muy lento. Usamos JuiceFS para hacer algo de aceleración, y el rendimiento medido es muy impresionante. Es básicamente comparable al disco local en el caso de la memoria caché. En base a esto, cambiamos rápidamente la escena actual directamente a JuiceFS.

Uso compartido de archivos a nivel de plataforma

El segundo escenario es el intercambio de archivos a nivel de plataforma. Todos los datos de archivos compartidos de nuestro sistema de programación actual, el sistema en tiempo real y la plataforma de desarrollo se almacenan en HDFS. Si dejamos de usar HDFS más adelante, debemos migrar estos datos. La solución actual es usar JuiceFS para conectarse al almacenamiento de objetos.A través del servicio de la capa de aplicación, todos ellos están montados en modo POSIX, y todos pueden solicitar los archivos en JuiceFS sin sentir.

JuiceFS cumple con la mayoría de los requisitos de nuestra aplicación en este escenario, pero todavía hay algunos escenarios pequeños que tienen problemas. La idea original era incluir todo el entorno de Python y similares. Más tarde, descubrí que la operación real es demasiado difícil, porque hay muchos archivos pequeños en el entorno de Python y todavía hay problemas al cargar. Los escenarios como el entorno de Python que contienen una gran cantidad de archivos fragmentados aún deben almacenarse en el disco local para su funcionamiento. En el futuro, vamos a colgar un bloque de almacenamiento específicamente para hacer esto.

Comparta algunos problemas que hemos encontrado con HDFS antes:

En primer lugar, cuando NameNode está bajo mucha presión o Full GC, habrá fallas en la descarga y actualmente no existe una solución perfecta. Nuestra solución es aumentar la memoria tanto como sea posible, o agregar algunos reintentos al descargar el paquete para evitar su período pico, pero es difícil resolver completamente el problema de HDFS en este caso, porque después de todo está escrito en Java, y el GC No hay manera de evitar la escena.

En segundo lugar, cuando usamos HDFS entre sistemas, por ejemplo, si tenemos dos clústeres, básicamente no es realista usar un clúster para compartir archivos, porque la red debe abrirse para conectar los dos clústeres o atravesar la aplicación, por lo que hay no hay manera de garantizar la seguridad. En la actualidad, básicamente tenemos dos clústeres que mantienen sus propios archivos compartidos de forma independiente. Ahora, la plataforma en tiempo real (como la plataforma Flink) se ha cambiado a JuiceFS, y sigue siendo muy fluida y no ha encontrado ningún problema.

En tercer lugar, actualmente tenemos una gran cantidad de implementaciones de máquinas físicas, todas de un solo clúster, sin una estrategia de recuperación ante desastres. Si ocurre algún problema catastrófico en la sala de computadoras, todo nuestro servicio no estará disponible. Pero el almacenamiento de objetos en sí es una sala entre computadoras, en la misma región, debe haber al menos tres copias, los proveedores de la nube nos ayudan a hacer la copia de seguridad. En el futuro, podemos desarrollar múltiples nubes, con la esperanza de usar JuiceFS para compartir algunos archivos de alto nivel, bases de datos centrales, incluidos algunos archivos de respaldo centrales, y realizar copias de seguridad en múltiples nubes. De esta manera, se realizan múltiples nubes, múltiples regiones y múltiples regiones, lo que puede resolver el problema de la recuperación ante desastres de un solo punto.

Uso multiplataforma de datos masivos

En otro escenario, todas las plataformas comparten datos masivos a través de JuiceFS. El primer tipo de datos compartidos de nuestro lado son los datos de prueba de manejo. Habrá una gran cantidad de datos de video, audio e imagen cargados para la prueba de manejo. Después de cargar, estos datos ingresarán directamente a JuiceFS, lo cual es conveniente para que el usuario pueda hacer algunos sincronizar y compartir Incluyendo algunos datos de detección, y luego obtener PFS es un sistema de archivos paralelo, bajo el cual se monta SSD. Esto puede hacer que la utilización de la GPU sea mayor, porque la capacidad de almacenamiento de objetos es relativamente débil; de lo contrario, la capacidad de la GPU se desperdiciará mucho.

Los tipos de datos restantes incluyen algunos registros informados por vehículos para análisis, datos de puntos enterrados y datos de señales relacionadas con vehículos requeridos por algunas plataformas nacionales. Estos datos se ingresarán en el almacén de datos para algunos análisis. También haremos algunas extracciones de datos de características en estos datos, haremos entrenamiento de modelos para el equipo de algoritmos, o haremos alguna recuperación de NLP y otros escenarios más.

Aceleración de almacenamiento nativo en la nube: Lustre como caché de lectura (bajo prueba)

Ahora estamos probando otro escenario, que es colgar un Lustre en la capa de almacenamiento de objetos para que sirva como caché de lectura para JuiceFS, y usar el caché de Lustre para ayudar a JuiceFS a mejorar la velocidad de lectura y la tasa de aciertos de caché.

Una ventaja de esto es que ahora estamos usando máquinas físicas, que tienen discos físicos, que se pueden usar para almacenar datos en caché. Pero debido a que las tareas informáticas se ejecutan en múltiples nodos, la tasa de aciertos de caché no es muy alta. Esto se debe a que la versión comunitaria de JuiceFS aún no admite el almacenamiento en caché distribuido P2P y solo admite el almacenamiento en caché local de un solo nodo, y cada nodo puede leer una gran cantidad de datos. En este caso, también se ejerce cierta presión sobre el disco en el nodo informático, ya que la memoria caché ocupará una cierta cantidad de espacio en disco.

Nuestra solución actual es usar Lustre como caché de lectura de JuiceFS. Específicamente, de acuerdo con el tamaño de los datos que se almacenarán en caché, monte un sistema de archivos Lustre con una capacidad de aproximadamente 20~30 TB en el nodo informático local y luego use este punto de montaje Lustre como el directorio de caché de JuiceFS. En este caso, después de que JuiceFS lea los datos, puede almacenarlos en caché de forma asíncrona en Lustre. Esta solución puede resolver eficazmente el problema de la baja tasa de aciertos de caché y mejorar en gran medida el rendimiento de lectura.

Si escribimos datos directamente en el almacenamiento de objetos en el escenario de Spark, habrá limitaciones de ancho de banda y QPS. Si la escritura es demasiado lenta, las tareas ascendentes pueden fluctuar. En este caso, se puede usar la función de caché de escritura de JuiceFS. Escritura de datos primero a Lustre y luego a la escritura asíncrona en el almacenamiento de objetos, esta solución es aplicable en algunos escenarios. Pero existe el problema de que Lustre no es una solución nativa de la nube, el usuario lo percibe y necesita escribir explícitamente un comando para montarlo al iniciar el pod. Por lo tanto, también esperamos realizar algunos cambios en JuiceFS en el futuro, identificar automáticamente el almacenamiento de objetos y Lustre, y luego implementar automáticamente algunos mecanismos de almacenamiento en caché, para que los usuarios no necesiten percibir la existencia de Lustre.

Actualmente, el PoC de esta solución se completó y pasó la prueba básica. A continuación, haremos muchas pruebas de presión en el entorno de producción. Se espera que se lance oficialmente en el tercer trimestre de este año para cubrir algunos servicios de borde. .

La solución global de JuiceFS en big data cloud native

Como se puede ver en el diagrama de arquitectura de la solución general, actualmente usamos los tres métodos proporcionados por el cliente de JuiceFS.

Como se muestra en la mitad izquierda de la figura anterior, tendremos clústeres Spark y Flink independientes, y montaremos directamente JuiceFS en todo el clúster a través del controlador CSI, de modo que cuando los usuarios inicien Spark y Flink, no se darán cuenta de JuiceFS existe, y la lectura y escritura de las tareas informáticas se realizan a través del almacenamiento de objetos.

Esta sección actualmente tiene una pregunta sobre la reproducción aleatoria. Debido a que la tarea de Spark requiere que se escriba una gran cantidad de datos en el disco durante la fase aleatoria del proceso de cálculo, una gran cantidad de solicitudes de lectura y escritura de archivos generadas durante este período tienen requisitos de rendimiento más altos para el almacenamiento subyacente. Flink es relativamente mejor porque transmite y no requiere una gran cantidad de discos. En el futuro, esperamos que JuiceFS pueda escribir directamente en Lustre, pero esto requiere algunas modificaciones en JuiceFS. A través de la integración del cliente, JuiceFS puede leer y escribir directamente en Lustre. Esto no será percibido por los usuarios, y también puede mejorar la lectura aleatoria de Stage. y rendimiento de escritura.

La aplicación en la mitad derecha de la figura anterior tiene dos escenarios. Una es simplemente consultar los datos de JuiceFS, como la vista previa de datos a través de HiveJDBC.En este escenario, se puede acceder a JuiceFS a través de la puerta de enlace S3.

El segundo es el escenario donde se vinculan la plataforma de big data y la plataforma de IA. Por ejemplo, los colegas en la plataforma de IA a menudo necesitan leer datos de muestra, datos de características, etc. en su trabajo diario, y estos datos generalmente son generados por tareas de Spark o Flink en la plataforma de big data y se han almacenado en JuiceFS. . Para compartir datos entre diferentes plataformas, cuando se inicie el pod de la plataforma AI, JuiceFS se montará directamente en el pod a través de FUSE, para que los colegas en la plataforma AI puedan acceder directamente a los datos en JuiceFS a través de Jupyter. para hacer algunos modelos El entrenamiento, en lugar de copiar datos repetidamente entre diferentes plataformas como la arquitectura tradicional, mejora la eficiencia de la colaboración entre equipos.

Debido a que JuiceFS usa usuarios y grupos de usuarios estándar POSIX para el control de permisos, y el contenedor se inicia como el usuario raíz de forma predeterminada, lo que dificulta el control de permisos. Por lo tanto, hicimos una modificación a JuiceFS para montar el sistema de archivos a través de un token de autenticación, que contiene la información de conexión del motor de metadatos y otra información de control de permisos. En algunos escenarios en los que es necesario acceder a varios sistemas de archivos de JuiceFS al mismo tiempo, utilizamos la puerta de enlace de JuiceFS S3 combinada con políticas de IAM para la administración unificada de permisos.

Algunas dificultades encontradas al usar JuiceFS en la actualidad

El primer punto es que la función de administración de permisos basada en usuarios y grupos de usuarios es relativamente simple. En algunos escenarios, el contenedor comienza como usuario raíz de forma predeterminada y los permisos no son fáciles de controlar.

El segundo punto es sobre la optimización de la configuración de JuiceFS Hadoop SDK. En la actualidad, tenemos principalmente tres configuraciones para optimizar el SDK de Hadoop de JuiceFS: juicefs.prefetch, juicefs.max-uploadsy juicefs.memory-size. Se encontraron algunos problemas en el proceso de ajuste juicefs.memory-sizede la configuración . El valor predeterminado de esta configuración es 300 MB. La sugerencia oficial es establecer una memoria fuera del montón que sea 4 veces el tamaño del valor predeterminado, que es 1.2 GB. En la actualidad, la mayoría de nuestras tareas están configuradas con 2 GB de memoria fuera del montón, pero algunas tareas ocasionalmente no pueden escribir incluso si se configuran más de 2 GB de memoria (HDFS puede escribir de manera estable). Sin embargo, esto no es necesariamente un problema con JuiceFS, también puede ser causado por Spark o el almacenamiento de objetos. Por lo tanto, en la actualidad, también estamos planeando adaptar Spark y JuiceFS en profundidad, y luego descubrir las razones paso a paso, tratando de superar todos estos escollos y reducir la memoria al tiempo que garantizamos la estabilidad de la tarea.

El tercer punto es que a medida que la arquitectura general (JuiceFS + almacenamiento de objetos + Lustre) se vuelve más compleja, hay más posibles puntos de falla y la estabilidad de las tareas puede disminuir, lo que requiere otros mecanismos tolerantes a fallas para garantizar. Por ejemplo, durante la fase de escritura aleatoria de la tarea de Spark, se puede informar un error similar a "tarea perdida" y aún no se ha localizado la causa específica del error.

La combinación de arquitectura de JuiceFS + almacenamiento de objetos + Lustre mencionada anteriormente mejora el rendimiento de lectura y escritura hasta cierto punto, pero también hace que la arquitectura sea más compleja y, en consecuencia, aumenta algunos posibles puntos de falla. Por ejemplo, Lustre no tiene una fuerte capacidad de copia de recuperación ante desastres. Si Lustre de repente cuelga un nodo, ¿pueden las tareas en ejecución continuar leyendo y escribiendo datos en Lustre de manera estable, o los datos en Lustre se pierden accidentalmente? ¿Puede seguir siendo estable? Actualmente no está claro si ir a JuiceFS y volver a extraerlo a través del almacenamiento de objetos, y actualmente estamos realizando este tipo de prueba catastrófica.

futuro y perspectiva

Solución de lago de datos en tiempo real basada en Flink + Hudi + JuiceFS

Una de las cosas que haremos en un futuro cercano es la solución de lago de datos en tiempo real de Flink + Hudi + JuiceFS. El lado izquierdo de la figura anterior es la fuente de datos. A través de Flink, Kafka/Pulsar, los datos se escriben en Hudi en tiempo real. Al mismo tiempo, los datos de Hudi caerán en JuiceFS para reemplazar nuestros datos actuales en tiempo real. depósito.

Planificación a largo plazo de big data cloud native

Finalmente, me gustaría presentar el plan a largo plazo del nativo de nube de big data ideal para automóviles, que también es una perspectiva.

El primer punto es un sistema unificado de gestión y gobierno de datos. Creemos que en la era del lago de datos 2.0, el mayor problema que debe resolverse es resolver el problema del pantano de datos en el escenario del lago de datos 1.0. Pero ahora parece que no hay mejor producto de código abierto para la administración unificada de metadatos, la administración de directorios de datos y el control de seguridad de datos, similar a AWS Glue y AWS Lake Formation. Actualmente estamos trabajando en un proyecto de "sistema de origen". El primer paso de este sistema es administrar todos los metadatos en la base de datos anterior y el almacenamiento de objetos en una administración de directorio unificada, control de seguridad unificado y administración de datos unificada. camino a seguir

El segundo punto son las capacidades de almacenamiento subyacentes más rápidas, más estables y de menor costo. En la actualidad, la mayor dificultad en todos los escenarios es el almacenamiento de objetos. Las ventajas del almacenamiento de objetos son la estabilidad y el bajo costo. Al mismo tiempo, el almacenamiento de objetos itera constantemente. Por ahora, creo que si se va a desarrollar big data cloud native, el almacenamiento de objetos debe proporcionar un mejor rendimiento bajo la premisa de garantizar la estabilidad.

Al mismo tiempo, S3 puede afirmar que admite una consistencia fuerte, pero en este momento entiendo que el diseño de arquitectura basado en el almacenamiento de objetos puede ser difícil de lograr una consistencia fuerte, o para lograr una consistencia fuerte, está obligado a sacrificar algunas cosas. Esto puede ser una necesidad Una cuestión de equilibrio. JuiceFS admite de forma nativa una consistencia fuerte, que es muy compatible con las plataformas de big data.

El tercer punto es un motor de consultas más inteligente, eficiente y fácil de usar. Para extender el pensamiento sobre la integración de lagos y almacenes mencionado anteriormente, la integración de lagos y almacenes aún se encuentra en las primeras etapas de desarrollo, y puede llevar de 5 a 10 años de desarrollo. Databricks y Microsoft están tratando de construir un motor MPP vectorizado en el lago de datos, con la esperanza de promover la arquitectura integrada del lago y el almacén. Esta puede ser una dirección de desarrollo futuro, pero parece que no hay forma de usar un motor para satisfacer las necesidades de todos los escenarios en poco tiempo.

Nuestra arquitectura actual está básicamente equipada con todos los motores de consulta, como Spark, Flink, base de datos relacional (para escenarios OLTP), base de datos de series temporales y base de datos OLAP. En principio, es mejor usar el que sea mejor, y nuestra capa superior lo administrará a través de un middleware unificado. Otro ejemplo es Snowflake, que aunque ya admite la consulta de datos estructurados y semiestructurados al mismo tiempo, aún no está claro cómo admitir datos no estructurados (como imágenes, voz y video) involucrados en la inteligencia artificial en el futuro. claro. Sin embargo, creo que esta es definitivamente una dirección de desarrollo futuro. Li Auto también tiene un escenario de inteligencia artificial similar, por lo que exploraremos y construiremos junto con varias partes comerciales.

Finalmente, el objetivo final de todo el desarrollo de big data es completar el análisis de datos al menor costo y con el mayor rendimiento, para obtener un valor comercial real .

Si es de ayuda, preste atención a nuestro proyecto Juicedata/JuiceFS . (0ᴗ0✿)