Lili Auto es un fabricante chino de vehículos de nueva energía que diseña, desarrolla, fabrica y vende vehículos eléctricos inteligentes de lujo. Fue fundada en julio de 2015 y tiene su sede en Beijing. Su propia base de producción que se ha puesto en producción se encuentra en Changzhou, Jiangsu. ., para proporcionar productos y servicios seguros y convenientes para los usuarios domésticos.
Li Li Auto es pionera en la comercialización exitosa de vehículos eléctricos de rango extendido en China.El primer y actualmente el único modelo de vehículo eléctrico de rango extendido comercializado Li Li ONE es un SUV eléctrico de lujo mediano a grande de seis asientos (deportivo utilitario), equipado con un sistema de extensión de rango y soluciones avanzadas de automóviles inteligentes, comenzará la producción en masa en noviembre de 2019 y lanzará el ideal ONE 2021 el 25 de mayo de 2021. Al 31 de diciembre de 2021, Li Auto ha entregado 124.088 Li Li ONE.
antecedentes
De acuerdo con las regulaciones y normas nacionales pertinentes, los datos de señal de los componentes principales deben recopilarse y enviarse a la plataforma de datos de vehículos de nueva energía construida por el gobierno durante el proceso de conducción de los vehículos de nueva energía. Las fuentes de estos datos son componentes centrales como motores y baterías. Al mismo tiempo, las autoridades reguladoras también requieren que los fabricantes de automóviles almacenen estos datos para respaldar el mantenimiento posterior a la venta, las actualizaciones de OTA, la detección del estado de salud del vehículo, la alerta temprana y el mantenimiento. Para brindar un mejor servicio a los usuarios, Li Auto comenzó a construir su propia plataforma de datos.
Comprometidos con crear una casa móvil y convertirse en un automóvil ideal para la compañía de vehículos eléctricos inteligentes líder en el mundo, la escala de datos que se administrará es muy grande. En el artículo de hoy solo estamos hablando de los datos de la señal de sincronización de un automóvil ideal. En la arquitectura de la plataforma de datos automotrices, la cantidad total de datos de señales de series temporales se almacena en HDFS, y la pila de tecnología Hadoop también se usa para completar varias tareas informáticas y de análisis complejas de acuerdo con los requisitos comerciales.
En diciembre de 2021, Li Auto entregó 14.087 Li Li ONE, un aumento interanual del 130,0 % en diciembre de 2020. De enero a diciembre de 2021, Li Li ONE entregó un total de 90.491 unidades, un aumento interanual del 177,4 %. Desde la entrega, el volumen de entrega acumulado de Lili ONE ha alcanzado las 124.088 unidades. Es concebible que el crecimiento de los datos de vehículos gestionados por la plataforma de datos también sea extremadamente rápido, lo que impone requisitos muy altos en cuanto a la agilidad y elasticidad de la plataforma de datos.
Los conductores veteranos que juegan con big data saben que la expansión de HDFS requiere mucho tiempo y mano de obra y, a veces, incluso es difícil mantenerse al día con la tasa de crecimiento del negocio. Ante el rápido desarrollo de los negocios y el HDFS inflexible, los ingenieros que mantienen la plataforma de datos a veces tienen que eliminar datos no válidos y redundantes y equilibrar los datos de cada nodo de datos para aliviar la contradicción entre los altos requisitos de agilidad del negocio y la inflexibilidad. de HDFS. Además, debido a que Hadoop es un diseño de acoplamiento de almacenamiento y computación, aumentar el espacio de almacenamiento también requiere aumentar la computación y, a menudo, la combinación de almacenamiento y computación está fuera de lugar, y la expansión no coincidente también generará una gran cantidad de redundancia de potencia informática, lo que genera desperdicios innecesarios.
La mejora continua del desarrollo comercial también ha traído dulces problemas a la plataforma de datos. En 2020, la plataforma de datos comenzó a resolver la contradicción entre los rápidos cambios comerciales y la inflexibilidad de HDFS. Las escalas seleccionadas en ese momento fueron:
- Minimice la modificación de los procesos ETL existentes y la lógica de cálculo, en otras palabras, tenga una excelente compatibilidad con HDFS
- Excelente elasticidad
- Aceleración transparente sin cuellos de botella en el rendimiento
- La estabilidad está al menos alineada con HDFS
Al principio, probamos la solución de integración de SDK de Hadoop proporcionada por los proveedores de la nube. Sin embargo, debido a que solo se implementaron API de Hadoop limitadas y no había caché, la estabilidad y el rendimiento eran muy inferiores a los de HDFS. La solución a este problema se retrasó.
El comienzo de 2021 coincide con el código abierto de JuiceFS, y los colegas de la plataforma de datos se enteraron del servicio en la nube de JuiceFS. JuiceFS es totalmente compatible con la API de HDFS y tiene tanto flexibilidad como almacenamiento en caché . El juicio preliminar puede resolver los tres primeros problemas. en la escala de selección. Con la mentalidad de probarlo, lo probamos por primera vez. También me gustaría agradecer a los pequeños socios de JuiceFS por su gran ayuda. La edición comunitaria de JuiceFS se lanzó con éxito en el automóvil ideal, que resolvió el problema de la escasez de capacidad de HDFS y también realizó la actualización de la arquitectura de la separación del almacenamiento de Hadoop y computación Lo más importante es satisfacer las necesidades del negocio Requerimientos de agilidad.
Presentamos JuiceFS
JuiceFS es un sistema de archivos distribuido de código abierto de alto rendimiento diseñado para el entorno de la nube. Es totalmente compatible con las interfaces POSIX, HDFS y S3. Es adecuado para escenarios como big data, entrenamiento de modelos de IA, almacenamiento compartido de Kubernetes, DevOps, y archivo masivo de datos. Al usar JuiceFS para almacenar datos, los datos en sí se mantendrán en el almacenamiento de objetos (como Amazon S3), y los metadatos correspondientes al sistema de archivos se pueden almacenar en Redis, MySQL, TiKV y otros motores de bases de datos. Al mismo tiempo, el cliente de JuiceFS tiene capacidad de almacenamiento en caché para proporcionar aceleración de E/S inteligente para aplicaciones de capa superior.
Escenarios de aplicación
Después de medio año de uso e iteración, JuiceFS se ha utilizado en múltiples escenarios comerciales de Ideal Car. Los siguientes son algunos escenarios comerciales típicos, que espero sean útiles para los usuarios de la comunidad de JuiceFS, y le invitamos a presentar sus ideas y preguntas.
JuiceFS es compatible con el almacenamiento de almacenamiento de datos central
Escenas
Actualmente, se agregan 2 TB de datos nuevos todos los días en escenarios de análisis de datos de vehículos. Los datos se leen y escriben directamente en JuiceFS a través de Spark para el procesamiento ETL. Debido a que JuiceFS es totalmente compatible con la API de HDFS, solo necesita especificar la ruta de la tabla al directorio de JuiceFS. El cambio es insensible.
ingreso
Después de cambiar a JuiceFS, el espacio de almacenamiento ha cambiado del disco limitado de HDFS al almacenamiento de objetos con capacidad ilimitada. Al mismo tiempo, también se realiza la separación del almacenamiento y la computación del clúster de Hadoop. Ahora el almacenamiento se puede escalar elásticamente usando JuiceFS y el clúster de computación también pueden ser independientes de acuerdo con el volumen de negocios Expansión y contracción . De esta forma, la plataforma de datos puede soportar el crecimiento del negocio y demandar cambios de forma más ágil.
plan de mejora
Cuando la empresa entró en línea en la primera mitad del año, JuiceFS usó Redis alojado en la nube pública para almacenar metadatos. Debido a que se requiere la API de transacción de Redis, el modo de clúster de Redis no se puede usar, por lo que el cuello de botella de expansión de capacidad de una sola instancia de Redis genera un límite en la cantidad de archivos en un solo sistema de archivos de JuiceFS, y todas las tablas no se han migrado a JuiceFS por el momento. Ahora que JuiceFS es compatible con TiKV para almacenar metadatos, estamos listos para probar y migrar todos los datos a JuiceFS y usar el disco físico local gratuito como un disco de caché.
Use JuiceFS para admitir el almacenamiento jerárquico MatrixDB de la base de datos de series temporales
Escenas
En el clúster de MaxtrixDB ideal para automóviles, incluso después de la compresión, todavía hay casi 500 G de datos incrementales cada día.Este tipo de datos de series temporales es muy sensible al tiempo, y cuanto más tiempo, menos frecuente es necesario verlos. La paradoja es que incluso los datos históricos tienen requisitos de consulta de baja frecuencia y los datos históricos no se pueden eliminar; sin embargo, MaxtrixDB usa almacenamiento local en su diseño de arquitectura y no puede expandirse o reducirse de manera flexible. Después de ver la práctica de almacenamiento en niveles de datos de JuiceFS en ClickHouse , se lo recomendamos al equipo de MatrixDB, y pronto MaxtrixDB admitió el mecanismo de almacenamiento jerárquico automático, que realizó con éxito la transferencia automática de datos tibios y fríos de discos locales a JuiceFS para cumplir con los requisitos de consulta.
ingreso
El costo de almacenamiento se reduce en casi un 50% cuando el usuario básicamente desconoce el uso . Use JuiceFS para implementar el almacenamiento de datos en niveles de la base de datos de series temporales MatrixDB. Los datos calientes se escriben en el SSD local y se transfieren automáticamente a JuiceFS a través de la política de ciclo de vida. Todo el proceso solo requiere una configuración simple, automática y transparente, sin necesidad de expansión manual frecuente y puede ahorrar en gran medida los costos de almacenamiento. La capacidad SSD de repuesto se puede utilizar para la aceleración de caché de datos tibios y fríos, y el uso ocasional de la aceleración de caché también puede mantener un buen rendimiento.
Intercambio de datos multiplataforma
Escenas
La plataforma de datos es la pila de tecnología de Hadoop, y la plataforma de algoritmos utiliza Kubernetes para la gestión de recursos. Las dos plataformas tienen relaciones ascendentes y descendentes en muchas empresas. La plataforma de datos es responsable de preparar los datos y luego enviarlos a la plataforma de algoritmos para completar la entrenamiento del modelo algorítmico. La forma en que resolvemos el intercambio de datos es que la plataforma de datos escribe los datos directamente en la tabla de Hive, y la capa inferior de la tabla de Hive usa el almacenamiento de JuiceFS. Cuando la plataforma del algoritmo inicia el Pod, monta automáticamente el mismo sistema de archivos de JuiceFS en modo POSIX. La aplicación en el Pod puede leer los datos de características como si accediera al directorio local. El resultado entrenado también se escribe en JuiceFS en modo POSIX. Plataforma los estudiantes también pueden usar fácilmente los resultados proporcionados por los estudiantes de algoritmos.
ingreso
Los flujos de trabajo de datos son cada vez más largos y complejos, y las tareas de trabajo deben completarse en colaboración en diferentes plataformas y equipos. En el pasado, los datos siempre se movían hacia y desde diferentes sistemas de almacenamiento. El tiempo para copiar, el tiempo para verificar la corrección, estos trabajos repetidos y de espera afectan en gran medida la eficiencia. Ahora JuiceFS, como un lago de datos unificado, puede compartir varios tipos de datos en diferentes plataformas y aplicaciones sin esperar, y la eficiencia es mucho mejorado _
plan de mejora
Actualmente, la plataforma de datos utiliza un enfoque multiusuario para las operaciones de ETL de datos. El Pod extraído por la plataforma de algoritmos es el usuario raíz de forma predeterminada. Después de que el colega del algoritmo vuelva a escribir los datos de resultados en JuiceFS, solo el usuario raíz tiene el permiso de escritura, y el componente Hive de la plataforma de datos no podrá agregar un nuevo partición porque no hay permiso de escritura al agregar una partición. Recientemente, la comunidad tiene una nueva solución, que consiste en agregar el usuario del componente Hive al supergrupo de Hadoop, para que el usuario tenga el mismo permiso de escritura que el usuario raíz. Probaremos esta solución junto con la plataforma de algoritmos después de que se publique la nueva versión en un futuro próximo.
Archivos compartidos de la plataforma
Escenas
En el pasado, toda la plataforma de datos usaba HDFS para compartir archivos. La aplicación de front-end de la plataforma carga datos directamente a HDFS a través de la interfaz de servicio de back-end. Por un lado, existen riesgos de seguridad, por otro lado, habrá fallas en la descarga de archivos grandes de HDFS durante la ejecución intensiva de tareas en la madrugada, lo que afecta la estabilidad de las tareas. En la actualidad, el uso compartido de archivos de la plataforma de desarrollo en tiempo real se ha cambiado al método POSIX de JuiceFS para brindar soporte para compartir archivos. En el futuro, está previsto integrar todas las plataformas que necesitan compartir archivos con JuiceFS para una gestión unificada.
ingreso
El acceso POSIX puede hacer que el desarrollo de aplicaciones sea más fácil y eficiente . Al mismo tiempo, JuiceFS también proporciona un rendimiento más estable que el pico de HDFS.
panorama
Después de casi un año de uso, hemos estado siguiendo la iteración de la comunidad de JuiceFS y tenemos una mejor comprensión de JuiceFS. Podemos recibir comentarios de la comunidad de manera oportuna cuando encontramos problemas, y el problema se resuelve muy rápidamente. Gracias a los grandes esfuerzos de nuestros socios de la comunidad. Soporte, hemos estado actualizando continuamente con el lanzamiento de la comunidad (la actualización de JuiceFS es muy simple). En el plan de trabajo para el próximo año, por un lado, se seguirá ampliando y profundizando el panorama, y tenemos previsto comprobarlo y potenciarlo en la gran cantidad de escenarios de recuperación de imágenes para la conducción autónoma de la compañía. Por otro lado, también comenzamos a desarrollar JuiceFS y, después de la verificación, discutiremos con la comunidad y lo retroalimentaremos al código original.
En primer lugar, el objetivo en 2022 es debilitarse hasta que se elimine HDFS, y el almacenamiento de objetos se utilizará como almacenamiento subyacente para todo el lago de datos más adelante. Y espero abrir el intercambio de datos a nivel de lago de datos y almacén de datos. Dado que el almacenamiento de objetos requiere sobrecarga de la red, tiene una buena escalabilidad y pierde algo de eficiencia. JuiceFS proporciona caché local para mejorar el rendimiento. El equipo de almacenamiento ideal para automóviles se está preparando actualmente para desarrollar funciones para aumentar la tasa de aciertos de caché, como las lecturas P2P locales.
En segundo lugar, toda nuestra plataforma se ejecuta en un entorno de múltiples inquilinos, y JuiceFS actualmente está diseñado para un solo sistema de archivos y no tiene capacidades de múltiples inquilinos. También nos estamos preparando para desarrollar una herramienta de administración similar a Apache Ranger, que brinda administración centralizada de políticas de seguridad y monitoreo del acceso de los usuarios para administrar la seguridad de los datos en JuiceFS.
En tercer lugar, JuiceFS actualmente necesita transferir metainformación directamente cuando se usa la experiencia de montaje POSIX. Por otro lado, los detalles de implementación del clúster se pueden aislar para facilitar el mantenimiento del equipo de la plataforma.
Cuarto, el escenario del lago de datos planea usar TiKV para el almacenamiento de metadatos, pero en escenarios individuales, TiKV no es tan rápido como Redis. Por lo tanto, considere que algunos escenarios que requieren un alto rendimiento de metadatos pero controlan la cantidad de datos continúan usando Redis. De esta manera, existe la necesidad de mantener varios conjuntos de JuiceFS. Es como si cada JuiceFS fuera un directorio. Lo que ve el usuario es lo mismo que un sistema de archivos. ViewFS similar a Hadoop con múltiples NameNodes.
¡Bienvenido a nuestro proyecto Juicedata/JuiceFS ! (0ᴗ0✿)